From: David Abrahams (dave_at_[hidden])
Date: 2005-04-24 07:08:40
"Giovanni P. Deretta" <lordshoo_at_[hidden]> 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 .
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk