Re: post-c++0x: modules in c++
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 needn't to get the nesting symbols, since you can make private the
nested namespaces
and symbols that won't get exported in modules (that's the point of
modules)
.. Please, read the proposal, you got confused I think.
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 can still fully qualify names (to disambiguate), like you do in
your code,
and still wouldn't be so verbose
as the one you get today.
3. if the "using namespace" is done in a very local context, such as a
function body or a "cpp" file (but mandating "import" to do "using
namespace" breaks this completely since people would want to use "import"
This makes sense with headers, but not with modules. It could be
allowed for compatibility reasons,
but anyway, with modules does not make sense.
Just with all the using namespace you say you use you can get easily
as long as 10 lines of code in a single
..cpp file . If you do this in, say, 40 files, you have -> 10 * 20 =
200 lines of extra code and FOR NO REASON.
even in headers I supose which will bring all those general names I fear
about in any code that indirectly includes this header,
Wrong. Modules don't behave like that.
which leads to very
risky situations since includes may be added by someone else not realising
they will bring the whole "std" names in the current scope)
If you do: import std, for example.
You won't get the whole std names, because it's likely you will do
import std::vector
if you want, instead of import std (which you will be able to do too,
I think). And
you won't get visibility for non-exported namespaces (the private
ones)
.. So name clashes are not likely.
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)
Again. No implementation defined names will be exported in well-
designed module code, since
these will stay in private qualified zones of the module. So you're
wrong with this.
I think you didn't read the proposal. With modules you won't get name
clashes like
with includes. Header files disappear. Implementation specific names
won't be exported since
they are written in private qualified module parts so they are just
visible from the module
itself. If you import std it's not like #include
<allstdwithimplementation>, it's just
#include <allstdwithoutimplementation>. And still, you could import
std::vector if you'd like
and you would get just things from vector. Just the public API is
exported.
I think you even didn't read the proposal. Read it first because what
you said is not correct.
Are you saying that you have "using namespace std" in your commonly included
headers? And you don't have name random clashes because someone else in his
module decides to include something that indirectly will be included by
your code and leading to the name clash?
What you say makes sense now with headers (using directives). But with
moudules, and with what I said above,
what you say doesn't hold. You can still use std::list if you want to
disambiguate.
You won't get strange exported symbols you didn't know of importing a
module, because that's one of
the purposes of the current modules proposal.
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.
That's one of the things that modules solve. When you import a module
in another module you get a using directive
for THAT module (in my proposal is implicit), not for other modules
that will import that module.
You get the idea? No propagation like with
headers. So code is perfectly stable and does not clash.
Let me give you an example of how modules would work with my proposal
(whose only change is implicit using)
, and how they would NOT work. You think
they work another way. The only using directive that makes still sense
is to make aliases for symbols. Look at the
example, I'll show you how I think this should work. And with modules,
there are not header files, just .ipp or something
like that (which are interface files generated by the compiler)
//File vector.cpp
....
private:
//This module won't be imported when vector is imported. It's just
used from inside this module.
import privatemodule;
//This won't be visible with an import directive
namespace std {
namespace impl {
class vectorimpl {
....
};
}
public:
//this import will make publicmodule's public API to be imported when
vector is imported
import publicmodule
//This one will be visible
namespace std {
template <class T>
class vector {
....
};
}
//File main.cpp
/** This directive imports the symbol vector. Not even anything from
privatemodule or
* std::impl. vector is exported, because it's a public symbol.
Module publicmodule
* public API is also exported, so you have control over exported
symbols*/
import std::vector; //Syntax by me (not the proposal one, but makes
sense)
import std::list;
//You can still use an alias for symbols
template <class T> using stlist = std::list<T>; //This is a new
proposal c++0x, but it's a using directive for alias.
int main(int argc, char * argv[])
{
//Can be used without qualification
vector<int> v(10);
//Also correct
std::vector<float> vf(10);
stlist<float> sl;
}
And that's all. The implicit using directive is for namespace std and
whatever public namespaces
are inside publicmodule. No privatemodule symbols are ever seen from
main.cpp. And if you happened
to import a module and then import that module to other one, the using
directive will just be propagated
for the public imports, not for the private ones, behaving as a user
would expect.
{ 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! ]