[subhransu.panigrahi@gmail.com]

Hi Guys,
It is obvious that "using namespace" should be added in the cpp file not in the header file.
But i want to know what are the pros & cos using this in header file.

Subhransu Panigrahi :)

[sarmanu]

When you are dealing with 'std::string' or 'std::cout', etc .. in a header file, and if you are too lazy to write the prefix std::, you can add an 'use namespace std' there, it's no harm, and won't affect anything (maybe it will take 0.001 miliseconds of compilation time :-P). I can't see any reason for not using an 'using namespace ___namespace_name' in a header file, but it's up to the user though. Personally, i prefer to not use it in a header file, I have no reason for that, but I just don't like it.
! if you add 'use namespace ___' in a header file, you don't need to add it to the .cpp file that includes the header. It will be a duplicate, and therefore, efficiency drops.

[seeP+]

One problem that I have found with 'using namespace std;' is in certain compilers. In Code::Blocks 'using namespace std;' changes the way you uppercase or lowercase an entire string because the function transfrom() is not recognized unless you do transform(variable.begin(), variable.end(), variable.begin(), ::toupper(or tolower)).

[Martyn.Rae]

@sarmanu

Quote

(maybe it will take 0.001 miliseconds of compilation time :-P)

You must have a very, very, very slow machine!

[no2pencil]

subhransu.panigrahi@gmail.com, on 04 February 2010 - 11:55 AM, said:

i want to know what are the pros & cos using this in header file.

It's often that people don't even post the correct headers, they swap between C & C++. I have no idea what putting namespace into a header & using it on a C project would do. I also don't care to find out

But my point is, that beginners sometimes have a hard time understanding proper header usage, let alone customization.

[Martyn.Rae]

@no2pencil,

Quote

It's often that people don't even post the correct headers, they swap between C & C++. I have no idea what putting namespace into a header & using it on a C project would do.

The compiler will be able to handle it. C++ is a superset of C, and as such cannot distinguish between the two. If you tell the compiler the progam being compiled is C only, then it effectively switches of all C++ constructs and statements.

[seeP+]

Are you saying every c++ compiler compiles c?

[Martyn.Rae]

@seeP+ - name me one C construct or statement that does not exist in C++ please.

[subhransu.panigrahi@gmail.com]

Answering to last question by "seeP+ Icon"

-->Are you saying every c++ compiler compiles c?

Ans: NO.
Reason let say in C there is a function which converts void function to other one.But the same will not work as C++ will not allow.
http://www.cprogramm...l/c-vs-c++.html

[PlasticineGuy]

C++ compilers will compile good C. Lazy C like this:

aFunction() {

Will not compile. In C it will default to returning int; C++ does not allow this.
Also, as mentioned, there is much stricter typing. Calls like malloc() and GlobalAlloc() must have explicit typecasting in C++, but not C:

int *myint = malloc(sizeof(int) * 2); //Doesn't work in C++
int *myint = (int*)malloc(sizeof(int) * 2); //Works in C++

[Martyn.Rae]

@PlasticineGuy

Quote

C++ compilers will compile good C

I never write lazy C, so I have never come across these compiler descrepancies. ISO standards state quite specifically "C++ is a superset of C". Agreed, compiler manufacturers implement this in odd ways giving rise to lazy code.

[NickDMax]

seeP+, on 05 February 2010 - 03:02 AM, said:

Are you saying every c++ compiler compiles c?

Most C++ compilers will compiler a file as C if you name it .c or use a command line switch to that effect. I think the GNU compilers actually seperate into two differnt commands but most of the other compilers I am aware of have a "c mode". For example Visual Studio/Borland will both compile a program as ANSI-C if the file is a .c file.

This little program:

testtest.c

#include <iostream>

int main() {
    std::cout << "hello world" << std::endl;
    return 0;
}

Borland C++ 5.5: Failed
VS 2010: Failed (apparently iostream include cmath... didn't know that)
MinGW (g + +): success -- "the exception that proves the rule"
DigitalMars: Failed

So those three all have a C mode... and mingw/gnu separate things out to two different compilers.

Though note that if you go the other way and take a C program and name it .cpp than most of the time a C++ compiler will compile it with no problems or errors.

There are some *slight* differences between C and C++ (like some operator precedence differences that randomly pop up) but for the most part any modern C program will compile in a modern C++ compiler.

[NickDMax]

PlasticineGuy, on 05 February 2010 - 05:05 AM, said:

C++ compilers will compile good C. Lazy C like this:

aFunction() {

Will not compile. In C it will default to returning int; C++ does not allow this.
Also, as mentioned, there is much stricter typing. Calls like malloc() and GlobalAlloc() must have explicit typecasting in C++, but not C:

int *myint = malloc(sizeof(int) * 2); //Doesn't work in C++
int *myint = (int*)malloc(sizeof(int) * 2); //Works in C++

You are correct there. C++ is much more type safe than C and requires that you obey a few rules to explicitly state type conversions. I kind of forget about that since I don't really write C very often (and when I do, I don't really write "lazy C" -- though I don't typecase malloc -- I seem to remember that there was a reason why but I don't recall).

[jjl]

PlasticineGuy, on 05 February 2010 - 09:05 AM, said:

C++ compilers will compile good C. Lazy C like this:

aFunction() {

Will not compile. In C it will default to returning int; C++ does not allow this.
Also, as mentioned, there is much stricter typing. Calls like malloc() and GlobalAlloc() must have explicit typecasting in C++, but not C:

int *myint = malloc(sizeof(int) * 2); //Doesn't work in C++
int *myint = (int*)malloc(sizeof(int) * 2); //Works in C++

you should avoid malloc() and calloc() commands in c++ anyways. The correct way is to use

new

[NickDMax]

well one should never speak in absolutes.

There are times when one must integrate with C libraries/functions.

I think the point was compiling C code (which can not use "new") with a C++ compiler has some differences such as C++'s type-pickyness vs C's free love attitude.


BTW -- the C standard library functions are part of the C++ standard -- so using malloc() or printf() or gets() in a C++ program may be *bad* but it is still standards compliant. It is still perfectly valid C++.