I agree with others – it is asking for name clashes,
ambiguities and then the fact is it is less explicit. While I can see the use of
using
, my personal preference is to limit it. I would also
strongly consider what some others pointed
out:
If you want to find a function
name that might be a fairly common name, but you only want to find it in the
std
namespace (or the reverse – you want to change all calls
that are not in namespace std
, namespace
X
, ...), then how do you propose to do
this?
You could write a program to do it, but
wouldn't it be better to spend time working on your project itself rather than writing a
program to maintain your project?
Personally, I
actually don't mind the std::
prefix. I like the look more than
not having it. I don't know if that is because it is explicit and says to me "this isn't
my code... I am using the standard library" or if it is something else, but I think it
looks nicer. This might be odd given that I only recently got into C++ (used and still
do C and other languages for much longer and C is my favourite language of all time,
right above assembly).
There is one other thing
although it is somewhat related to the above and what others point out. While this might
be bad practise, I sometimes reserve std::name
for the standard
library version and name for program-specific implementation. Yes, indeed this could
bite you and bite you hard, but it all comes down to that I started this project from
scratch, and I'm the only programmer for it. Example: I overload
std::string
and call it string
. I have
helpful additions. I did it in part because of my C and Unix (+ Linux) tendency towards
lower-case names.
Besides that, you can have
namespace aliases. Here is an example of where it is useful that might not have been
referred to. I use the C++11 standard and specifically with libstdc++. Well, it doesn't
have complete std::regex
support. Sure, it compiles, but it
throws an exception along the lines of it being an error on the programmer's end. But it
is lack of implementation.
So here's
how I solved it. Install Boost's regex, and link it in. Then, I do the following so that
when libstdc++ has it implemented entirely, I need only remove this block and the code
remains the same:
namespace
std
{
using boost::regex;
using
boost::regex_error;
using boost::regex_replace;
using
boost::regex_search;
using boost::regex_match;
using
boost::smatch;
namespace regex_constants =
boost::regex_constants;
}
I
won't argue on whether that is a bad idea or not. I will however argue that it keeps it
clean for my project and at the same time makes it specific: True,
I have to use Boost, but I'm using it like the libstdc++ will
eventually have it. Yes, starting your own project and starting with a standard (...) at
the very beginning goes a very long way with helping maintenance, development and
everything involved with the project!
Just to
clarify something: I don't actually think it is a good idea to use a name of a
class/whatever in the href="http://en.wikipedia.org/wiki/Standard_Template_Library" rel="nofollow
noreferrer">STL deliberately and more specifically in place of. The string
is the exception (ignore the first, above, or second here, pun if you must) for me as I
didn't like the idea of 'String'.
As it is, I am
still very biased towards C and biased against C++. Sparing details, much of what I work
on fits C more (but it was a good exercise and a good way to make myself a. learn
another language and b. try not be less biased against object/classes/etc which is maybe
better stated as less closed-minded, less arrogant, and more accepting.). But what
is useful is what some already suggested: I do indeed use list (it
is fairly generic, is it not ?), and sort (same thing) to name two that would cause a
name clash if I were to do using namespace std;
, and so to that
end I prefer being specific, in control and knowing that if I intend it to be the
standard use then I will have to specify it. Put simply: no assuming
allowed.
And as for making Boost's
regex part of std
. I do that for future integration and –
again, I admit fully this is bias - I don't think it is as ugly as
boost::regex:: ...
. Indeed, that is another thing for me. There
are many things in C++ that I still have yet to come to fully accept in looks and
methods (another example: variadic templates versus var arguments [though I admit
variadic templates are very very useful!]). Even those that I do accept it was
difficult, and I still have issues with
them.
No comments:
Post a Comment