francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<+CDwuHdZjTuAFwd$@robinton.demon.co.uk>...
> In article <yo0uc.3668$Yd3.473@newsread3.news.atl.earthlink.net>, Edward
> Diener <eldiener@earthlink.net> writes
> >I think that what is disappointing is the slowness by which the C++
> >committee moves to make helpful language changes. While I understand much of
> >the conservative nature of that slowness, I know of no other major language
> >which has a ten year span to make language changes.
>
> Fortran, Cobol (and both are still actively used languages) C etc. It is
> very unwise to tinker with a language before the last lot of changes
> have been widely implemented. The reason some languages need such short
> cycles of change is that they have to keep repairing the things they
> broke the last time. Getting something wrong once is excusable, doing so
> more than once isn't.
> <snip>

FWIW, in recent years the Fortran committee has been trying to do
revisions on a shorter time scale than a decade.  There are several
reasons for this

1. The thirteen year delay from F77 to F90 was viewed as much too long
and hurt market share too much.

2. While some time is needed to define features properly, in practice
more time allows the addition of features whose combination is
difficult to validate.  If there is no concensus (and F90 was
notorious for its lack of concensus), there may be no usable compiler
experience. Even with concensus C++ has a couple of problematic
features due to a lack of implementor experience with them before the
publication of the standard, or the rejection of that experiencee by
the committee. In the end, no matter how much time you allow for
standardization, you may (almost certainly will) still wind up with
something wrong that needs to be fixed.

3. The complexity of F90 required significant fixes, and the
developement of HPF led to a demand for a few new well tested
features. It was therefore possible to develop F95 in about five
years, to incorporate the fixes with a few small additions.

4. With F95 done the committtee had a more solid foundation to work
with and was able to develope a larger revision (to be published soon
as Fortran 2003 (F03)) in about eight years.

5. The current plan is to develope another bug fix plus minor
enhancement revision of the language in five years, i.e. F08.

There are costs to this approach. The duplication of editorial work
and review processes meant that F03 will be published later than it
would have been if there had been no F95. It might instead have been
F01 or F02.  But on the other hand the extral review for F95 means
that F03 is almost certainly a solider language than it would have
been without F95, and F95 did much to shore up Fortran's market share.

It is also a difficult approach to keep on track.  Simply because of
the large number of features in F90, there was a very strong concensus
that a quick cleanup was needed, and feature addition was not allowed
to significantly interfere with the cleanup of the F95 work.  The F03
revision is not quite as large as F90,  and several of its additions
(e.g. C compatiblity, allocatable array extensions, and IEEE math) had
significant compiler experince during the development of the standard,
so there is an expectation that the standard will need less fixing
than was required for F95. This in turn has led to the expectation
that more features can be added to F03 by F08 than were added to F90
by F95. If carried too far this optimism will cause F08 to become F1X.
(I believe there are more than 100 proposed additions for F08 at this
stage. Most of them are minor, but a few such as such as "templates"
and units checking (a big interest of NASA after the Mars probe loss
due to a confusion of SI and imperial units) are not. While most of
the proposals will not be accepted for the language even ten minor
additions will be more than were accepted for F95.  My expectation is
that more than twenty additions will be studied in detail by the
committee, that more than ten additons will be accepted, and two or
three of the additions will be major. If they are lucky F08 will be
F10.)

That being said, many requests for rapid revisions have an unrealistic
expectation of the time scale.  The need to review the document both
inernally and externaly, combined with the need to coordinate among
several bodies: ISO, ANSI, and the committees, means that
standardizing a simple bug fix requires a minimum of about four years.
Every major addition to the language can be expected to increase this
time by a minimum of one year to ensure proper review.

---
[ 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 Thu, 27 May 2004 17:17:36 +0000 (UTC), tom_usenet
<tom_usenet@hotmail.com> wrote:

>> I agree with Niall.  Lack of move semantics is a /major/ drawback in
>> today's C++.
>
> I agree that the feature is needed. But we need to implement it, try
> it out and only once the best solution has been found, standardise it.
> I for one would prefer a proposal that included destructive move
> semantics, which will in general will provide the highest efficiency
> gains. I note that your proposal is purely for non-destructive
> semantics at the moment.

What on earth would be the point of a move constructor which *didn't*
destroy the original?

Cheers,
Niall

---
[ 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                       ]

In article <opfbb0prdpb865spacq6mstlljeietcpsv@4ax.com>,
 tom_usenet@hotmail.com (tom_usenet) wrote:

> I agree that the feature is needed. But we need to implement it, try
> it out and only once the best solution has been found, standardise it.

100% agreed.  Working... ;-)

> I for one would prefer a proposal that included destructive move
> semantics, which will in general will provide the highest efficiency
> gains. I note that your proposal is purely for non-destructive
> semantics at the moment.

<nod>  Go for it! :-)  There's nothing in N1377 that prevents a
destructive move coexisting (placement destructor syntax perhaps?).
They don't need to compete and might be mutually beneficial.  But reread:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alterna
tive%20move%20designs

before you start so that you don't relearn the gotchas that are in there
the hard way.  Imho, while non-destructive move is widely applicable,
destructive move would have a much narrower focus (useful nonetheless).
I.e. A destructive move constructor would be very handy in moving
objects from one buffer to another when resizing the buffer.  But I see
little use for destructive move assignment, or destructive move
functions in the user interface of a class.  For example:

vector<T>::push_back(T&&);  // non-destructive move into vector.
                            // But no destructive move into vector
                            // desired.

BigObject t;
vector<BigObject> v;
v.push_back(move(t));  // do not want to destruct t, just move from it.

> Have you implemented rvalue references in MWCW, or at least in an
> experimental internal version?

Partially, and internal/experimental only for the moment.  I would like
to take that partially up to full in the not too distant future, but
naturally I can't promise anything (schedules, priorities, etc.).

-Howard

---
[ 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                       ]

In article <opr8oj2hzvy9klrv@news.iol.ie>,
 s_googlegroups@nedprod.com (Niall Douglas) wrote:

> What on earth would be the point of a move constructor which *didn't*
> destroy the original?

Consider inserting into a vector in the case where there is sufficient
capacity to hold the insert.  Some of the elements in the constructed
region of memory will have to be moved to the uninitialized region to
make room for the new elements to be inserted.

With copy semantics one copy constructs from the existing elements in
the vector to the uninitialized region.  With move semantics you want a
nondestructive move construction to the uninitialized region.  If you
instead perform a destructive move for this purpose then your vector is
in a state before the new elements are inserted such that there is a
region of memory internal to the vector's size that is uninitialized.
If any of the external elements throws while you are copy constructing
them into your "hole", you will be left with a vector which does not
meet its internal invariants.  I.e. vector::insert will fail to achieve
basic exception safety.  One might be able to work around this by move
constructing the vector back to its original state (assuming a nothrow
move constructor), but that would be most inefficient, both in
performance (not so important) and in code size (very important).  Such
an operation requires basic exception safety, not strong exception
safety.

This is but one example.

Destructive move semantics has uses, but must be used with the same care
that one uses an explicit call to an object's destructor.  In practice
such calls though useful, are relatively rare.  Much more common is
needing to move from an object with static or auto storage (as opposed
to an object on the heap).  If an object has static or auto storage, it
already has a well defined time to be destructed.  If you move from it,
you need to leave it in a valid constructed state so that when existing
language rules destruct it, things will go smoothly.

N1377 briefly discusses destructive move semantics and some of the
problems associated with it.  One of the biggest problems I see is
destructively move constructing an object made up of members or base
classes that also want to destructively move construct.  During such an
operation you get into a state such that that part of your object is
destructed while another part is still trying to move itself.  It is a
state very foreign to C++ as we know it today (compared to destructing
most derived parts first such that an object is always in a self
consistent state even as it destructs).

That's not to say that destructive move constructors would not be
useful.  I do see a few benefits.  But destructive move semantics in the
hands of a non-expert is a recipe for a crashing program.  It would be
an advanced topic that beginner and intermediate level programmers
should not touch (like explicit calls to an object's destructor).

In contrast, the non-destructive move semantics outlined in N1377
describe a system that is so safe that beginners can start using it
without even realizing that they are using it (no syntax changes from
today).  And it accomplishes 96% - 99% of the performance goals of
destructive move semantics (estimated).

So the real question is:  Is introduction of destructive move semantics
(in addition to N1377) worth the risk in buggy code for achieving that
last few percent in performance?  There's a large part of me that says
yes!  C++ has always been the language to say:  Here's the rope, do with
it what you want.  Please try not blow up half the planet with the
nuclear device attached to the other end of that rope.

Another part of me says that the added benefit does not justify the
associated risk.  So N1377 leaves the question of destructive move
semantics open, for somebody else to carry the torch.  I will neither
support nor oppose such an effort until it is much more developed.

-Howard

---
[ 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                       ]

tom_usenet wrote:
> On Mon, 24 May 2004 14:29:39 CST, Niall Douglas
> <s_googlegroups@nedprod.com> wrote:
>
>> I personally feel that when producing language standards as with any
>> standard, the format should be big release, then point 1 release and
>> point 2 release with point 2 released as the next big release is in
>> preparation. ISO C++ has not followed this, much to its detriment :(
>
> You appear to have missed the 2003 TC (or "point release"). There's
> also the library TR coming out fairly soon. So you have a "bug fix"
> point release and a new features point release. What more do you want?

A release that adds new language features for which many have been asking.
The 2003 TC appears as a much-needed clarification to a number of C++
language issues, but it does little as far as I can see to solve certain
language issues. The library TR is certainly appreciated, since I and many
other C++ programmers already use a number of the libraries, especially the
ones from Boost.

Before you ask specifically what language features, I think that there are a
number of ones for which there has been a general consensus that a solution
should be found, even if no consensus solution officially exists yet or
there are a number of highly regarded solutions being considered. An example
would be the forwarding problem for which a number of the leading Boost
developers have spoken eloquently. But that is one example and there are a
number more ( templated typedefs is another ).

I think that what is disappointing is the slowness by which the C++
committee moves to make helpful language changes. While I understand much of
the conservative nature of that slowness, I know of no other major language
which has a ten year span to make language changes. I know that there will
be many arguments why this time span is needed, including the standard two
about the work of the committee being freely given with no pay and the
invitation to be part of the committee if I want to see changes made. I am
not in any way denigrating the work or the integrity of the committe
members. But I see the slowness to add language features to C++ as a
detriment toward both attracting programmers to the language and as a means
of improving the language for the sake of the C++ programmers already using
it who are attempting to use language features to solve difficult problems.

Ten years in computer time is very long, and by the time C++ may be ready to
ease a programming problem through a needed language change, other languages
have already solved the problem long ago ( I am thinking of Python
especially although C# and Java are also faster about making changes than
C++, not necessarily of course every time to the benefit of those
languages ). I would like C++ to solve problems a little quicker, but then
again I don't see occasionally taking the wrong road and then correcting it
later on as such a disaster as C++ seems to consider it. As an example of
this, C++ exception specifications are generally considered pretty useless
as they have been specified in the language, but it is not a disaster and I
can see little reason that they can not be either dropped, improved, or
respecified in the future. Will it break some code ? Most probably. But the
C++ programming world will not come to an end if this happens and thousands
of C++ programmers will not throw up their hands in disgust, foment against
Mr. Stroustrup and the C++ commitee, and leave for other language pastures.
They will simply change their code for a hopefully better future. The idea
that all changes must be absolutely and perfectly correct the first time
around has led to a stasis in the language that I think is unnecessary.

The other issue I see with C++ language changes, with all due respect to Mr.
Stroustrup and his opinions, is the need to maintain backward compatibility
with C forever and forever. Can not this Gordian knot simply be cut and C++
declared its own language with backward compatibility with the C programming
language not important or wanted anymore ? I think so and, if the time has
not already come to do this, it will come very soon if C++ is to move
forward into richer and easier to use programming areas.

---
[ 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 Sat, 29 May 2004 15:50:05 +0000 (UTC), Edward Diener
<eldiener@earthlink.net> wrote:

>> You appear to have missed the 2003 TC (or "point release"). There's
>> also the library TR coming out fairly soon. So you have a "bug fix"
>> point release and a new features point release. What more do you want?
>
> I think that what is disappointing is the slowness by which the C++
> committee moves to make helpful language changes. While I understand
> much of
> the conservative nature of that slowness, I know of no other major
> language
> which has a ten year span to make language changes. I know that there
> will
> be many arguments why this time span is needed, including the standard
> two
> about the work of the committee being freely given with no pay and the
> invitation to be part of the committee if I want to see changes made. I
> am
> not in any way denigrating the work or the integrity of the committe
> members. But I see the slowness to add language features to C++ as a
> detriment toward both attracting programmers to the language and as a
> means
> of improving the language for the sake of the C++ programmers already
> using
> it who are attempting to use language features to solve difficult
> problems.

I absolutely concur with this message.

Thing is, it's not like there isn't a lack of people willing to volunteer
time. I among many would be happy to contribute to fixing shortfalls in
the language. However how the C++ standardisation process is currently
laid out makes this very hard for us - why can't it use the methods free
software projects have shown so efficable and parallelise the "debugging"
part of new features? N1377 for one could be solved within weeks and could
technically become part of the standard within a year (everyone so far has
said "it needs more practical experience").

Cheers,
Niall

---
[ 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                       ]

In article <yo0uc.3668$Yd3.473@newsread3.news.atl.earthlink.net>, Edward
Diener <eldiener@earthlink.net> writes
>I think that what is disappointing is the slowness by which the C++
>committee moves to make helpful language changes. While I understand much of
>the conservative nature of that slowness, I know of no other major language
>which has a ten year span to make language changes.

Fortran, Cobol (and both are still actively used languages) C etc. It is
very unwise to tinker with a language before the last lot of changes
have been widely implemented. The reason some languages need such short
cycles of change is that they have to keep repairing the things they
broke the last time. Getting something wrong once is excusable, doing so
more than once isn't.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 Mon, 24 May 2004 14:29:39 CST, Niall Douglas
<s_googlegroups@nedprod.com> wrote:

>I personally feel that when producing language standards as with any
>standard, the format should be big release, then point 1 release and point
>2 release with point 2 released as the next big release is in preparation.
>ISO C++ has not followed this, much to its detriment :(

You appear to have missed the 2003 TC (or "point release"). There's
also the library TR coming out fairly soon. So you have a "bug fix"
point release and a new features point release. What more do you want?

>Now we have most major compilers nearly complying with the standard (I
>view "export" as not particularly useful/important if I understand the
>standard correctly),

I'd like to see what EDG do with their implementation before
commenting on this. I'm hoping for template "object code", which I
think may be possible.

 we really could do with a point release of the
>standard to address urgent issues in a timely fashion. My top five most
>annoying features of C++ are:
>
>1. Lack of move constructors. It really, *really* annoys me to see the
>generated assembler for using say a string class and see loads of
>pointless copying. With move constructors the compiler can optimise the
>case when the object being copied is obviously about to get destroyed.
>Also, around 5% of the classes I design operate with move semantics which
>is a royal PITA when your copy constructor takes const references (either
>you const_cast or use mutable).

For now you have many options:

- Move objects with memcpy. This works fine when the object isn't
self-referencing (directly or indirectly), but is non-standard for
non-PODs of course. For the vast majority of "value" types (including
std::containers on implementations I know), memcpy works fine.

- Use mojo, or something similar.

- Just use the suboptimal copy/destruct.

- Implement move constructors on your favourite open source compiler.
:)

- Use default construction and std::swap.

>2. Lack of local functions. I use a lot of "undoable operations" to roll
>back partially completed work in case of an exception. I got the idea
>originally from Alexandrescu but I've improved on his original work and
>you can find them at
>http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html. Sometimes
>the rollback can be quite complex and here you need local functions -
>unfortunately these are not permitted, so instead you declare a local
>class with a static member function but this furls up the source :(. If
>local classes with static member functions are possible, so are local
>functions! I'd particularly love if local functions had access to the
>scope in which they are defined.

This isn't too hard to do as long as the function doesn't have to
outlive the scope in which it is defined (which it doesn't in your use
case). I wonder whether there are any sample implementations out
there? I saw this:
http://people.debian.org/~aaronl/Usenix88-lexic.pdf. The problem comes
when someone tries to return a pointer to a local function from the
enclosing function...

>3. Removal of stupid and arbitrary limits. There are lots in here but
>thankfully most are obvious from reading through the standard. Off the top
>of my mind, why can't you define operator new & delete within a namespace
>(why aren't they just treated like normal functions with an irregular call
>syntax)?

They are operators, not functions. However, the name lookup of
operator new/delete could be improved, as you say.

> Why can't you template a typedef?

This is actually quite complicated, and there is no (or little)
implementation experience yet. The committee isn't a design team, it's
there to standardise existing practice.

 Why doesn't the standard
>mandate marking in the mangled symbol of non-throwing functions so the
>compiler can warn at compile time when a function shouldn't be
>non-throwing or indeed when it could (it also helps the optimiser here)?

Compile time exception specification checking has been done to death.
It'll probably never happen.

>Why can't you initialise aggregate types with compile-time known functions
>(I'm thinking compile-time variable arrays here)?

What do you mean?

 Why can't you mark
>virtual functions as being "once" in all subclasses (ie; if there are
>virtual functions A::foo() and B::foo and class C inherits A and B in that
>order, A's foo() points at B's foo() rather than there being two
>(ambiguous) foo()'s) - such a feature would greatly ease mixing run-time &
>compile-time polymorphism without introducing the costs of virtual base
>class inheritance? Why can't templates have parameterised pieces of code
>so we can finally get rid of macros?

Such things would just be macros by another name, surely. Unless you
have some suggestions for how name-lookup, scoping, export, etc. would
work with this? Would an improved preprocessor serve the same purpose?

Do you have an example of what you want to use this for? I don't
generally use macros to parametrise "code blocks", only when I need
__LINE__ and __FILE__ in debugging/logging really.

 And why is the only way to determine
>an unknown type is via template argument deduction via a function which
>severely castrates your metaprogramming flexibility (and forces stilted
>design)?

You'll have to wait for this one, or use the "typeof" extensions that
a few compilers offer (which differs from what will be standardised).

 I can go on, but the "D" programming language has many more good
>ideas here.
>
>4. Lack of basic tools in the STL (eg; a hash based dictionary container,
>reference counting abstract base classes (preferably based on
>policy-driven smart pointers), LRU caching etc. etc). This stuff is hardly
>new technology - I threw together a generic hash based dictionary
>container in a few hours using map, vector and list. It's really not hard.
>And no, I don't like hash_map from the SGI library as it's not
>configurable enough.

TR1 will have both of these.

>5. Speaking of which, the STL in general annoys me. I deliberately don't
>use large sections of it and I'm hardly alone here - a large minority of
>C++ programmers refuse to use the STL at all. The thing which annoys me
>the most is the naming scheme - it consistently names the functions the
>least likely thing you'd think of and I personally can't see why lots more
>synonyms couldn't be added

Code bloat?

>(eg; list<>::splice() could also be called
>list<>::relink() or craziest of all, list<>::move())

Splice is the traditional name for the operation, isn't it? The other
two are less clear to me at least. The classic example of bad naming
is "empty", but it takes all of 10 minutes to become familiar with the
naming conventions used...

. It's this style
>issue and it being totally contrary to how I write my own C++ which makes
>me always uncomfortable using it, which is why I wrapped it with a thin
>veneer to provide Qt API emulations (see
>http://tnfox.sourceforge.net/TnFOX/html/group___q_t_l.html).

That doesn't seem to offer splice under any name that I can see.

>The language itself is generally good, though it has an unfortunate habit
>of requiring more keyboard typing to create better C++ which means
>laziness automatically causes bad C++. However its weakest point IMHO is
>the STL which if I had absolute control over the ISO standardisation
>process I'd personally start most of it again from scratch and supply thin
>veneers emulating the existing STL's API. My new STL would be far more
>policy driven as the existing lack of same prevents usage of STL-provided
>functionality (eg; searching a list when the predicate isn't fixed nor
>simple).

The STL probably could do with a rewrite, but probably not for the
reasons you give. e.g. property maps, standardise segmented iterators,
etc. I think the existing policy set for the containers is generally
pretty good - I've never needed to configure them in any way not
supported.

>(Note that I am aware that some of my top five most annoying things about
>C++ either are being addressed or have been addressed in the next
>standard. What's wrong is that none of the above five items require much
>work - they are simple - and could be safely added to the standard within
>months rather than years.

Really? And who is going to do the work? What is going to be
standardized? Do you have a working implementation of the features you
suggest? Have lots of people used it and given you feedback?

> They would also require trivial quantities of
>additional work by compiler vendors. The fact they are not being applied
>with haste means millions of more lines of code must be written to
>circumvent them, certainly hundreds of thousands of more programmer hours
>must be wasted and I think this is very irresponsible).

Have you put any time into the standards process yourself? Do you know
the issues and processes involved in standardisation?

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

In article <opr8ikyhjey9klrv@news.iol.ie>, Niall Douglas wrote:

> Though I cannot speak for them, I cannot see Microsoft up-ending the
> Windows DLL mechanism just for ISO C++ compliance. DLL's are absolute core
> to Windows because unlike Unix it was designed from the beginning with
> them in mind. If the ISO C++ spec adopts a mechanism incompatible with
> Win32, then that feature will likely be ignored on the vast majority of
> the world's computers.

Obviously Microsoft isn't going to break the current DLL linking and loading
machinery.  However, I see no reason why Microsoft wouldn't be able to
*extend* it to support other (and more C++-friendly) approaches to dynamic
linking.

- Wil

--
Wil Evers, DOOSYS R&D BV, Utrecht, Holland
[Wil underscore Evers at doosys dot 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                       ]

In article <tb36b0h3ef6j2k8pq6hq5bnt5qr2oelaig@4ax.com>,
 tom_usenet@hotmail.com (tom_usenet) wrote:

> >1. Lack of move constructors. It really, *really* annoys me to see the
> >generated assembler for using say a string class and see loads of
> >pointless copying. With move constructors the compiler can optimise the
> >case when the object being copied is obviously about to get destroyed.
> >Also, around 5% of the classes I design operate with move semantics which
> >is a royal PITA when your copy constructor takes const references (either
> >you const_cast or use mutable).
>
> For now you have many options:

Indeed, too many options. ;-)

> - Move objects with memcpy. This works fine when the object isn't
> self-referencing (directly or indirectly), but is non-standard for
> non-PODs of course. For the vast majority of "value" types (including
> std::containers on implementations I know), memcpy works fine.

Count Metrowerks node-based containers out.  They've been self
referencing for five or so years.  I believe gcc 3.4 node based
containers are now self referencing, pretty sure about std::list, not as
sure about the others.  I also believe Dinkumware's std::string is self
referencing, but again I'm not positive about that.  So be extra careful
before you memcpy something you're not intimately familiar with.  I
might wager everyone's vector is movable with memcpy, but I'm not sure
how many other std::containers you could say that about.

> - Use mojo, or something similar.

A valiant attempt at move within the current language.  It is not
without drawbacks such as disabling RVO (the ultimate in move semantics).

> - Use default construction and std::swap.

Suboptimal for heavy weight objects that are movable with memcpy.  Very
suboptimal for pods.  Doesn't work at all for types without default
ctors (e.g. std::containers don't require their value_type to have a
default ctor).

> - Just use the suboptimal copy/destruct.

I.e. use copy semantics instead of move semantics.

And when writing generic code, how do you know which option is best?  Or
even viable?  Today, only the last option is always viable in generic
code (use copy semantics).

I agree with Niall.  Lack of move semantics is a /major/ drawback in
today's C++.

-Howard

---
[ 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                       ]

Niall Douglas <s_googlegroups@nedprod.com> wrote:
> 4. Lack of basic tools in the STL (eg; a hash based dictionary container,
> reference counting abstract base classes (preferably based on
> policy-driven smart pointers), LRU caching etc. etc).

Apparently you are confusion "STL" with the standard C++ library: the STL
is, essentially, a library of algorithms plus a few supporting classes
(eg. iterators and functors) and a few usage examples (ie. the containers).
STL is all about sequences where a "reference counting astract base class"
does not really fit.

Hashes can and have been added easily using third party providers or
extensions to standard libraries. Actually, STL is all about algorithms for
an open set of sequences. There is nothing wrong with this approach IMO: you
wouldn't want C++ to ship with a particular database either. There is nothing
different in view to having advanced containers, added algorithms, etc. Still,
hashes (under the awkward name "unorder_associative_...") are on the way into
the standard, as are smart pointers for reference counting (which is a much
more sensible approach than having some form of base class, IMO).

> The language itself is generally good, though it has an unfortunate habit
> of requiring more keyboard typing to create better C++ which means
> laziness automatically causes bad C++. However its weakest point IMHO is
> the STL which if I had absolute control over the ISO standardisation
> process I'd personally start most of it again from scratch and supply thin
> veneers emulating the existing STL's API.

STL is C++'s strongest point - despite being wrong: the concepts STL is
based on are to course-grained. This is my favorite complaint: iterators
combine two distinct concepts, namely cursors for positioning and property
maps for attribute access (BTW, an implementation of algorithms based on
property maps is available from <http://www.dietmar-kuehl.de/cool/>). I'm
not aware of any other language which ships with an extensive library of
algorithms being efficient while also being applicable to [nearly] arbitrary
sequences (the restriction is due to being based on the wrong concepts, of
course :-)

> My new STL would be far more
> policy driven as the existing lack of same prevents usage of STL-provided
> functionality (eg; searching a list when the predicate isn't fixed nor
> simple).

I'd say you should pick up a good book about STL and try to understand what
it is all about...

> (Note that I am aware that some of my top five most annoying things about
> C++ either are being addressed or have been addressed in the next
> standard. What's wrong is that none of the above five items require much
> work - they are simple - and could be safely added to the standard within
> months rather than years. They would also require trivial quantities of
> additional work by compiler vendors. The fact they are not being applied
> with haste means millions of more lines of code must be written to
> circumvent them, certainly hundreds of thousands of more programmer hours
> must be wasted and I think this is very irresponsible).

My short-term memory is extremely bad but I can't remember having met you
at the last few committee meetings: with your claimed efficiency you should
be able to really speed things up. For some non-obvious reason the progress
made without your excellent help is much slower. A possible reason may be
that those investing in standardization also have other stuff to do. Your
accused irresponsiblity of the standardization process is possibly due to
the fact that there are only few people who have the time to provide quality
papers on the various issues and move the working groups through all those
details swiftly.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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 Wed, 26 May 2004 18:01:52 +0000 (UTC), Dietmar Kuehl
<dietmar_kuehl@yahoo.com> wrote:

> My short-term memory is extremely bad but I can't remember having met you
> at the last few committee meetings: with your claimed efficiency you
> should
> be able to really speed things up. For some non-obvious reason the
> progress
> made without your excellent help is much slower. A possible reason may be
> that those investing in standardization also have other stuff to do. Your
> accused irresponsiblity of the standardization process is possibly due to
> the fact that there are only few people who have the time to provide
> quality
> papers on the various issues and move the working groups through all
> those
> details swiftly.

Oh don't get me wrong, I've never participated and I deliberately avoid
having anything to do with groups like this (I've already been here longer
than I intended). But in a way, that's precisely where the value in what I
think comes from - I bring a fresh viewpoint direct from the coal-face
which you may or may not already have enough of.

As with any standardisation process, much of it will be driven by lowest
common denominator, horse-trading between vested interests and a real
paucity of independent funding. But then cooperation with mutually hostile
interests will always be glacially paced and after all, now that C++ has
clearly taken the crown of most popular platform-independent programming
language from C there are in many ways more reasons for it to go slower
rather than faster.

What I am suggesting though is a "fast track" mechanism for getting new
features which absolutely everyone agrees upon into the standard quickly
(six months) rather than having to wait to be bundled with more
contentious features. This carries dangers proportionate to the size of
the feature so should only be allowed for small features eg; move
constructors.

I'm hardly the first to call for such a thing I'm sure - I'm merely saying
"from the coal-face" that certain pretty obvious minor additions to the
feature set are urgently required. The powers that be can take that or
leave it - after all, there is no viable alternative to C++ available in
the area it covers so I nor anyone else really has a choice.

Cheers,
Niall

---
[ 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                       ]

dietmar_kuehl@yahoo.com (Dietmar Kuehl) writes:

[...]

| > The language itself is generally good, though it has an unfortunate habit
| > of requiring more keyboard typing to create better C++ which means
| > laziness automatically causes bad C++. However its weakest point IMHO is
| > the STL which if I had absolute control over the ISO standardisation
| > process I'd personally start most of it again from scratch and supply thin
| > veneers emulating the existing STL's API.
|
| STL is C++'s strongest point - despite being wrong: the concepts STL is
| based on are to course-grained. This is my favorite complaint: iterators
| combine two distinct concepts, namely cursors for positioning and property
| maps for attribute access (BTW, an implementation of algorithms based on
| property maps is available from <http://www.dietmar-kuehl.de/cool/>). I'm
| not aware of any other language which ships with an extensive library of
| algorithms being efficient while also being applicable to [nearly] arbitrary
| sequences (the restriction is due to being based on the wrong concepts, of
| course :-)

So, did you mean that if the STL was based on the "right" concepts,
it would not have been as extensive and efficient? :-) :-)

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

In article <opr8mjlcpwy9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>What I am suggesting though is a "fast track" mechanism for getting new
>features which absolutely everyone agrees upon into the standard
>quickly (six months) rather than having to wait to be bundled with more
>contentious features. This carries dangers proportionate to the size of
>the feature so should only be allowed for small features eg; move
>constructors.

Are there any such issues? Our experience teaches us to be much more
cautious. However there is a way to add new features should we wish to
do so. It is called a normative addendum.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 Wed, 26 May 2004 04:15:06 +0000 (UTC), hinnant@metrowerks.com
(Howard Hinnant) wrote:

>Indeed, too many options. ;-)
>
>> - Move objects with memcpy. This works fine when the object isn't
>> self-referencing (directly or indirectly), but is non-standard for
>> non-PODs of course. For the vast majority of "value" types (including
>> std::containers on implementations I know), memcpy works fine.
>
>Count Metrowerks node-based containers out.  They've been self
>referencing for five or so years.  I believe gcc 3.4 node based
>containers are now self referencing, pretty sure about std::list, not as
>sure about the others.  I also believe Dinkumware's std::string is self
>referencing, but again I'm not positive about that.  So be extra careful
>before you memcpy something you're not intimately familiar with.  I
>might wager everyone's vector is movable with memcpy, but I'm not sure
>how many other std::containers you could say that about.

Ahh, I'm glad I haven't been using the memcpy trick then!

>From a quick glance and <xstring> in VC7.1, std::string isn't
self-referencing. They have:
union _Bxty
{  // storage for small buffer or pointer to larger one
  _Elem _Buf[_BUF_SIZE];
  _Elem *_Ptr;
} _Bx;

and choose which pointer to use based on the value of:
size_type _Myres; // current storage reserved for string

>I agree with Niall.  Lack of move semantics is a /major/ drawback in
>today's C++.

I agree that the feature is needed. But we need to implement it, try
it out and only once the best solution has been found, standardise it.
I for one would prefer a proposal that included destructive move
semantics, which will in general will provide the highest efficiency
gains. I note that your proposal is purely for non-destructive
semantics at the moment.

Have you implemented rvalue references in MWCW, or at least in an
experimental internal version?

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

"Niall Douglas" <s_googlegroups@nedprod.com> wrote in message
news:opr8mjlcpwy9klrv@news.iol.ie...

> On Wed, 26 May 2004 18:01:52 +0000 (UTC), Dietmar Kuehl
> <dietmar_kuehl@yahoo.com> wrote:
>
> > My short-term memory is extremely bad but I can't remember having met
you
> > at the last few committee meetings: with your claimed efficiency you
> > should
> > be able to really speed things up. For some non-obvious reason the
> > progress
> > made without your excellent help is much slower. A possible reason may
be
> > that those investing in standardization also have other stuff to do.
Your
> > accused irresponsiblity of the standardization process is possibly due
to
> > the fact that there are only few people who have the time to provide
> > quality
> > papers on the various issues and move the working groups through all
> > those
> > details swiftly.
>
> Oh don't get me wrong, I've never participated and I deliberately avoid
> having anything to do with groups like this (I've already been here longer
> than I intended). But in a way, that's precisely where the value in what I
> think comes from - I bring a fresh viewpoint direct from the coal-face
> which you may or may not already have enough of.
>
> As with any standardisation process, much of it will be driven by lowest
> common denominator, horse-trading between vested interests and a real
> paucity of independent funding. But then cooperation with mutually hostile
> interests will always be glacially paced and after all, now that C++ has
> clearly taken the crown of most popular platform-independent programming
> language from C there are in many ways more reasons for it to go slower
> rather than faster.

For someone who's made a point of not understanding the standardization
process, you've certainly developed an elaborate, cynical, and flawed
vision of how it actually works.

> What I am suggesting though is a "fast track" mechanism for getting new
> features which absolutely everyone agrees upon into the standard quickly
> (six months) rather than having to wait to be bundled with more
> contentious features.

a) I don't agree about your features, so not everyone agrees.

b) We only meet once every six months.

c) It takes more than one meeting to prudently agree about anything.

>                      This carries dangers proportionate to the size of
> the feature so should only be allowed for small features eg; move
> constructors.

Glad you think it's small. It was first raised a couple of years ago
and I still don't see universal agreement even on what it means.

> I'm hardly the first to call for such a thing I'm sure - I'm merely saying
> "from the coal-face" that certain pretty obvious minor additions to the
> feature set are urgently required. The powers that be can take that or
> leave it - after all, there is no viable alternative to C++ available in
> the area it covers so I nor anyone else really has a choice.

Lots of things are pretty obvious to the bloke who works just one
coal face. Work a few more faces and you learn what's not so obvious.
Try to run a mine and you get humbled further still. Try to develop
mine safety standards and you get humbled even more. You, I believe,
have a large vein of humility before you, if only you can learn to mine
it, and benefit from it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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 Sun, 23 May 2004 00:18:04 +0000 (UTC), Davide Bolcioni
<6805b3x001@sneakemail.com> wrote:

>> One could take the view that Unix has it wrong and it needs to change
>> for its own good. Irrespective of what the standard says, the
>> implementors on Unix will devise some transitory/interoperability
>> strategy.
>
>  From the point of view of a programmer doing mostly maintenance work of
> existing code bases, I would say that Unix had it right from the
> beginning and Windows requires the programmer to pepper the code with
> too much detail for his own good: the notion that shared libraries are
> not something which should concern the language, only the linker, made
> my job exceedingly easier.

Sure, the Unix method makes your job easier to produce something which
functions. However as anyone who has ever compared real-world application
performance between Windows and Unix realises, Unix GUI applications just
go slower - and I was even comparing two applications both using Qt.

If you go the Unix route, code *quality* suffers because it's much easier
for the programmer to be lazy. If you go the Windows route, you get as
perfect quality as you can for free with slightly more work. You already
know which I prefer but I'll elaborate below.

>> BTW in N1496 appendix item 4 I can confirm that the Unix mechanism
>> cannot be implemented on Windows.
>
> Given the time scale expected of C++0x, maybe the right question is
> whether it is implementable for .NET ?

I personally feel that when producing language standards as with any
standard, the format should be big release, then point 1 release and point
2 release with point 2 released as the next big release is in preparation.
ISO C++ has not followed this, much to its detriment :(

Now we have most major compilers nearly complying with the standard (I
view "export" as not particularly useful/important if I understand the
standard correctly), we really could do with a point release of the
standard to address urgent issues in a timely fashion. My top five most
annoying features of C++ are:

1. Lack of move constructors. It really, *really* annoys me to see the
generated assembler for using say a string class and see loads of
pointless copying. With move constructors the compiler can optimise the
case when the object being copied is obviously about to get destroyed.
Also, around 5% of the classes I design operate with move semantics which
is a royal PITA when your copy constructor takes const references (either
you const_cast or use mutable).

2. Lack of local functions. I use a lot of "undoable operations" to roll
back partially completed work in case of an exception. I got the idea
originally from Alexandrescu but I've improved on his original work and
you can find them at
http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html. Sometimes
the rollback can be quite complex and here you need local functions -
unfortunately these are not permitted, so instead you declare a local
class with a static member function but this furls up the source :(. If
local classes with static member functions are possible, so are local
functions! I'd particularly love if local functions had access to the
scope in which they are defined.

3. Removal of stupid and arbitrary limits. There are lots in here but
thankfully most are obvious from reading through the standard. Off the top
of my mind, why can't you define operator new & delete within a namespace
(why aren't they just treated like normal functions with an irregular call
syntax)? Why can't you template a typedef? Why doesn't the standard
mandate marking in the mangled symbol of non-throwing functions so the
compiler can warn at compile time when a function shouldn't be
non-throwing or indeed when it could (it also helps the optimiser here)?
Why can't you initialise aggregate types with compile-time known functions
(I'm thinking compile-time variable arrays here)? Why can't you mark
virtual functions as being "once" in all subclasses (ie; if there are
virtual functions A::foo() and B::foo and class C inherits A and B in that
order, A's foo() points at B's foo() rather than there being two
(ambiguous) foo()'s) - such a feature would greatly ease mixing run-time &
compile-time polymorphism without introducing the costs of virtual base
class inheritance? Why can't templates have parameterised pieces of code
so we can finally get rid of macros? And why is the only way to determine
an unknown type is via template argument deduction via a function which
severely castrates your metaprogramming flexibility (and forces stilted
design)? I can go on, but the "D" programming language has many more good
ideas here.

4. Lack of basic tools in the STL (eg; a hash based dictionary container,
reference counting abstract base classes (preferably based on
policy-driven smart pointers), LRU caching etc. etc). This stuff is hardly
new technology - I threw together a generic hash based dictionary
container in a few hours using map, vector and list. It's really not hard.
And no, I don't like hash_map from the SGI library as it's not
configurable enough.

5. Speaking of which, the STL in general annoys me. I deliberately don't
use large sections of it and I'm hardly alone here - a large minority of
C++ programmers refuse to use the STL at all. The thing which annoys me
the most is the naming scheme - it consistently names the functions the
least likely thing you'd think of and I personally can't see why lots more
synonyms couldn't be added (eg; list<>::splice() could also be called
list<>::relink() or craziest of all, list<>::move()). It's this style
issue and it being totally contrary to how I write my own C++ which makes
me always uncomfortable using it, which is why I wrapped it with a thin
veneer to provide Qt API emulations (see
http://tnfox.sourceforge.net/TnFOX/html/group___q_t_l.html).

The language itself is generally good, though it has an unfortunate habit
of requiring more keyboard typing to create better C++ which means
laziness automatically causes bad C++. However its weakest point IMHO is
the STL which if I had absolute control over the ISO standardisation
process I'd personally start most of it again from scratch and supply thin
veneers emulating the existing STL's API. My new STL would be far more
policy driven as the existing lack of same prevents usage of STL-provided
functionality (eg; searching a list when the predicate isn't fixed nor
simple).

(Note that I am aware that some of my top five most annoying things about
C++ either are being addressed or have been addressed in the next
standard. What's wrong is that none of the above five items require much
work - they are simple - and could be safely added to the standard within
months rather than years. They would also require trivial quantities of
additional work by compiler vendors. The fact they are not being applied
with haste means millions of more lines of code must be written to
circumvent them, certainly hundreds of thousands of more programmer hours
must be wasted and I think this is very irresponsible).

>> The PE binary hardcodes what symbols it looks for from each library by
>> name as of course under PE you can use ordinal rather than mangled
>> symbol resolution. The advantage of the PE system is a substantially
>> reduced search tree and thus improved load & link times but it does
>> mean you can't arbitrarily muck around with DLL contents without a
>> relink (not hard as ELF dynamic loaders ARE the full-strength standard
>> linker).
>
> This should be of interest only to people implementing a linker, in my
> opinion.

Though I cannot speak for them, I cannot see Microsoft up-ending the
Windows DLL mechanism just for ISO C++ compliance. DLL's are absolute core
to Windows because unlike Unix it was designed from the beginning with
them in mind. If the ISO C++ spec adopts a mechanism incompatible with
Win32, then that feature will likely be ignored on the vast majority of
the world's computers.

> In other words: we don't tell the programmer how the program will be
> cobbled together, he had better make sure it works anyway. Guidelines as
> to which tricks not to pull in order to not have things break
> unexpectedly would be really welcome and in my humble opinion belong in
> a language standard: FORTRAN got much mileage from its rules for common
> variable access, for example.

The trouble with this approach is that it produces sub-optimal code. If
the compiler cannot know if a symbol is local to this DSO/DLL or not, it
must assume the worst and run *every* *single* *access* through an
indirection lookup. This is why code compiled with GCC using -fPIC is
markedly slower than code compiled without and it's also more bloated.

This is partially where the speed & size differential between MSVC & GCC
compiled binaries comes from. The trouble with "default shared" is that it
encourages laziness - most programmers will do the minimum to get a
working application and then stop. If it's "default private" then
programmers must add the extra annotation to even reach a working binary -
which is good, because code quality improves substantially.

I also feel that whether something is visible outside its DSO/DLL is part
of its API spec and thus interface contract. If you disagree with this,
consider how public/protected/private relate to class design and note that
similar logic applies to both.

> On the contrary, I suggest leaving the language as it stands; just
> acknowledge that shared libraries are a reality of current
> implementations and might impose a series of restrictions which should
> be observed by the programmer.

The "stick head in sand" approach is only useful when a technology is
brand new and the consequences of misapplying it may be dangerous. Shared
libraries have been in widespread use for fifteen years - we know them
well enough now that not acting just makes things worse.

Cheers,
Niall

---
[ 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                       ]