does not compile with "using namespace std"

[Douglas]

**** Post for FREE via your newsreader at post.usenet.com ****

Hello,

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
6.0.
Thanks a lot,

Douglas

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
commented.

using std:stream;
using std::cin;
using std::cout;

template<class T> class Stack {

public:
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
ostream&

private:
T* items;
int sp;
st
};


template<class T>
ostream& operator<<(ostream & output, Stack<T> &a) //output type was
ostream&
{
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;
a.push(ans);
}

cout << a;

return 0;
}




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 

[Phlip]

I do not understand it. Could somebody explain it to me? I am using MSVC
6.0.

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

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

using std:stream;
using std::cin;
using std::cout;

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

 

[Denis Remezov]

**** Post for FREE via your newsreader at post.usenet.com ****

Hello,

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
6.0.
Thanks a lot,

Douglas

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
issues).

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
commented.

using std:stream;
using std::cin;
using std::cout;

template<class T> class Stack {

public:
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
ostream&

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.

private:
T* items;
int sp;
st

^^
Just a typo, I guess.

};

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

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

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
template:

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).

Denis

 

[Stone Lan]

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

 

[John Harrison]

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

Your faith is very touching, but totally misplaced.

john

 

[Phlip]

Your faith is very touching, but totally misplaced.

Partly misplaced.

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

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
compiling.

 

[Stone Lan]

2004-7-20 14:41:39


<[email protected]>

John Harrison wrote:


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

compiling.



http://industrialxp.

org/community/bin/view/Main/TestFirstUserInterfaces



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

 

[John Harrison]

Partly misplaced.

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

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
compiling.

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'.

john

 

[Phlip]

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

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.