"Giovanni P. Deretta" <lordshoo@gmail.com> writes:
I've have seen that the current consens is to encode the the stream type in the address, so to allow a dynamic behaviour: the actual transport is selected only at runtime, based on the address string.
Yeah, a similar unfortunate line of thinking seems to prevail in the discussion of Unicode libraries.
I think this is a bad decision (i considered doing it while implementing my library) and this is why:
- C++ is a static language, let's leave these niceties to more dynamic languages. I have found myself weeks hunting a bug in the http code because i thought that it would be cool if i could access http properties using a map instead of proper accessor functions. I spent weeks hunting persistent connection bug. It was a simple typo inside a http property string that would have been caught immediately by the compiler if i were using functions or costants [1].
Right. If you need to do dynamic polymorphism, add a layer of type erasure in a separate component. I think that's what you meant by "external polymorphism," but that's not a great term because it doesn't distinguish the static from the dynamic.
- It mimics standard library usage. You cannot open the input stream instead of a file by using the "input:" file name. (well under Unix you might actually do it, but i don't think this was the intention of the standard library authors and it is not portable any way).
- It is extremely insecure. In a network library security must be paramount. If the transport type were encoded in the address, it would be much harder to validate externally received addresses. A similar argument can be made for the port numbers. It is better to keep these things separated. The library user can create its own indexed factory collection if it really needs to.
That's a very convincing argument. I don't know much about networking, but from what I've heard here I like your design instincts very much. I'll try to look at your docs. Is this in the same design space as a "sockets library?" -- Dave Abrahams Boost Consulting www.boost-consulting.com