Using namespaces - your thoughts?

I try to use namespaces, but VC++ makes it very difficult. When using something from a namespace, I use
using namespace::classname;

unless I''m using many things from the same namespace, then I''ll use the standard

using namespace namespace_name;

I like using namespaces because you don''t have to worry about how you name your variables, classes, and functions (that is, you don''t have to resort to some odd naming scheme like MyLib_MyFunction () ), you can name them something logical and use the namespace to reference them explicitly.

I tend not to use them, I think theres little point. My theory is that if theres a clash between names, the names don''t describe the object well enough.

quote:

---

Original post by Evil Bill
I tend not to use them, I think theres little point. My theory is that if theres a clash between names, the names don''t describe the object well enough.

---

Here is an exception to your theory. I wanted to use Nehe basecode AND my application framework, and both of them had a "Application" entity (structure for Nehe basecode, class for mine) thus a conflict arose. After putting my lib into a namespace, no more problem.




----
David Sporn AKA Sporniket

If it were me, i''d name my actual Application: CApplication, and if i had a choice, the NeHe one SApplication, or maybe SAppVars or something.

But true, if you''re wanting to produce a library or something, its probably a good idea to use a namespace, just to be sure that nothing clashes. All it takes is an extra using namespace std; in the app.

2p

Namespaces are a very good thing in my opinion. All the modules in my apps are placed in their own namespace, and called with namespace::function()

quote:

---

Original post by Evil Bill
I tend not to use them, I think theres little point. My theory is that if theres a clash between names, the names don''t describe the object well enough.

---

Well, most of my modules have setup, and shutdown functions. I''d hate to have to think of 10 different names for Setup, when I can just use video::Setup(), audio::Setup() and so on, sure I could use the C version which would just be something like vid_Setup(), snd_Setup() etc, but I think namespaces can be neater, and (although not a major reason), it''s useful to have the IDE give me a list of callable video functions when I type in "video::" (especially useful if I haven''t worked on something for a while, and I''ve forgotten what I''d called something).

John B

quote:

---

Original post by Evil Bill
If it were me, i''d name my actual Application: CApplication, and if i had a choice, the NeHe one SApplication, or maybe SAppVars or something.

---

Why?!

The type system that the compiler enforces knows they''re classes.
Your IDE knows they''re classes.

Why taint your code with such shit?

Yes, I use namespaces.

When using namespaced code, I use using namespace statements inside functions.

I can certainly appreciate the point in them, its just i''ve never had a need for them.

DrPizza: Because i find it makes my code more readable. How am i to know, looking back on my code, that Application is a class, and not a typedef? It least if i prefix it with a ''C'', i can think "ah, thats my Application class".

When i use the standard library, i tend to ''cheat'' and just do:

#include <vector>
usign namespace std;

I know it defies the point in the standard library being in a namespace, but i find it neatens up my code.

quote:

---

Original post by Evil Bill
Because i find it makes my code more readable. How am i to know, looking back on my code, that Application is a class, and not a typedef?

---

What would you do with that knowledge?

EvilBill, I suggest you try working on projects with several hundred thousands of lines of code.

Namespaces are good, imo.

Then again, it would be exactly like adding a prefix to your variable names in C..

namespace poop
{
int x;
}

// same effect as

int poop_x;

except namespaces let you use "using namespace poop;"

SabreMan: Erm... good point
flangazor: To be honest, i haven't worked on any big projects, so you're right, i probably don't appreciate the use of namespaces properly. Ok, i'll rephrase what i was saying: for small to medium sized projects, i find namespaces aren't nessecarry.

My 2p



[edited by - Evil Bill on November 29, 2002 1:47:07 PM]

That is not cheating. Picture a company like Microsoft. A individual team is part of a heirarchy at least four or five levels high. So say there are groups, divisions, departments, applications and teams. So you assign each group a unique namespace. Within each group you assign each division a unique namespace and so on down to the individual team. How long is the fully qualified name going to be? Most likely at least 50 to 100 characters for semi-descriptive names. Who seriously would require their programmers to type 50 to 100 characters everytime they use a structure, class, union or enum. Most often there is no conflict. Using namespaces on the chance of a conflict is prudent, but using fully qualified names for the same reason is a foolish waste of your programmers time. Rather you just want the ability to resolve the conflict should one arrise.

The alternative to namespaces is a big battle between two groups when one of them has to use the other ones code in an unanticipated manner. You change your 1,000 source files using that name. No the name is rightfully ours, you change yours. Not going to happen. Instead whoever you assign is going to duplicate your files and change the names. Now you have two copies of the same file and all changes have to be made to both. Now multiply that by a few hundred or a few thousand over the course of several years and you have a nightmare. It is a lot better if they just qualify name in the new file they are creating.

But then the namespaces wouldn''t describe a team, they''d describe related parts of code. So several teams would work on in same namespace, producing code to d othe same thing.

quote:

---

Original post by LilBudyWizer
That is not cheating. Picture a company like Microsoft. A individual team is part of a heirarchy at least four or five levels high. So say there are groups, divisions, departments, applications and teams. So you assign each group a unique namespace. Within each group you assign each division a unique namespace and so on down to the individual team. How long is the fully qualified name going to be?

---

How stupid was the project coordinator, or whoever came up with such a dumb naming scheme?

Namespaces should reflect either functionality or collections, not arbitrary organizational hierarchies (what happens if you move one team from one division to another? this is as dumb as Hungarian notation or pther name wart schemes today).

If you''ve ever used Perl, you''ve seen use of namespaces (packages) without any confusion or detrimental effect. I''m convinced that people who malign namespaces don''t understand them, since they don''t affect code functionality in any way whatsoever.

quote:

---

...Rather you just want the ability to resolve the conflict should one arrise.

---

No, you want a mechanism to minimize the occurence of conflicts.

quote:

---

Original post by Evil Bill
If it were me, i''d name my actual Application: CApplication, and if i had a choice, the NeHe one SApplication, or maybe SAppVars or something.

---

Often, you don''t have a choice. Even worse, often you can''t predict choices.

quote:

---

But true, if you''re wanting to produce a library or something, its probably a good idea to use a namespace, just to be sure that nothing clashes. All it takes is an extra using namespace std; in the app.

---

The use of namespaces is slightly more involved than a simple "using namespace std;"; the fact that you don''t recognize this bothers me about your competence to comment on this issue. No offense.

quote:

---

Original post by JohnBSmall
Well, most of my modules have setup, and shutdown functions. I''d hate to have to think of 10 different names for Setup, when I can just use video::Setup(), audio::Setup() and so on...

---

"video", "audio" and so on are fairly common identifiers in multimedia programming; they make bad choices for namespace identifiers. I had an Audio class in my last library, but I put it within the Obsidian namespace (Obsidian is derived from my initials, and was the library internal identifier). I would need to exit to the global (unnamed) namespace before I could use your classes in a scope where my namespace had been introduced - code inconsequential, but inelegant and inconvenient.

quote:

---

Original post by LilBudyWizer
How long is the fully qualified name going to be? Most likely at least 50 to 100 characters for semi-descriptive names. Who seriously would require their programmers to type 50 to 100 characters everytime they use a structure, class, union or enum.

---

Namespace aliasing :

namespace FooGroup
{
	namespace FooModule
	{
		namespace FooStuff
		{
			typedef int Foo;
		}
	}
}

namespace Bar
{
	namespace FooStuff = ::FooGroup::FooModule::FooStuff;

	FooStuff::Foo x;
}
 

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

You may not like it, but calling it stupid goes a bit to far. Just from a practical perspective it helps when you have thousands of programmers and millions of lines of code. Realistically everything above the app name makes no differance because the app name is unique. You never have to qualify past that. It doesn''t create any burden because all they have to do is tell the editor to insert their teams code template.

You could put the information into the block comment at the top. That is unreliable though when you are scanning the source. You are just cateloging the source. Most people are not going to realize they could type whatever they want for most of it and it wouldn''t cause a problem. At least in the compile. When they make mistakes though you are going to have the manager tell them to change it. Your source distribution system won''t let it go through because as far as it is concerned you don''t own it because it has code for a namespace you don''t own. The actual source file name is what matters, but you want to enforce the standard.

Now that you have the namespaces insured to be right to some level you can watch what they are doing. What namespaces have they added since last week. What namespaces are being updated the most often. You have to impose restriction on how they organize source to track that otherwise. Track some of this information over the long haul and your job as a technical architect/software engineer gets a whole lot easier. When you walk in to a meeting the notion you are dip with no clue about their system goes out the door real fast as you start explaining things they are doing that they don''t even know they are doing. That is your biggest challenge. Win their respect, request them to do things that makes life easier for themselves and you can accomplish all kinds of wonderful things. Walkin without a clue and you won''t accomplish jack other than listening to them say "screw you" in more polite terms.

Admittedly much of it has nothing to do with what namespaces are for. That does not make it stupid though.

I write the full identifier usually, unless I use something a lot


Namespace aliasing can be handy too, but I haven''t had need for it yet.

quote:

---

Original post by Oluseyi
"video", "audio" and so on are fairly common identifiers in multimedia programming; they make bad choices for namespace identifiers. I had an Audio class in my last library, but I put it within the Obsidian namespace (Obsidian is derived from my initials, and was the library internal identifier). I would need to exit to the global (unnamed) namespace before I could use your classes in a scope where my namespace had been introduced - code inconsequential, but inelegant and inconvenient.

---

Well, that''s a pity, but it doesn''t really affect me. I''m working on my own, if I ever get into a group I''ll have to think about how to organise/name things better, but until then it doesn''t bother me.
I''d have probably have to change my coding style quite a lot to fit into a group anyway, since I don''t use classes anywhere near as much as everyone else seems to.

John B