How to use namespace in different files

[slcsuda]

// 1.cpp
//-------------------
#include<iostream>
namespace np {
int i = 0;
}
//-------------------

// 2.cpp
//------------------------------------------------------------
#include<iostream>
int main()
{
std::cout << "hello" << std::endl;
np::i = 3;// How to get np::i in file 1.cpp???
}
//-------------------------------------------------------------


In file 2.cpp, How to get np::i in file 1.cpp???

[edge6768]

You need to include the first file in your second file.

#include "1.cpp"
#include <iostream>
int main() {...

As a side note, why is #include <iostream> in the 1.cpp file? You do not use any members/methods of <iostream> in this file.

EDIT: The above assumes 1.cpp and 2.cpp are in the same directory. If not, or to be safe, include the full directory in the #include statement

// For Windows
#include "C:\<rest of the directory>"
// Or (for ubuntu)
#include "/home/<rest of the directory>" 

[TheIdeasMan]

@edge6768

Don't ever include cpp files - that is evil :+)

Instead include header files, in this case the header which has the namespace in it. I like to use *.hpp for header files - it means a header with c++ code in it.

// np.hpp
//-------------------
#include<iostream>
namespace np {
int i = 0;
}
//-------------------

// 2.cpp
//------------------------------------------------------------
#include<iostream>
#include "np.hpp"

int main()
{
std::cout << "hello\n"; << std::endl;
np::i = 3;  // now the reference to the namespace works fine :+)
}

[edge6768]

My apologies for bad advice, below is a link detailing the error of my solution and the reasoning (AFAIK) behind @TheIdeasMan logic

http://stackoverflow.com/questions/1686204/why-should-i-not-include-cpp-files-and-instead-use-a-header

@TheIdeasMan thank you for bringing this to my attention, I didn't realize what was going on beneath the code.

[doug4]

Actually, the above code may not be exactly what you want. If you end up including np.hpp in multiple source files that get linked together, you will end up with multiple definitions of np::i. You need to do the following instead.

np.hpp

#ifndef np_hpp_
#define np_hpp_

namespace np
{
	extern int i;
}

#endif /* np_h_ */ 

np.cpp

#include "np.hpp"

namespace np
{
	int i = 0;
}

Also, instead of getting rid of the << std::endl;, it would be better to get rid of the \n after "hello". The std::endl not only adds a new line but also flushes the output buffer

[mbozzi]

Alternatively, you may declare the variable inline if you want to allow multiple definitions without linker errors.

[TheIdeasMan]

doug4 wrote:

Also, instead of getting rid of the << std::endl;, it would be better to get rid of the \n after "hello". The std::endl not only adds a new line but also flushes the output buffer

Hi doug4,

I have always looked forward to what you have had to say, but could I query this one?

Because std::endl flushes the buffer, that is a reason not to use it, because it is slow. Also, doesn't the buffer flush itself automatically when required?

One can use std::cerr which forces a flush each time, if one is worried about multiple access from different threads.

I guess there are various reasons why one would or would not want to force flushing.

[doug4]

Alternatively, you may declare the variable inline if you want to allow multiple definitions without linker errors.

Unless something was added in c++14 (c++11 is the latest that I have available to me), it doesn't look like variables can be inlined. That only works with functions.

Also, if the variable were inlined, then it would have to be sort of a static variable compiled into each compilation unit separately, so there would be versions of "np::i" floating around, each potentially with a different value.


@TheIdeasMan

For a beginner, the performance hit from a stream flush is trivial. I have had programs where output did not get flushed before a the program crashed, and I was misled as to what actually got written. I just think it's generally a good idea to use std::endl (that's why it was added to the standard) unless performance issues dictate otherwise.

Maybe instead of "it would be better to" in my original post I should have said "I would instead". I think it is better, but that may more of an opinion than an objective statement.

And I would never use std::cerr for standard program output. That should be used for exceptional output only (well, at least in my opinion ;) )

[mbozzi]

@doug4
The ability to inline variables was (will be) added in C++17:
http://en.cppreference.com/w/cpp/language/inline