does not compile with "using namespace std"

does not compile with "using namespace std"

Post by Dougla » Wed, 21 Jul 2004 04:53:05

**** Post for FREE via your newsreader at ****


The following code does not compile if line 3 is uncommented "using
namespace std".
I do not understand it. Could somebody explain it to me? I am using MSVC
Thanks a lot,


Error message is:

C:\test\stacktest.cpp(36) : error C2248: 'sp' : cannot access private member
declared in class 'Stack<char>'

// --------------- CODE STARTS HERE --------------------------
#include <iostream>

#define STACK_SIZE 10

// using namespace std; // It does not compile unless this line is

using std::ostream;
using std::cin;
using std::cout;

template<class T> class Stack {

Stack() {items = new T[STACK_SIZE]; sp = -1;}
~Stack() {delete [ ] items;}
T top() const { return items[sp];}
T pop() {return items[sp--];}
void push(T i) {items[++sp] = i;}

friend ostream& operator<< (ostream &, Stack<T>&); // return type was

T* items;
int sp;

template<class T>
ostream& operator<<(ostream & output, Stack<T> &a) //output type was
cout << "\n\nElements in stack are: ";
for (int i=0; i< STACK_SIZE; i++)
output << a.pop();
output << a.sp;
return output;

int main()
Stack<char> a;
char ans;
cout << "Enter elements in stack: ";
for (int i =0; i< STACK_SIZE; i++)
std::cin >> ans;

cout << a;

return 0;

*** - The #1 Usenet Newsgroup Service on The Planet! ***
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored

does not compile with "using namespace std"

Post by Phli » Wed, 21 Jul 2004 05:13:10

VC++ has bugs that help you write better code.

Only import identifiers with these, or typedefs. When you dump an entire
namespace into your module, you defeat the purpose of namespaces.



does not compile with "using namespace std"

Post by Denis Reme » Wed, 21 Jul 2004 11:59:46

ouglas wrote:

While I cannot give you any insight on the way MSVC 6.0 works, your
code does have a problem that needs fixing, one way or the other,
or else it will not work on more conforming compilers.
See comments below (only on that specific problem, ignoring other

The above is a declaration of a normal function, not a function
template. That means that a specialisation of class Stack for some
template parameter T will have the following function
ostream& operator <<(ostream&, Stack<T>&);
as a friend. Again, the above is a normal function, not a
specialisation of a function template.

Just a typo, I guess.

Now this is a function template, which is unrelated to the declaration
friend ostream& operator <<(ostream&, Stack<T>&);

Your code should compile with the right compiler, but it won't link
because you haven't provided a definition for the friend operator <<.

There are several ways you can implement what you want, but I'm not
sure which one of them (if any) VC 6.0 will accept (I'm not bashing
MSVC, I just cannot take it for a test run).

0. Define what you have declared, a properly typed operator << for
your Stack specialisation:
ostream& operator <<(ostream& output, Stack<char>& a) {...}

It's a kludge. I would avoid using it if at all possible.

1. Declare your friend as
friend ostream& operator<< <>(ostream &, Stack<T>&);

in which case you will also need a couple of forward declarations
just before the line "template<class T> class Stack {":

template<class T> class Stack;
template<class T>
ostream& operator <<(ostream& output, Stack<T>& a);

The effect is that a specialisation of Stack will have a
corresponding specialisation of the /function template/ operator <<
as a friend. Leave the definition of operator << as it is.

2. You can let the Stack declare a friend template:
template <class T1>
friend ostream& operator <<(ostream &, Stack<T1>&);
Now all specialisations of this operator << will be friends of
any specialisation of Stack. Though this probably won't be a
big problem, it is likely not what you really want either.

#1 should be the default choice to consider.

All of the above should work. If everything fails, you can at least
use a work-around: define a public member function for the Stack class

ostream& print(ostream& s) {...}

that does all of the job the operator << is supposed to do. Then
make operator << template call this function.

(I think all of the above has been discussed here before, I've
just restored it by memory).


does not compile with "using namespace std"

Post by Stone La » Wed, 21 Jul 2004 13:52:48

but I think such a product like VC++ won't have such bugs like that.......
"Phlip" wrote

does not compile with "using namespace std"

Post by John Harri » Wed, 21 Jul 2004 14:35:40

On Tue, 20 Jul 2004 12:52:48 +0800, Stone Lan < XXXX@XXXXX.COM >

Your faith is very touching, but totally misplaced.


does not compile with "using namespace std"

Post by Phli » Wed, 21 Jul 2004 15:41:39

Partly misplaced.

The top-poster responded to my "VC++ has bugs that help you write better

Of course that's a joke. However, in some small sick way, if enough
programmers try to do X, and can't, but should, MS might respond. So market
forces eventually drill a hole thru the bugs, permitting the most beneficial
programmer activities thru.

I have seen very large programs with absurdly twisted that constantly named
namespaces, then threw the spaces away by using "using namespace" to insert
everything into everything else. If you changed one of them, VC++ would stop


does not compile with "using namespace std"

Post by Stone La » Wed, 21 Jul 2004 16:02:21

2004-7-20 14:41:39

<D83Lc.315$ XXXX@XXXXX.COM >


So market


constantly named

to insert

would stop


In fact I am always using "using namespace std" in VC++6.0,but I
didn't have the problem.Why?
Composed with Newz Crawler 1.7

does not compile with "using namespace std"

Post by John Harri » Wed, 21 Jul 2004 16:05:25

This is a true story.

When Windows 95 was released MS were obviously very keen that as many DOS
programs as possible would run without problems. One that didn't was Sim
City. MS were pretty sure that the problem was in Sim City so they decided
that they would debug Sim City themselves. Turned out the problem was in
heap use. Sim City was freeing memory and for a short time continuing to
use that memory. In a single tasking system like DOS they got away with
it, but in a multitasking system some other process would grab the memory
that Sim City was trying to use.

What was MS's next action? Did they alert the Sim City programmers and say
'Hey you've got a bug in Sim City, you better fix it'. Not at all. What
they did was to write a special heap allocation algorithm especially for
Sim City. This algorithm said 'if you are running Sim City work the heap
this way, for everyone else work the heap the usual way'. Thus working
around the problem.

My slightly round about point is that I don't think market forces benefit
coding standards, common programming practises are not necessarily good
programming practises. And market forces will always go for the short term
benefit at possible long term cost.

I think market forces alone would dictate 'if enough programmers try to do
X, even though they shouldn't, MS would respond'.


does not compile with "using namespace std"

Post by Phli » Wed, 21 Jul 2004 16:16:28

There are two problems.

In a small program, you should not use that statement, because you want your
program to remain small, and easy to understand. Use the fewest symbols
possible, not all of them, and make the lists of what you import explicit.

using std::string;
using std::cout; // etc

In a big program, VC++ will puke its internal symbol tables, due to bugs
caused spending too much effort reacting to sloppy programmers' other bad
habits, and not enough effort on raw Standards compliance.