Re: post-c++0x: modules in c++
I do not agree. If people need "using namepsace" they can do it in the
current proposal but alot of people (such as myself) do not need it and
your sugestion would force it for these people. I wouldn't use "using
namespace" for ANY big namespace with alot of common names (one good
example is "std" where it makes sense to write "std::list" as oposed to
just "list" since in a big project you have several kinds of lists from
various places).
Please. Read the proposal before answering because I think you didn't:
1.- The import directive won't force anyone not to fully qualify names
if they want to.
2.- You can disambiguate std::list or mylib::list if you want to, as
you would do anyway.
BTW, I am one of those having alot of nested namespaces (max 3 levels, but I
do have alot of 2 levels namespaces) and I don't mind at all the verbosity
especially since you can opt it out with "using namespace", "using" or
namespace aliases to make local short aliases for longer namespaces (such
as I do for "boost::filesystem" which usually gets a "bfs" alias almost
everywhere in non-header code).
You could still use namespace aliases, but you won't need them. And
that's good
because you say you use namespace aliases to shorten names, and with
this you wouldn't
need to shorten anything because it would be taken into scope. And
what is taken into
scope in one module is not necessarily taken into scope in another
one, like with header
files (read the proposal, you'll see how this works)
3.-
//Importing module std (package std in my wording)
import std;
//Now I can use vector<int> or list<int> without std::; because there
is an implicit using namespace std
//with the import statement.
There are very little probabilities of name clashes. You can still do
import std::vector
(assuming std is a folder and vector a module file). You JUST will get
symbols from the
std::vector module, not those which vector includes, because modules
do not get propagated
unless you make a public import inside vector. No name clashes, then.
After all, you can
still fully qualify a name to disambiguate.
1. if the namespace is very big named (including the nesting and such), but
here a better option is a local shorter namespace alias
you will be able to do it. But... why would you? It's a better
solution the
other one, because most of the time you won't have to qualify every
name (less
verbosity)
2. if the namespace has not many "generic" names (std is the opposite,
having alot of too general names such as "list", "vector", "pair" that have
high chance of name clashes)
You won't have many chances of name clashes. You have that with
#includes, but
with modules, which have controlled exporting of symbols it is much
less likely to have
a clash.
I supose which will bring all those general names I fear
You suppose a wrong thing. Because, again, when you import a module
all those general
names you refer won't get exported. Just the ones you expect them to
be there, no more,
no less.
risky situations since includes may be added by someone else not realising
they will bring the whole "std" names in the current scope)
This is exactly how modules DO NOT behave. Because modules do not
propagate another imports
unless a public import is done from the module you import. And that
would be a bad design
choice if you do a public import from things that are not public API.
4. if the names of the namespace that will be brought in current context are
clearly known (and "std" again is the opposite since doing "using namespace
std" may bring alot more than what you know as being the "public" std
names, it may bring implementation specific names, thus a recipe for name
clashes)
Same reason as above. Not likely.
module decides to include something that indirectly will be included by
your code and leading to the name clash?
This is not true for modules. Indirect includes is common in header
files, not in modules.
In modules you can say which symbols will be included. So the clashing
is much less likely.
Read the proposal, please. This is not the behaviour.
That is the problem with "using namespace", the more you use it the more the
risk of having name clash by unrelated changes, thus your code is
not "stable" enough.
And modules is the solution to that problem :-)
An example:
//File std/vector.cpp
private:
//When module vector is imported, all symbols from privateimport are
not seen by the user of module vector.
import privateimport;
namespace std { namespace impl {
class vectorimpl { ... };
}
}
public:
//This import is done public, so public api from publiimport module is
exported when some user imports vector (and it's controlled by the
library writer)
import publicimport;
namespace std {
template <class T>
class vector {
...
};
}
//File mymodule.cpp
private:
import std::vector;
public:
namespace mymodule {
class MyClass {
vector<int> v; //No need to qualify vector in mymodule. Implicit
using directive.
...
};
...
}
//File main.cpp
import mymodule; //This does not export the indirectly included
std::vector module, because std::vector is a private import inside
mymodule
import std::list;
//This could lead to ambiguous code. So you can fully qualify names or
alias names of std::list and something::list;
import something::list;
template <class T> using somelist = something::list<T>;
int main()
{
vector<int> v; //error, vector not included
MyClass mc; //Correct, because there is implicit using namespace
mymodule;
list<int> l; //Ambiguous. You can write std::list<int> or
something::list<int> to disambiguate.
somelist<float> l; //Correct. An alias has been used.
}
This way you avoid a lot of lines of unnecessary using directives and
still works pretty well. You
always have the option to fully qualify names to disambiguate. And
using directives just get applied to the modules
you directly import and for public imports that the module you import
has inside. No more. No name clashes (very few
chances). And you can use alias for commonly used symbols that could
clash anyway. This makes code shorted, almost for
sure. I would say much shorter than now.
{ Edits: quoted signature and clc++m banner removed. Please don't quote
extraneous material. -mod }
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]