By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,402 Members | 1,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,402 IT Pros & Developers. It's quick & easy.

does not compile with "using namespace std"

P: n/a
**** 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::ostream;
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jul 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Douglas wrote:
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::ostream;
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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #2

P: n/a
but I think such a product like VC++ won't have such bugs like that.......
"Phlip" wrote
Douglas wrote:
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::ostream;
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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Jul 22 '05 #3

P: n/a
On Tue, 20 Jul 2004 12:52:48 +0800, Stone Lan <st*********@hotmail.com>
wrote:
but I think such a product like VC++ won't have such bugs like
that.......


Your faith is very touching, but totally misplaced.

john
Jul 22 '05 #4

P: n/a
John Harrison wrote:
Stone Lan wrote:
but I think such a product like VC++ won't have such bugs like
that.......


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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #5

P: n/a
2004-7-20 14:41:39

Phlip <ph*******@yahoo.com> wrote in message

<D8***************@newssvr16.news.prodigy.com>
John Harrison wrote:
Stone Lan wrote:
but I think such a product like VC++ won't have such bugs like that.......

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. -- Phlip 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?
--
Composed with Newz Crawler 1.7 http://www.newzcrawler.com/
Jul 22 '05 #6

P: n/a
Douglas wrote:

**** 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::ostream;
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
Jul 22 '05 #7

P: n/a
On Tue, 20 Jul 2004 06:41:39 GMT, Phlip <ph*******@yahoo.com> wrote:
John Harrison wrote:
Stone Lan wrote:
> but I think such a product like VC++ won't have such bugs like
> that.......


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.


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
Jul 22 '05 #8

P: n/a
Stone Lan wrote:
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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.