|
Boost : |
From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-26 10:46:26
From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> I would agree with you if in the end there were really just *two*
> namespaces. Unfortunately, in my experience, this won't be the case; at
> least not in the numerical applications I'm used to work with.
> That is, in general -an according to my views- a numerical application
> doesn't use *one* library, but a set of libraries, either layered or
> independent. Following the separate namespace approach will lead to a set of
> numerical constants spread along a set of namespaces, probably many.
If your using several different numerical packages, it's probably because they all do different things. It would seem that keeping each in its own namespace helps clarify in the client code what is going on. But perhaps you're coming from a situation where a common namespace is desirable because there is overlap in what the packages do. In this case, though, I would expect the commonality to trigger a high risk of name collisions. And if two packages conflict with each other, you're generally out of luck, since you can't or don't want to be mucking with prepackaged code.
If you're envisioning some scenario where it would be helpful to merge namespaces of disparate packages, without problems due to package names conflicting, maybe a concrete example would help.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk