I am writing c++ in eclipse. When I add a new class it asks for a namespace. I added boost because I am using boost. When I looked at the class eclipse surrounded my class with namespace boost{}. I thought namespace was for java/c# not a c++. Also, I did a little research and it looks like adding namespace boost is a big no no. So I deleted namespace boost. One question, is there a good reason why I should of kept namespace boost and will erasing it haunt me later in the dev cycle?
Thanks, that what I thought. I don't know why eclipse wants me to add a namespace
Erm. #Aaron, "adding" a namespace is good practice, unless you want to be thrown back into the era of C APIs with eternal clashes library symbols or clumy libraryx_myfunction naming conventions.
In fact, chosing a proper namespace for your classes is so elementary that I'd rephrase that. It's not
adding a namespace to your class;
Rather it is
creating a namespace for your to (later) add types and functions to.
Namespaces serve to separate your code from LibraryX and LibraryX from LibraryY etc. Therefore it is indeed bad practice to chose a namespace name that is likely to collide. Defining user defined types is expressly prohibit in the std namespace (or Undefined Behaviour ensues).
Putting stuff into other lirary's namespaces is asking for trouble with
future extensions of the library
internal, undocumented symbols in those libraries
subtle bugs due to ADL (where the library might start finding your function(s) instead of it's own without knowing)
A good reason why I should keep namespace boost?
Why? Are you extending the boost library? I don't see any reason to keep namespace boost, in fact, for small projects, you do not need a namespace at all. Namespaces are designed to prevent name conflict, and for a small project, I doubt you'll have any (be careful about swap though).
Basically speaking, your question is almost the same as asking why I shouldn't surround my code with namespace std, after all, I am using the standard library, right?
Related
I'm trying to use two old (and different) usb libraries in a bigger project by encapsulating them into their own namespace like so:
namespace usbA {
#include "/msp430/usb.h"
}
namespace usbB {
#include "/cypress/usb.h"
}
This leads to linker errors obviously because the names in the actual libraries are not decorated with the namespaces as are the function calls.
Can this be solved without editing the libraries code?
According to some other posters answers this cannot be done. This begs the question of what are namespaces good for then? If I have to go in and modify library source code I can as well prefix each function with "usbA_" instead of using namespace at all. It's equally inflexible.
This leads to linker errors obviously because the names in the actual libraries are not decorated with the namespaces as are the function calls. Can this be solved without editing the libraries code?
I'm sure there will be ghastly ways to hack this, but I would really just … not. In my opinion it's bound to end in tears.
If you really need both libraries, and their names really conflict, I think on balance you're probably best off forking them and giving them namespaces yourself.
This begs the question of what are namespaces good for then?
They're good for nothing if you don't use them (and C code obviously doesn't use them). If these libraries were C++ projects with namespaces, then you wouldn't have this problem, which is good for quite a lot.
It's equally inflexible
Well, this is why C++ introduced namespaces. Sadly you can't force everyone to write C++.
I am working on compiling a very old piece of legacy code with g++ 4.4.7. All I really know about this code is that it was developed on a Irix/Sun system meaning it had a MIPS architecture. One rather odd thing I found when working with this code is that it sometimes calls function like endl and set_new_handler without the std:: prefix. Obviously this results in a compilation error. Since I am working under the assumption that this piece of code compiled on some machine at some time, I am a bit wary about blindly adding the std:: prefix to make it compile since It may change the behavior.
So, is there some old non-ISO compiler that allowed this piece of code to compile? Or is there some sort of flag that I can pass to gcc that would allow this piece of code to work?
The std namespace wasn't introduced into C++ until the first ISO/IEC standard in 1998 (often referred to as C++98). Prior to that time all of the standard library functions and objects were part of the global namespace.
Herb Sutter wrote a piece called Migrating to Namespaces in 2000 detailing his advice on making the transition.
I am not aware of any compiler flags that would fold the std namespace into the global one, and it would be a bad idea anyway - std is much larger today than when it was first introduced, and name collisions would be almost certain. See Why is “using namespace std” considered bad practice?
It is unlikely that you would have a collision with names that were part of the standard library prior to 1998, so it should be safe to pull those names individually into the global namespace. If you are using precompiled headers you can put the using directives in there after including the standard headers that define the symbols and fix the entire project silently. Just add a line for each compiler error you run across.
using std::endl;
using std::set_new_handler;
I would only advise this if your goal is to get the code up-and-running in as little time and effort as possible. The better long-term solution is still to put std:: in front of all the names from the library.
In languages like java, a package name is a domain name, like com.foobar.mystuff.
So if you own com.foobar, it is highly unlikely that someone would have used the package name com.foobar, you can be reasonably sure there will not be a collision.
But in c++, you can choose any namespace name. How do you know if a library you are linking to, is not already using a particular namespace name ? Is there a way to test it, especially if you don't have access to source code or documentation ? Is there some guideline to avoid this problem ?
Is there some guideline to avoid this problem?
While it may surprise you to find that one of the third party libraries you are using uses a namespace as your application, it shouldn't cause too much problem, if any.
In the worst case scenario, you'll have to create a namespace that is specific to your application and create nested namespaces under the main namespace.
Coming from a c# and java background, namespaces are nothing new to me and I have come to love the organizational structuring it brings to code.
I've been doing more work in c++ lately and I try to keep my coding habits as modern as possible. I have been toying around with some sandbox code, trying some new things and I would like to get some feedback on something I've been playing around with.
What I did was create a header file that explicitly declares a series of structured namespaces. The reason I did this is I wanted to layout a predefined structuring for namespaces to be used in the project. I realize that obviously the namespaces could be declared within any classes as the classes are defined but I like the idea of predefined structuring of the namespaces, such as (just an example):
namespace System
{
namespace IO
{
}
namespace Serialization
{
}
namespace Security
{
namespace Cryptography
{
}
}
}
etc. You get the idea.
My question is: Is there anything wrong with this approach? I figured it could be a good practice since it follows good coding practices with encapsulation and naming, etc.
I have seen some strange comments about similar things by old-school c++ devs, such as: "You're trying to combine Java and c++", or "Namespaces are just a way to mangle type names to avoid naming conflicts". I completely disagree with those opinions and don't feel those people are fully understanding the utility that namespaces can provide.
I don't think there's anything inherently "wrong" with it: you're documenting the intended structure of your namespaces.
But, ultimately, it's also pretty pointless, since nothing about this file stops namespaces with the same names from being [accidentally] created in a different structure, leaving you with a broken hierarchy there with actual types declared in it, and your intended hierarchy here with nothing at all in it.
Consequently I'd probably stick to standalone documentation for this sort of thing.
Declaring a namespace hierarchy in a header file is not very useful in practice; including the header file in any other files has no effect.
It seams to me you are trying to create a rule for people working on that project to follow, which or may or may not stick...it's all a matter of style and preference.
But there is nothing wrong with the approach it can do no harm.
I've often found myself wanting a way to undo the effect of a using statement or to include all of a namespace (such as std) but exclude a bit to be replaced (such as cout). For some reason this isn't possible. I am wondering if anyone knows why it was decided not to add this ability to the language? Is there some technical reason? I assume it wasn't just forgotten since it doesn't seem slated for C++0x either.
Just to clarify, I'm not looking for workarounds since Google can show me those. I'm looking for an explanation of why this is impossible, and why it was not considered (as far as I can tell) for inclusion in 0x.
A using directive brings a name or set of names into a given declarative scope.
You can't "un-using" for the same reason that you can't say
int x = 42;
// and later
[remove name x somehow]
There's no way to unintroduce names from a scope at all in C++, regardless where those names came from.
Given that it would overcomplicate name lookup (since names could be both added and removed from a scope), unless there is a really compelling use case, it's unlikely to be considered as a potential language feature.
This is because the using directive is not meant to be used for native C++ code. It was intended to help migrate C code to C++. In this context, "un-using" doesn't make sense.
-edit-
I should have been more specific. In this particular case, it looks like mstearn is using the using directive to include the std namespace globally. Doing this is generally a bad idea because it results in global namespace pollution, and should only be done in certain circumstances, like transitioning from another language to C++.
There are other situations where utilizing the using directive is fine (within a function, namespace composition). However "un-using" doesn't make sense in these situations either.
Mostly because there are workarounds that are sufficiently simple and straightforward that virtually nothing would be gained by including a "feature" for that specific purpose. Though I'm not sure he ever states it directly, I think you could argue that one of the guidelines in the design of C++ has always been to prefer general mechanisms to special-purpose ones, so using the existing scope system (for example) makes more sense than adding some special way to remove something from a scope after it's been introduced.