SFNUL

[Nexus]

Any way to programatically find out all your interface addresses would be very platform specific and have to be implemented on each platform you want to support.

It may be that this is one of the problems that everybody has to solve again in C++, but for example in Java such functionality is part of the standard library. One could also have a look at how they do it.

[binary1248]

As usual, it is not a question of whether it can be done, but who would actually use it. We all know that Java likes to overestimate/over-engineer the feature set of its library, resulting in 98% of it never being used. We really shouldn't consider it as an example of what should be available in C/C++ . The languages have completely different philosophies, and I prefer C++'s one more.

If you look at most of the daemons running on Unix systems (where C/C++ and the Berkeley socket API originated), you will notice that they don't try to detect your interfaces and offer you a choice of which addresses to listen/bind to. This is the task of other user-space tools that serve that specific purpose. Most of the time, you would have to configure which addresses you want to listen on (completely disregarding what interface they correspond to). The reason why there isn't an API to iterate over all the interfaces is probably because nobody would end up using it.

Instead of asking how to iterate over all interfaces, one should just take a step back and first ask what one wants to achieve by doing so. I really can't think of any use case where it would make sense.

[Xotraz]

I am concerned with performance (maybe too much).

What I imagined for my 2D online card game was that a player need an image and an interface. So I used little packets to control Animation (ID of animation, name of animation, number of times to play, position). (and another packet class for sounds)

I think this could handle all kinds of game. But in SFML books or this library people seem to "serialize" the world and send it.
Am I missing something that make your way much better ?

PS : I am a big fan of your works thought. 

[binary1248]

In SFNUL you get serialization for free. I guess you could say that objects are "self-serializing". Of course you will have to use the proper types as shown in the examples because you can't change the behaviour of any built-in type or STL containers. The SFNUL types were designed to mimic/proxy the built-in types as well as STL containers, so the conversion from "standard" objects to SFNUL objects should be really simple in most scenarios.