So sue me again (namespaces)
Scott Meyers
neat trick, by the way, and one I'd never seen before), but I'm hoping
they'll let me sneak this in on the basis that I was the one asking to be
sued.
{ This is a hot subject and a cool discussion is desirable. Please
concentrate on the concepts and facts without attacking others
and their opinions. -mod/jep }
On 14 Jul 2001 20:42:19 -0400, David Abrahams wrote:
> The problem was that this standard library implementation (the one that
> comes with GCC-3.0) uses unqualified calls to standard algorithms (a
> nonconforming implementation technique). So, for example, its
> implementation of std::vector<T,A>::insert(...) tries to call std::fill
> like this:
>
> fill(__position, __position + __n, __x_copy);
>
> I happen to have a type called "fill" in my own namespace (in case you
> think that's a crazy name for a type, it's used to compute fill-in for
> sparse matrix operations). Because the first template argument to the
> vector I was using lives in the same namespace as my fill type,
> argument-dependent lookup is forced to add the name "fill" from my
> namespace to the set of considered overloads. When it does, it finds that
> the call is ambiguous and complains that my "fill" isn't a function.
Note two things here. First, the library should have used a qualified
call, i.e., std::fill instead of fill. Second, the problem involved
argument-dependent lookup, aka Koenig lookup. Both are important to the
position I have come to hold. In fact, I was surprised to see so little
mention of the interaction of namespaces and Koenig lookup in the thread.
On 14 Jul 2001 20:48:06 -0400, Pete Becker wrote:
> claimed that it is "sooooo dangerous". I have said that proper analysis
> of the issue requires weighing the likelihood of failure and the
> seriousness of the resulting harm against the benefit of this practice.
Where Pete writes "benefit," I think he means "cost".
I chose to quote Dave and Pete because of the following:
On 11 Jul 2001 01:11:41 -0400, Herb Sutter wrote:
> I'll let [Scott] speak for himself when it comes to technical details,
> but just as data points: He thinks he also wrote "so sue me" in public
> posts, not just private email, and routinely writes using directives at
> function scope and somewhat less at global scope; and just yesterday a
> client (who writes libraries) had asked him about his recommendations for
> namespaces, and the answer said what I've been saying except that it went
> even further than I would have dared go. I'm sure Dave and Pete would be
> properly horrified at the advice he gave, whereas I happen to think
> there's a lot of merit in it.
So here's the horror: if it were up to me, we'd get rid of namespaces
entirely.
First, I think they were created to solve a problem that largely fails to
exist. No C programs use namespaces and most C++ programs use no
namespaces other than std (unfounded assertion -- so sue me), and my
experience in working with a wide variety of software companies in the past
decade is that problematic name conflicts are uncommon. Anecdotal
evidence? Certainly. Sue me. Why have we gotten along this well for so
long? Because of the unque-prefix convention, whereby global symbols
beloning to library xyz tend to be prefixed with xyz, e.g., xyzfill. In my
view, the unique prefix convention worked well, was completely portable,
and required no language support.
Interestingly, it is increasingly becoming clear that library authors must
adhere to Dave's suggestion above: avoid unqualified names. For names like
fill or count in std, this means that library source code must always refer
to std::fill or std::count to avoid surprises. But if that's the case, why
not get rid of the colons and use the unique-prefix solution, e.g.,
stdfill? Where is the benefit of namespaces if we have to fully qualify
our uses of the names in them?
But Koenig lookup is the really kicker. Those of you who are familiar with
the history of namespaces will recall that Koenig lookup was added when it
became clear that the name lookup rules introduced with the first draft
semantics of namespaces led to programs failing (due to name lookup
failures) that everybody wanted to succeed. Like magic, Koenig lookup
makes them succeed. But it's a double-edged sword. Koenig lookup also
makes some calls fail that we would like to succeed -- calls that would
succeed if namespaces didn't exist. I don't have the time now to look up
the particulars, but it's my understanding that somewhere at Boost is an
analysis of this issue, and I think Herb may have written a GotW on how
Koenig lookup can warp user code from its own namespace to the std
namespace, where necessary user names are suddenly hidden by the name
lookup rules. And recently I've been seeing talk of making function names
like "swap" essentially reserved to get around these problems.
Here's my summary of the history of namespaces:
Namespaces Version 0 (no Koenig lookup): Oops, some things fail that
shouldn't...
Namespaces Version 1 (Koenig lookup): No problem, we can hack it
to make it work.
Namespaces Version 2 (whatever Hmmm, that hack didn't work
comes next): as we thought it would.
Maybe this will fix it...
Don't get me wrong, I have tremendous respect for the people who have been
working on namespaces, only one of whom is named Koenig. I just think that
namespaces are an experiment that failed. In Pete's terms, I don't think
the benefits of the practice justify the costs. Others almost certainly
disagree.
Oh, a brief note on nested namespaces. When was the last time anybody made
effective use of std::rel_ops? My conclusion from that fiasco is that
namespaces don't effectively nest, another victim of unanticipated
interactions in name lookup rules.
And one more thing. I think using declarations are a syntactic pain in the
hind quarter, and for that reason I don't recommend their use. They're a
pain to type (over and over and over at the top of each function), and I've
noticed that in practice they tend to harken back to the days of C before
C99, because pretty much all the examples I've seen of their use cluster
all the using declarations at the top of a block, just like declarations in
C89. To me, this is not progress, and it doesn't make it easier for
programmers to get their jobs done more clearly or easily.
For those of you itching to take shots at me, let me give you all
the ammo you need:
- I don't write software for a living, and I haven't done it in many,
many years. I make my living by *studying* C++, not by using it.
- I have never written or worked on a million-line library or framework
that had to stay in use for years at a time with tens of thousands of
customers.
- My hair style calls into immediate question all my judgements.
However, there are some factors that might be viewed as mitigating:
- In the past decade, I have personally worked with hundreds of
programmers in scores of teams from dozens of companies in a fair
number of different problems domains. I get around a little. I see
what people write. I talk to them about why they do it the way they
do. I listen to them.
- I have written three books and a bunch of articles on C++, and I get
mail from my readers. When I make mistakes or make impractical
suggestions, they are not shy about letting me know.
I don't think I'm completely out of touch.
Assuming the moderators let this through, there may be follow-ups. The
follow-ups may ask questions. Let me apologize right now for almost
certainly not having enough time to reply to them. I keep up with the
newsgroups when I can, and I feel guilty when I ask more of them than I
have time to give back (which has recently been the case, I fear). I'm
posting this in part because people were speculating about my "so sue me"
comment, but also because I wanted to air my feelings about namespaces and
see what other people think of my ideas. If you don't see me post on
this thread again, have faith, I'll be reading anything that follows. I
just may not get around to it until October. Sigh.
Scott
--
Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/
Also check out "Effective STL," http://www.aw.com/estl/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Richard B. Kreckel
[...]
: So here's the horror: if it were up to me, we'd get rid of namespaces
: entirely.
:
: First, I think they were created to solve a problem that largely fails to
: exist. No C programs use namespaces and most C++ programs use no
: namespaces other than std (unfounded assertion -- so sue me), and my
: experience in working with a wide variety of software companies in the past
: decade is that problematic name conflicts are uncommon. Anecdotal
: evidence? Certainly. Sue me. Why have we gotten along this well for so
: long? Because of the unque-prefix convention, whereby global symbols
: beloning to library xyz tend to be prefixed with xyz, e.g., xyzfill. In my
: view, the unique prefix convention worked well, was completely portable,
: and required no language support.
No, it didn't work well -- not at all. In my experience, people were
attaching prefixes everywhere where they suspected nameclashes could
occur and omit them where they thought it would be safe to omit them.
In the next release-cycle they found that there were some clashes at
places were they thought no clashes could occur. They then inserted
prefixes at those places, forcing people to recompile everything and
insert `#if (PROJECTVERSION<=314)' around the places where name changes
have occured. Repeat cycle.
You can see this sad thing happen all over the place. Just have a
look at the last Changes made to the GNU Readline library at
<http://cnswww.cns.cwru.edu/~chet/readline/rltop.html>.
Having namespaces at their availabilty, people can now wrap their
*entire* library inside that namespace without having to think (and
err) what can possibly ever clash and what not. This makes software
much more stable.
[...]
: Oh, a brief note on nested namespaces. When was the last time anybody made
: effective use of std::rel_ops? My conclusion from that fiasco is that
: namespaces don't effectively nest, another victim of unanticipated
: interactions in name lookup rules.
Can anybody enlighten me what that fiasco was about? Was the fiasco
about the operators defined in std:rel_ops or was it about the
namespace nesting? I recently submitted a bugreport concerning
std::rel_ops brokenness in GCC-3.0 and a heated discussion arose were
people claimed (without detailed justification) that the operators are
known to be evil and the fact that they were put into std::rel_ops was
an indication of this. No consensus was reached. (It's in Gnats at
<http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3628>.)
Regards
-richy.
--
Richard B. Kreckel
<Richard...@GiNaC.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Pete Becker
>
> On 14 Jul 2001 20:48:06 -0400, Pete Becker wrote:
> > I have said that proper analysis
> > of the issue requires weighing the likelihood of failure and the
> > seriousness of the resulting harm against the benefit of this practice.
>
> Where Pete writes "benefit," I think he means "cost".
No, I meant benefit. The point was that looking only at the likelihood
of failure isn't sufficient. Likelihood of failure times seriousness of
resulting harm is the probable cost, and a cost-benefit analysis weighs
that cost against the benefit. If the benefit is less than the cost then
it's not worth doing, regardless of how unlikely the failure is.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Markus Schaaf
already wondered at before:
"Scott Meyers" <sme...@aristeia.com> wrote:
> On 14 Jul 2001 20:42:19 -0400, David Abrahams wrote:
> > The problem was that this standard library implementation (the one that
> > comes with GCC-3.0) uses unqualified calls to standard algorithms (a
> > nonconforming implementation technique). So, for example, its
> > implementation of std::vector<T,A>::insert(...) tries to call std::fill
> > like this:
> >
> > fill(__position, __position + __n, __x_copy);
> >
> > I happen to have a type called "fill" in my own namespace (in case you
> > think that's a crazy name for a type, it's used to compute fill-in for
> > sparse matrix operations). Because the first template argument to the
> > vector I was using lives in the same namespace as my fill type,
> > argument-dependent lookup is forced to add the name "fill" from my
> > namespace to the set of considered overloads. When it does, it finds that
> > the call is ambiguous and complains that my "fill" isn't a function.
>
> Note two things here. First, the library should have used a qualified
> call, i.e., std::fill instead of fill.
Would "std::fill" be qualified enough? You could have done something
like this:
namespace my
{
class T { /* ... */ };
namespace std
{
void fill( /* ... */ );
}
}
I don't even know if Koenig-lookup takes "my::std::fill" in account,
but if it does, that's a problem too. In fact "std" isn't a reserved
word, is it?
Stan Brown
comp.lang.c++.moderated:
>First, I think they were created to solve a problem that largely fails to
>exist. No C programs use namespaces and most C++ programs use no
>namespaces other than std
Obviously no C programs use namespaces. No C++ programs use 'record'
or 'perform' either. It hardly seems worth mentioning that programs
written in a particular language don't use constructs that are not
part of that language. Surely you don't mean to advance the
principle that something missing from one language is bad for other
languages? In that case you would have to say that Smalltalk doesn't
need garbage collection because C++ doesn't have it.
As to most C++ programs using only std and not other namespaces, I
doubt you or I know about "most" C++ programs. But if we stipulate
that your assertion is true, again it is unremarkable. To write a
conforming C++ program that actually does anything, you have to use
std, at least by implication. Contrariwise, namespaces themselves
are relatively new and it takes time for new features to get taken
up in practice and exploited to advantage.
The C++ committee may have exceeded its plan a bit by mandating
namespaces in the absence of widespread "prior art".(*) But I think
they did well. The problem of name conflicts was well known and
pervasive; namespaces solve it, and at no run-time cost in time or
space.
(*) Suddenly I can't remember whether the committee added namespaces
or took them up from the ARM. I don't think the point is important
for this discussion, but I acknowledge uncertainty here so that the
side issue doesn't distract us.
If you don't think naming conflict is a real problem, you're free to
ignore namespaces completely by using old-style headers. So everyone
is well served.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
Carlos Moreno
Scott Meyers wrote:
>
> So here's the horror: if it were up to me, we'd get rid of namespaces
> entirely.
If it ever comes down to voting, and normal mortals like me are allowed
to vote, don't forget to drop me an e-mail if you need support!! :-)
Actually, I don't think I hate namespaces as a whole. What really
annoys me is the std namespace. Namespaces should be an optional
feature that we choose to use, not one that is forced to us.
Standard library facilities shouldn't clash with user-provided
things -- standard library facilities were there first!!! (and
if they weren't, too bad: they're standard library facilties).
User-provided facilities are the ones that could conflict with
other things -- so, if anything, user-provided toolkits could
(should?) be in their namespace. In the particular cases where
you use them, then you put up with the namespace syntax overhead;
but when you're dealing with standard library facilities, why
would you need to be extra-specific with what you type?? Why
do you need to be extra specific to say that you mean std::cout
and not just cout?? (like no one is familiar with cout!)
At the risk of sounding disrespectful, I see the std namespace as
one of those "politically correct" practices. They're good because
any software professional that has some self-respect says they're
good. Why? Because! You have to say they're good, you have to
be horrified at the sight of a call to a standard facility that is
not explicitly qualified, etc. -- or you suck as a software
professional.
One of the main reasons why I hated Pascal was the excess of
keywords to do just about anything. <exaggeration> For (whatever),
do, begin, start, go -- and then finally you can put the one
statement you wanted in the loop </exaggeration>.
The feeling of the redundant std:: qualifications everywhere kind
of reminds me of that feeling (of course, keeping the distances!
Pascal was dull and plain, so the excess of keywords was enough
to make me hate it; C++ is pure poetry...). Coming back to the
topic, I was saying that when I see
std::string name;
std::getline (std::cin, name);
std::cout << "Hello, " << name << std::endl;
I can't help but wonder why is it that <exaggeration> I had to take
two minutes to type something that should have taken ten seconds
</exaggeration>, <sarcasm> with the only benefit of making the
code 10 times less readable. (What is an "std::string"??? That's
not even a word!!!) </sarcasm>
> But if that's the case, why
> not get rid of the colons and use the unique-prefix solution, e.g.,
> stdfill? Where is the benefit of namespaces if we have to fully qualify
> our uses of the names in them?
I think the :: is indeed intuitive. It does suggest scope. True,
a prefix also suggests scope, but the :: suggests it in a way that
is more consistent with the C++ syntax.
> makes them succeed. But it's a double-edged sword. Koenig lookup also
> makes some calls fail that we would like to succeed -- calls that would
> succeed if namespaces didn't exist. I don't have the time now to look up
> the particulars
template <typename T1, typename T2>
ostream ...
I mean, excuse me... apologies... I meant:
std::ostream & operator<< (std::ostream & out, const std::pair<T1,T2> &
p)
{
out << p.first << ", " << p.second;
}
> For those of you itching to take shots at me, let me give you all
> the ammo you need:
Don't worry, they'll have easier targets -- me, for instance ;-)
I'm guilty on all the counts you say you're guilty (including the
hairstyle -- though I always thought that, for software professionals,
that would act as a plus concerning other's view about our judgement
;-)), plus many more, plus I haven't written any highly respected
books... (and now that we're on it, you can remove the "highly
respected" namespace qualification ;-))
Carlos
--
Gabriel Dos Reis
[...]
| Oh, a brief note on nested namespaces. When was the last time anybody made
| effective use of std::rel_ops?
std::rel_ops was created to sequester those too greedy operators which
don't interact very well with the rest of the library and user
programs. If your experience is that it isn't routinely used, then
that experience should be counted as a namespace success story:
std::rel_ops makes it possible to nearly hide things which should
never have been there in the first place :-)
--
Gabriel Dos Reis, dos...@cmla.ens-cachan.fr
Mark Wilden
news:MPG.15eba7c9...@news.hevanet.com...
> No C programs use namespaces and most C++ programs use no
> namespaces other than std (unfounded assertion -- so sue me)
I can't speak for most C++ programs (or most C++ programmers), but I
personally do use my own namespaces quite a bit. For example, as "the
database guy" in my current job, I'm off on the outskirts of the "real"
project (a peers-to-peer download utility), so I don't want to step on any
toes. My Client class is related to the database, and the other programmers
may have their own Client class that manages information about clients in a
different way, for different reasons. I also have classes or typedefs called
IP_Address, Address, State, and other common names. Hence, I've avoided
conflicts (both personal and technical) by putting my stuff in a DB
namespace. And of course I have "using namespace DB;" at the top of all my
sources. :)
But I find Scott's iconoclasm intriguing, and will be very interested in
what others have to say. Because, after all, what would it really cost for
me to call my class DBClient?
> - My hair style calls into immediate question all my judgements.
Yes, I've been meaning to write to you about that.
:)
Dave Harris
> In my view, the unique prefix convention worked well, was
> completely portable, and required no language support.
In my experience the unique prefix convention produced names which were
short and cryptic, or long and unwieldy. I prefer namespaces. I use
longish namespace names for clarity and then get rid of them with using
declarations where I need to avoid clutter.
> When was the last time anybody made effective use of std::rel_ops?
> My conclusion from that fiasco is that namespaces don't
> effectively nest, another victim of unanticipated interactions
> in name lookup rules.
I have used nested namespaces, without problems. I tend to put all my
library code into a library namespace, and I also put enums into their own
namespace, so library enums are in nested spaces. They work fine.
I think the design of std::rel_ops is flawed for other reasons. What I
want is to generate relational operators for one precise type at a time. I
don't think std::rel_ops can do that.
> using declarations [...] a pain to type (over and over and over at
> the top of each function),
I don't do that. They either go once at the top of the one function which
needs them, or, if there are many functions, they go at the top of the
source file. When they are at the top of the file they are notionally
similar to #include statements.
> [...] avoid unqualified names. For names like fill or count in
> std, this means that library source code must always refer
> to std::fill or std::count to avoid surprises.
Alternatively, document the use of the names. I would like to be able to
provide my own specialised fill or count or whatever, and have the
libraries use it where appropriate.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Alf P. Steinbach
Namespaces seem to be in the spirit of C/C++ in that before namespaces
you had to use file inclusion, conditional compilation, "static", name
prefixes and some runtime library support (atexit) in order to assemble
something halway corresponding to a logical module. With namespaces
one more tool is added to the mix. Even with all this there are still
the problems of guaranteed module initialization order, information
hiding wrt. modules exposed via a given module's interface (pimpl idiom
solves some of that), resolution of name clashes.
A truly useful namespace construct would IMO have to be integrated with
a logical module concept, and with templates, but then we're talking
a very different language, namely where the language's power is based on
*limitations that enable*, rather than the original C/C++ "do anything
you want" that at some scale don't scale.
So, I don't think the trouble with namespaces is the particular annoying
things about them, but that they *by necessity* must have some problems
because they in the best tradition of C and C++ are based on being
decoupled from everything else (which is never quite achieved 100%),
and used at the programmer's discretion, instead of being part of an
integrated concept and limited to whatever is meaningful for that concept.
Cheers,
- Alf
E. Mark Ping
Scott Meyers <sme...@aristeia.com> wrote:
>First, I think they were created to solve a problem that largely fails to
>exist.
Well, I sure am glad the std namespace exists, or it would be nigh
impossible to migrate from classic streams in our project.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Herb Sutter
>: Oh, a brief note on nested namespaces. When was the last time anybody made
>: effective use of std::rel_ops? My conclusion from that fiasco is that
>: namespaces don't effectively nest, another victim of unanticipated
>: interactions in name lookup rules.
>
>Can anybody enlighten me what that fiasco was about?
Basically, as I was told by the person who proposed putting them into
rel_ops, it was a deliberate act to bury them and make them go away. (Note
that was his intention, which I point out succeeded, but not everyone who
voted for it necessarily had the same intention.)
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
Gabriel Dos Reis
| Would "std::fill" be qualified enough?
Qualification suppresses Koenig lookup.
--
Gabriel Dos Reis, dos...@cmla.ens-cachan.fr
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<bra...@mindspring.com> writes
>>First, I think they were created to solve a problem that largely fails to
>>exist. No C programs use namespaces and most C++ programs use no
>>namespaces other than std
>
>Obviously no C programs use namespaces.
C programs are also, on average, much smaller than C++ ones and so name
collisions are less of a problem. Actually something like namespaces has
been considered for C but we had enough else to do and it was of minor
importance.
The other feature of namespaces that can be useful is that the create
limited contexts, which can be useful for templates.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Dave
>Note two things here. First, the library should have used a qualified
>call, i.e., std::fill instead of fill. Second, the problem involved
>horror: if it were up to me, we'd get rid of namespaces entirely.
>to exist... Why have we gotten along this well for so long? Because
>of the unque-prefix convention....
We're talking about a couple of separate issues here. One issue is name
matching. Another issue is program organization.
There are two kinds of name matches in C++:
1. Those that we want, and
2. those that we don't want. [Note 1]
We all want to maximize type 1, while minimizing type 2.
But that's not so easily done. We make it difficult for ourselves by
sometimes wanting names to match library names, and other times not. For
example, when David Abrahams wrote a function named "fill", he didn't
want it to match a library name. But when I write an entity named "swap",
I want it to match the "swap" that the library calls. Clearly a library can't
satisfy two opposing goals, can it?
This is why the library group struggles with open issues #225 and #229. If
library functions fully qualified all internal calls, then I wouldn't be able
to
match swap() the way I'd like to. If the library never qualified names it
uses internally, then David Abrahams and lots of other people will be
surprised when an innocent user function named fill() causes the library to
go berserk in unpredictable ways. Any compromise solution, such as
specifying for every function which names it may use -- or will use --
internally without qualification [Note 2] may prove to be overly complex
to specify. At best, it will introduce a different set of problems. Whether
that is preferable is under discussion.
>I think they [namespaces] were created to solve a problem that largely fails
>to exist... Why have we gotten along this well for so long? Because
>of the unque-prefix convention....
There's a contradiction here. If a problem "largely" doesn't exist, then what
does the unique-prefix largely solve? There is a need to organize our
solution space, especially when it becomes so large that no single human
can comprehend it at once. We already had the notion of scope, and we
already had to solve name matching problems with class scopes. It was
only a small step to the generalization of namespaces.
If namespaces went away, we would still have to define name matching
rules for other scopes, and we would still have to find a way to organize the
naming aspect of our solution space.
In other words, namespaces per se are not the problem. Name resolution
and program organization present challenges. Our reaction to the challenge
exposes a quirk of human nature: sometimes when we find ourselves in
a mess, we point to something in the solution domain and identify it as the
"problem."
>In my view, the unique prefix convention worked well, was completely
portable,
>and required no language support.
It works. And it suffers even more repetitive naming than all those using
declarations. And sometimes it doesn't work precisely because it has no
compiler support to enforce it. Like the trend to enforce "concepts" as
early as possible, we want to enforce the organization of names as early
as possible.
> ...I just think that namespaces are an experiment that failed.
We just haven't had enough experience with it yet to make that call.
-- Dave Miller
Notes:
[1] There are two types of people in the world: (a) those who classify
everything, and (b) those who don't.
[2] From the excellent paper by Peter and David, WG21 N1296.
Jeff King
>But I find Scott's iconoclasm intriguing, and will be very interested
>in what others have to say. Because, after all, what would it really
>cost for me to call my class DBClient?
After using namespaces for a while (long enough, IMO, to get comfortable
with them) I found that your example is indicative of my common use.
That is, in C I would have called the struct DBClient. In C++, I call it
DB::Client. My general take on this is:
- it's not much more typing (especially when ProjectAreaSubareaType
becomes Project::Area::Subarea::Type
- it's more readable (I think)
- most importantly, you've told the compiler which part is prefix and
which part is the actual type. Giving the compiler more information
never hurts (unless it's trouble to provide it, but in this case
you're providing it either way), and it is likely to help in the
form of `using namespace DB'.
Personally, I think it makes the code more readable to use the shortest
names. It lets you use context to get your meaning, rather than beating
it over the head by mentioning a FooBarDBClient all the time.
-Peff
Francis Glassborow
<mor...@mochima.com> writes
>Standard library facilities shouldn't clash with user-provided
>things -- standard library facilities were there first!!! (and
>if they weren't, too bad: they're standard library facilties).
You mean you never want to use legacy code that has such identifiers as
'string', 'swap', 'complex' etc. in it? Personally for all the rough
edges I think putting the Standard Library in a namespace was a great
step forward. We even (though this still needs work) have the
possibility of versioning the standard library (look how stuck C is when
it wants to introduce new standard functions, even though the programmer
is lumbered with a multitude of reserved spellings, that most do not
even know exist).
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Richard B. Kreckel
:>Can anybody enlighten me what that fiasco was about?
:
: Basically, as I was told by the person who proposed putting them into
: rel_ops, it was a deliberate act to bury them and make them go away.
Okay, this is obvious. But what is so bad about them in the first
place? I find it *very* embarrassing that people find this is in the
standard (or some book), then use namespace std::rel_ops in order to
access these operators, find problems with certain implementations and
then are being told by the language gurus that they are greedy, evil,
whatever, must go away, without any clear justification. They are not
even marked deprecated or such in the standard!
Next time when I am giving a C++ course and somebody comes up with
this question, what am I going to say? "Well, they are too greedy,
they don't interact well with the rest of the language." Geez, I
never even had any problems with such interactions myself!
Regards
-richy.
--
Richard Kreckel
<Richard...@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
nik...@sun.com
> But Koenig lookup is the really kicker. Those of you who are familiar
with
> the history of namespaces will recall that Koenig lookup was added when
it
> became clear that the name lookup rules introduced with the first draft
> semantics of namespaces led to programs failing (due to name lookup
> failures) that everybody wanted to succeed. Like magic, Koenig lookup
> makes them succeed.
I'd be very curious, what was it, that failed.
There is something, I assume – please correct me, if I'm wrong.
I assume, the reason for introducing the koenig-lookup were binary
operators
with possible infix notation on objects within the namespace std.
Anything like:
std::basic_ostream &
std::operator<<( std::basic_ostream & os, const std::string & s );
This obviously would never be called by infix notation in cases like:
std::string s(„hello world“);
std::cout << s << endl;
... if there were no Koenig lookup.
Ok – so far I understand the arguments. But I think, the better and more
consistent solution would have been, to let all definitions of
binary infix operators stay outside of namespace std.
Simply declaring
std::basic_ostream &
operator<<( std::basic_ostream & os, const std::string & s );
in the global namespace does the same job. The used version of
operator<<() is already fully defined by the two operands. I don't see
any
advantage of putting the operator itself into namespace std.
I tend to assume as a general rule, that declaring any binary operator
with
possible infix notation within a named namespace, but outside of a class,
would be a
design failure. The same kind of design failure as making them behave
unlike
„with ints“ in any other case.
I assume, there was a „holy rule“, an unquestioned axiom, that there had
to be
everything of the STC within namespace ::std – is that right?
So – two questions to the standard or history experts:
1. Was the above mentioned reason, the reason for introducing
Koenig-lookup?
2. Wouldn't it have been a better solution, to never declare operators
like
operator<<() or operator+() within namespace std? Because the version
of such
operators is already completely defined by there arguments?
I think, Koenig lookup is inconsistent with the rest of the language and
gives less security without any real advantage. But I'm interested in any
arguments, that may prove, I'm wrong ;-)
Regards
Nikolai
--
Nikolai Pretzell
Software Engineer Development Tools
Star Office Gmbh, Hamburg
Carlos Moreno
Francis Glassborow wrote:
>
> In article <3B8286FC...@mochima.com>, Carlos Moreno
> <mor...@mochima.com> writes
> >Standard library facilities shouldn't clash with user-provided
> >things -- standard library facilities were there first!!! (and
> >if they weren't, too bad: they're standard library facilties).
>
> You mean you never want to use legacy code that has such identifiers as
> 'string', 'swap', 'complex' etc. in it? Personally for all the rough
> edges I think putting the Standard Library in a namespace was a great
> step forward. We even (though this still needs work) have the
> possibility of versioning the standard library (look how stuck C is when
> it wants to introduce new standard functions, even though the programmer
> is lumbered with a multitude of reserved spellings, that most do not
> even know exist).
I meant that if you need to use legacy code (an insignificant
fraction, compared to the number of new applications developed
in C++ from scratch), then put the legacy code in a separate
namespace!
Legacy code is used once in a while -- the standard library is
used *always*. Why do I need to live with the syntactical
overhead of an unreadable std:: in front of everything, just
to avoid a problem that occurs in a small fraction of the
applications?
Carlos
--
Pete Becker
>
> sme...@aristeia.com (Scott Meyers) wrote (abridged):
> > In my view, the unique prefix convention worked well, was
> > completely portable, and required no language support.
>
> In my experience the unique prefix convention produced names which were
> short and cryptic, or long and unwieldy. I prefer namespaces. I use
> longish namespace names for clarity and then get rid of them with using
> declarations where I need to avoid clutter.
>
And let's not forget namespace aliases...
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Stan Brown
comp.lang.c++.moderated:
>In article <MPG.15ec4f62a...@news.mindspring.com>, Stan Brown
><bra...@mindspring.com> writes
>>>First, I think they were created to solve a problem that largely fails to
>>>exist. No C programs use namespaces and most C++ programs use no
>>>namespaces other than std
No, I did not write the above. I _quoted_ the above, with proper
attribution to Scott Meyers, for the purpose of posting my
disagreement.
Sometimes messing up attributions is not important. But when I am
made to say the opposite of what I actually believe, I think it's
important to set the record straight.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hadrian Zbarcea
news:3B83DBD2...@mochima.com...
No, no, std:: IS readable. It tells you exactly what you are dealing with.
I've seen code on Windows that mixed "old style streams" (like in
<iostream.h>) with std streams. It's a nightmare.
And if you don't like std:: everywhere you always have to option to say
using namespace std;
Hadrian
Greg Hickman
> [snip] standard library facilities were there first!!!
Only if you rule out future extensions to the standard.
> At the risk of sounding disrespectful, I see the std namespace as
> one of those "politically correct" practices.
Without the std namespace (or some equivalent scoping mechanism), future
updates to the standard might break my code.
-Greg
Attila Feher
I am not a guru in C++ and most of the books I have read about it were
written by the OP... so pls. don't kill me immediately if I write sthg
stupid.
Scott Meyers wrote:
[SNIP]
> Note two things here. First, the library should have used a qualified
> call, i.e., std::fill instead of fill. Second, the problem involved
> argument-dependent lookup, aka Koenig lookup. Both are important to the
> position I have come to hold. In fact, I was surprised to see so little
> mention of the interaction of namespaces and Koenig lookup in the thread.
First of all I have been working in large projects, large to my
understanding. In the few things I did _not_ let to happen (not talking
about C++ as a language) was to use any "too general" names in a naked
way. That would include _anything_ called fill, esp. in global
namespace. Now since _anyone_ at _anytime_ can say: using
myNamespace::fill, that means (in my view of the world) the name fill a
big nono.
Anyone could drop a URL to a page which describes the original problem
in an easy way? Koening lookup is something which I have missed to
study until now... so I would like to make a better understanding of
this problem. First of all so I can revisit my comment above. The 2nd
reason is that I will know about the problem before hitting it.
[SNIP]
> So here's the horror: if it were up to me, we'd get rid of namespaces
> entirely.
You frighten me. I have considered namespaces as a very very good
idea. It seems, that while the idea is good: giving the opportunity to
decouple/group/encapsu;ate several "modules" of the implementation
without using a big struct. Now it seems however, that there are
drawback or problems with the actual implementation.
I would say (esp. reading your comments about prefixes), that it a
little bit resembles the old saying about marriage: it is done to deal
with problems which would never exist without it... You just start your
next paragraph with it. And it seems that it does not only creates
problems which it does solve, but new ones (just like marriage).
However I would take it as an extrimists view to make the solution by
divorce or throwing away the idea of marriage.
While marriage involves people (with all their psychological and other
"programming" against monogamy) the problem of namespaces is less
serious. I mean more simple. It is more of a scientific problem, so
the approach should be first of all more scientific than emotional or
historical.
> First, I think they were created to solve a problem that largely fails to
> exist. No C programs use namespaces and most C++ programs use no
> namespaces other than std (unfounded assertion -- so sue me), and my
> experience in working with a wide variety of software companies in the past
> decade is that problematic name conflicts are uncommon. Anecdotal
> evidence? Certainly. Sue me. Why have we gotten along this well for so
> long? Because of the unque-prefix convention, whereby global symbols
> beloning to library xyz tend to be prefixed with xyz, e.g., xyzfill. In my
> view, the unique prefix convention worked well, was completely portable,
> and required no language support.
I personally hate prefixes. I don't see them "flexible enough". Just
if for some reason I need to change that very prefix I can do it much
more easily if I use namespaces (esp. if I use them qualified and not
with "using"). I did not think about it much, but I guess very simple
updates could work. Probably even with using. However with prefixes I
would come up with some sort of very good regular expressions to do the
job. One can argue how often you need to do that - and the answer is
probably never. Anyways for me it "feels" more right to have namespaces
than not to have them. All I see here as a question: how to make them
work without the problems we (I mean you) know today.
About namespace usage. Yes, I need to back you up that at many places
namespaces are not taken into use. It may be caused by bad support for
them from certain compilers (old gcc comes into mind) and the reason of
the large projects being portable... But in this case (people not using
as the argument ot get rid of it)... it will hurt but I have also seen
large projects (ones with stability problems) where the basic rules you
lay out in your Effective C++ book were not used either. And I don't
even dare to mention that More Effective C++ techniques may not have
effected large percent of the existing C++ programs. Why? No time. Is
it good? No.
About sue me... I just happen to know that in the US you cannot even
sue a racists because of his oppinion and letting the public to know
about it, so I guess we will rather try to understand why you are saying
what you do rather than blindly hate you for it. :-)))
One more, about prefixes:
- I hate to type them
- I hate code lines longer than needed
I know! It will only be shorter if namespaces and the lookup works
right and _if_ I have to prefix them with the full qualification of the
namespace they will be longer with the two colons...
> Interestingly, it is increasingly becoming clear that library authors must
> adhere to Dave's suggestion above: avoid unqualified names.
You mean I do this:
namespace xxx {
Obj *DoANewObj() {
Obj *o = new ObjImpl;
xxx::fill(o);
return o;
}
}
Stupid example, I know. You mean that _in_ the xxx namespace I have to
use the xxx:: prefix? Why? Won't it become xxx::xxx? (Never ever
needed to do that)
> For names like
> fill or count in std, this means that library source code must always refer
> to std::fill or std::count to avoid surprises.
I don't get this (anyone send me a URL pls. with a desrciption of this
problem for dummies!). This seems to be a fault of the implementation
of namespaces. It sounds like you tell to your C++ compiler in the
kitchen (next to a chair) "take a seat please" and this imaginary fellow
walks into the living room to sit down, or even worse, the neighbours
house.
> But if that's the case, why not get rid of the colons and
> use the unique-prefix solution, e.g., stdfill?
Now you know the answer yourself: because some marriages does not work
you won't remove the institution: it would break many lives, like this
would break ceartainly many programs. Only 10% of all the existing
ones? Maybe. Maybe this 10% is the best paying 10%, who keeps the C++
industry running.
> Where is the benefit of namespaces if we have to fully qualify
> our uses of the names in them?
Good question! What I would get rid of is the using directives (I don't
have a keyword to bring the bathroom to my living room, so I guess it is
a bit of invading the privacy/encapsulation of namespaces) but if things
does not work even _inside_ a namespace{}, it is clearly a fault - which
(in my belief) has to be addressed by people much more clever and
eductaed than me, including the C++ comitee.
[SNIP]
> lookup rules. And recently I've been seeing talk of making function names
> like "swap" essentially reserved to get around these problems.
Looks like the marriage problem again... Introducing restrictions
instead of addressing the real problem: how to implement the namespaces
without the problem... I could add some more to it: ban also knifes and
public places. Both are dangerous, with the former one can kill, at the
latter flu can spread... Oh, I am being sarcastic with a bad style,
sorry.
Cannot it be so, that if namespaces needs some more work to get them
working right... this more work will be done? How many of us is being
effected by this issues? Is it so that since people never really
started to use namespaces these problems are rare, so noone cares?
[SNIP]
> Oh, a brief note on nested namespaces. When was the last time anybody made
> effective use of std::rel_ops? My conclusion from that fiasco is that
> namespaces don't effectively nest, another victim of unanticipated
> interactions in name lookup rules.
Is it s "secret saying"? What is the problem with std::rel_ops?
> And one more thing. I think using declarations are a syntactic pain in the
> hind quarter, and for that reason I don't recommend their use.
Now those are what I would ban! I cannot count how many projects I have
seen with "using namespace std;" in nearly _all_ of the headers using
any std:: element...
I know (at least think) that this whole using was there to allow old
code not to be broken by the new std:: namespace, but I would simply ban
them - at least from the global scope. Probably letting it to be used
in bodies of functions is OK... But since there is no unuse namespace
xxx; - using them in the high level kills. I mean I include a header
and it says using namespace Joint and I say smoke() and think I am
getting it from XxxxLightsMenthol namespace... This (using using in a
header, esp. library one :-) can (and effectively do) break open the
whole concept the namespaces are here for - encapsulation of independent
modules.
> They're a
> pain to type (over and over and over at the top of each function), and I've
> noticed that in practice they tend to harken back to the days of C before
> C99, because pretty much all the examples I've seen of their use cluster
> all the using declarations at the top of a block, just like declarations in
> C89. To me, this is not progress, and it doesn't make it easier for
> programmers to get their jobs done more clearly or easily.
As far as I see now, the "solution" would be:
- to ban using to appear (ensure encapsulation)
- make name lookup work properly if inside a namespace
- use full qualification outside
I know, it will not happen, since _even_ if the STD will say so
implementors will keep backwards compatbility.
Anyways if a Java programmer can type
this.that.there.in.that.KindOfWindow to access a class... I mean
probably even us can live with boost::
[SNIP]
> - My hair style calls into immediate question all my judgements.
Now that you say it... :-)
[SNIP]
> I don't think I'm completely out of touch.
I am no psychologist but I guess you are too much in touch. It seesm
that people come to you with problems they have around namespaces and
since (now) the concept is broken, you cannot help them. And it makes
you feel bad...
> Assuming the moderators let this through, there may be follow-ups. The
> follow-ups may ask questions. Let me apologize right now for almost
> certainly not having enough time to reply to them. I keep up with the
[SNIP]
> this thread again, have faith, I'll be reading anything that follows. I
> just may not get around to it until October. Sigh.
No problemo, you can sue me when we meet on the Seminar :-)))
A
Mark Wilden
>
> Legacy code is used once in a while -- the standard library is
> used *always*. Why do I need to live with the syntactical
> overhead of an unreadable std:: in front of everything, just
> to avoid a problem that occurs in a small fraction of the
> applications?
You don't, of course. You can use "using namespace std;".
Carlos Moreno
Mark Wilden wrote:
>
> "Carlos Moreno" <mor...@mochima.com> wrote in message
> news:3B83DBD2...@mochima.com...
> >
> > Legacy code is used once in a while -- the standard library is
> > used *always*. Why do I need to live with the syntactical
> > overhead of an unreadable std:: in front of everything, just
> > to avoid a problem that occurs in a small fraction of the
> > applications?
>
> You don't, of course. You can use "using namespace std;".
I know... That's the only real saver. But I do hate seeing
how "politically incorrect" that is. Even in situations where
that is irrelevant (e.g., posting a sample code to help a
beginner solving a problem about iomanip or a simple
std::string manipulation technique, etc.), the mere sight
of "using namespace std;" is seen as the antichrist... :-(
(yes, that was a concrete example -- I've seen in this and
other NG's related to C++, someone posting a very simple
piece of code to illustrate something to a beginner, and
then several people that reply only to point out what a
heresy is to put "using namespace std;" :-\ )
I disagree with the standard library facilities in the
namespace std (or any namespace, for that matter), because
it makes them look like they're something out of the
ordinary. Imagine how ridiculous it would be, for example,
that all the keywords of the language were "in a namespace"
such as lang:
lang::int main()
{
std::string name
lang::do
{
std::getline (std::cin, name);
}
lang::while (name == "");
// ...
lang::return 0;
}
Would you argue that that is good because it allows you to
work with legacy code where you have functions/variables
such as long, try, catch, throw, std, namespace, and, or,
etc.???
Standard library facilities *are part* of the language, and
as such, should look as natural as possible -- there's
nothing weird or special about them. When the keywords
are actual English words, the code is readable. std::printf
is not an word! std::string is not a word, etc.
Carlos
--
Carlos Moreno
Greg Hickman wrote:
>
> "Carlos Moreno" <mor...@mochima.com> wrote in message
> news:3B8286FC...@mochima.com...
>
> > [snip] standard library facilities were there first!!!
>
> Only if you rule out future extensions to the standard.
>
> > At the risk of sounding disrespectful, I see the std namespace as
> > one of those "politically correct" practices.
>
> Without the std namespace (or some equivalent scoping mechanism), future
> updates to the standard might break my code.
Future expansions *will* break existing code. New keywords are
always introduced. It's true that the standard library is more
likely to be updated, but still... I'm sure it's less the time
it would take you to fix your broken code (due to a conflict
consequence of a standard library update) than the total amount
of time it took typing the extra std:: in all the programs you
have ever written. (actually, fixing your code should be only
a matter of putting *your* code in a namespace... Well, plus
minus a few things)
Carlos
--
LR
Scott Meyers wrote:
[big snip]
>And recently I've been seeing talk of making function names
> like "swap" essentially reserved to get around these problems.
Can you please clarify the phrase "essentially reserved" as opposed to
simply "reserved"?
In anycase, I don't want to see the name swap reserved. I'm using it
for other things. As a member function for example. And what would
reserving it say about the utility of polymorphism/overloading?
>
> Here's my summary of the history of namespaces:
[snip]
I've reformatted a little here
> Namespaces Version 2 (whatever comes next):
> Hmmm, that hack didn't work
> as we thought it would.
> Maybe this will fix it...
I hope the problems are fixable, because getting rid of namespaces would
feel to me like throwing out the baby with the bathwater.
[moved from above]
> Why have we gotten along this well for so
> long? Because of the unque-prefix convention, whereby global symbols
> beloning to library xyz tend to be prefixed with xyz, e.g., xyzfill.
> In my view, the unique prefix convention worked well, was
> completely portable, and required no language support.
Isn't it likely that the prefixes will tend to be short for the same
reason that people don't want to type things like
math_software_company::ceiling? So the prefix may be shortened to msc,
or worse ms. This shortening will probably lead to collisions with, for
example, mine_software_company, when they in turn, choose msc or ms as
their prefix. There is no guarantee that the prefixes will be unique.
With namespaces there is probably less of a chance that the actual,
longer, names will have a collision, and I can use an alias or a using
statement to save on typing if that's what's important to me.
I can imagine three developers working on a very large program. A
creates an include file that includes a file from math_software_company
that has a function double mscceiling(double). B creates an include
file that includes a file from mine_software_company that has a function
double mscceiling(double). C decides to include the include files
created by Developers A and B.
And it's likely too, that not every prefix will be originate in a third
party library. Some will be created in house.
I'm not saying that these or similar kinds of problems can't occur with
namespaces or, in some cases, even without them. I'm just wondering
what the costs of rewriting the code are going to be using namespaces vs
prefixes.
And yes, the problem I've outlined is somewhat contrived, but I've run
into problems like function name collision on projects. I mean other
than the one I outlined in the earlier thread.
>- In the past decade, I have personally worked with hundreds of
> programmers in scores of teams from dozens of companies in a fair
> number of different problems domains. I get around a little. I see
> what people write. I talk to them about why they do it the way they
> do. I listen to them.
Could you please give a few examples of situations in which it was
decided to not use namespaces, for reasons other than the dislike of
having to type std::fill? Any situations where it was decided to use
namespaces?
Could you please guesstimate a percentage of those you spoke to who ever
said something like, "We do it this way, but if we had to do it all over
again, we woulda done it this other way instead." In general, and then
regarding namespaces, pro and con.
[moved from above]
> So here's the horror: if it were up to me, we'd get rid of namespaces
> entirely.
As you may have guessed, I have what might be called the opposite view.
Is there any real advantage to allowing the placement of PODs, objects
and functions in global scope?
LR.
A friend told me what you could learn about people from the way they
name integer variables in FORTRAN: "You see 'COUNT' declared to be an
integer, that's pretty good. And you see "KOUNT' or 'ICOUNT' which are
ok. But every once in a while you see people who call it 'IKOUNT' and
those people are clueless."
James Kanze
news:<9lv4ge$1r90$1...@agate.berkeley.edu>...
> In article <MPG.15eba7c9...@news.hevanet.com>,
> Scott Meyers <sme...@aristeia.com> wrote:
> >First, I think they were created to solve a problem that largely
> >fails to exist.
> Well, I sure am glad the std namespace exists, or it would be nigh
> impossible to migrate from classic streams in our project.
Good point.
Traditionally, the rule was that if you changed the semantics of a
function, you changed the name as well, so that all uses of the old
function would be caught by the compiler. Namespaces are as good of
means as anything else for changing the name, I guess. (Provided, of
course, that you always write std::cout, etc.)
Another positive benefit is the unnamed namespace, which allows me to
define classes that aren't visible elsewhere. While I have no problem
with using prefixes on my public interfaces, it was always a pain to
be required to use them when I needed a small helper class in one
file.
Whether the benefits outweigh the costs, of course, is another
question. (To begin with, think of all the time you loose reading
threads like this, which wouldn't exist without namespaces:-).)
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
James Kanze
news:<MPG.15ec4f62a...@news.mindspring.com>...
> The C++ committee may have exceeded its plan a bit by mandating
> namespaces in the absence of widespread "prior art".(*) But I think
> they did well. The problem of name conflicts was well known and
> pervasive; namespaces solve it, and at no run-time cost in time or
> space.
It was an invention of the committee. And while there is no run-time
cost, there is significant cost in the complexity of name lookup
rules. As if they were too simple before.
James Kanze
> So here's the horror: if it were up to me, we'd get rid of
> namespaces entirely.
Too late, I'm afraid. But I agree that they never should have been
introduced. Too much complication for too little benefit.
> First, I think they were created to solve a problem that largely
> fails to exist. No C programs use namespaces and most C++ programs
> use no namespaces other than std (unfounded assertion -- so sue me),
> and my experience in working with a wide variety of software
> companies in the past decade is that problematic name conflicts are
> uncommon. Anecdotal evidence? Certainly. Sue me. Why have we
> gotten along this well for so long? Because of the unque-prefix
> convention, whereby global symbols beloning to library xyz tend to
> be prefixed with xyz, e.g., xyzfill. In my view, the unique prefix
> convention worked well, was completely portable, and required no
> language support.
Well, I do know of one case of name conflict that caused enormous
amounts of problems. Both the X Windows headers and the USL defined a
symbol String. It's a two edged example, however; the X Windows
definition happened to be a macro (and in C compatible code as well),
so namespaces wouldn't have helped much.
Other than that, I agree. There was a problem. There was, however, a
well know solution for that problem, used by all experienced
programmers I know. And you can't play around with anything as
fundamental as name lookup without introducing new problems.
> Interestingly, it is increasingly becoming clear that library
> authors must adhere to Dave's suggestion above: avoid unqualified
> names.
Actually, I think it's only a problem with templates. And of course,
until we get quality implementations of export, templates aren't
really very usable anyway, except for tiny (and very stable) things
like basic containers.
> For names like fill or count in std, this means that library source
> code must always refer to std::fill or std::count to avoid
> surprises. But if that's the case, why not get rid of the colons
> and use the unique-prefix solution, e.g., stdfill? Where is the
> benefit of namespaces if we have to fully qualify our uses of the
> names in them?
It gives us one more character that we can use in the names. It makes
it visually clear what part is the prefix. It allows us to write
implementation code without the prefix.
Advantages, certainly, but not much compared to the cost.
For what it's worth: I've just started working on an application which
makes extensive use of namespaces, including nested namespaces. It's
too early for me to see the effect, but I expect soon to have some
concrete experience to back up my feelings.
Francis Glassborow
<mor...@mochima.com> writes
>> Without the std namespace (or some equivalent scoping mechanism), future
>> updates to the standard might break my code.
>
>Future expansions *will* break existing code. New keywords are
>always introduced. It's true that the standard library is more
>likely to be updated, but still... I'm sure it's less the time
>it would take you to fix your broken code (due to a conflict
>consequence of a standard library update) than the total amount
>of time it took typing the extra std:: in all the programs you
>have ever written. (actually, fixing your code should be only
>a matter of putting *your* code in a namespace... Well, plus
>minus a few things)
Oh, boy, you obviously do not work in parts of the industry where any
code change requires revalidation. It isn't the typing time by itself
but the requirement to put everything through test again.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> > You can use "using namespace std;".
>
> I know... That's the only real saver. But I do hate seeing
> how "politically incorrect" that is. Even in situations where
> that is irrelevant (e.g., posting a sample code to help a
> beginner solving a problem about iomanip or a simple
> std::string manipulation technique, etc.), the mere sight
> of "using namespace std;" is seen as the antichrist... :-(
Hey, tell me about it. :) The only reason I didn't put a smiley after my
comment is that I was afraid the moderators would think I was just making a
contentless joke. I guess you missed the long and volatile thread on the
issue of the using directive lately.
> I disagree with the standard library facilities in the
> namespace std (or any namespace, for that matter), because
> it makes them look like they're something out of the
> ordinary.
I think that's a good point. It's the standard library, so in theory
practically every program written in C++ should use it. Of course, one of
C++'s goals has always been to maintain compatibility with existing C++ (and
even a lot of C) code. But I think this is a case of going overboard (at
least, until I see someone more expert than I respond to your points:).
David Kieras
>
> But Koenig lookup is the really kicker. <snip>
> lookup rules. And recently I've been seeing talk of making function names
> like "swap" essentially reserved to get around these problems.
>
> Don't get me wrong, I have tremendous respect for the people who have been
> working on namespaces, only one of whom is named Koenig. I just think that
> namespaces are an experiment that failed. In Pete's terms, I don't think
> the benefits of the practice justify the costs. Others almost certainly
> disagree.
>
Here is some of my usage experience with medium-to-large one-person-size
projects.
>From Koenig and Moo's recent book I picked up the approach of putting
things like
using std::cout; using std::cin;
at file scope after the #includes in .cpp files (surprisingly few seem to
be needed) - this is just a more elaborate "inclusion" syntax. it seems
like a good compromise between typing effort+visual clutter and namespace
pollution.
I got bit hard by the lookup issues. Based on my experience with Common
Lisp packages, I tried to group big hunks of my code into large-scale
modules with some namespaces. I then discovered that my handy overloads of
operator<< in different modules for debugging output produced very
confusing lookup failures. I couldn't see a good way to fix them; bringing
the different overloads into the same scope seemed to require making some
of my more generic code dependent on modules in ways that it really
shouldn't have to be.
I also had to explicitly qualify some of my names on every usage simply
because of conflicts with old libraries that put "good" names into the
global namespace. This is so much like a prefix that I wonder whether it
wouldn't be preferable.
So, my own namespaces are so clumsy that I'm tempted to remove them, which
indeed suggests a failed experiment, or at least I can't grasp how to use
them properly from everything I have studied. Maybe a few general-purpose
libraries are really the only good things to put into a namespace.
--
remove "_mapson" from my email address to reply
Francis Glassborow
<mor...@mochima.com> writes
>I know... That's the only real saver. But I do hate seeing
>how "politically incorrect" that is. Even in situations where
>that is irrelevant (e.g., posting a sample code to help a
>beginner solving a problem about iomanip or a simple
>std::string manipulation technique, etc.), the mere sight
>of "using namespace std;" is seen as the antichrist... :-(
>(yes, that was a concrete example -- I've seen in this and
>other NG's related to C++, someone posting a very simple
>piece of code to illustrate something to a beginner, and
>then several people that reply only to point out what a
>heresy is to put "using namespace std;" :-\ )
There will always be extremists. MY rule is do not have using directives
in header files, and make sure that people think before putting them
elsewhere.
>
>I disagree with the standard library facilities in the
>namespace std (or any namespace, for that matter), because
>it makes them look like they're something out of the
>ordinary. Imagine how ridiculous it would be, for example,
>that all the keywords of the language were "in a namespace"
>such as lang:
But there is already a 'namespace' for new keywords it involves using
leading underscores (and C99 resorted to this for the new types, of
bool, complex, imaginary, that are just typedefs for the real names.
>
>lang::int main()
>{
> std::string name
>
> lang::do
> {
> std::getline (std::cin, name);
> }
> lang::while (name == "");
>
> // ...
>
> lang::return 0;
>}
>
>
>Would you argue that that is good because it allows you to
>work with legacy code where you have functions/variables
>such as long, try, catch, throw, std, namespace, and, or,
>etc.???
New keywords are a problem, but there are a couple of orders og
magnitude fewer of them than library identifiers. Do you prefer the C
alternative of reserving such things as str..., to... etc.
>
>Standard library facilities *are part* of the language, and
>as such, should look as natural as possible -- there's
>nothing weird or special about them. When the keywords
>are actual English words, the code is readable. std::printf
>is not an word! std::string is not a word, etc.
But we add very few keywords, but probably want to add many more library
names. I, for one, do not want to argue interminably as to whether
introducing some new function or class can be justified because of the
potential for breaking existing code.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> It gives us one more character that we can use in the names. It makes
> it visually clear what part is the prefix. It allows us to write
> implementation code without the prefix.
And it allows us to use our own prefix name if for some reason we don't
want to use the vendor's prefix. I think people tend to overlook
namespace aliases...
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Greg Hickman
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
news:NdxGbjAA...@ntlworld.com...
> We even (though this still needs work) have the
> possibility of versioning the standard library ...
The possibility of using namespaces to facilitate multiple versions of a
library (even simultaneous use?) is intriguing. IIRC, TC++PL contains an
example like
// Library header
namespace Lib_v211 {}
// User code
namespace Lib = Lib_v211;
Is this the kind of thing you're suggesting? Are there libraries out there
that might serve as models of such an approach?
Greg
Greg Hickman
> So here's the horror: if it were up to me, we'd get rid of namespaces
> entirely.
Horrifying indeed.
> First, I think they were created to solve a problem that largely fails to
> exist. No C programs use namespaces and most C++ programs use no
> namespaces other than std (unfounded assertion -- so sue me), and my
> experience in working with a wide variety of software companies in the
past
> decade is that problematic name conflicts are uncommon.
I work for a large corporation with a large number of product lines, the
vast majority of which require software of significant size and complexity
for their production and as well as their operation. Combining their size
and complexity with the fact that many (if not most) of those products share
various software functionality in common creates a situation that just begs
for a strategically chosen collection of libraries to reduce that size and
complexity. Assuming our eventual success in developing such libraries,
name conflicts will occur far too often without an effective partitioning of
the namespace. The contexts for reuse are just too numerous to avoid them
otherwise.
We address this issue by placing all of our libraries in nested namespaces
using a Company::Lib1, Company::Lib2 naming convention, and I use a similar
convention (e.g., AppName::Lib1, etc.) for my application-specific
libraries. This is surely easier than implementing a C-style prefix, and
having lived with this organization for a couple of years now, I've come to
see namespaces as a natural way to embody (and even encourage) logical
modularity. In total, namespaces "been very, very good to me" thus far.
> I just think that
> namespaces are an experiment that failed. In Pete's terms, I don't think
> the benefits of the practice justify the costs.
The kind of suprising behavior documented by the 'fill' example certainly
seems unacceptable. I've never had such a problem, but perhaps my time is
yet to come. On the other hand, discovering that my libraries are
inherently flawed by their use of namespaces would be more than a little
frustrating at this point.
> And one more thing. I think using declarations are a syntactic pain in
the
> hind quarter ...
I don't usually like fully qualified names, yet we're cautioned against
using declarations in header files to prevent other surprising lookup
behavior. Heeding that advice often leaves me no choice but to declare a
lot of typedef's in headers, but that's almost as bad as using fully
qualified names in the first place.
Greg Hickman
> MY rule is do not have using directives
> in header files, and make sure that people think before putting them
> elsewhere.
Just to clarify, do you mean to exclude using *declarations* from header
files too, or is that something you feel may vary on a case by case basis?
To me, its only natural to want to employ using declarations in my headers
to shorten names in situations like:
#include "TheirCompanyX/Inc/Library1/TheirType.h"
namespace MyCompany::MyLib {
using TheirCompany::Library1::TheirType;
class MyClass {
public:
TheirType get_their_type();
//...
};
}
But having been cautioned against this due to the using declaration creating
the potential for silent changes in meaning, I resort to typedef's instead.
Greg
Greg Hickman
"Dave Harris" <bran...@cix.co.uk> wrote in message
news:memo.20010821...@brangdon.madasafish.com...
> sme...@aristeia.com (Scott Meyers) wrote (abridged):
> I use
> longish namespace names for clarity and then get rid of them with using
> declarations where I need to avoid clutter.
That sounds ideal, but it seems like the long names will be too cumbersome
if I can't have using declarations in header files.
Greg Hickman
Francis Glassborow
Hickman <ghic...@flash.net> writes
>"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
>news:sml+ViAU...@ntlworld.com...
>
>> MY rule is do not have using directives
>> in header files, and make sure that people think before putting them
>> elsewhere.
>
>Just to clarify, do you mean to exclude using *declarations* from header
>files too, or is that something you feel may vary on a case by case basis?
>To me, its only natural to want to employ using declarations in my headers
>to shorten names in situations like:
>
>#include "TheirCompanyX/Inc/Library1/TheirType.h"
>
>namespace MyCompany::MyLib {
> using TheirCompany::Library1::TheirType;
as you have encapsulated this within your own namespace I have no great
objections even in a header file.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
Hickman <ghic...@flash.net> writes
>"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
>news:NdxGbjAA...@ntlworld.com...
>
>> We even (though this still needs work) have the
>> possibility of versioning the standard library ...
>
>The possibility of using namespaces to facilitate multiple versions of a
>library (even simultaneous use?) is intriguing. IIRC, TC++PL contains an
>example like
>
>// Library header
>namespace Lib_v211 {}
>
>// User code
>namespace Lib = Lib_v211;
>
>Is this the kind of thing you're suggesting?
Yes.
> Are there libraries out there
>that might serve as models of such an approach?
I think more work still needs to be done so that this will work as
smoothly as we would want. I guess the next release of the C++ Standard
will be good motivation for this.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Kevlin Henney
Sure, they are far from perfect, sometimes subtle, often misused,
misimplemented, and we'll be picking nits out of their hair for years to
come, but this does not automatically qualify them as failures. I doubt
that many language features have a spotless record of use, defects and
implementation.
Consider the use of namespaces to enclose libraries, such as std, boost
and CORBA. These clearly mark the point of origin of a feature and have
avoided a number of clashes and naming wars. For instance, the migration
from classic I/O streams to standard I/O streams, the migration of
classic STL to the standard library (modulo inappropriate name lookups,
such as provided by g++), the migration to std::string and std::list
from (unsurprisingly) identically named cognate classes. Looking at
Boost, I cannot imagine how the removal of namespaces would greatly
simplify library development, discussion and use (bst_ or boost_
prefixes?).
One issue that has become apparent is that the conventions that
libraries should follow in using features from namespaces should be set
more concretely in per-library guidelines than has perhaps been the case
in the past. Namespaces cannot be introduced effectively without the
additional adoption of recommended practices. No feature comes without
its idioms... even if we may not know what they are to begin with ;->
Whilst there are constraints in some places on how they can be used, and
some of these are relatively recent discoveries, they still typically
provide users with a reasonable amount of flexibility when it comes to
usage -- using directives, declarations and aliases, or full
qualification.
Namespaces also provide a convenient mapping to other languages that
support modular or namespace-like structures. The CORBA IDL-C++ mapping
for compilers that support namespaces is far simpler and easier to use
than the one without.
So, no, they are not perfect, but they are also not terminally flawed. I
believe that the motivation for their existence is reasonably well
realised in addition to being well intentioned. They are sufficiently
useful, even if insufficiently perfect.
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
mailto:kev...@curbralan.com mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
____________________________________________________________
David A. Ferguson
like
> fill or count in std, this means that library source code must always
refer
> to std::fill or std::count to avoid surprises. But if that's the case,
why
> not get rid of the colons and use the unique-prefix solution, e.g.,
> stdfill? Where is the benefit of namespaces if we have to fully qualify
> our uses of the names in them?
Namespaces are useful. It is the ' using namespace std;' statement that is
not as useful as it could be. Some method of applying the statement
using namespace std;
to a limited scope needs to be available. For example, it could apply to
only apply the current file (not translation unit), or class, or it could
be contained within a pair of braces.
Currently a lot of important code is contained within headers (due somewhat
to the current implementations of templates). This code will be included
in a wide variety of environments. Since, you have no idea or control over
the context under which your header will be compiled you are forced to put
std:: (or some other namespace) in front of everything. This
std::effectively std::reduces std::the std::namespace std::prefix std::to
std::a std::mandatory std::wart, std::which std::reduces std::the
std::readability std::of std::the std::code.
Being able to scope the 'using namespace std;' statement would remove a lot
of noise for the program text, and allow simple uncluttered code with the
reasonable defaults.
Now that I am thinking about it, it would be nice to be able to say ...
all these functions are a part of
template< class TBase, class TObj, class TTraits=Traits<CObj> > MyClass::
without having to spell it out in painful detail in front of each function.
Repectfully...David
Andrew R. Thomas-Cramer
"Greg Hickman" <ghic...@flash.net> wrote in message
news:pplh7.2247$rx2.88...@newssvr16.news.prodigy.com...
>...
> To me, its only natural to want to employ using declarations in my headers
> to shorten names in situations like:
>
> #include "TheirCompanyX/Inc/Library1/TheirType.h"
>
> namespace MyCompany::MyLib {
> using TheirCompany::Library1::TheirType;
>
This header file introduces TheirType into the MyCompany::MyLib namespace,
for any module that includes it. If this isn't the goal, but merely a
side-effect of simplifying declarations within the header file, the benefit
of the internal simplicity may be overridden by the costs.
Francis Glassborow
Ferguson <DavidF...@NOcsiSPAM.com> writes
>Being able to scope the 'using namespace std;' statement would remove a lot
>of noise for the program text, and allow simple uncluttered code with the
>reasonable defaults.
You can, the problem is header files and there is no reasonable way of
dealing with those because they are intended to work as parts of other
files.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Greg Hickman
"Andrew R. Thomas-Cramer" <ar...@prism-cs.com> wrote in message
news:3b8a5798$0$42877$272e...@news.execpc.com...
>
> "Greg Hickman" <ghic...@flash.net> wrote in message
> news:pplh7.2247$rx2.88...@newssvr16.news.prodigy.com...
> >...
> >
> > namespace MyCompany::MyLib {
> > using TheirCompany::Library1::TheirType;
> >
> >...
>
> This header file introduces TheirType into the MyCompany::MyLib namespace,
> for any module that includes it.
Perhaps that should read "... for any module that includes it, as long as
that module is also in the MyLib namespace", and that's exactly what I'm
after here. If I make a decision to use a class provided by another library
in the public interfaces of MyLib (e.g., Their_company::Math::Vector), then
I might like to do so in an unqualified manner within MyLib. A
using-declaration like the one above has no effect on the namespaces of
MyLib clients unless they ask for it via their own using-declaration
or -directive.
Greg Hickman
Serge Smeesters
>> a lot of noise for the program text, and allow simple uncluttered code
>> with the reasonable defaults.
> You can, the problem is header files and there is no reasonable
> way of dealing with those because they are intended to work
> as parts of other files.
Are you talking about think like that :
// smell.cpp
//
#include "smell.cpp"
using namespace std;
namespace Smell
{
void fill( int a, int b )
{
// ...
}
#include <list>
void sniff_function()
{
#include <set>
// ... maybe that can work!?
}
}
// ...
//
// smell.cpp
I propose to apply the "contract" concept to including header !
At the enter point of an header, we are in the global scope
without using anything !
Usage should be like that :
// suave.cpp
//
#include "suave.h"
#include <list>
#include <set>
// this is not the "best", but only regard this file !
using namespace std;
void Suave::sniff_function()
{
// Ok, I know exactly what are there ...
}
//
// suave.cpp
With good (I think "logical") habits, what can be wrong again about namespace
?
--
Serge Smeesters
http://www.sesa.ucl.ac.be/serge/
Look at this video (to fun ;))) :
http://www.sesa.ucl.ac.be/serge/Video/dancemonkeyboy.mpg
David Bradley
> I disagree with the standard library facilities in the
> namespace std (or any namespace, for that matter), because
> it makes them look like they're something out of the
> ordinary.
Not to me, it looks quite normal. Immediately tells me this is coming
from the C++ library and I don't have to go look around to see where it
really is coming from, or worry that the author reused some library
identifier and that the code does something I don't expect.
David Bradley
> So here's the horror: if it were up to me, we'd get rid of namespaces
> entirely.
>
> beloning to library xyz tend to be prefixed with xyz, e.g., xyzfill. In my
> view, the unique prefix convention worked well, was completely portable,
> and required no language support.
Cool, then all those people complaining about typing std::identifier
would be forced to type stdidentifier or std_identifier and couldn't use
the using namespace std trick to get around typing std::.
Andrew R. Thomas-Cramer
"Greg Hickman" <lmco_com!greg_h...@uunet.uu.net> wrote in message
news:9mecin$34...@news1.lmtas.lmco.com...
>
> "Andrew R. Thomas-Cramer" <ar...@prism-cs.com> wrote in message
> news:3b8a5798$0$42877$272e...@news.execpc.com...
> >
> > "Greg Hickman" <ghic...@flash.net> wrote in message
> > news:pplh7.2247$rx2.88...@newssvr16.news.prodigy.com...
> > >...
> > > #include "TheirCompanyX/Inc/Library1/TheirType.h"
> > >
> > > namespace MyCompany::MyLib {
> > > using TheirCompany::Library1::TheirType;
> > >
> > >...
> >
> > This header file introduces TheirType into the MyCompany::MyLib
namespace,
> > for any module that includes it.
>
> Perhaps that should read "... for any module that includes it, as long as
> that module is also in the MyLib namespace", and that's exactly what I'm
No, I don't think so.
> after here. If I make a decision to use a class provided by another
library
> in the public interfaces of MyLib (e.g., Their_company::Math::Vector),
then
> I might like to do so in an unqualified manner within MyLib. A
> using-declaration like the one above has no effect on the namespaces of
> MyLib clients unless they ask for it via their own using-declaration
> or -directive.
Given the header file above, client code can legally refer to
MyCompany::MyLib::TheirType. This pollutes the MyCompany::MyLib namespace
for all clients of the header file, merely for simplicity within one header
file. It introduces the possibility of client coupling to
MyCompany::MyLib::TheirType, which may affect maintainability.
news-server.satx.rr.com
> entirely.
>
I hate to sound like a middle ground person, but that's where I stand. In
my experience, namespaces serve a useful purpose, but only under the right
circumstances.
Foundation level code, standard library/boost/STL, should always be
encapsulated in namespace declarations. While the code may change, it
changes very little, therefore making it perfectly acceptable to use "using
namespace std;" at the top of .cpp files.
Middleware code, the main classes that build the structure of the project,
should use namespace declarations, but rarely be used with "using namespace
....". The functions in this code change frequently, and the code writers
need to protect those above.
AType::Node and BType::Node is not that much harder to type and comprehend
than ATypeNode and BTypeNode.
Top level code, the code that glues all the pieces together, rarely needs to
be encased in namespace declarations. I know the argument is that you never
know how the project is going to evolve and who is going to eventually
maintain your code, but successful project organization is based on 1000's
of such judgement calls, and most experienced programmers should have that
intuition highly toned.
The day I have to write:
std::type::int std::main ( std::type::int argc, std::type::char **argv )
{
return std::constant::0;
}
is the day I revolt :)
LR
David Bradley wrote:
> Scott Meyers wrote:
> > [snip] if it were up to me, we'd get rid of namespaces
> > entirely.
[snip]
> [snip] people [snip]
> would be forced to type stdidentifier or std_identifier [snip]
Would we need a new rule in the standard reserving identifiers begining
with 'std' or 'std_'?
LR.
Andrew R. Thomas-Cramer
> long? Because of the unque-prefix convention, whereby global symbols
my
> view, the unique prefix convention worked well, was completely portable,
> and required no language support.
On the other hand, choosing an appropriate prefix was difficult. It had to
be short enough to be readable -- and avoid chewing up the 32 characters
guaranteed supported in identifiers -- but long enough to avoid name clash.
In practice, prefixes tended to be short, usually three characters or less.
Trolltech's Qt, for example, uses the single letter "Q".
> Interestingly, it is increasingly becoming clear that library authors must
> adhere to Dave's suggestion above: avoid unqualified names. For names
like
> fill or count in std, this means that library source code must always
refer
> to std::fill or std::count to avoid surprises.
Always in header files. Are you suggesting this is also true in source
files?
> But if that's the case, why
> not get rid of the colons and use the unique-prefix solution, e.g.,
> stdfill? Where is the benefit of namespaces if we have to fully qualify
> our uses of the names in them?
Library header files aren't the only C++ code written. Using
declarations/directives can still be used in library source files, and in
application files.
>...
> And one more thing. I think using declarations are a syntactic pain in
the
> hind quarter, and for that reason I don't recommend their use. They're a
> pain to type (over and over and over at the top of each function), ...
Forgive me if I'm missing something obvious, but is there a good reason not
to type them once per source file, at the top?
> - My hair style calls into immediate question all my judgements.
Your hair style doesn't compare to my scraggly beard, based on the pictures
on the back of "Effective C++" and "More Effective C++".
Greg Hickman
[snip]
> > > "Greg Hickman" <ghic...@flash.net> wrote in message
> > > news:pplh7.2247$rx2.88...@newssvr16.news.prodigy.com...
> > > >...
> > > > #include "TheirCompanyX/Inc/Library1/TheirType.h"
> > > >
> > > > namespace MyCompany::MyLib {
> > > > using TheirCompany::Library1::TheirType;
> Given the header file above, client code can legally refer to
> MyCompany::MyLib::TheirType.
And if we remove the using-declaration, client code can still legally refer
to the type as ThierCompany::Library1::ThierType.
> This pollutes the MyCompany::MyLib namespace
> for all clients of the header file, merely for simplicity within one
header
> file.
I would certainly consider injecting a name into someone else's namespace to
be pollution. Since the name is being introduced only into my namespace, I
consider it to be more of a design decision. ;-)
> It introduces the possibility of client coupling to
> MyCompany::MyLib::TheirType, which may affect maintainability.
Agreed.
Greg Hickman
Ron Natalie
LR wrote:
>
> David Bradley wrote:
> > Scott Meyers wrote:
> > > [snip] if it were up to me, we'd get rid of namespaces
> > > entirely.
> [snip]
> > [snip] people [snip]
> > would be forced to type stdidentifier or std_identifier [snip]
>
> Would we need a new rule in the standard reserving identifiers begining
> with 'std' or 'std_'?
>
And then we'd need scoped name substitutions so we could do:
define vector std_vector;
Carlos Moreno
"Andrew R. Thomas-Cramer" wrote:
>
> On the other hand, choosing an appropriate prefix was difficult.
Ahh, and they had to come up with std!!
I'm not a doctor, but I can't help but associating std with
"sexually transmitted disease"... As I can't help but associating
MS with "multiple sclerosis" (a very nasty neurological disease)...
I guess you understand now that my hating MicroSoft and hating
the std namespace might follow the same pattern after all :-)
Carlos
--
David A. Ferguson
> You can, ...
How?
How do you apply the 'using namespace std;' to a limited scope?
I haven't found a way to scope the 'using namespace std;', and would like
to know how.
It seems to apply to the entire translation unit. Once you utter that
phrase in any file within the TU, it blasts its way across all other files
used in the TU. With effects much like a macro, the using namespace
statement knows no boundaries.
We need a way within a header to create a know sheltered environment,
*in spite* of the fact that the header will be included in many different
translation units under different environments.
In some libraries (especially template based libraries) the header
functions more like a complete module and is not intend to work as part
of something
If you could do this...
class AClass {
// Only applies to this class
using namespace std;
public:
void AFunc() {
cout << "AClass AFunc\n";
}
};
or this
using {
using namespace std; // Only applies within the braces
class AClass { ... }
}
or
if it was simply limited to the physical file (not the TU)
...then you could have a header file only module that includes the
declaration and definition, with the convince of namespace defaults, while
limiting the scope to a know area. The code in your header module would be
safe from the TU environment and would likewise not pollute the TU
environment.
If you can't scope the 'using namespace' statement then you can never use
it safely and you must prefix everything with xyz::.
Respectfully...David
Attila Feher
[SNIP]
> > Would we need a new rule in the standard reserving identifiers begining
> > with 'std' or 'std_'?
> >
> And then we'd need scoped name substitutions so we could do:
>
> define vector std_vector;
And give a low-hit to Mr. Stroustrup who wanted to get rid of the
preprocessor...
A
Chris Uzdavinis
> > > Being able to scope the 'using namespace std;' statement ...
>
> > You can, ...
>
> How?
> How do you apply the 'using namespace std;' to a limited scope?
namespace Limited_Scope
{
using namespace std;
// ...
}
--
Chris
Francis Glassborow
Ferguson <DavidF...@NOcsiSPAM.com> writes
>How do you apply the 'using namespace std;' to a limited scope?
>
>I haven't found a way to scope the 'using namespace std;', and would like
>to know how.
...
using namespace xyz; // applies to the whole TU
void foo () {
using namespace xyz; // applies to function foo
...
}
namespace abc {
using namespace xyz; //limited to namespace abc
}
etc.
However when you include a file in another everything at filescope in
the first file becomes included at filescope in the second.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Graeme Prentice
"Chris Uzdavinis" <ch...@atdesk.com> wrote in message
news:j61ylt7...@explicit.atdesk.com...
> "David A. Ferguson" <DavidF...@NOcsiSPAM.com> writes:
>
> > > > Being able to scope the 'using namespace std;' statement ...
> >
> > > You can, ...
> >
> > How?
> > How do you apply the 'using namespace std;' to a limited scope?
>
>
> namespace Limited_Scope
> {
> using namespace std;
>
> // ...
> }
this is potentially dangerous because some compilers (specifically
Borland C++ 5.5.1) allow members of std (or whatever namespace the
using directive refers to) to hide/override names that are in the
scope surrounding namespace Limited_Scope and are being accessed
unqualified from within namespace Limited_Scope i.e. future
additions to namespace std can cause a silent change in the meaning of
code (actually I have reported this problem to Borland but they
havn't responded as yet). If Borland can get it wrong, others
probably can too.
Also you can put the using directive at block scope (I think) or
function scope (I think Borland handle this correctly).
Graeme
Daniel James
> > How do you apply the 'using namespace std;' to a limited scope?
>
>
> namespace Limited_Scope
> {
> using namespace std;
>
> // ...
> }
>
The trouble is that that does more than it seems most people want. If you
subsequently do a
using namespace Limited_Scope;
you end up 'using' the whole of the std namespace as well as the things
defined
in Limited_Scope. IOW I think people want 'using' within a namespace to allow
them to refer to objects in the 'used' namespace implicitly, but not to
include
everything from the 'used' namespace in the one being defined.
What I'd like to see is a construction something like
namespace Limited_Scope2
{
using private namespace std;
// ...
}
which would allow me to refer to things in the std namespace without the std::
prefix while definig things in the Limited_Scope2 namespace, but wouldn't
automatically drag in the whole of std if Limited_Scope is later 'using'ed.
I have a nasty suspicion that this would play havoc with the rules for
resolving scopes - particularly Koenig lookup, though.
Cheers,
Daniel
[nospam.demon.co.uk is a spam-magnet. Replace nospam with sonadata to reply]
Graeme Prentice
>
> namespace Limited_Scope
> {
> using namespace std;
>
> // ...
> }
I commented in my earlier post that this is potentially dangerous if
unqualified names are used within namespace Limited_Scope that refer
to entities visible in the scope surrounding namespace Limited_Scope
because names in namespace std can silently hide names in the
surrounding scope.
(so if you include a new header file one day that introduces a whole
heap of previously not visible names from the std namespace then you
have a chance of a silent change to the meaning of your code).
The Borland compiler 5.5.1 does the name hiding I refer to, but the
Comeau C++ compiler does not - it reports ambiguities (except for
overloaded functions of course, where the risk of implicit type
conversions can still produce silent changes in the meaning of code).
To be honest, I don't know which way round it should be - and nor do
too many other people judging by the fact that I asked this very
question in this newsgroup a week or two ago and no-one responded.
The rules of name lookup and name hiding in the C++ standard are
numerous and complex and I havn't understood them all.
Also, when I referred to "function scope" for the using directive in
my last post, I really meant the outermost block of a function (which
is actually block scope not function scope) - function scope is a
thing for labels which have to be unique within the entire function.
Using directive scope is limited to the block it is in within a
function
Graeme.
Francis Glassborow
<gpre...@paradise.net.nz> writes
>To be honest, I don't know which way round it should be - and nor do
>too many other people judging by the fact that I asked this very
>question in this newsgroup a week or two ago and no-one responded.
>The rules of name lookup and name hiding in the C++ standard are
>numerous and complex and I havn't understood them all.
Knowing that you do not understand them fully probably qualifies you as
an expert :)
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<gpre...@paradise.net.nz> writes
>this is potentially dangerous because some compilers (specifically
>Borland C++ 5.5.1) allow members of std (or whatever namespace the
>using directive refers to) to hide/override names that are in the
>scope surrounding namespace Limited_Scope and are being accessed
>unqualified from within namespace Limited_Scope
But that is how it is meant to work, AFAIU it. If you want to access
things in outer scopes, you need to use explicit qualification if you
also use using declarations/directives.
> i.e. future
>additions to namespace std can cause a silent change in the meaning of
>code (actually I have reported this problem to Borland but they
>havn't responded as yet). If Borland can get it wrong, others
>probably can too.
>
>Also you can put the using directive at block scope (I think) or
>function scope (I think Borland handle this correctly).
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<inte...@nospam.demon.co.uk> writes
>namespace Limited_Scope2
>{
> using private namespace std;
>
> // ...
>}
>
>which would allow me to refer to things in the std namespace without the
std::
>prefix while definig things in the Limited_Scope2 namespace, but wouldn't
>automatically drag in the whole of std if Limited_Scope is later 'using'ed.
>
>I have a nasty suspicion that this would play havoc with the rules for
>resolving scopes - particularly Koenig lookup, though.
It would completely blow overloading if the overloaded name was in more
than one namespace. Working with namespaces means that the programmer
has to use an appropriate 'namespace safe' programming style.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Graeme Prentice
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in
message news:RtzB3rBG...@ntlworld.com...
>
> But that is how it is meant to work, AFAIU it. If you want to access
> things in outer scopes, you need to use explicit qualification if
you
> also use using declarations/directives.
>
determine this are.
In section 3.4.1 item 2 the standard says ...
[basic.lookup.unqual] 3.4.1 Unqualified name lookup
2 The declarations from the namespace nominated by a using-directive
become visible in a namespace enclosing the using-directive; see
7.3.4. For the purpose of the unqualified name lookup rules described
in 3.4.1, the declarations from the namespace nominated by the
using-directive are considered members of that enclosing namespace.
Yet in section 7.3.4 Using Directive the standard says ...
A using-directive specifies that the names in the nominated namespace
can be used in the scope in which the using-directive appears after
the using-directive. During unqualified name lookup (3.4.1), the names
appear as if they were declared in the nearest enclosing namespace
which contains both the using-directive and the nominated namespace.
[Note: in this context, "contains" means "contains directly or
indirectly". ]
which appears to me to be a contradiction.
Borland CPP 5.5.1 does it one way and "Comeau on Line" does it
another.
Graeme
Phil Edwards
Dave Harris <bran...@cix.co.uk> wrote:
> sme...@aristeia.com (Scott Meyers) wrote (abridged):
> > [...] avoid unqualified names. For names like fill or count in
> > std, this means that library source code must always refer
> > to std::fill or std::count to avoid surprises.
>
> provide my own specialised fill or count or whatever, and have the
> libraries use it where appropriate.
Tricky issues... by the way, have you looked at defect reports 225, 226,
and 229 of the standard library's working group? The appended notes for
#226 seems to sum up the four options under consideration.
Phil
--
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
- anonymous Egyptian scribe, c.1700 BC
Dave Harris
> Tricky issues... by the way, have you looked at defect reports 225, 226,
> and 229 of the standard library's working group? The appended notes for
> #226 seems to sum up the four options under consideration.
Yes.
Graeme Prentice
declarations you need into that namespace (rather than at function
scope or at file scope in the global namespace) do you know if this
means that members of your namespace can access those "imported" names
unqualified, safely, and without any chance of name clashes due to
names visible in the scope surrounding your namespace.
Graeme