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 ;)
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? Who cares? And don't answer "it's slow" if you haven't tested it seriously
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.
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.Yep, I could do that. But the current solution is simpler and safer.