Visual Studio 2005 Professional, errors C2039 C2873 : c++

When compiling the program below using Visual Studio 2005 Professional,
one of my students gets the error messages:

Error 1 error C2039: 'exit' : is not a member of '`global
namespace'' c:\program files\microsoft visual studio
8\vc\include\cstdlib 23

Error 2 error C2873: 'exit' : symbol cannot be used in a
using-declaration c:\program files\microsoft visual studio
8\vc\include\cstdlib 23

The errors occur also on other apparently correct programs.

A Microsoft website says something about enclosing #include <csdtlib>
in namespace std. That doesn't make any sense to me.

Another student has compiled the program successfully on VS 2005 Prof.
The remainder of the class are using VS Express, and that is okay too.

I suspect that there may be problems with his installation of VS 2005
Prof. But I'm mildly curious; anyone any suggestions?

----------------------------
#include <iostream>
using namespace std;

class Cell{
public:
Cell(){val_= 0;}
void set(int val){val_= val;}
int get(){return val_;}
void print(){cout<<"value= " << val_<< endl;}
private:
int val_;
};

int main()
{
Cell c;
c.set(123);
cout<< "Cell c: "<< endl; c.print();

Cell* pc= &c;
cout<< "Cell* pc = &c: "<< endl; pc->print();

//c.val_= 345; // remove the first "//" and see if the program
compiles
return 0;
}
-------------------------------------

Best regards,

Jon C.

* jg.campbell.ng:
> When compiling the program below using Visual Studio 2005 Professional,
> one of my students gets the error messages:
>
> Error 1 error C2039: 'exit' : is not a member of '`global
> namespace'' c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> Error 2 error C2873: 'exit' : symbol cannot be used in a
> using-declaration c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> The errors occur also on other apparently correct programs.
>
> A Microsoft website says something about enclosing #include <csdtlib>
> in namespace std. That doesn't make any sense to me.

Presumably you're talking about <url:
http://support.microsoft.com/kb/243444>.

It makes perfect sense. Like most other standard library
implementations, the one used seems to place 'exit' in namespace 'std'
by including <stdlib.h> and then adding 'namespace std { using ::exit;
}', which is technically not in the spirit of the standard, but is done
to make it practical to use the same headers for C and C++. And due to
some bug, for your code <stdlib.h> doesn't get included.

One fix is then presumably to do

#include <stdlib.h>

before anything else, and another and better fix to install the latest
service pack.

Btw., the program technically needs to include <ostream>.

Perhaps that (a technically correct program) will do the trick, also?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

jg.campbell.ng said:

> When compiling the program below using Visual Studio 2005 Professional,
> one of my students gets the error messages:
>
> Error 1 error C2039: 'exit' : is not a member of '`global
> namespace'' c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> Error 2 error C2873: 'exit' : symbol cannot be used in a
> using-declaration c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> The errors occur also on other apparently correct programs.

I'm no C++ expert, but this looks like a straightforward implementation bug.
If you're really getting those diagnostics for that program, then I can see
no C++ reason why. It seems to me that your implementation's iostream
header has included the cstdlib header, and done it badly.

This would not be the first time that a Microsoft implementation failed to
compile its own headers!

> A Microsoft website says something about enclosing #include <csdtlib>
> in namespace std. That doesn't make any sense to me.

Well, had you included <cstdlib> (e.g. so that you could call exit()), it
would make sense to say either this:

using namespace std; /* not my preference, but it would do the job */

or this:

using std::exit; /* or should it be std::exit()? :-) */

but since you didn't (and had no reason to), the diagnostic is just
gibberish. It does seem to be either a bug in the compiler - a rare beast,
but not exactly extinct - or a flaw in the installation.

> Another student has compiled the program successfully on VS 2005 Prof.

That's odd, and suggests that the flaw is in the installation. Perhaps
someone has been messing with the system headers?

> The remainder of the class are using VS Express, and that is okay too.
>
> I suspect that there may be problems with his installation of VS 2005
> Prof.

It's possible. Maybe even likely.

> But I'm mildly curious; anyone any suggestions?

gcc :-)

Seriously, the usual three Windows Rs apply here: retry, reboot, reinstall.
In this case, the first two steps seem unnecessary (and I bet you've
already tried them), so I suggest completely uninstalling the
implementation (make sure there's nothing relevant left lurking in that
stupid registry thing they have), and then installing it again.

If the problem persists, I think you should contact the vendor and ask them
for some support. You paid enough for it, after all.

Oh, just one more thing:

> //c.val_= 345; // remove the first "//" and see if the program
> compiles

....which is that when I tested this program on gcc, the two lines quoted
above gave me a syntax error. On Usenet, /* comments */ are far better, as
they survive line-wrapping. (After I fixed this, the program compiled just
fine, and gave the expected runtime results.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Richard Heathfield wrote:
> jg.campbell.ng said:
>
> > When compiling the program below using Visual Studio 2005 Professional,
> > one of my students gets the error messages:
> >
> > Error 1 error C2039: 'exit' : is not a member of '`global
[...]
> >
> > Error 2 error C2873: 'exit' : symbol cannot be used in a
[...]
> > The errors occur also on other apparently correct programs.
>
> I'm no C++ expert, but this looks like a straightforward implementation bug.
> If you're really getting those diagnostics for that program, then I can see
> no C++ reason why. It seems to me that your implementation's iostream
> header has included the cstdlib header, and done it badly.
>
> This would not be the first time that a Microsoft implementation failed to
> compile its own headers!
>
> > A Microsoft website says something about enclosing #include <csdtlib>
> > in namespace std. That doesn't make any sense to me.
>
> Well, had you included <cstdlib> (e.g. so that you could call exit()), it
> would make sense to say either this:
>
> using namespace std; /* not my preference, but it would do the job */
>
> or this:
>
> using std::exit; /* or should it be std::exit()? :-) */
>
> but since you didn't (and had no reason to), the diagnostic is just
> gibberish. It does seem to be either a bug in the compiler - a rare beast,
> but not exactly extinct - or a flaw in the installation.
>
> > Another student has compiled the program successfully on VS 2005 Prof.
>
> That's odd, and suggests that the flaw is in the installation. Perhaps
> someone has been messing with the system headers?
>
> > The remainder of the class are using VS Express, and that is okay too.
> >
> > I suspect that there may be problems with his installation of VS 2005
> > Prof.
>
> It's possible. Maybe even likely.
>
> > But I'm mildly curious; anyone any suggestions?
>
> gcc :-)

Sure, that's what I use myself, and why the curiosity is only mild.
Years ago I was strong-willed enough to demand that my then college
provide a Linux system. These students are learning DirectX as well, so
I cannot be bothered even introducing them to Cygwin or MinGW.

[...]
> Oh, just one more thing:
>
> > //c.val_= 345; // remove the first "//" and see if the program
> > compiles
>
> ...which is that when I tested this program on gcc, the two lines quoted
> above gave me a syntax error. On Usenet, /* comments */ are far better, as
> they survive line-wrapping. (After I fixed this, the program compiled just
> fine, and gave the expected runtime results.)

Runtime? Surely compile time?

$ make Cell0
g++ Cell0.cpp -o Cell0
Cell0.cpp: In function 'int main()':
Cell0.cpp:15: error: 'int Cell::val_' is private
Cell0.cpp:27: error: within this context
make: *** [Cell0] Error 1

Thanks everyone. I'm going to think no more of it. They were told to
use VS Express, so I owe him no duty of support; in addition to Express
VS 2005 Prof. is also on the college system, and my programs all work
on that too.

God knows what mixture of include files he has --- the problems occur
only on the student's personal laptop.

Alf P. Steinbach wrote:
> * jg.campbell.ng:
> > When compiling the program below using Visual Studio 2005 Professional,
> > one of my students gets the error messages:
> >
> > Error 1 error C2039: 'exit' : is not a member of '`global
[...]
> before anything else, and another and better fix to install the latest
> service pack.
>
Hopefully, he has already installed VS Express.

> Btw., the program technically needs to include <ostream>.
>

Why?

Best regards,

Jon C.

* jg.campbell.ng:
> * Alf P. Steinbach:
>>
>> Btw., the program technically needs to include <ostream>.
>
> Why?

Because <iostream> only is guaranteed to declare the eight standard
stream objects. The operator<< used in the code is as far as I recall
not a member function, and std::endl is not guaranteed to be available.
Those are supplied by <ostream>.

With at least one compiler that code will fail to compile.

On the other hand, presumably this will be fixed in C++0x, since nearly
all the non-normative examples in the standard do the same thing (but on
the third and gripping hand, the non-normative examples are not exactly
free of errors, such as the 1998 standard's examples of sequence points,
corrected, IIRC, in TC1 aka C++2003, and the committee is overworked).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

jg.campbell.ng said:

> These students are learning DirectX as well, so
> I cannot be bothered even introducing them to Cygwin or MinGW.

Understood. Never fear... the keen ones will work it out for themselves.

>
> [...]
>> Oh, just one more thing:
>>
>> > //c.val_= 345; // remove the first "//" and see if the program
>> > compiles
>>
>> ...which is that when I tested this program on gcc, the two lines quoted
>> above gave me a syntax error. On Usenet, /* comments */ are far better,
>> as they survive line-wrapping. (After I fixed this, the program compiled
>> just fine, and gave the expected runtime results.)
>
> Runtime? Surely compile time?

No, I left the comment in-place. Never fear - I know what would happen if I
were to remove it! :-)

> Thanks everyone. I'm going to think no more of it. They were told to
> use VS Express, so I owe him no duty of support;

Hahaha! :-) That's lovely - "you were told to use this cheap tacky free
thing, and you used that shiny expensive thing instead, so that's your
problem, not ours". And the crazy thing is, you're right. (This is not a
criticism of you. I just can't resist the ironic flavour that always seems
to creep into discussions of Microsoft software...)

> God knows what mixture of include files he has --- the problems occur
> only on the student's personal laptop.

This is beginning to sound more and more like a hacked-up hack job, isn't
it? Frankly, I'd just make him ditch the thing and use what you told him to
use in the first place.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

<jg.campbell.ng> wrote in message
news:1164802543.098792.231930@16g2000cwy.googlegro ups.com...
> When compiling the program below using Visual Studio 2005 Professional,
> one of my students gets the error messages:
>
> Error 1 error C2039: 'exit' : is not a member of '`global
> namespace'' c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> Error 2 error C2873: 'exit' : symbol cannot be used in a
> using-declaration c:\program files\microsoft visual studio
> 8\vc\include\cstdlib 23
>
> The errors occur also on other apparently correct programs.
>
> A Microsoft website says something about enclosing #include <csdtlib>
> in namespace std. That doesn't make any sense to me.
>
> Another student has compiled the program successfully on VS 2005 Prof.
> The remainder of the class are using VS Express, and that is okay too.
>
> I suspect that there may be problems with his installation of VS 2005
> Prof. But I'm mildly curious; anyone any suggestions?
>
> ----------------------------
> #include <iostream>
> using namespace std;
>
> class Cell{
> public:
> Cell(){val_= 0;}
> void set(int val){val_= val;}
> int get(){return val_;}
> void print(){cout<<"value= " << val_<< endl;}
> private:
> int val_;
> };
>
> int main()
> {
> Cell c;
> c.set(123);
> cout<< "Cell c: "<< endl; c.print();
>
> Cell* pc= &c;
> cout<< "Cell* pc = &c: "<< endl; pc->print();
>
> //c.val_= 345; // remove the first "//" and see if the program
> compiles
> return 0;
> }
> -------------------------------------
>
> Best regards,
>
> Jon C.

This may have nothing to do with it, but today I couldn't compile a program
with a simple
#include <winsock2.h>
int main() { return 0; }

Got an error in WinNT.h.

Turned out I had turned off Language Extentions in the project, and
apparently WinNT.h used them.

So you might want to check that Langauge Extentions are turned on (although
they proably are, on by default when creating a project)

that's just a typical microsoft products bug. this bugs are created who knows how. one day is everthing ok, and on the next one - ERROR.

this problem happened to me too. the fastest solution:

goto to csdtlib.h and delete the using::exit entry from this file.
it's easy to spot, it's together with a whole bunch of others using::.

attention, in my case worked perfectly but remember this is just a temporary patch. this may also create others problems.