Archived

This topic is now archived and is closed to further replies.

Package prefixes vs. (nested) namespaces

This topic is 5533 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How to organize packages This is a question concerning physical design, not logical design. Those of you who have read Lakos'' Large-Scale C++ Software Design or similar books should know what I''m talking about. I agree with Lakos on almost every major and minor design rule he states in his book - and I really do see the necessity to come up with some distinct method to identify members of certain packages - but I can''t get myself to use unique package prefixes. It''s not a problem at all when defining entities (read: classes) but when using them in code, it becomes rather tedious (i.e. using geom_Point, geom_Vector3, math_Matrix44). Additionally, it''s sometimes difficult to come up with suitable and nonetheless cohesive package prefixes. How to call a generic rendering package including a component RenderDevice? render might be an obvious choice but how does the class name render_RenderDevice look like? Calling it gfx might fix that problem (gfx_RenderDevice looks okay) but does it really describe that package''s functionality? gfx is too broad a term for a package that simple provides an interface and parts of the implementation of a graphics renderer. The other method to avoid name collisions might be nested namespaces, e.g. a render namespace inside the main team/company namespace. Using render::RenderDevice in the headers looks better to me than the above solution. In source files, using declarations might be used to avoid the constant prefix and that would break with the physical cohesion. But on the other hand, there won''t be more than one programmer working with that source file and he should know what he''s doing. What do you think about this issue? I hope that I made my question understandable. I''m just looking for a way to organize packages (i.e. collections of source files) so that there is a constant identification (naming) scheme for components.

Share this post


Link to post
Share on other sites
The first edition of the book pre-dates standard C++, and if I recall corectly, namespaces were a late addtion.

Using prefixes makes backwards compatiblity to (namespace-less) C easier, and allows the code to be ported to platforms where the C++ compiler is just C with classes.

Those issues not-with-standing, use nested namespaces.

Share this post


Link to post
Share on other sites
Lakos'' book predates namespaces. In it, he suggests using classes to simulate namespaces. I myself prefer to use namespaces. Using declarations may be used in those situations where it''s "obvious" thus reducing typing. The one issue that namnespaces brings up, though, is Koenig lookup. That''s sometimes mishandled by compilers. Do a search if you''re not sure what Koenig lookup is.

Share this post


Link to post
Share on other sites
Well, the edition of the book I have (1996 I think) mentiones namespaces in the context of registered package prefixes. It states that both namespaces and registered prefixes can be used in similar ways to avoid name conflicts among classes developed within a single company. Neither, however, can serve as a complete substitute for the other.

He then suggests putting everything into a global company namespace (thereby avoiding name collisions between several companies) but nonetheless using package prefixes to decorate identifiers of each package within the namespace.

He states that completely replacing package prefixes with package namespaces is ill advised. (...) By identifying a component or class as belonging to a particular package, you immediately provide a context that aids in understanding its broader purpose. In time, the package prefix will be the first thing to catch your eye when reading application code that depends on components from multiple packages. In addition to its semantic cohesion, a package is also a physical unit. An important function of a package is to identify where in the file system the definition of a given class or component can be found. Package prefixes also make searching for "use" of a particular package much easier. (...) A package, like a component, represents a cohesive unit. As with component-level design, the logical and physical design of a package are tightly interleaved. It is important when discussing packages and, in particular, their physical interdependencies, that the logical and physical properties of each package coincide. (...) The purpose of a prefix is to provide a hierarchical identification for the physical location of a component or global logical construct.

I can understand his arguments, but maybe, for large systems (as opposed to very large systems), identifying packages through namespaces might be just fine. That''s like Loki or boost handle packages.

Bobo: I think koenig lookup is basically the same than argument-dependent name lookup (looking up functions in foreign namespaces by argument). Can you tell me which compilers have problems handling this lookup algorithm?

Share this post


Link to post
Share on other sites
Hmm... interesting. My version of Lakos doesn''t mention namespaces at all, unless I''m misremembering. It uses a trick to simulate namespaces by putting definitions inside of a struct. From what you''ve copied, is Lakos merely against using declarations, not namespaces as such? In the projects of the size he talks about, I can understand his worry.

MSVC, at least pre-7.0, doesn''t handle name-dependent lookup properly. As of a couple of years ago, it was a fairly common failing of a number of compilers. I can''t say which handle it properly and which don''t, though. I''ll bet that there''s people on comp.lang.c++.moderated who know, though.

Share this post


Link to post
Share on other sites