[comp.lang.c++.moderated] 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! ]