|
![](/i/fill.gif) |
scott <sco### [at] scott com> wrote:
> > "using namespace" statements might in some cases be justifiable if the
> > name of the namespace is very long and/or there are many nested namespaces
> > (which is sometimes the case). However, a common recommendation in these
> > cases is to use namespace aliases instead (which is possible in C++). It's
> > a bit like a typedef, but for namespaces. For example:
> >
> > namespace bid = boost::io::detail;
> >
> > After that you can use 'bid::' instead of 'boost::io::detail::' as the
> > prefix for names in that namespace.
> In that case what is the benefit of using 'bid::' to qualify every type
> rather than simply putting "using namespace boost::io::detail" at the top?
1) It makes it clear where the names are coming from (which is especially
important if you are using names from several different namespaces, as eg.
boost has quite many of them). The namespace prefix makes it much easier
to recognize a name if you know it, or if you don't know it, it makes it
much easier to know where to look for documentation.
(Since the "namespace bid = boost::io::detail;" ought to be somewhere in
the beginning of the file or the beginning of the function where it's used,
it ought to be hard to miss, so it's easy for the reader to know what it
means.)
2) It greatly lessens the possibility of name collisions if some name
happened to also exist in the global namespace, or if you are doing a
"using namespace" to two different namespaces which have the same name
in them, a name you are using.
> The disadvantages are obvious - having to type bid:: before every type
> (annoying if almost every line contains several types from that namespace)
Do you also use single-character and two-character names for all your
variables, functions and types so that you have less to type?
Brevity only leads to obfuscation, ie. it causes the code to be harder
to understand. Using unambiguous names and prefixes makes the code easier
to read and understand.
> and your code looks very "unoptimised" when the same string is repeated a
> huge number of times.
Unoptimised? I don't understand what you mean. Unoptimized in what way?
At least not in execution speed or memory usage.
Does a piece of code "look very unoptimized" if it has a lot of 'void'
and 'int' keywords? In a typical program there are usually hundreds of
them. So what?
What does "looks very unoptimised" even mean? I don't really get it.
You seem to be of the camp who prefers to trade clarity for brevity.
The shorter the code, the better, even if shortening happens at the expense
of clarity and readability. Well, the only thing I can say to that is that
I wholeheartedly disagree: Brevity is not any kind of virtue in programming.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |