should one use 'using namespace std' or not ?

Great start :) Some good points are made. Some more thoughts based on them :


First, the example code I gave is not something I came up with - it's something I found in existing code while tracking down a bug (which turned out to be caused by this). I agree that the name of the function could have been chosen better, but the point of the example is that the person that wrote the code expected his own min function to be called, but that wasn't the case.


Then, even though I agree that you can write 100% correct code while adding 'using namespace std;', you're usually not the only one working on the code. And not everybody might be as familiar as you with the std namespace. (the 'you' is generic here, and doesn't refer to anybody in particular). More specifically :

(a) you have to know all symbols in the std namespace to make sure that none of them clash with your own symbols
(b) you have to be sure that symbols that might be added to the std namespace in the future (C++0x is coming up soon) won't clash with any of your own symbols

An experienced C++ developer will know the large majority of all symbols currently in the std namespace (ie. the ones from (a) above), but most likely not all of them. However, he will never be sure about the symbols from (b).

In short, making sure the addition of 'using namespace std;' doesn't cause any problems requires a lot more effort than it would have taken to simply specify std:: explicitly. Especially, if at some point in the future, you'll be required to 'port' your code to a more recent version of C++, because you'll need to go over the entire code to make sure that there are no symbol clashes.


The readability argument is a good one of course, although I don't necessarily agree that adding std:: makes things less readable. More verbose, yes, but proper formatting can make up for that ;)

I am using C++ for about 17 years and only for the last few years some of my projects make use of namespaces at all. When using older libraries I generally have no problems regarding namespace std cause my classes begin with a capital letter. I rarely used global functions and never used names like 'string' or 'list' as variable names, so I can't remember one single naming conflict though it may have occured the one or the other with the years.  

Personally, I didn't use the std:: prefix when I started to using (learning) STL (about in 2002). Then in 2004/2005 I had a phase here in EE where I used std:: in every sample code same as Infinity does. I ended that phase after an asker complaint about readibility of some sample code. It was somewhat like
 
    std::map<std::string, std::pair<FuncPtr, std::vector<std::vector<AnyClass> > > >::iterator it;

You may say that

    map<string, pair<FuncPtr, vector<vector<AnyClass> > > >::iterator it;

wasn't so much better or that a typedef could have helped out. But for sample code you hardly make typedefs and the sample code had about 50 lines where nearly each has a few std::  prefixes. Those prefixes made the code uglier than it had to be, and the complaint made clear for me that the main goal when adding sample code in a comment was to explain a concept and not to provide full code which could be copied and would compile in any environment. If both could be achieved with a code sample it is fine but if not the first goal is more important than the second (especially as namespace errors hardly compile and conflicts with namespace std generally are less likely with newer C++ code. So I never heard of a commercial third party library which conflicts with STL). That thread was the initial trigger for me to further omit the std:: here in EE beside of header file samples and I am deeply convinced that it was a good decision as many askers were newbies who might get scared from those kind of coding.

>>>> But, of course this is just a opinion/habit.
Same applies for me.

In the initial thread for that discussion I used the following sample code

     ostringstream oss;
     oss << right << setw(3) << (int)c
           << "  0x" << right << setw(2) << setfill('0') << hex << (unsigned int)c;
     cout << oss.str() << endl;

It would have been

     std::ostringstream oss;
     oss << std::right << std::setw(3) << (int)c
           << "  0x" << std::right << std::setw(2) << std::setfill('0') << std::hex << (unsigned int)c;
     std::cout << oss.str() << std::endl;

where probably everyone could see that the std:: prefixes take too much room and don't add anything to the message I wanted to tell with those statements.

For the record : we're not discussing how to post on EE (that's a matter of taste). We're discussing how to write actual code (for a real world project).

>>>> we're not discussing how to post on EE (that's a matter of taste).
You are the boss.

I would like to focus on these comments:

>> a) you have to know all symbols in the std namespace to make sure that none of them clash with your own symbols

We can extend this concern to all .net:
.net code will be really unreadable if don't work with:
     using System;
     using System.Collection.Generics;   // for handling arrays, dictionaries, etc.
or
     using System.Windows.Forms;   // for a winforms application

Developers cannot know all the vast set of .net classes under those namespaces, but the point is:
You have to be confident with your compiler, it shall detect all the inconsistencies.

>>(b) you have to be sure that symbols that might be added to the std namespace in the future (C++0x is coming up soon) won't clash with any of your own symbols
Again the same point. I am sure compiler makers have thought on this issue.

>> You have to be confident with your compiler, it shall detect all the inconsistencies.

I haven't found any compiler that is intelligent enough to catch all namespace related mistakes. For example, in the code sample I posted earlier ... Do you know any compiler that would throw a warning about that ?

It would sure be nice, and if one exists, I'd definitely like to try it out. But I'd doubt it, since the compiler would get extremely complicated to be able to find these kind of mistakes.


>> just give me points!

Hehe ... Patience ;) We've got some interesting thoughts already, but I'm sure there's more where that came from :)

>> We could possibly discuss whether the #include discipline is not even more important than 'using namespace std;' in the .cpp file.

Definitely agree with that ... But that's another discussion ... Maybe I'll open another one for that ... if someone doesn't beat me to it heh.


>> What C++ standard says about what min() will be used in the snippet?

The C++ standard algorithm min is defined using template arguments. And the compiler has to prefer to pick the closest match (paragraph 13.3 in the C++ standard, which deals with function overload resolution).

Since in the snippet, min was called with two int's as parameters, the compiler prefers to pick the templated standard min function (with T = int), rather than do an implicit cast to double to call our own min function. When the standard min function is not made visible by the std using directive, it will do the implicit cast to double for both parameters, and call our own min function.

Personally, I feel a similar feeling here as when discussing multiple inheritance.  I think that 100% multiple inheritance is useful, and I have used it in my projects, but it definitely shouldn't be overused.  It all depends on the project, the environment, the people you're working with, etc.  Similarly, I find "using namespace std;" useful, but again should be used more rarely then the other counterparts (i.e., "using std::cout;" or "std::cout").

Really, if every new programmer used aut_ptr or boost's shared_ptr, I could care less if they use "using namespace std;"  I'm so tired of seeing memory leaks in C++ programs.  It happens to everybody...

I agree that there are more important issues than whether or not to use 'using namespace std;', but nevertheless it's an interesting iscussion point imo.

Ok, it seems the discussion has slowed down a bit, so how about a summary of what we have so far. Feel free to correct me and/or add to the summary :


advantages of using the using directive ('using namespace std;') :
(a) convenience : less type work
    counter argument : although convenience is nice, there are more important considerations (it's only 5 characters)
(b) readability/brevity : the code isn't riddled with std:: namespace qualifiers, which makes it easier to process/read
    counter argument : proper formatting of the code can help with this, although it doesn't solve it entirely


advantages of using the using declarations ('using std::cout' etc.) and/or explicit namespace qualifiers ('std::') :
(a) robustness : avoids certain hard to track down bugs
    counter argument : these kind of bugs aren't common in well written code, and a good compiler might catch many of them anyway
(b) easier integration of third party code : if the third party code defines some of the same symbols as in the std namespace, it can still be used without any issues
    counter argument : wherever possible, the third party code can be re-factored to avoid namespace problems
(c) future proof : future additions to the std namespace won't have an impact on your current code
(d) doesn't require detailed knowledge of the symbols defined in the std namespace
(e) convenience : aids name completion features in certain IDE's


Some general arguments made :
(a) always follow the company/project code style guidelines and standards
(b) following certain naming and other style rules (to avoid collisions with symbols in the std namespace) could make this discussion largely irrelevant
(c) we all seem to agree never to put 'using namespace std;' in a header file
(d) it's not a black-and-white issue - in certain situations one approach is better, in other situations the other approach is preferred

>>Some may be related to inability to type (fast keyboard typing).

This is an interesting point.  Someone with certain physical handicaps may be better off not typing as much.  Still, you can do "using std::cout;".  I'm sure there's not enough interest in it, but it'd be interesting to design a programming language for easier use by someone with injured hands or for someone who can't see very well (but of course can still see).  Although, these languages probably already exist, unintentionally by the designer, like Scheme and Ruby, where less code may have to be typed, although this is very debateable.  A good C++ programmer with many already made (by them or by someone else) classes can write extremely short code for complex programs.  An example would be using Simple DirectMedia Layer (SDL) or Boost.  Although, this is getting a bit off-topic...it brings up the question again that must programmers arrive at, that is usually answered with a firm No.  Can a universal programming language exist from which is the only one solely used?  Of course, this seems impossible, but if Quantum computers reach Sci-Fi levels, maybe this could seem more feasible.  Also, it'd be interesting to see a programming language created by a very large group of people based on voting or something (I don't know what), similar to certain Linux distros.  Anyway, this is way off topic, but just some thoughts for new posts and future discussions.

Just want to remind you guys, "std" is just an (simple) example. At my work we use lots of 3rd party libs and own libs and they all have nested namespaces. So rather than discussing a little "std" we should discuss it more general and keeping in mind, that there can be very long and nested namespaces..

The reason I made the question about the std namespace, is because it's very common - it's used it pretty much all C++ projects. Obviously the same conclusions/arguments made for the std namespace can be made for any other namespace. So, feel free to expand the discussion to general namespaces, rather than the specific std namespace ;)

Ok i see, then i misunderstood the question. I thought it was a general one, and the "std" was just an example.

>> Sorry infinity, just because someone made really bad code, i wouldnt use it as an example.

I wouldn't call it really bad code. In this case, the reason it was there is because the software grew with time, and was maintained by different people.
Originally there was just a normal min function which behaved as you'd expect, and there was no 'using namespace std;'. Then at some point, a bug was discovered when in certain rare cases, negative values were processed incorrectly. It seems they went for the quickest way to fix that - by adding the fabs's. Still correct, although the function name was no longer the best choice. Then at some other point in time, a feature was added, for which the developer added the 'using namespace std;' and the <algorithm> include. And the rest is history lol - the original bug re-emerged mysteriously.

And that's the point I was trying to make earlier. If you have 'using namespace std;' somewhere in your code, there's a good chance it will cause a problem somewhere down the line. Maybe tomorrow, maybe in 10 years. Which is why I avoid it.

The discussion so far seems to revolve around convenience/readability vs. robustness. Some consider the chance it will cause trouble small enough to prefer making the code more readable by adding 'using namespace std;'. Others want to avoid issues, no matter how small the chance of them occurring, even if that means making the code more verbose.

>> If some other developer would have moved the new overload of min to some other module

There was no overload involved, and the function was only used locally in the compilation unit. It was simply modified to fix a bug. Anyway, wrong or not doesn't really matter. The whole point is that a different function was called than expected due to the use of 'using namespace std;'. I think we're focussing too much on this one example, as if if we can (dis)prove this one example, we've (dis)proven the whole case.


>> I joined this discussion very late

Glad to have you back among the living, evilrix ;) ADL is an interesting consideration. It does indeed complicate matters, and there's no easy way around it, except to never call a function in one namespace with argument types from a different namespace. That can get pretty annoying/difficult to manage.


>> So, we can port these conventions to function names. If you don't use all-lowercase names for functions then you won't have unexpected use of the wrong functions.

That would work, but only for the std namespace. What if other namespaces are involved ?

In any case, namespaces were precisely put into place to avoid these problems. They allow different namespaces to define the same symbol. So, what you propose sounds like emulating namespaces by using naming conventions ... Why not simply use the namespaces then ?

In C, it's common to include the module name into externally accessible symbols to avoid conflicts between different modules (modulea_function vs. moduleb_function). This is the C way of having some sort of emulated namespaces. In C++, namespaces formalized this and made it more convenient (ie. modulea::function vs. moduleb::function).

They then decided to put all standard symbols into the std namespace to allow developers to define those same symbols in their own modules. 'using namespace std;' overrides this flexibility, which is fine if you don't need it (but you might not be 100% about that).

I like that approach, Ike. Let's see if we can come up with a better example that would without doubt show that 'using namespace std;' is unsafe. Anyone ?

>>         String string;
>>         string stringForInputAndFileNamesAndConverting; //Short name

Your compiler would catch this though, so you would be able to fix it instead of it going by unnoticed. I think what we're looking for, is an example of a bug or other problem introduced by the use of 'using namespace std;' that goes by unnoticed, and is otherwise perfectly ok code.



pepr, yes, that's what I was referring to when talking about the C way of emulating namespaces. It has the serious downside of not being very flexible or scalable (especially when using many levels of nested namespaces) though.

But namespaces aren't specific to C++, and many languages implement it in a similar way.

Take the java packages for example. You can use 'import' to add all or specific symbols for a certain package into the current one ('import java.lang.*;', 'import java.lang.String;'). Or you can use explicitly qualified symbols ('java.lang.String').

Or modules/packages in Python. You can also import them ('from sys import *' or 'from sys import stdin'), and explicitly qualify them ('sys.stdin').

I can come up with many more that use the same approach to namespaces as C++. So :

>> Maybe, namespaces would be designed differently

It sounds interesting, but I'm not sure how we can improve on the concept (except for cosmetic improvements).

Obviously, C++ namespaces can be used in a different way than to implement modules, but they do allow you to do that. In fact, I'd say that is one of their primary purposes.

Maybe the attached one is a sample to discuss about - IMO it's correct code. I didn't test in other compilers, but with VS 2008 it works fine without 'using namespace std' and crashs as soon as 'using namespace std' is used.

The code swaps two instance's values. Without 'using namespace std' in line 4 it works fine and generates output like this:
> t1: 5 (0x0080DDB0)
> t2: 7 (0x0080DDE0)
> t1: 7 (0x0080DDB0)
> t2: 5 (0x0080DDE0)

When uncommenting the 'using namespace std' in line for the application crashs after the second line of output.

The reason is that the copy-constructor of 'CBase' doesn't instantiate the pointer 'm_pInt'. If calling 'swap' with references to 'CBase' objects the implemented 'void swap( CBase& t1, CBase& t2 )' is called which works fine, but with 'CDerived' object it seems to call 'std::swap' which crashes.

ZOPPO

#include "stdafx.h"
#include <iostream>
 
// using namespace std;
 
class CBase
{
	int*	m_pInt;
public:
	CBase( int n = 0 )
	{
		m_pInt = new int;
		*m_pInt = n;
	}
 
	CBase( const CBase& src ) { *this = src; }
	CBase& operator = ( const CBase& src )
	{
		if ( this != &src )
		{
			*m_pInt = *src.m_pInt;
		}
		return *this;
	}
 
	~CBase() { delete m_pInt; }
 
	int	GetValue() { return *m_pInt; }
	int* GetPointer() { return m_pInt; }
};
 
class CDerived : public CBase
{
public:
	CDerived( int n = 0 )
	: CBase( n )
	{}
 
};
 
void swap( CBase& t1, CBase& t2 )
{
	CBase tmp;
	tmp = t1;
	t1 = t2;
	t2 = tmp;
}
 
int _tmain( int argc, char* argv[] )
{
	CDerived t1( 5 ), t2( 7 );
 
	std::cout << "t1: " << t1.GetValue() << " (0x" << std::hex << t1.GetPointer() << ")" << std::endl;
	std::cout << "t2: " << t2.GetValue() << " (0x" << std::hex << t2.GetPointer() << ")" << std::endl;
	swap( t1, t2 );
	std::cout << "t1: " << t1.GetValue() << " (0x" << std::hex << t1.GetPointer() << ")" << std::endl;
	std::cout << "t2: " << t2.GetValue() << " (0x" << std::hex << t2.GetPointer() << ")" << std::endl;
 
	return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:

Sorry, one thing I missed: Of course one can say the copy constructor of CBase is the problem since it should instantiate the 'm_pInt'.

But, even without that copy constructor implemented at all the swap even crashes with 'using namespace std' but doesn't without, but later on since the pointer 'm_pInt' of 't1' gets deleted after the swap functions called the destructor of 'tmp'.

You can try by just commenting out the line 16

ZOPPO

And one more addition: The crash only happens in DEBUG builds. In RELEASE build it may crash or set one of the both object's values to a undefined number. Which IMO is even worse since it's extremely hard to find such a bug.

I'm not sure how the std swap is implemented for VS 2008, but the crash might be due to the fact that your copy constructor doesn't perform a deep copy.

>> but the crash might be due to the fact that your copy constructor doesn't perform a deep copy.

Which means that if the temporary object in the swap function is deleted, it basically deletes one of the two original object's m_pInt pointers.

Ignore that lol ... I was a bit too pre-mature with my analysis heh. Although the problem still seems to be with the copy constructor, it's not because it deletes the m_pInt of another object, but because it tries to assign without allocating memory first.

Try this instead :

CBase( const CBase& src ) { m_pInt = new int; *this = src; }

                                              

1:

Yes, I know that this is the problem. But even it fails without any copy constuctor (and IMO adding a 'using namespace std' shouldn't force me to implement a copy constructor) and no matter how this can be corrected IMO it's a major issue that adding 'using namespace std' leads to a call of another 'swap' function as without.

>> But even it fails without any copy constuctor

The compiler generates one for you that performs a shallow copy ;)

>> (and IMO adding a 'using namespace std' shouldn't force me to implement a copy constructor)

It can be argued that since you have a class that uses dynamically allocated memory, you should implement your own copy constructor and assignment operator to perform a deep copy, rather than the default shallow copy.

>> it's a major issue that adding 'using namespace std' leads to a call of another 'swap' function as without.

I couldn't agree more. But we're looking for a clean example that illustrates that.
It can be argued that in my earlier example, choosing a better name for the min function would have solved the problem too. Similarly, it can be argued for your example, that implementing the copy constructor and assignment operator correctly solves the problem too.

>> The 'swap' function is implemented in a way it just swaps the pointers.

That's more interesting :) But technically, you should still make sure that the copy constructor and assignment operator are either implemented correctly, or can't be called at all (by making them private for example).


Sorry for being picky ... We're on the same "side" ;) I'm just looking for the perfect example that no-one can refute heh.

> Sorry for being picky ... We're on the same "side" ;)
No problem at all :o)

> ... choosing a better name for the min function would have solved the problem too
Of course, this even can be sayd about my sample - but I think this is what we discussed above about style guides/code conventions.

> The compiler generates one for you that performs a shallow copy
I know ...

> or can't be called at all (by making them private for example)
That's right, but I guess people often won't think about doing this fir such a simple class

Further I found it may be a problem even if copy ctor and 'operator =' are implemented correctly. I.e. add attached code to CBase. In this case the application won't crash or produce wrong results but the 'operator =' is called three times when 'using namespace std' is used so it's bad for performace and needs more resources. Without 'using namespace std' it's much more efficient.

ZOPPO

	CBase( const CBase& src )
	: m_pInt( NULL )
	{ *this = src; }
 
	CBase& operator = ( const CBase& src )
	{
		if ( this != &src )
		{
			delete [] m_pInt;
			m_pInt = new int[ BUFSIZE ];
			memcpy( m_pInt, src.m_pInt, BUFSIZE );
		}
		return *this;
	}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

>> Without 'using namespace std' it's much more efficient.

Aha. I like that spin :) Let's see what the others have to say about all this ...

@Zoppo

Your example crashed, because the copy-ctor was not implemented properly. Using the std-namespace just made that clear. But the problem was not the namespace, it was the wrong implementation of your class. You MUST provide a proper copy-ctor and assignment-operator, if you have dynamically allocated memory in that class. That's got nothing to do with the namespace.

>> Without 'using namespace std' it's much more efficient.

In your example yes, because you programmed it that way. You overloaded the swap function with a more specialized version for your class. Then of course its faster. But you can't generalize that. You cant say in general "using namespace" is less efficient, I guess you agree there.

>> but I think we can at least agree that using "using namespace std;" has more of a potentional for problems than using "std::".

Agreed :) But that means also, with the same arguments presented for "std", that you have to do it for every namespace you use, even nested namespaces.
We have a lot of it in our company. Big projects are not just written with STL and libc as you guys all know.
So if you want to be consistent, then the code becomes unreadable and hard to maintain.
"std" is as important as any other namespace for us.
And I think we agree, that namespaces with longer names then 3 characters have the same potentional for problems ;)

well, it seems this doesn't generate much more discussion. Unfortunately, we don't seem to have found a definitive reason (that everyone can agree with) to use one or the other. So, I guess the conclusion is that one chooses whichever is appropriate for the situation, making sure to be aware of the risks and disadvantages.

Any further thoughts ?

Suggestions for how to close this ?

Oh, and if someone other than me wants to make a final summary of the most important arguments, then that would be an obvious choice for the 'accepted' post, with the others being the 'assisted' posts.

On Zoppo's comment:

That's a good point.  A possible solution to that could be either doing a find & replace all on all documents in an IDE changing std::list to betterstd::list or possibly deriving from std::list and changing the function implementations if that is possible.

From what I've read here, I think that "using std::" or just "std::" has won at least with a 51% to 49% advantage or something close like that.  A really long namespaces with multiple namespaces seemed to have gone the other way, but I haven't read anything here that would make me think that "using namespace std;" should be used the majority of the time.  In most cases (even if that is 51%) overall in general use of C++ code that you write (in your lifetime or w/e unless a new standard comes out), it seems like "std::" or "using std::" should be used instead.  Does anyone disagree?

>> A possible solution to that could be either doing a find & replace all on all documents in an IDE
I nearly always use typedefs from the off-set to (a) make code more readable and (b) provide abstraction from the real types. All that would be required is the modification of the typedef.

typedef std::list<int> mylist_t; // I'd name this after what it actually represents to give it semantic meaning

Of course, there is nothing to suggest they'd have identical interfaces so it's probably going to need effort no matter what you do.

It is questionable, whether we are albe to find the anwer here. As far as I know, the C++ committee allowed new features only when it could not be replaced by the existing features (i.e. no new keywords or structures or the core functionality if it can be solved by a library). Namespaces are clearly the core functionality. However, namespaces (generally) can work without 'using ...'. This way, there must had been reasons why they put it there (sorry for my possibly bad English grammar -- my fourth language ;). It could be the case that it was neccessary for other reasons be able to write something like 'list' without neccessity to write 'st::list' to implement say some generic code. Maybe, we did not touch the reason why 'using ...' must be there and we only discuss the case that we 'can' use it and when it is good and when it is bad.

It would be interesting to search for the original reasoning of the 'using namespace ...' or 'using xxx::yyy'. This way we could possibly compare the 'neccessity to use it' with the 'possibility to use it'. We could possibly find that the existence of 'using ...' is some compromise on itself (the related reasons could explain the existence of ADL). This could help to find and explain the 'suggested practice' for a programmer.

>> Well, I did write some code that demonstrated uncaught ambiguity when using ADL but decided against posting it because it was a little contrived (although it could happen in the real world).

I'd still like to see it though ;) If you didn't throw it away already heh.



Basically it comes down to this : follow the company/coding conventions for the project you're working on. If there are none or they don't talk about namespaces, choose wisely between the two options, weighing the advantages against the disadvantages, depending on the specific environment.

When given the choice, I'd still not use the using directive (using namespace std;). But I understand the reasons of the "opposite camp", and they make sense too :)

I can sense this is going to be difficult to close and award points lol.

>> I'd still like to see it though ;) If you didn't throw it away already heh.
I did, but it won't be too hard to recreate... I'll post it back here sometime later.

>> I can sense this is going to be difficult to close and award points lol.
Good luck with that... seriously though, I doubt anyone in this thread (all long term experts) are too worried about points so I'm pretty sure just picking a few salient posts that demonstrate the general feel of the thread will be fine by us all (I hope I speak for everyone here :) ).

>> It would be interesting to search for the original reasoning of the 'using namespace ...' or 'using xxx::yyy'.

Here's what Stroustrup says in paragraph 5.2 of "An Overview of the C++ Programming Language" (http://www.research.att.com/~bs/crc.pdf) :

        Repeating a namespace name can be a distraction for both readers and writers. Consequently, it is possible
        to state that names from a particular namespace are available without explicit qualification. For example:

            void f(int max)
            {
                using namespace Mylib;   // make names from Mylib accessible
                Stack<int> s1(max);      // use my stack
                Yourlib::Stack s2(max);  // use your stack
                // ...
            }

So, the original reason for including it in the C++ standard seems to be the exact same reason mentioned in this thread in favor of using the using directive.


Here's another interesting read : "Using Me" by Herb Sutter and Jim Hyslop :

        http://www.ddj.com/cpp/184401782

and the referenced comp.lang.c++.moderated discussion on this exact issue :

        http://groups.google.ca/group/comp.lang.c++.moderated/browse_frm/thread/34f00c3ce3f3f3b7?hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=65&prev=/groups%3Fq%3Dgroup:comp.lang.c%252B%252B.moderated%2Binsubject:%2522how%2Bto%2Bsay%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26start%3D60%26sa%3DN%26filter%3D0

Yep, I know about Herb Sutter, which is why I mentioned it as an interesting viewpoint. It kind of comes down to the same conclusion we came up with ourselves. As long as you know what you're doing, either approach is just fine (for .cpp files). Some will prefer one over the other, and that's fine too.

We all agreed (from the beginning) that in header files, the using directive should never be used. Extending that to before the #includes, is obvious/logical, but indeed worth mentioning.

Thats a nice summary, thanks for the interesting thread Infinity.
And as pepr already said, dont worry about how to reward points.
What about dice or a little side-quest quiz? ;)

@Infinity08: my suggestion about points is to ask moderators to move the question to PAQ and refund the points to you.

Well, knowing enough things, everything is logical ;)  The problem is that we all need the rules of thumb to manage the complexity without neccessity to rethink it again and again.

>> And as pepr already said, dont worry about how to reward points.
Did you mean me? {http:#25140225}

I'll gladly spend my points, so there's no need for a refund :) It's just a matter of picking the right set of posts that together form a good sumary of the discussion heh.

Just give me a bit of time to work out how best to do it :) I'll give everyone a last chance to come up with a killer argument, and then I'm closing it :)


@pepr : true. And it's what makes this kind of discussion worthwhile. It makes us all think about an issue, and consider things from different viewpoints, resulting in an enrichment of all participants.

>> >> And as pepr already said, dont worry about how to reward points.
>> Did you mean me? {http:#25140225}

Oops, yes .. sorry rix .. ;)

Thanks to all for your participation. It was a great discussion, and I hope you enjoyed it as much as I did :)

I spent quite a bit of time trying to figure out how to split the points fairly lol. I followed my original intent of assigning points on the basis of merit to the discussion. I hope none feel cheated :)

In any case, I hope you enjoyed this discussion as much as I did. We should do this more often. Whenever someone can think of an interesting topic to discuss, just create a question for it, and we can exchange ideas, and probably learn a lot from each other.

Thank you all !