Sign in to follow this  
toddhd

Unity Ok, using namespace or not? And why?

Recommended Posts

toddhd    115
Twice today I have seen posts in various places where people have said: ...Don't put using namespace std; in your headers, use std::string (or whatever) instead... Here and In a comment here I thought the whole point of using namespaces to begin with was to avoid having to use the longer notation? In my other posts about my IniFile class, several people suggested that I make it a namespace instead of class for the exact reason of being able to use "using namespace". So which is it? To use namespace or not to use namespace? That is my question :)

Share this post


Link to post
Share on other sites
wyrzy    430
Everyone has different coding styles. People who say, "Don't type 'using namespace...'", should realize that everyone has different coding styles. I would have to agree with them, however, that it is better practice when you don't mind typing more. This way you know what is actually local to the file, and what you need to access throught a specific scope using '::'.

My opinion is if you only need to type 'namespace::function()', then type it out, otherwise I would put a using to avoid typing so much.

As far as string goes, I've had some problems when including specific headers in VC6, so I usually just type out the std::string

Share this post


Link to post
Share on other sites
petewood    819
You can put using namespace std in your own cpp file if you must.

When things are declared in a namespace, the intention is to avoid polluting the global namespace with names. For example if I write a class called string and you write a class called string and I want to use your library with my library, I've got a problem. If both headers declaring the classes are included the compiler can't tell the difference between the two when I refer to a string (and neither can I). So if we both put our string classes nicely into a namespace they can be qualified with the namespace:


#ifndef TODDLIB_STRING_H
#define TODDLIB_STRING_H

namespace toddlib {
class string;//etc
}

#endif




#ifndef PETELIB_STRING_H
#define PETELIB_STRING_H

namespace petelib {
class string;//etc
}

#endif




#include "toddlib/string.h"
#include "petelib/string.h"

int main() {
using petelib::string
string address;//uses petelib::string no ambiguity

toddlib::string name;//uses toddlib::string no ambiguity
return 0;
}




So they coexist nicely. However, if you have some header which says using toddlib::string (or even worse using namespace toddlib), then any place I include your header, I won't be able to unambiguously use my own string:


#ifndef TODDLIB_SOMETHING_BAD_H
#define TODDLIB_SOMETHING_BAD_H

#include "string"
using namespace toddlib;

void printName(string);//uses string from toddlib
//void printName(toddlib::string);//better way doesn't need 'using'

#endif



#include "toddlib/something_bad.h"
#include "petelib/string"

int main() {
using petelib::string
string address;//ambiguity because something_bad.h brought
//toddlib::string into global scope
return 0;
}

Share this post


Link to post
Share on other sites
Rebooted    612
The whole reason is to avoid conflicts with type names, global variables, etc. If I released a library with a class in it, I'd want to make sure that it wouldn't interfere with the user's code if they happened to have a class with the same name.

Also, you can split your project into different namespaces to help you organise it. For example: namespace Engine, namespace Engine::Foundation, namespace Engine::Core.

Share this post


Link to post
Share on other sites
toddhd    115
Quote:
Original post by petewood
However, if you have some header which says using toddlib::string (or even worse using namespace toddlib), then any place I include your header, I won't be able to unambiguously use my own string


Ah... I see what you are saying now. So if I release my IniFile class for someone else to use, and using namespace whatever is in my header, then that namespace will be pulled into their program too, possibly causing problems, or at least adding overhead.

Ok, that makes sense.

Share this post


Link to post
Share on other sites
petewood    819
In regard to the worries related to excessive typing:

You can alias namespaces. So I have namespaces which divide my projects up into separate parts:


namespace library_name {
namespace component_name {
namespace detail {
}
}
}


When I am working on the detail part I wrap the whole cpp file as above and don't have to use all the qualifications (unless there is some ambiguity).

When I am making use of the library component I might alias the library name and component to lncn (library name component name, see (c:)


namespace lncn = library_name::component_name;

lncn::string player;
lncn::string comments;
//or
using lncn;
string player2;
string more_comments;

Share this post


Link to post
Share on other sites
petewood    819
Quote:
Original post by toddhd
Quote:
Original post by petewood
However, if you have some header which says using toddlib::string (or even worse using namespace toddlib), then any place I include your header, I won't be able to unambiguously use my own string

Ah... I see what you are saying now. So if I release my IniFile class for someone else to use, and using namespace whatever is in my header, then that namespace will be pulled into their program too, possibly causing problems, or at least adding overhead.

Ok, that makes sense.


Right, you've got it. (c:

Basically it's to do with being friendly.

There won't be any overhead at runtime, only at compile time with the set of names the compiler will consider for lookup.

Share this post


Link to post
Share on other sites
MaulingMonkey    1728
Quote:
Original post by toddhd
...Don't put using namespace std; in your headers, use std::string (or whatever) instead...

Yes, because it can cause naming conflicts in code that 'uses' those headers.
Quote:
I thought the whole point of using namespaces to begin with was to avoid having to use the longer notation?

To avoid having to write (using SDL as an example) SDL_Init instead of Init. But if your headers start using namespaces, any file that includes them will also be forced to include those namespaces. This becomes problematic when two Init functions exist in seperate namespaces. Why?

1) The programmer is forced, if both namespaces are included, to forevermore use sdl::init and myotherlib::init (if both these existed) even if he only really wanted to call one of those. Thus, by saving some typing in the headers (which have less code (usually) than source files), you can force both more typing in using code (read: source files, the longer ones) and potential headaches (not realising that the headers use a namespace, causing compile errors with the bellow code:)

#include "c++sdl/sdl.hh" //uses namespace sdl like the sneaky devil you made it be
#include "otherlib/otherlib.hh"
using namespace otherlib;

//...

void SomeClass::InitSubsystemA ( void )
{
if (! gOtherLibInitialized) init(); //ERROR: sdl::init or otherlib::init?
}



Quote:
In my other posts about my IniFile class, several people suggested that I make it a namespace instead of class for the exact reason of being able to use "using namespace".


Sounds good, but only do the using namespace bit in your SOURCE FILES, NOT your headers. Using them in headers entirely defeats the purpouse of namespaces for any code that uses those headers.

Quote:
So which is it? To use namespace or not to use namespace?
That is my question :)


Use them or I will be angry ;-).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this