post-c++0x: modules in c++
german diago
great! I know there's quite a few time left for that proposal to be
added to the language. But anyway, I have some suggestions for modules
in C++. I know it's not a finished proposal, so maybe what I say here
is quite obvious but has not been included in the paper.
The paper is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf
My suggestions are:
1.- Module partitions should be simply called "modules" and modules
"packages". This is less confusing since there
are languages like python and java that use this terminology and it's
known to everyone.
2.- When using an import directive, I think that it would be useful
that the import directive had an implicit using namespace, because
it's soooo verbose to use today's c++ with namespaces, that people (at
least this is true for me and some friends I know) don't nest more
than two namespace just because of its verbosity.
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.
//vector is a module partition (module in my wording), so namespaces
in std::vector module should be exported.
import std::vector;
This makes code much less verbose. In the case of ambiguities, you can
still fully qualify a name and makes
coding less verbose.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
dizzy
german diago wrote:
> Hello. I've been checking the proposal to add modules to C++ and it's
> great! I know there's quite a few time left for that proposal to be
> added to the language. But anyway, I have some suggestions for modules
> in C++. I know it's not a finished proposal, so maybe what I say here
> is quite obvious but has not been included in the paper.
>
> The paper is here:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf
>
> 2.- When using an import directive, I think that it would be useful
> that the import directive had an implicit using namespace, because
> it's soooo verbose to use today's c++ with namespaces, that people (at
> least this is true for me and some friends I know) don't nest more
> than two namespace just because of its verbosity.
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).
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).
>
> 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.
Which is wrong because IMO "std" is one of the clear examples where "using
namespace" would result in bad code. Generally I can see the utility
of "using namespace" as this:
1. if the namespace is very big named (including the nesting and such), but
here a better option is a local shorter namespace alias
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)
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"
even in headers I supose which will bring all those general names I fear
about in any code that indirectly includes this header, 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)
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)
Doing "using namespace std" automatically with "import std" beats all the
purposes above I believe.
>
> //vector is a module partition (module in my wording), so namespaces
> in std::vector module should be exported.
> import std::vector;
>
> This makes code much less verbose. In the case of ambiguities, you can
> still fully qualify a name and makes
> coding less verbose.
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?
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.
--
Dizzy
german diago
> 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 }
--
german diago
> 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 }
--
german diago
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).
The implicit using directive wouldn't force you not to use std::list
in the
case of ambiguity, so you don't get ANY problem with name clashes. You
are still
allowed to write std::list. This is what C# does. When you write using
System;
you import the namespace. Now you can write System.Console.WriteLine
or simply
Console.WriteLine. And it works pretty well. But I'm not sure if the
mapping in
C++ modules would be similar or not.
> 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.
The sad truth is that verbosity is a thing that makes code less
readable sometimes.
It's tedious. And if you don't mind verbosity, take in account that
there are other
people who do care verbosity. With my proposal you can still get it as
verbose as you
like (you can fully-qualify names) but I don't want to, if it's not
necessary.
> 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).
The point
with modules is that you don't need using namespace for EVERY
namespace which can make you
use like 4 or 5 lines of using directives when it could be completely
avoided and there's no
drawback in that.
> Which is wrong because IMO "std" is one of the clear examples where "using
> namespace" would result in bad code. Generally I can see the utility
> of "using namespace" as this:
> 1. if the namespace is very big named (including the nesting and such), but
> here a better option is a local shorter namespace alias.
> 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 disambiguate name clashes with FULL QUALIFICATION, don't
ignore me, I'm
telling you you still have the option. And that's what you do in your
code, at
least that's what you said. You don't get any drawback.
> 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"
> even in headers
I think you didn't read the proposal at all. With modules, header
files disappear.
With modules, you can control which exported symbols are public and
which of them AREN'T.
With modules you won't get imported anything else that the public
symbols included in the module
you imported. I mean that #includes are not propagated like in today's
C++. So if you happen to have
a module which imports another module but the import from that module
is private, you don't get clashes
for those symbols.
>I supose which will bring all those general names I fear.
> about in any code that indirectly includes this header, 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)
Incorrect. See above.
> 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)
>
> Doing "using namespace std" automatically with "import std" beats all the
> purposes above I believe.
>
>
>
> > //vector is a module partition (module in my wording), so namespaces
> > in std::vector module should be exported.
> > import std::vector;
>
> > This makes code much less verbose. In the case of ambiguities, you can
> > still fully qualify a name and makes
> > coding less verbose.
>
> Are you saying that you have "using namespace std" in your commonly included
> headers?
I think you didn't read the purpose of modules. Modules DO NOT include
what you don't
want to be indirectly include. Read the modules proposal and be
serious about your answers,
please.
> 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?
No name clashes. Well-designed modules just will show the symbols you
can expect from importing
that module. Not all the other symbols you want to be exported so that
I'm wrong.
>
> 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.
Again. It's much more difficult to have a name clash in modules
because imports don't propagate like
includes if you don't want. And in the case (still possible, but not
like with headers) of clashes, you
can fully qualify the ambiguous names. So, I think that using
namespace makes sense with headers, but
not with modules. What still makes sense is alias for symbols. Look at
this example:
//MyModule.cpp
private:
import anotherthing;
import somethingelse;
public:
import whatyouexpecttobeincluded;
namespace MyModule {
class A { ... };
}
//MyModule2.cpp
import MyModule; //This will import public symbols from MyModule and
public symbols from whatyouexpecttobeincluded
//Why to use a using namespace MyModule?? There are no name clashes.
In
//this code just code from namespace MyModule and public namespaces in
module
whatyouexpect are searched. No interference neither with module
anotherthing nor
with module somethingelse.
//alias still makes sense.
using MyNameWithProbabilityOfClash = MyModule::CommonName;
int main() {
A a;
MyNameWithProbability
}
You get less verbose code. Look at it. And it doesn't have any
of the problems you mentioned about, because modules do not propagate
symbols if you make private import.
{ Edits: quoted signature and clc++m banner removed. Please don't quote
extraneous material. -mod }
--
Bart van Ingen Schenau
<snip>
> 2.- When using an import directive, I think that it would be useful
> that the import directive had an implicit using namespace, because
> it's soooo verbose to use today's c++ with namespaces, that people (at
> least this is true for me and some friends I know) don't nest more
> than two namespace just because of its verbosity.
I strongly disagree on this.
If the statement
import std;
automatically implies that (the equivalent of)
using namespace std;
follows, then it becomes impossible to create optimised drop-in
replacements for parts of the standard library.
This becomes impossible, because a module 'optimised_sorting' that
provides a function template optimised_sorting::sort() with the same
signature as std::sort() can not be imported without causing a name
conflict.
You could resolve the conflict with explicit qualification, but the
purpose of a drop-in replacement is that you do not have to go through
all the code to find and change each use.
On the other hand, if the import directive does *not* imply a using
directive, it is still possible to use drop-in replacements from other
modules and people like you only have to write some additional lines of
boilerplate code for the explicit using directives.
In my view, making the using directive implicit in the import directive
has the same net effect as completely removing namespaces from the
language.
>
> 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.
>
> //vector is a module partition (module in my wording), so namespaces
> in std::vector module should be exported.
> import std::vector;
>
> This makes code much less verbose. In the case of ambiguities, you can
> still fully qualify a name and makes
> coding less verbose.
I don't see how a few explicit using declarations or using directives
make the code so much more verbose.
Worst case, it is like 20 additional lines at the top of a source file,
or one or two at the start of a function.
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
dizzy
>
>> 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.
But that's not the point. I am using unqualified names for local names and
having import do "using namespace" would create the potention of conflict.
I would like to have the choice between doing using namespace and not doing
it as we have it today with include.
> 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)
As I described bellow "using namespace" is not a solution for anything when
importing unknown, many, potentially conflicting names in popular headers
(and you proved that modules reduce the ammount of unknown exposed names
but they do not remove it completely so there's a problem).
>
> 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.
If you assume there will be a module for every possible name from the std
namespace, that's too much isn't it? "vector" is a good example for your
sugestion but I find another, not so good, "utility". How do you control
which names it brings and which doesn't? or "algorithm" (like I want to
have my sort and use it with "sort" without possible nameclash with
std::sort for which I qualify so there is no name clash).
In general in my code when I refer to my own types I use unqualified names
(since they are in the current namespace of my code anyway) and when I
refer to whatever library types I qualify them (which makes sense since
they are external and out of my direct control). Your sugestion would make
it have to qualify internal names too since possible name clashes from
bringing library names into the local context. And I really don't see how
code would look any way better when one would have things like:
namespace mycode {
void MyClass::func(mycode::SomeType arg) {}
}
instead of the simple and more direct:
namespace mycode {
void MyClass::func(SomeType arg) {}
}
(since SomeType is in the same namespace as "mycode" it makes sense not to
require qualification)
> After all, you can
> still fully qualify a name to disambiguate.
But I do not want to be forced to do this for local code. One big advantage
IMO of C++ namespaces in general is that they find unqualified names
without qualification if you are in a namespace context and that
unqualified name is in that context, which follows a natural design of the
code. That is, I have a project which has everything in the
namespace "project" and does use boost and std. Thus, when I refer to my
own names I do not need to qualify them since the code is too in the same
namespace and it will find unqualified names in the same namespace. When I
need to refer to library names I always qualify them since I do not have
direct control over their names (someone else maintains that library code
so I need to make sure I don't create name clashes just upgrading a version
of the library code).
>
>> 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.
What about "algorithm", "utility" and other modules which may bring more
than a single name?
>>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.
How can you specify that importing "algorithm" you expect
only "std::transform" to be brought in the current namespace?
> 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.
Ok, that is a good thing about modules. But still doesn't provide the per
name control I want, plus I almost never refer to library names unqualified
(but I do to my own names).
This still forces me to qualify local names which normally I don't. Also it
does not fix the situation of modules with many names (vector is not such a
module as you describe).
> 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.
>From what I understand I don't have this option anymore, you force me to
qualify for my own names to avoid possible name clashes from automatic
using namespace of public module names.
--
Dizzy
Martin Bonner
> On 27 feb, 17:53, dizzy <di...@roedu.net> wrote:
>
> 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).
>
> The implicit using directive wouldn't force you not to use std::list
> in the case of ambiguity, so you don't get ANY problem with
> name clashes.
Yes you will. The compiler won't be confused, but if I see "list" in
a particular file I will assume that it is std::list (just like in the
other 5000 files in the code-base). However in this particular case,
it may refer to some other list.
If one has a standard of always writing std::list, and then I just see
a naked list, I will expect it to be something different. Please
don't say "but you still /can/ write std::list"; I like my compiler
set up to enforce my coding conventions.
The main point of code is to communicate with other programmers - not
the compiler. Requiring import to force a "using namespace" will
complicate that.
german diago
> In my view, making the using directive implicit in the import directive
> has the same net effect as completely removing namespaces from the
> language.
This does not remove namespaces at all since because if you fully
qualify
a name, it will be still there, where it was before.
> You could resolve the conflict with explicit qualification, but the
> purpose of a drop-in replacement is that you do not have to go through
> all the code to find and change each use.
You could still use a namespace alias at the top of the module, and
everything could go ok:
using sort = optimised_sort::sort;
and everything would be located at the beginning of the module without
that problem. What do you think of this solution?
--
Bart van Ingen Schenau
>
>> In my view, making the using directive implicit in the import
>> directive has the same net effect as completely removing namespaces
>> from the language.
>
> This does not remove namespaces at all since because if you fully
> qualify
> a name, it will be still there, where it was before.
I didn't say it actually removes them, it just defeats the entire reason
for having them in the first place.
Yes, I can still qualify my names and if there happens to be a
name-clash, I will be forced to do so for every occurrence of the name
as if the namespace name is a prefix to the actual name.
>
>> You could resolve the conflict with explicit qualification, but the
>> purpose of a drop-in replacement is that you do not have to go
>> through all the code to find and change each use.
>
> You could still use a namespace alias at the top of the module, and
> everything could go ok:
>
> using sort = optimised_sort::sort;
This is not a namespace alias.
This is, and it would not help me one bit:
namespace os = optimised_sort;
> and everything would be located at the beginning of the module without
> that problem. What do you think of this solution?
I think it would be a non-solution for a problem that should not be
introduced in the first place.
The rules for unqualified name lookup are already difficult enough,
without adding more complexity due to this kind of generic name
aliasing.
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]