Marc Schoolderman wrote:
> verec wrote:
> ...
> You will probably encounter a lot of mixed (old/new style STL) code;
> programmers will have to re-familiarise with both styles; you'll have to
> explain to novices why the library has two API's. This will confuse a
> lot of people, and confusion results in errors.
>
> > This is what Bjarne Stroustrup had to say about the matter in May 2005:
>
> I agree with this! There are a lot of places where the language could be
> more friendly. Things like allowing "vector<vector<int>>" and requiring
> meaningful template instantiation diagnostics would probably go a long
> way in preventing early baldness in C++ programmers. ;)
>
> But I doubt renaming the entire STL is the kind the "modest effort"
> Stroustrup is talking about here.

You'll get the vector<vector<int>> (without the extra space), and more
(for example see my "The Design of C++0x" (my title was the more modest
"Rules of thumb for the design of C++0X"):
http://www.research.att.com/~bs/rules.pdf

Remaning is a fundamentally bad idea, though. One person's improvement
is another person's obfuscation. By choosing your favorithe names,
you'd simply substutute new confusion for old. Furthermore, old code,
library implementations, textbooks, manuals, and habits last "forever".
Also, the STL names aren't perfect, but they aren't bad either. There
are bigger problems to tackle.

  -- Bjarne Stroustrup; http://www.research.att.com/~bs

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-06-27 15:55:54 +0100, "bjarne" <bjarne@gmail.com> said:

> Remaning is a fundamentally bad idea, though. One person's improvement
> is another person's obfuscation.

If anyone consults a cheap dictionnary of antonyns and synonyms while
_designing_, then nothing comes out of personal whim, but from
current and accepted usage _in the real world_

> By choosing your favorithe names,
> you'd simply substutute new confusion for old.

See above. My preferred computer book is called:
Oxford Dictionnary of Synonyms and Antonyms. =A38.99
Oxford University Press.

> Furthermore, old code,
> library implementations, textbooks, manuals, and habits last "forever".

True enough, but no justification for the status quo. C++ itself has
made obsolete most C text books, and I'm not sure anyone complains :)

> Also, the STL names aren't perfect, but they aren't bad either. There
> are bigger problems to tackle.

Like choosing more bad names for newly introduced features?
(just kidding, obviously :-)
--
JFB

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

(Thanks to the moderator for rejecting the glitched post.)

kuyper@wizard.net wrote:

> The problem is, pop_front() isn't the inverse of push_front(). If it
> were, the name would be appropriate.
[...]
> Yes, and the pop_* functions don't implement the pop operation.

You're forcing your definition of 'pop operation' here. Simply "To
discard the top item from a stack" is equally valid.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

bjarne wrote:

>=20
>=20
> Marc Schoolderman wrote:
>> verec wrote:
>> ...
>> You will probably encounter a lot of mixed (old/new style STL) code;
>> programmers will have to re-familiarise with both styles; you'll have =
to
>> explain to novices why the library has two API's. This will confuse a
>> lot of people, and confusion results in errors.
>>
>> > This is what Bjarne Stroustrup had to say about the matter in May 20=
05:
>>
>> I agree with this! There are a lot of places where the language could =
be
>> more friendly. Things like allowing "vector<vector<int>>" and requirin=
g
>> meaningful template instantiation diagnostics would probably go a long
>> way in preventing early baldness in C++ programmers. ;)
>>
>> But I doubt renaming the entire STL is the kind the "modest effort"
>> Stroustrup is talking about here.
>=20
> You'll get the vector<vector<int>> (without the extra space), and more
> (for example see my "The Design of C++0x" (my title was the more modest
> "Rules of thumb for the design of C++0X"):
> http://www.research.att.com/~bs/rules.pdf
>=20
> Remaning is a fundamentally bad idea, though. One person's improvement
> is another person's obfuscation. By choosing your favorithe names,
> you'd simply substutute new confusion for old. Furthermore, old code,
> library implementations, textbooks, manuals, and habits last "forever".
> Also, the STL names aren't perfect, but they aren't bad either. There
> are bigger problems to tackle.
>=20
>   -- Bjarne Stroustrup; http://www.research.att.com/~bs

Hmmm...I suspect I'm not going to make much headway in this, but this is =
my
2=A2 worth on the matter. I was just going to suggest a possible radical
approach to renaming, not one that I particularly like, but to my mind a
viable one.  That wold be to adopt the newer convention of mixedCase,
rather than under_scores.  With a bit of inventiveness name collisions
could be avoided between the old and new.  From my perspective, I have re=
ad
about half of Josuttis's TC++SL, and so far I have not had a chance to
really study the C++ string classes.  If the naming (and functionality)
were congruent between the string classes and the container classes, I
suspect I would have far less left to learn. =20

>From the conditions I've been subject to on a regular basis, I never exp=
ect
things to remain fixed for an extended period.  I guess I would be rather
disoriented if ls, grep, xterm, etc were renamed out of existence. OTOH,
I've also seen APIs change significantly from version to version in rapid
succession. I've also seen new, redundant, naming conventions introduced
from time to time.  I can see where that might make the implementation of
the Standard Library a bit cluttered and therefore harder to maintain.  I
also understand the force of momentum.  I regularly see people using
C-style code in C++, where a superior C++ option is available.  Trying to
get the old-timers to adjust to new ways of doing this is often a lost
cause.  Additionally we /are/ talking about C++ programmers.=20

I find your comment about old library implementations and particularly ol=
d
textbooks rather ironic.  I guess it's a tribute to the design of C++ tha=
t
anything in the computing industry can remain valid for more than a coupl=
e
years, at best.

As for the naming the the Standard Library not being "that bad", on the
whole this is true.  I will also note that the new proposals seem to be
more carful and consistent in naming.  The last section I finished in
TC++SL was ypoc_sdrawkcab.
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

verec wrote:
> On 2005-06-27 15:55:54 +0100, "bjarne" <bjarne@gmail.com> said:
.
> > Furthermore, old code,
> > library implementations, textbooks, manuals, and habits last "forever".
>
> True enough, but no justification for the status quo. ...

It's not a justification for the fact that the names that were chosen,
but it is a very strong justification for keeping them, now that
they've been chosen. It is essentially impossible to get all old code
recompiled with the latest version; in many cases the original source
code doesn't even exist anymore, and binary compatibility is required
if old object files or libraries are to be linked with new ones. A new
version of C++ that removed any function as widely used as pop_back()
would result in that version of C++ being ignored by just about anyone
who has to deal with legacy C++ code.

> ... C++ itself has
> made obsolete most C text books, and I'm not sure anyone complains :)

C still exists, and there are still a fairly large number of people who
deliberately choose C over C++, at least in some contexts; and there
are some valid reasons for doing so. See comp.std.c and comp.lang.c for
evidence of the continued existence of C. Note: I don't want to get
involved in a debate over the validity of those reasons; for the
purposes of this discussion, it's sufficient to note that they believe
the reasons are valid.

What is very relevant is the large number of things that were NOT
changed in C++, in order to retain backwards compatibility with C. The
goal was to make sure that most well-written C code would require
little or no changing to compile as C++ code with the same meaning as
the original C code (in this context "well written" means such things
as making full use of function prototypes). This required a great many
compromises; see "The Design and Evolution of the C++ language" to get
a better appreciation of what those compromises were. In particular,
the C standard library was taken up, with almost no changes, as part of
the C++ standard library. Not a single function from the C standard
library was replaced with a differently named function for the C++
library. Many new C++ functions gave similar functionality to C library
functions, but they supplemented that library, rather than replacing
it.

The fact that backward compatibility with C was given a high priority,
made it much easier for C++ to be accepted and widely adopted. Other
approaches are possible. For example, Java faced the same issues, and
made more changes and fewer compromises. As a result, translating
legacy C code into Java is a lot more work than translating it into
C++. I think it would be counter-productive to debate the two different
approaches; the best way to determine which approach is better, is to
try both, and see which one works best, and that's exactly what is
already happening.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

> Marc Schoolderman wrote:
>> (Thanks to the moderator for rejecting the glitched post.)
>>
>> kuyper@wizard.net wrote:
>>
>> > The problem is, pop_front() isn't the inverse of push_front(). If it
>> > were, the name would be appropriate.
>> [...]
>> > Yes, and the pop_* functions don't implement the pop operation.
>>
>> You're forcing your definition of 'pop operation' here. Simply "To
>> discard the top item from a stack" is equally valid.
>
> Even if it's only "equally" valid (and I don't know how you could prove
> that, one way or the other), that still implies that the more specific
> definition of 'pop' is also valid.
>
> It's a good idea to avoid confusing people by using a name to describe
> something that is inconsistent with a widely used definitions of the
> name, even if that definition is not universally accepted.

I'm not so concerned about pop and push as I am about remove(coll) vs
list::remove(), and coll::clear() vs. stringstream::clear().  I don't
believe we really can succeed in getting the established naming changed.
The best we can do is to identify the (few) places where there really is a
problem and try to mitigate it.  I'm not sure what approach to take.  If
you leave a clarification to page 300 of 800 pages in a standard work on
the C++ Standard Library, there are going to be a lot of people confused
about coll::clear() vs. stringstream::clear(), etc.  OTOH, if you introduce
such inconsistencies up front you're likely to confuse many people trying
to get started, and make Java programmers out of would-be C++ programmers.

Josuttis's approach is to explain why things are as they are when the
problematic names appear in context.  That helps a great deal in both
understanding and accepting things as they are.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

verec wrote:
> On 2005-06-27 15:55:54 +0100, "bjarne" <bjarne@gmail.com> said:

> > Remaning is a fundamentally bad idea, though. One person's
> > improvement is another person's obfuscation.

> If anyone consults a cheap dictionnary of antonyns and
> synonyms while _designing_, then nothing comes out of personal
> whim, but from current and accepted usage _in the real world_

In what real world?  Many of the terms are highly technical.

> > By choosing your favorithe names, you'd simply substutute
> > new confusion for old.

> See above. My preferred computer book is called: Oxford
> Dictionnary of Synonyms and Antonyms.    8.99 Oxford University
> Press.

In sum, a book which will give you about a dozen different words
for each particular meaning.  With no hint as to which is most
appropriate in this context.  (And no technical meanings, of
course.)

I think that Boost has specified some naming conventions, and
that these are generally applied to new library components.  I
think that their conventions were more or less based on existing
names in the standard (ignoring inconsistencies like
basic_ios::Init, of course).  And I think that that's about the
best we can hope for; we can't change the existing, and
regardless of what is decided, the future won't be perfect
either.  (Look at all the naming inconsistancies in the Java
library, although Java had a very rigorous naming convention
long before most of the library was written.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

    [...]
> What is very relevant is the large number of things that were
> NOT changed in C++, in order to retain backwards compatibility
> with C. The goal was to make sure that most well-written C
> code would require little or no changing to compile as C++
> code with the same meaning as the original C code (in this
> context "well written" means such things as making full use of
> function prototypes).

Except, of course, that that wasn't the case when C++ started
requiring function prototypes.  When C++ started requiring
function prototypes, they didn't even exist in C, so even the
best written C didn't use them.  (I've never used function
prototypes in C.  By the time they became portably available, I
was deep into C++, and not about to go back.)

Stroustrup has been quoted as saying "as close to C as possible,
but no closer".  From this and the above, I gather that he felt
a language without having to declare the function parameters was
not possible.  (I agree with him on that.)  About all that was
offered was a separate program (protoize, I think it was called)
to generate the prototypes automatically.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> bjarne wrote:

> Hmmm...I suspect I'm not going to make much headway in this,
> but this is my 2    worth on the matter. I was just going to
> suggest a possible radical approach to renaming, not one that
> I particularly like, but to my mind a viable one.  That wold
> be to adopt the newer convention of mixedCase, rather than
> under_scores.

Why?  Psychologically, under_scores are more readable and take
less getting used to (although the difference isn't enormous).
I currently use mixed case simply because my customers do and
did.  Most of my customers originally adopted it because the
CCITT used it.  I don't know where the CCITT got it from.  It
works.  As do underscores.  I would hardly call it a defect that
the standard chose a different convention that the one I happen
to use today.

> With a bit of inventiveness name collisions could be avoided
> between the old and new.

I thought inventiveness was precisely what we wanted to avoid.

> From my perspective, I have read about half of Josuttis's
> TC++SL, and so far I have not had a chance to really study the
> C++ string classes.  If the naming (and functionality) were
> congruent between the string classes and the container
> classes, I suspect I would have far less left to learn.

There's a lot of similarities: you'll find push_back, insert,
etc. in both.  String has a lot of additional operations, which
the other containers don't.

> From the conditions I've been subject to on a regular basis, I
> never expect things to remain fixed for an extended period.  I
> guess I would be rather disoriented if ls, grep, xterm, etc
> were renamed out of existence.

And yet, the names of the Unix commands are far worse than
anything we have in C++.

> OTOH, I've also seen APIs change significantly from version to
> version in rapid succession.  I've also seen new, redundant,
> naming conventions introduced from time to time.  I can see
> where that might make the implementation of the Standard
> Library a bit cluttered and therefore harder to maintain.  I
> also understand the force of momentum.  I regularly see people
> using C-style code in C++, where a superior C++ option is
> available.  Trying to get the old-timers to adjust to new ways
> of doing this is often a lost cause.  Additionally we /are/
> talking about C++ programmers.

> I find your comment about old library implementations and
> particularly old textbooks rather ironic.  I guess it's a
> tribute to the design of C++ that anything in the computing
> industry can remain valid for more than a couple years, at
> best.

I'm not sure.  I still consult Barton and Nackman.  And some of
the code I maintain is more than 15 years old.  My memory goes
back that far (and further, but not in C++) too.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

> It's a good idea to avoid confusing people by using a name to describe
> something that is inconsistent with a widely used definitions of the
> name, even if that definition is not universally accepted.

I can understand your position now: even if a common definition people
have isn't useful in C++ (and I'm guessing you wouldn't have preferred
pop_* to return values either), we should still obey that definition by
not using it.

My argument is that having 'push' and 'drop' is confusing as well
because it breaks the symmetry in naming. We disagree over which
confusion is more serious. ;)

I think what's more important is that (judging from your other post) we
both think that renaming would be a bad idea. Probably even such
horrendous things as std::streambuf.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> pop_front() and pop_back() are even worse, in my mind.  I expect something
> named pop to return a value.  But that may simply be my own bias.

I thought there was a good reason why pop_front() and pop_back() didn't
return values - exception safety. The "pop" functions are guaranteed not
to throw (generally) and you can't guarantee this if they return values.

If they DID return values, it would not be possible to provide the
strong guarantee, I think. See http://www.gotw.ca/gotw/008.htm

>>On the other hand, it is definitly way too late to think of
>>changing any of this now.
> I'm not sure of that.  Deprecation is a great thing.  It can be used as a
> way of shaming programmers for not adapting new conventions rather than a
> sincere promise that their code will (really) become uncompilable.

I sense an unwarranted assumption here. IMO, the point of the C++
Standard is to provide a stable, unfragmented language and core library,
so people (this includes managers, etc.), can be reasonably sure that
the projects they invest development time in will work on multiple
implementations, and will still work in 5 years time from now.

I don't think the standard aims to make C++ nicer from a pedagogical
viewpoint, nor do I think many C++ programmers recognise the CWG/LWG as
having authority over what conventions they should adopt.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Schoolderman <squell@alumina.nl> writes:

> Steven T. Hatton wrote:
>
>> pop_front() and pop_back() are even worse, in my mind.  I expect something
>> named pop to return a value.  But that may simply be my own bias.
>
> I thought there was a good reason why pop_front() and pop_back() didn't
> return values - exception safety.

No, it's just a question of usefulness.  Calling the possibility of an
exception (or of changed data in the face of an exception) a lack of
safety is wrong.

That said, a pop that modifies the container and returns data but
might throw is less useful than the one we have.

> The "pop" functions are guaranteed not to throw (generally) and you
> can't guarantee this if they return values.
> If they DID return values, it would not be possible to provide the
> strong guarantee, I think. See http://www.gotw.ca/gotw/008.htm

That's true.  However, one could have chosen to provide the strong
guarantee for erase on begin() or end() - 1.  So you'd have the
functionality, and pop_xxx() could have the less useful but
more-intuitive-to-Steven functionality.

Personally, I go for usefulness ;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-06-25 10:22:05 +0100, Marc Schoolderman <squell@alumina.nl> said:

> Steven T. Hatton wrote:
>
>> pop_front() and pop_back() are even worse, in my mind.  I expect something
>> named pop to return a value.  But that may simply be my own bias.
>
> I thought there was a good reason why pop_front() and pop_back() didn't
> return values - exception safety. The "pop" functions are guaranteed
> not to throw (generally) and you can't guarantee this if they return
> values.

Fair enough, but besides the point. Better names that would have preserved the
semantics you have alluded to could have been ``drop_front'' and ``drop_back''
repsectively.

> If they DID return values, it would not be possible to provide the
> strong guarantee, I think. See http://www.gotw.ca/gotw/008.htm
>
>>> On the other hand, it is definitly way too late to think of
>>> changing any of this now.
>> I'm not sure of that.  Deprecation is a great thing.  It can be used as a
>> way of shaming programmers for not adapting new conventions rather than a
>> sincere promise that their code will (really) become uncompilable.
>
> I sense an unwarranted assumption here. IMO, the point of the C++
> Standard is to provide a stable, unfragmented language and core
> library, so people (this includes managers, etc.), can be reasonably
> sure that the projects they invest development time in will work on
> multiple implementations, and will still work in 5 years time from now.

Non sequitur. Whether "management" has any confidence in the perennity of
the language/library has nothing to do with its internal naming consistency
(or lack thereof), After all, they're not supposed to _understand_ it. In
that respect, the current version of C++ is huge success: even _programmers_
don't grasp it :)

> I don't think the standard aims to make C++ nicer from a pedagogical
> viewpoint, nor do I think many C++ programmers recognise the CWG/LWG as
> having authority over what conventions they should adopt.

That's precisely why C++ is the tragedy it currently is. Unfortunately,
we haven't got anything better, but what we've got is pretty lame.
--
JFB

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Schoolderman wrote:

> Steven T. Hatton wrote:
>
[...]
> If they DID return values, it would not be possible to provide the
> strong guarantee, I think. See http://www.gotw.ca/gotw/008.htm

I agree with verec in his reply to this.

>>>On the other hand, it is definitly way too late to think of
>>>changing any of this now.
>> I'm not sure of that.  Deprecation is a great thing.  It can be used as a
>> way of shaming programmers for not adapting new conventions rather than a
>> sincere promise that their code will (really) become uncompilable.
>
> I sense an unwarranted assumption here. IMO, the point of the C++
> Standard is to provide a stable, unfragmented language and core library,
> so people (this includes managers, etc.), can be reasonably sure that
> the projects they invest development time in will work on multiple
> implementations, and will still work in 5 years time from now.

Well, there are many arguments in favor of the approach I am suggesting.
Not the least of which is the probability of having technology that can
upgrade code that uses the older naming conventions with very little need
for human intervention.  Since there would be little reason on the part of
compiler providers to actually remove the deprecated support, it is
unlikely it would impact 5-year-old code other than producing a lot of
warnings when it's compiled.

> I don't think the standard aims to make C++ nicer from a pedagogical
> viewpoint, nor do I think many C++ programmers recognise the CWG/LWG as
> having authority over what conventions they should adopt.
>
> ~Marc.

This is what Bjarne Stroustrup had to say about the matter in May 2005:

"C++ has drifted towards becoming an ?expert friendly? language. In
a gathering (in person or on the Web) of experts, it is hard to build a
consensus (or even interest) for something that ?just? helps novices.
The general opinion (in such a gathering) is typically that the best we
can do for novices is to help them become experts. But it takes time
to become an expert and most people need to be reasonably productive
during the time it takes. More interesting, many C++ novices have
no wish or need to become experts in C++. If you are a physicist
needing to do a few calculations a week, an expert in some business
processes involving software, or a student learning to program, you
want to learn only as many language facilities as you need to get your
job done. You don?t want to become a language expert?you want
to be (or become) an expert in your own field and know just enough
of some programming language to get your work done. When
supported by suitable libraries, C++ can be used like that?it is widely
used like that. However, there are traps, pitfalls, and educational
approaches that make such ?occasional use? of C++ unnecessarily
difficult. With a modest effort, C++0x can do much better in this area."

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:

> That's true.  However, one could have chosen to provide the strong
> guarantee for erase on begin() or end() - 1.  So you'd have the
> functionality, and pop_xxx() could have the less useful but
> more-intuitive-to-Steven functionality.
>
> Personally, I go for usefulness ;-)
>
I really wasn't suggesting the behavior of pop_front() or pop_back() should
be changed.  I was suggesting both that the name was slightly unintuitive
to me, and that intuitiveness is a somewhat subjective matter.

Consider this as a better example of something that could (be) have been
named more effectively:

namespace std {
  template <class Key, class T, class Compare = less<Key>,
              class Allocator = allocator<pair<const Key, T> > >
  class multimap {
  public:

    typedef Key                                     key_type;
    typedef T                                       mapped_type;
    typedef pair<const Key,T>                       value_type;
    //...
  };
}

Here's how Josuttis presents that as follows:

container::value_type
* The type of elements.
* For sets and multisets it is constant.
* For maps and multimaps, it is pair<cosnt key-type, value-type>
..

Perhaps element_type might be better for what is called value_type? Changing
mapped_type to value_type is certainly problematic at this point.  It's one
thing to change an old name to something currently unused; quite another to
use a previously defined name for someting different within the same scope.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

verec wrote:

>> I thought there was a good reason why pop_front() and pop_back()
>> didn't return values - exception safety. The "pop" functions are
>> guaranteed not to throw (generally) and you can't guarantee this if
>> they return values.
> Fair enough, but besides the point. Better names that would have
> preserved the
> semantics you have alluded to could have been ``drop_front'' and
> ``drop_back''
> repsectively.

This is easy to say, but the pop_front function has it's inverse
function in 'push_front'. "Push" and "pop" are two basic operations in
computer science, so it's pretty easy to memorise the functions -
back(), front(), push_back() pop_back() etc.

What's the inverse operation of 'drop'? Is it 'push'? Steve Hatton was
suggesting 'append' en 'prepend' - same problem, but in that case the
assocation to back() and front() is gone, and it's no longer clear to me
that the functions operate one item at a time.

Instead of going on criticising individual functions, it would be more
interesting to see a comprehensive alternative naming proposed.

> Non sequitur. Whether "management" has any confidence in the perennity of
> the language/library has nothing to do with its internal naming consistency
> (or lack thereof), After all, they're not supposed to _understand_ it. In
> that respect, the current version of C++ is huge success: even
> _programmers_
> don't grasp it :)

This is precisely the point. They don't understand it, but they will
notice as soon as code needs to change, because this will involve
developer time, introduce the risk of introducing new bugs, etc. I've
often heard the story where some programmer discovers poorly written
code, and subsequently gets told not to fiddle with it, because "it works".

Steven T. Hatton wrote:

> Since there would be little reason on the part of
> compiler providers to actually remove the deprecated support, it is
> unlikely it would impact 5-year-old code other than producing a lot of
> warnings when it's compiled.

Suppose we follow this route; this means the C++ STL api gets duplicated
in its entirety and there is a blanket permission to rely on deprecated
behaviour because it's not going to be removed anyway.

You will probably encounter a lot of mixed (old/new style STL) code;
programmers will have to re-familiarise with both styles; you'll have to
explain to novices why the library has two API's. This will confuse a
lot of people, and confusion results in errors.

> This is what Bjarne Stroustrup had to say about the matter in May 2005:

I agree with this! There are a lot of places where the language could be
more friendly. Things like allowing "vector<vector<int>>" and requiring
meaningful template instantiation diagnostics would probably go a long
way in preventing early baldness in C++ programmers. ;)

But I doubt renaming the entire STL is the kind the "modest effort"
Stroustrup is talking about here.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Schoolderman wrote:
> verec wrote:
.
> > Fair enough, but besides the point. Better names that would have
> > preserved the
> > semantics you have alluded to could have been ``drop_front'' and
> > ``drop_back''
> > repsectively.
>
> This is easy to say, but the pop_front function has it's inverse
> function in 'push_front'.

The problem is, pop_front() isn't the inverse of push_front(). If it
were, the name would be appropriate.

> ... "Push" and "pop" are two basic operations in
> computer science,

Yes, and the pop_* functions don't implement the pop operation.
Therefore, it's a bad idea to name them as if they did.

> What's the inverse operation of 'drop'?

It's uninvertible. The closest equivalent to an inverse would be an
operation that appends a default-constructed object of the contained
type. The point is, that since the standard has specified the existence
of drop_back and drop_front operations, they should have been called
drop_back and drop_front rather than pop_back and pop_front.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I am reading Josuttis's TC++SL and noticed that the member function
collection.empty() seems to be poorly named.  To my mind, when I saw
c.empty() my intuition expected it to be a means of emptying the container.
I don't know what the cost of changing that to is_empty() and deprecating
empty() would be, but it would probably add clarity to the interface, and
facilitate learning to use the library.  There is a similar problem with
clear().  In that case, clear also is used for stream objects.  When I saw
std::stringtream::clear() I assumed it functioned in the same way
std::string::clear() functions.  I learned differently while reading (part
of) clause 27 of the Standard.  My I suggest erase_all()?

I know these are really minor nits, and even people who agree with me in
principle, are likely to believe it is a waste of time to haggle over such
trivialities.  In principle I will agree with that.  I'm presenting these
two observations with the hope that they might inspire others to consider
this type of issue everywhere in the Standard.  Although there is not much
agreement on the exact details of naming conventions it is clear (probably
much clearer in 2005 than in 1995) that subtelties of naming can impact
(sometimes significantly) the usability of an API.


--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:

> I am reading Josuttis's TC++SL and noticed that the member
> function collection.empty() seems to be poorly named.  To my
> mind, when I saw c.empty() my intuition expected it to be a
> means of emptying the container.  I don't know what the cost
> of changing that to is_empty() and deprecating empty() would
> be, but it would probably add clarity to the interface, and
> facilitate learning to use the library.  There is a similar
> problem with clear().  In that case, clear also is used for
> stream objects.  When I saw std::stringtream::clear() I
> assumed it functioned in the same way std::string::clear()
> functions.  I learned differently while reading (part of)
> clause 27 of the Standard.  My I suggest erase_all()?

Overall, the naming conventions in the standard library are
pretty bad: push_back isn't really a push (which I would
associate with a stack structure), the "iterators" are more like
smart pointers than iterators, and remove doesn't.  Outside of
the STL part, of course, streambuf::sgetc doesn't remove
anything from the stream, for that you need sbumpc (which
actually returns the character).  And so on.

On the other hand, it is definitly way too late to think of
changing any of this now.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

> "Steven T. Hatton" wrote:
>
>> I am reading Josuttis's TC++SL and noticed that the member
>> function collection.empty() seems to be poorly named.  To my
>> mind, when I saw c.empty() my intuition expected it to be a
>> means of emptying the container.  I don't know what the cost
>> of changing that to is_empty() and deprecating empty() would
>> be, but it would probably add clarity to the interface, and
>> facilitate learning to use the library.  There is a similar
>> problem with clear().  In that case, clear also is used for
>> stream objects.  When I saw std::stringtream::clear() I
>> assumed it functioned in the same way std::string::clear()
>> functions.  I learned differently while reading (part of)
>> clause 27 of the Standard.  My I suggest erase_all()?
>
> Overall, the naming conventions in the standard library are
> pretty bad: push_back isn't really a push (which I would
> associate with a stack structure),
append(), preppend().

pop_front() and pop_back() are even worse, in my mind.  I expect something
named pop to return a value.  But that may simply be my own bias.

> the "iterators" are more like smart pointers than iterators,

That was a point of confusion for me. Coming up with a better naming scheme
might be difficult in this case, however.  Some iterators really are
iterators, and they are the essential components in the category of things
called iterator.

> and remove doesn't.

But list::remove() does.  This was yet another gotcha I hit along the road.

> Outside of
> the STL part, of course, streambuf::sgetc doesn't remove
> anything from the stream, for that you need sbumpc (which
> actually returns the character).  And so on.

sbumpc is a clearly intuitive function name.  What does it do?

> On the other hand, it is definitly way too late to think of
> changing any of this now.

I'm not sure of that.  Deprecation is a great thing.  It can be used as a
way of shaming programmers for not adapting new conventions rather than a
sincere promise that their code will (really) become uncompilable.

To my way of thinking, the entire library is excessively arcane.  There's no
clear gestalt for the overall structure, and it does not provide an
intuiteve interface.  I'm just beginning to grasps with clarity the
distinction between "global" container functions such as remove() and
container member functions such as list::remove().

I've mentioned before that I believe the library should be divided into
namespaces reflecting the header names.  I don't recall who, but one of the
people I regard as an authority suggested that would break the generic
functionality of the library.  I did not follow up on that argument at the
time, but I believe it's worth investigating.  It seems to me if the
Standard Library cannot effectively be partitioned into namespaces, there
is a problem in how C++ defines namespaces.

These are suggestions from one of the most successful API designers I know
of: http://doc.trolltech.com/qq/qq13-apis.html
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]