The risk of using using namespace: my feedback as a newbie, Emanuele

Unreal Courses Talk
,
#1

Well, the most obvious risk is that the if an item has the same name in different namespaces, the moment we call the item in the code, our programming environment will look at the names of items/namespacecannot and cannot judge if there is a difference IN the items or decide which one to use causing a clash.

As a very beginner, I’ve never had this problem but I am expecting a conflict causing either:

  • Compiling error
  • Crash of the program whle running
  • one of the 2 (or more) items is selected according to some “priority settings”: This scenario is quite risky because the program would run but we “might” not be aware if the wrong item is being used.

Did I hit some of them?

Thanks for the feedback

Cheers

Emanuele

1 Like
#2

You’re on the right track. If you are not using a namespace declaration, then you’re forced to expicitly declare which namespace you’re selecting the function or variable from. No confusion. If, however, you’re using a namespace, then it’s possible that you might forget to qualify a function that might exist in both… the std:: and some custom library. Even worse, you might come back to your code a year later, and forget that you’re using one namespace over another. Remember, your code should always be readable in such a way that you could set it aside for a year, and when you return to it, you should still be able to see what’s going on. using namespace declarations have the potential to muddy those waters.

3 Likes
#3

Thanks Brian fo your feedback! this is an useful Tip. I guess for the purpose of this course is good to know the options available.
I’ve noticed already seen few examples where the namespace is declared everytime, I guess for this very reason.

#4

Hello all,

Just doing my part for the challenge of this section. In the past I have read about this dilemma. At the very basic it seems that using the “using namespace std” method is just limiting and may set oneself up for problems in the future. For instance, when you need to use two or more items from different namespaces. You would have to include another “using namespace” entry. This becomes a bigger problem when two or more namespaces have an item of the same name. Such as “cout”. Then your compiler does not know which one to choose and the program will not work.

From what I can tell, using the format “namespace::item” is the most organized and it takes away the problem of forgetting which namespaces you declared in the begging as you will be calling them each time you use them.

I think that when you begin to make larger and larger programs it will be very benificial to know which namespace you are working out of just by looking at individual snippets of code, rather than zooming up to the top of your code and then back to something your are trying to debug.

1 Like
#5

Hello everyone,

I believe I understand the problem you can run into with using this method of “using namespace”. If you have multiple namespaces with the same items within them, the compiler will not be able to determine which one to use, correct? But if you know before hand that you are going to use multiple namespaces that do not have the same items, than it saves a bit of time not having to type the same things countless times.

#6

hi Bryan H,

Well that should be, in principle, the advantage of the declaration of the namespace.
However I am figuring that in more complex codes you might declare several namespaces, being rather difficult to remember if and which item is shared among them.

I guess you could say:

  • on simple codes you might be 100% sure that there are no overlap, however as it get more complex i think is unrealistic to be always 100% sure about that. If we could assume you can be 100% sure, it would make sense.

  • on more complex codes you might have to declare several namespace out of several reasons and as Brian T said and you want to be sure and unambiguous. Giving the amount of instructions in each namespace, I guess it would be easy to forget if one is shared among multiple namespaces or not, thus resulting in a potentially dangerous practice for your code. I personally liked the suggested approach of “one year later check”, Ref Above

Cheers

Privacy & Terms