8

I've been programming in various languages for about 10 years now. And I still haven't figured out when it is a good idea to import something into the global namespace (using x::y in C++, from x import y in Python etc.), so I hardly ever do it.

It almost always seems like a bad idea to me, if only because it limits the set of variable names I can use. For example: Where I to use using namespace std; or using std::string;in C++, I couldn't use stringas a variable name anymore, which I occasionally do (e.g. for string utility functions).

But I'm wondering: Are there some situations where importing a name into the global namespace really makes sense? Any rules of thumb?

11

In C++, it's generally frowned upon- especially using namespace std. That std namespace has so many names, many of which are very generic algorithms, you can get some extremely nasty surprises when using namespace std. Something like using std::cout; isn't so bad. But never, ever, using anything into the global namespace in a header file. That's a firing-squad offence.

  • 1
    But what about my question? When to use using x::y or import x from y? – futlib Feb 11 '13 at 5:55
4

You should do it when it simplifies your code. You shouldn't do it when it would cause naming conflicts, or when it could be later brought into scopes where it would cause naming conflicts, such as a header file.

Some people think it should be rare. I think (outside of header files) not using it should be rare, because the namespace prefix doesn't generally add any useful information, like using someone's full name every single time you address them.

Let me put it this way. When you see string as a class name, do you automatically think std::string or mycustom::string? It's like the old adage. When you hear the sound of hooves, you think horses, not zebras. In other words, using namespace std is almost always no big deal. using namespace mycustom is likewise usually not a big deal, unless it contains a conflict with std, in which case your custom namespace is the one you want to always require the prefix for.

  • What happens if mycustom contains a string class. At the top you using namespace mycustom;. Through the rest of the code you now use string. Everybody else that reads the code is thinking std::string only you (and a few very observant people) are thinking mycustom::string. Here you have put the zebras in the horse paddock. Also see stackoverflow.com/q/1452721/14065 – Martin York Mar 2 '13 at 16:27
  • 1
    Did you not read my last sentence? I specifically said if mycustom conflicts with std you should always require the mycustom:: prefix. – Karl Bielefeldt Mar 2 '13 at 18:03
  • I did. The trouble is that most namespaces are non trivially large. Knowing everything in them is even harder (and future versions of the namespace may expand). Thus including a whole namespace is a recipe for disaster (using specific items (within a small specific scope is easier to control)). If your code contains doStuff(int). And a newer version of mycustom adds doStuff(double) then the whole meaning of any call to doStuff(5.5); changes (potentially without you noticing). – Martin York Mar 2 '13 at 18:59
3

Working in Python, I use from x import y (as z) constantly, to have clear, concise names to reference imports.

From imports are invaluable in a codebase with a deep namespace hierarchy. This is especially so when the style standard for the codebase is PEP 8, which limits line length to under 80 characters.

For example, consider:

import foo

foo.bar.baz.baf.perform_task(foo.bar.baz.quux.SOME_CONSTANT, foo.bar.alice.bob.preferred_hash_function, '42', foo.bar.magic_numbers.MY_SALT)

Which could instead be written:

from foo.bar import baf
from foo.bar.alice import bob
from foo.bar.baz.quux import SOME_CONSTANT
from foo.bar.magic_numbers import MY_SALT

baf.perform_task(SOME_CONSTANT, bob.preferred_hash_function, '42', MY_SALT)

Since Python identifiers are case-sensitive and unlimited in length, we won't run out of names regardless of how many we import.

If we want to use the same name in our module as one of the modules we wish to import, we can use an alias for the import:

from foo.bar.alice import bob as carol

def bob(x, y):
    print "running bob function"
    return carol(x, y, 42)
0

It's up to programmer when to use it. IMHO it's better not use them at all, especially in header files. But there are several cases when I use it

  • When I want to introduce something to another namespace e.g.

    namespace cg
    {
      namespace details
      {
        //lots of stuff
        void some_cool_foo()
        {
          //uses a lot stuff from details, here because I don't want prefix everything with details::
        }
      }
      using details::some_cool_foo;
    }
    
  • To enable ADL for some algorithms from another namespace

    namespace n1
    {
    //some general foo
    }
    namespace n2
    {
      using n1::foo;
    //some struct
    }
    namespace n3
    {
      using n1::foo;
    //some struct
    }
    

If I don't want write long names of namespaces at .cpp I can always make alias

namespace bl = boost::lambda;
namespace fs = boost::filesystem;
  • sorry, could not make it highlight my source =/ – kassak Mar 2 '13 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.