sfIpAddress size

[Jeanne-Kamikaze]

sfIpAddress represents an IPV4 address according to the documentation, yet it is 16 bytes long (at least on x86):

typedef struct
{
    char address[16];
} sfIpAddress;

On the other hand, an IpAddress is 4 bytes:

class SFML_NETWORK_API IpAddress
{
    ...
private :

    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    Uint32 m_address; ///< Address stored as an unsigned 32 bits integer
}

Shouldn't sfIpAddress be 4 bytes as well, or am I missing something ?

[Laurent]

I don't remember why, but there must be a good reason.

Is it really important anyway?

[Jeanne-Kamikaze]

Maybe you were thinking IPV6. And no, it's not really important, unless the C code accesses a byte other than the first 4 of course. It also looks confusing in my opinion.

[Laurent]

You misunderstand what is stored in sfIpAddress. It's not the 32-bits representation of the address, it's its string form ("xxx.xxx.xxx.xxx" -> 16 characters with the ending \0).

Now I remember why I did it this way: when you call sfIpAddress_toString() I can return a direct pointer to this member. Otherwise I would have to allocate a memory area, and let the caller manage its lifetime. Would be very inconvenient.

[Jeanne-Kamikaze]

Ah! Good to know then. Maybe state that in the docs ?

[Jeanne-Kamikaze]

But wait, so every time I use stuff like sfUdpSocket_send it's gonna parse the string address into a dword ?

Edit: This is indeed the case. Why not cache the dword in sfIpAddress then to avoid having to reparse the string on every call ?

[Laurent]

Maybe state that in the docs ?

You don't need to do that, although it's public, you should never access it directly. The only API that you should know is the set of sfIpAddress_xxx functions.

Why not cache the dword in sfIpAddress then to avoid having to reparse the string on every call ?

Why? Who cares? And don't answer "it's slow" if you haven't tested it seriously

[Jeanne-Kamikaze]

You don't need to do that, although it's public, you should never access it directly. The only API that you should know is the set of sfIpAddress_xxx functions.

True. I'm reimplemeting some of the functions however. For instance, I don't really have to call C to initialise an address to 0. And yes, I can afford the maintenance.

Why? Who cares? And don't answer "it's slow" if you haven't tested it seriously

I personally don't care, but it's a multimedia library. Real-time systems will be built on it, and as a library provider you should ensure that what you ship runs half decent. It would suck to profile my application only to find out that the bottleneck is in the underlying API, and not because I'm making a bad use of it but simply because it is inherently slow. And no, there aren't any alternatives; SFML is the multimedia library.

[Laurent]

Real-time systems will be built on it, and as a library provider you should ensure that what you ship runs half decent. It would suck to profile my application only to find out that the bottleneck is in the underlying API, and not because I'm making a bad use of it but simply because it is inherently slow.

True. And I'll be glad to change this if someones proves me that it's too slow. But to be honest, I have almost no time to work on SFML itself, and CSFML is only a way to enable other bindings, so its improvement is very low on my task list.

[Jeanne-Kamikaze]

When you said

Now I remember why I did it this way: when you call sfIpAddress_toString() I can return a direct pointer to this member. Otherwise I would have to allocate a memory area, and let the caller manage its lifetime. Would be very inconvenient.

Why ? Can't you make a function that takes a char* and writes the string in there ? No need to allocate anything on the library side.

It's not SFML that needs changing, just CSFML. If you don't have time then I could do it.

[Laurent]

Why ? Can't you make a function that takes a char* and writes the string in there ? No need to allocate anything on the library side.

Yep, I could do that. But the current solution is simpler and safer.

[Jeanne-Kamikaze]

Oh well, I forked the project and made the changes there. Took me just 2 minutes . I'm liking your fromSFMLAddress and toSFMLAddress helpers.