dave@boost-consulting.com (David Abrahams) writes:
[snip]
>> 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)
>
> When we run across such a feature, maybe we'll have use for that
> mechanism.  AFAICT it hasn't happened so far.  We do have technical
> reports that allow us to "bless" features before officially
> standardizing them.
>
> Also, 6 months, being only the total time between committee meetings,
> is a bit short to expect to give any feature full consideration, get
> implementation experience, and draft appropriate specifications.
> We've been working on starting a process for making progress between
> meetings, similar to Boost's, but even then I think 6 months would be
> too short for actually adding a new feature, no matter how much
> agreement it got.
[snip]

Somewhat related, in some ways Boost is a way of experimenting with
    potential standard library features *before* they are
    standardized.

Maybe Niall should experiment with Boost, and see how well it
    fullfills his requirements for a 'fast track mechanism'; does
    Niall need feature availablity, or does he need features chisled
    into the granite of 14882?

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

[Reposted after fixing moderator's reason for rejection]

On 26 May 2004 16:20:15 GMT, llewelly <llewelly.at@xmission.dot.com> wrote:

>> Local
>> functions would be easy enough to add, move constructors also though I
>> would have difficulties with modifying the optimiser to fully make use
>> of them. Of course the GCC masters aren't keen on extra-specification
>> extensions right now.
>
> Easy to add to the core language, maybe. Easy to add to all the
>     appropriate spots in the standard library? I don't think so.

Given this (I agree), why isn't the core language spec released before the
library spec? I can see of course that the library gives a good testing of
a new language feature so one can backpedel if needs be - so I'd keep
synchronised releases for major updates. Bug fix and point releases could
be done independently so end-users could get on quickly with using
desperately needed minor features.

>>> A delete expression may choose the deallocation function (that's the
>>>     user-definable operator delete) dynamicly, based on the runtime
>>>     type of the deleted object. So a user-defined operator delete
>>>     within a namespace would naturally apply to all *types* declared
>>>     in said namespace, *not* to all delete-expressions in said
>>>     namespace.
>>
>> I'm not sure I get you. Surely Koenig lookup takes care of finding
>> which operator delete to use?
>
> Not for types with virtual destructors. See 12.5/4:
> [snip]

This still doesn't seem to be a problem (if I am understanding correctly).
Does the static type have a vtable? If yes, does it have a virtual
destructor? If yes, does the vtable have an operator delete due to a
subclass defining one? If so use that, otherwise go with the usual rules
for a function lookup. None of this prevents or causes issue with the
compiler performing the usual Koenig followed by in-to-out scope search
for a suitable operator delete. The only difference between choosing which
operator delete to use as against a standard overloaded function is a
little bit of extra work must be done if the type has a vtable.

>> I quite like the "throws nothing" specifier. It's the only one I
>> use. All the others from my examination of the generated assembler
>> seem to generate type checking code which is inefficient.
>
> True, but not the only thing that is wrong with exception
>     specifications.

Well I don't know anything about that. If a feature seems to cost more
than it gives to me I just don't use it. If it does give more but throws
stupid hurdles in the way, then I get frustrated. In that sense exception
specifications were done right because using either "throw()" (throws
nothing) or not using them at all doesn't come with unwanted side-effects.
True they may not have achieved what people thought they might, but then
they didn't balls up other stuff either. That to me reflects good design
(is "orthogonal" the right word here?)

>> One thing I really dislike (and I should have included it in my top
>> five, but I forgot) is what the standard mandates if you throw an
>> exception while you're in the middle of handling one. That means
>> programmer error causes an immediate exit of the process with no
>> chance to clean up (I don't view terminate_handler() as a realistic
>> way of properly cleaning up a large multithreaded application!)!
>
> If cleanup results in an error, can you safely clean up? The standard
>     assumes not.

But that's singularly unhelpful! How can the standard possibly know what
you're doing with your classes (what if they all have trivial
destructors?)? Maybe you can or maybe you can't clean up, but the standard
just hard exits your process - like a SIGILL. I've taken the approach that
if the nested exception throw corrupts memory or fatally damages
application state, then so be it - then you get SIGILL or whatever and
your hard exit - but at least your code had some chance to wipe encryption
keys and flush files. The current standard's approach is throwing the baby
out with the bathwater.

> There are surely applications for which this isn't true, but I  think
>     they are a minority. I don't know if that minorty is important
>     enough to justifty the work necessary to define and implement
>     something smarter.

Well, most of that work can be obviated by plucking ideas off an existing
implementation a la Boost library. I'm sure C++ gurus would risk blood
clots when examining my sloppy C++, but that code is LGPL and I freely
offer explanatory support!

My issue with how it is right now is that if you have a secure or
mission-critical app then the standard is helping attackers or
catastrophic failure respectively right now (many of course would say such
applications should not be written in C++, but that didn't work for C so
why C++?). This is surely not something we want to encourage?

>>> I realize that those of you who never leave the bounds of Purified
>>>     Natural Filtered Sanctified OO find the STL's favortism towards
>>>     value types bizzare, confusing, and inappropriate, but those of
>>>     us who don't have entity types falling out of ears generally
>>>     appreciate it.
>>
>> Heh, I am one of the few programmers I know of who dislikes OO and
>> thinks it a bad thing.
>
> Obviously my biases are leading me to make false assumptions
>     again. :-)

Oh don't worry, this happens to me all the time. Partially due to how I
deliberately frame posts in a "stir things up" style which most people
take as arrogance & naivity (which is intended).

>>> Again, it would be niced to see it improved in various ways, and nice
>>>     to see it complemented by something that better supported entity
>>>     types, but it shouldn't be removed or replaced.
>>
>> I'm afraid I don't know what an entity type is.
>
> An entity has identity. Even if you and I both have the same make,
>     year, model, and options on a car, my car is not your
>     car. Examples include bikes, shoes, ostreams, etc.
>
> An entity type is a type you instantiate to get an entity.
>
> An example of a non-entity type is an int. An int is a value type;
>     when dealing with ints, any two ints which have the value 5 are
>     the same.

<wince> This relabelling of old concepts with new fancy names seems to get
worse every year. It's probably a good thing for teaching first year
undergraduates as we used to interchange terms inconsistently before but
it does cause some of us who don't keep up surprise. I still don't really
know what a "visitor pattern" or "singleton" etc. precisely are, just that
I wouldn't call that code those names.

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                       ]

On Thu, 27 May 2004 21:11:01 +0000 (UTC), llewelly
<llewelly.at@xmission.dot.com> wrote:

> Somewhat related, in some ways Boost is a way of experimenting with
>     potential standard library features *before* they are
>     standardized.
>
> Maybe Niall should experiment with Boost, and see how well it
>     fullfills his requirements for a 'fast track mechanism'; does
>     Niall need feature availablity, or does he need features chisled
>     into the granite of 14882?

While I'd like to see changes to the standard library, I would hardly
consider them urgent. All the changes I originally outlined were very
substantial changes and therefore not possible in a short time. If you
remember, I was speaking of complete redesigns.

Anyway besides, if a library annoys you you can fix it yourself. Language
(mis)features you can't fix :(

See my other post to Dave Abrahams for my ideas on how to streamline ISO
C++ standardisation and involve a lot more workers.

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                       ]

tom_usenet@hotmail.com (tom_usenet) writes:

> I for one would prefer a proposal that included destructive move
> semantics, which will in general will provide the highest efficiency
> gains.

If you can figure out how to make use of destructive move work at all,
much less in the presence of exceptions, *and* you can prove that it
will improve efficiency, I'm all for it.  Personally I have grave
doubts:

  struct Foo
  {
      ~Foo();
  };

  void f(Foo& x, bool y)
  {
      if (y) { Foo z(move(x)); }
  }

  int main(int argc, char**argv)
  {
      Foo a;
      f(a, argc > 1);
      // Do we generate a destructor here?
  }

Ultimately you end up having to carry around an "exists" state bit
with every object.   Not worth it, IMO.

--
Dave Abrahams
Boost Consulting
http://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                       ]

llewelly <llewelly.at@xmission.dot.com> writes:

>> I'm afraid I don't know what an entity type is.
>
> An entity has identity. Even if you and I both have the same make,
>     year, model, and options on a car, my car is not your
>     car. Examples include bikes, shoes, ostreams, etc.
>
> An entity type is a type you instantiate to get an entity.
>
> An example of a non-entity type is an int. An int is a value type;
>     when dealing with ints, any two ints which have the value 5 are
>     the same.

Not quite, at least not in C++.  No two lvalues are precisely
equivalent, because they have detectable addresses that may differ.
It's actually a major problem that crops up when trying to define
almost *any* formal semantics for C++ code.  There's really no
difference between two ints and two bikes in this respect.

--
Dave Abrahams
Boost Consulting
http://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                       ]

s_googlegroups@nedprod.com (Niall Douglas) writes:

> 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,

If wg21 is really lowest common denominator, how on earth do you
    explain the STL? People claim the STL is 'popular', but in my
    experience, it was *not* popular prior to about 2000 or so -
    and even today, it seems it is only popular amoung programmers
    whose knowledge of C++ is substantially above average, and a long
    way outside of 'lowest common denominator'.

> horse-trading between vested interests

I must admit I only read one or two papers from each mailing (no, I'm
    not member, but most/all of the papers have been publicly
    availible for a long time.), but I have seen little evidence that
    'horse-trading' has much influence on committee decisions.

Can somebody point to an example? If so, did it result in a worse
    standard?

> 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

Can you cite numbers?

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

Move constructors affect overloading. Overloading is one the most
    complex areas of C++ (ISTR Daveed described it as 'worse than
    templates')

Namespaces are a simple concept, but look at the mess that resulted
    from them being introduced into the already complicated C++ name
    lookup rules.

I believe there is a real danger something similar might happen with
    move constructors. I am strongly in favor of move constructors,
    and it would be great to get some real-world experience with them
    soon, but I would prefer the comittee move cautiously in
    standardizing them.


---
[ 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 03:22:32 +0000 (UTC), Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

> namespace local_new {
>         // contains its overrider or overload of operator new and delete
> }
>
> mytype * i_ptr = new mytype;

mytype's vtable:
[0]: flags (indicates vtable contents)
[1]: ptr to destructor
[2]: ptr to appropriate delete for new used to instantiate

> In file f2.cpp
>
> extern mytype * i_ptr;
>
> namespace local_new {
>    delete i_ptr;
> }

Compiler knows mytype has vtable. Generates code which examines vtable of
i_ptr. Sees there is an operator delete in it at [2]. Calls [1] then [2]
which calls correct destructor & operator delete.

> is just one example of a multitude of possible problems. Unlike classes
> where the compiler sees all the declarations in the class definition
> there is no requirement that the compiler sees all the declarations in a
> namespace in any particular translation unit.

Since this dynamic calling of operator delete already requires a vtable
(as the standard requires), I still don't see this as a problem.

> When you are annoyed by something in C++ it is usually a good idea to
> discover why it is the way it is. We (I was part of the group whose
> responsibility included this part of the core language)  very carefully
> considered issues of overloading and overriding (i.e. replacing)
> operator new and operator delete at namespace scope and concluded that
> with the C++ separate compilation model it was impossible to implement
> which is why it is not allowed.

With respect, and I know of your name from many years ago when you
published an article of mine in ACCU, unless I have missed something your
explanation does not make any sense. As soon as a vtable is available, you
can call any operator delete anywhere at all including one completely
unknown to the current compiland. It just requires an appropriately laid
out vtable.

Indeed, if maximising code efficiency and minimising vtable size were
important, one could annotate the class to indicate if it does or doesn't
need to store a pointer to the appropriate delete to use when newed. Of
course, with the machinery that will be required by the export keyword,
the pre-linker stage could determine that on its own.

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 <opr8oc5wpgy9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>On Thu, 27 May 2004 03:22:32 +0000 (UTC), Francis Glassborow
><francis@robinton.demon.co.uk> wrote:
>
>> namespace local_new {
>>         // contains its overrider or overload of operator new and delete
>> }
>>
>> mytype * i_ptr = new mytype;
>
>mytype's vtable:
>[0]: flags (indicates vtable contents)
>[1]: ptr to destructor
>[2]: ptr to appropriate delete for new used to instantiate

1) You were originally writing about overriding/overloading operator new
and operator delete at namespace scope. Exactly how does a vtable help
with tracking in which namespace a variable was created:

mytype * i_ptr(0);

namespace local1 {
   i_ptr = new mytype;
}

namespace local2 {
  delete i_ptr;
}

2) a vtable is a property of a polymorphic class with one per class not
one per instance and so cannot be used to track the version of new that
is used to create an instance, only the version that the class as a
whole uses.

Note that non-polymorphic types do not have vtables.

Before pontificating on what C++ should provide please take time to
understand why it is the way it is today. Granted that there are
numerous places where it can be improved but it would be a mistake to
assume that features that seem superficially attractive were left out
just because we never thought about them. In this case we did think, and
think carefully. The cost of allowing new and delete operators to be
defined at namespace scope would be that every single data object
(including all the built in types, which would break C compatibility)
would need to track how they were created.



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

In article <opr8oc5wpgy9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>With respect, and I know of your name from many years ago when you
>published an article of mine in ACCU, unless I have missed something
>your explanation does not make any sense. As soon as a vtable is
>available, you can call any operator delete anywhere at all including
>one completely unknown to the current compiland. It just requires an
>appropriately laid out vtable.

We do not seem to be talking about the same thing. The topic was
allowing user defined operator new and delete at namespace scope.
Checking back I note that the original suggestion was for these to only
apply to types declared in that namespace. However even with that
limitation it is still flawed:

1) Only a subset of all types have vtables.
2) vtables are about polymorphic functionality provided within a class
hierarchy for objects that belong to that hierarchy.
3) namespaces are re-openable so how does the compiler track whether or
not there is a namespace scope operator new that is applicable. Just as
an example, suppose that WG21 added an operator new to namespace std::
.. that addition would have to be visible in every header file that
defines a Standard Library type.

That is why it is fine to have operator new/delete provided at class
scope (even in a non-polymorphic class) because the type of the object
identifies how it can be dynamically created and so how it should be
dynamically destroyed. Either it was created in raw memory provided by a
class memory allocator or in memory provided by a global allocator.
Which is fully determined (apart from fancy footwork with placement new,
but in such cases the programmer has to tread very carefully at the
destruction site.)

Allowing definitions of operator new/delete at namespace scope breaks
this simplicity and introduces a level of complexity that cannot (IMO)
be justified by any possible benefits.

Please give some thought to the real problems in implementing this idea.
We did and concluded that we would have to special case overloading
operator new and delete by prohibiting their provision at namespace
scope. The decision was not taken lightly.



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

s_googlegroups@nedprod.com (Niall Douglas) writes:

> 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").

As I've said, it also needs a formal specification.  And if you think
the contents of N1377 is an adequate formal spec., that just
reinforces my claim that your view of what constitutes
standard-readiness is terribly naive.  I don't know who you think has
the time/ability to solve the problems of specifying the interactions
with overload resolution and filling in all the other holes "within
weeks", but I assure you that I can't do it that quickly, and I don't
know of anyone else who's prepared to.

Furthermore, there are real practical problems with a standard that
changes on a yearly basis, too many for me to list here, but I'm sure
you can google for the many discussions that have already happened.
One reason you probably won't find there is that, to avoid making a
worse mess of the language design, it's important to consider the
major new features together.  It has happened more than once that
proposed features I thought would be great began to look bad or even
disastrous in the context of newer ideas/proposals.

As it happens, someone *is* working on a revised move/forwarding paper
that should get us closer to something that's ready to be accepted
into the WP.  I also happen to think that these features are fairly
orthogonal to the other things we want to do, but that was far from
obvious until recent progress was made on varargs templates, and it's
still not equally obvious to everyone.

I'm only going to say this one more time: complaining that things
could be done faster doesn't do anything to actually get them done
faster.  I have already mentioned some of the things you *could* do to
help make progress (hint: making suggestions from the sidelines about
what other people should do isn't one of them).  This may be a waste
of time, but I encourage you to start mining the rich vein that PJP
referred to in a recent post, and apply yourself in some of these
ways... at least if you care about making a difference.

--
Dave Abrahams
Boost Consulting
http://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                       ]

eldiener@earthlink.net ("Edward Diener") writes:

> 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.

C++, unfortunately, is too complicated for simple features to be
    added to the core language without potentially complex
    fallout. Namespaces, a very simple concept, had much complex
    fallout - why, because C++ name lookup was already
    complicated. As far as C++ is concerned, small language changes
    aren't.

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

C comes to mind, as does Ada. I think Fortran has a similar
    schedule. I think the overall picture is that young languages
    change rapidly, and mature languages change slowly.

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

python, java, (and also perl):

(0) Are not standarized the way C++ is.
(1) 95% of the users use implementations from a specific source.

(1) is also true for C#, AFAIK.

FWIW, when C++ was young, it changed at least as fast as any of these
    languages - and it continued to change rapidly even when it was
    much less young; look at all the standards comittee added to the
    ARM; all of that was added after C++ was over 10 years old.

> 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.

I have seen many people 'throw up their hands in disgust' and leave
    C++ precisely becuase they felt it changed to much and / or too
    quickly. In my experience, this is one of the primary reasons
    people leaving C++ cite for leaving. Now, sometimes the gain is
    worth the loss, but do not pretend no-one will leave.

> 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 ?

Not yet. Here's why:

(0) Almost all large C++ projects use some C libraries.

(1) People still move from C to C++ by taking a large application
    written in C, and making the necessary changes to make it build
    a C++ implementation.

> 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.

I bet C proggrammers still outnumber proggrammers in '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 Tue, 25 May 2004 03:56:06 +0000 (UTC), llewelly
<llewelly.at@xmission.dot.com> wrote:

>> 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.
>
> In my experience, this has far more to do with the the multiple (and
>     complicated!) layers of abstraction which come with the X window
>     system. Note that it is generally true for staticly linked
>     executables as well as dynamicly linked. Also, the opposite is
>     generally true for non-gui applications, due to more aggressive fs
>     caching. I'm not saying the unecessarily visible names which
>     often result from the unix model (note, not always, they can be
>     made not visible) and GOT lookups and such have no effect on
>     performance; (they are a performance problem) but for most apps,
>     I/O overwhelms most other factors.

I would agree - however, the X server is strongly decoupled from the
application and is far more efficient than Windows at avoiding unnecessary
GUI work. A lot of the time in my experience the X11 application just
trundles along and its GUI gets updated some time later.

However given your point, how about doxygen? Running the same on Linux and
Win32 it's at least twice as fast on Win32. Even including that doxygen is
running in VMWare which will come with some penalty (not much for CPU
bound tasks like doxygen), there's something wrong there.

Granted though it's getting better. GCC 3.4 produces noticeably better
quality code than v3.3 and earlier. PIC binaries are much smaller (by 50%
with TnFOX). And Linux 2.4 kernels aren't fast with memory mapped i/o (as
against FreeBSD or Windows) which will affect things too.

> What do you think TC1 is, if not the better-labeled equivalent of a
>     point release?

I thought TC1 was no more than wording changes to the standard? ie; to fix
ambiguities and contradictions and no more? That isn't what I'd call a
point release, more a bugfix release.

>> 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
>
> IMO, 1. and 2. are serious changes. Do you think serious changes belong
> in
>     point releases? I don't. Note, I'm in favor of move constructors,
>     and possibly local functions (depending on semantics) as well.

Well, I suppose I'm basing it on my experience with GCC. Local functions
would be easy enough to add, move constructors also though I would have
difficulties with modifying the optimiser to fully make use of them. Of
course the GCC masters aren't keen on extra-specification extensions right
now.

For both the infrastructure is already there (copy constructors and static
member functions of local classes). On most compilers it even has a
specific warning that local functions are not supported if you try.

>> 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)?
>
> A delete expression may choose the deallocation function (that's the
>     user-definable operator delete) dynamicly, based on the runtime
>     type of the deleted object. So a user-defined operator delete
>     within a namespace would naturally apply to all *types* declared
>     in said namespace, *not* to all delete-expressions in said
>     namespace.

I'm not sure I get you. Surely Koenig lookup takes care of finding which
operator delete to use? After that, if the type has a virtual destructor
you call that, else you generate (or call) a suitable destructor based
upon your static knowledge of the type?

> A desireable feature, IMO, but it potentially comes
>     with some difficult design work, and, most importantly, design
>     work that can't assume a delete-expression is just 'irregular
>     call syntax' - the semantics for what function is called
>     are also different, and a delete-expression does more than just
>     call the deallocation function anyway.

I was thinking basically that if you define a "namespace Secure" and
within that namespace new & delete work with a special secure heap it
would be most useful. Interestingly I didn't know this wasn't possible
originally and it worked fine in MSVC and nearly in GCC (occasionally it
got the wrong delete). Maybe this latter problem is what you refer to?
Only ICC barfed with the correct error that this was not supported by the
standard.

>>    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)?
>
> *shrug* C++ exception specifications seem broken beyond all repair,
>     and in any case, it seems most all C++ programmers who use
>     exceptions are focused on using them for non-local error
>     handling. Why complicate their lives with a feature designed for
>     local error handling? If C++ is to gain a feature to force
>     specified errors to be handled locally, it shouldn't have
>     anything to do with exceptions.
>
> Rather, if the committee is going to spend any time on exception
>     specifications, they should consider deprecating them. Probably,
>     this either isn't feasible, or isn't worth the effort, so the
>     committee's time IMO seems better spent on other things.

I quite like the "throws nothing" specifier. It's the only one I use. All
the others from my examination of the generated assembler seem to generate
type checking code which is inefficient.

> If the committee is concerned with making exceptions *safer*, I would
>     aprreciate it if they would ask if the programmer can readily provide
>     enough information so that the implementation can diagnose simple
>     but common violations of exception guarantees.

One thing I really dislike (and I should have included it in my top five,
but I forgot) is what the standard mandates if you throw an exception
while you're in the middle of handling one. That means programmer error
causes an immediate exit of the process with no chance to clean up (I
don't view terminate_handler() as a realistic way of properly cleaning up
a large multithreaded application!)!

I in TnFOX implemented a complex but efficient mechanism for nested
exception handling. If you throw while one is being handled, it's still a
fatal exception but the stack gets fully unwound and all threads get a
chance to unwind theirs too. Best of all, it gets to save information so
even in release builds a decent error report can be given detailing what
went wrong and where. I've grown so used to it that I forget this original
limitation nowadays :)

My C++ is written expecting that any line can throw any exception unless
marked with "throw()". This I've found means you must design and write
code in quite a different fashion than without this constraint - OTOH, you
get code which correctly handles any situation no matter how esoteric.
However it does mean that my code tends to use lots of exceptions - for
indicating parameters are out of bounds for example - and my exception
base class is very "fat". And the numerous use of exceptions causes
especial problems for destructors as it's very easy to throw unwittingly
when a destructor is running higher up the call stack which can raise
fatal exit time again!

If one is to write secure & robust applications in C++ then these
misfeatures can cause you a lot of hassle - getting my nested exception
handling framework working was hard. Certainly more hassle than it could
have with slightly improved wording of the standard.

>>    Why can't you
>>    initialise aggregate types with compile-time known functions (I'm
>>    thinking compile-time variable arrays here)?
>
> What do you mean by this? Surely your compiler supports dynamic
>     initialization

Well I'll tell you what I was doing. I wanted a metaprogramming class
which generates a jump table for a typelist so that a run-time index into
the typelist will call code specialised for that type. I couldn't get
better than a 16 member static const array of function pointers each of
which was initialised by a template which specialised a supplied template
with that type. While another bit of metaprogramming could assemble as
many chunks of 16 as required I couldn't get them to get stored
consecutively and thus would have to have a series of if() statements
choosing which table to use (or I could have a jump table jumping into
jump tables). Ideally I'd want to generate an array of arbitrary length
initialised with an arbitrary number of function pointers but the
aggregate initialiser syntax won't help you here. Non-standard GCC (and I
think MSVC) extensions will though so it can't be hard to implement.

>>    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.
>
> IMO, most of them are costing themselves time, costing their
>     co-workers time, and if you work with their code, costing you time.

I agree that the benefits of everyone using the same library are
undervalued. However that said, I personally tend to use something if it
seems to me to add value. If it doesn't, I don't use it.

A good example here is choice of metaprogramming library. Dave Abrahams
tried his best to get me to use Boost but I instead went with writing my
own. It's not that I have anything against Boost apart from it
unfortunately replicating the style of the STL, but my own library is much
easier to use and less obtuse as I can mandate use of a partial template
specialisation supporting compiler.

>> 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.
> [snip]
>
> What would this achieve? The standard only defines an interface.

It would achieve a migration path onto a better standard template library.

> I realize that those of you who never leave the bounds of Purified
>     Natural Filtered Sanctified OO find the STL's favortism towards
>     value types bizzare, confusing, and inappropriate, but those of
>     us who don't have entity types falling out of ears generally
>     appreciate it.

Heh, I am one of the few programmers I know of who dislikes OO and thinks
it a bad thing.

> Again, it would be niced to see it improved in various ways, and nice
>     to see it complemented by something that better supported entity
>     types, but it shouldn't be removed or replaced.

I'm afraid I don't know what an entity type is. What I would like to see
in a replacement STL is use of traits so metaprogramming can far better
optimise operation, a layered hierarchy of implementation by inheritance
(policies) so it's much easier to reuse parts of a STL container
implementation but reimplement other parts (this is hard right now) and
better genericity eg; iterators which operate the same no matter which
container they belong to (eg; list<>::iterator could be +='d and -='d just
like a vector<>::iterator). I would also redo algorithms as worker classes
rather than supposedly generic functions eg; ContainerSorter which when
instantiated with a vector<> instance provides the "perfect" stable and
non-stable sorts etc. but can also be subclassed to customise it further.

I vaguely remember Alexandrescu saying he was working on a STL
reimplementation called YASLI. Did anything ever come of that?

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                       ]

===================================== MODERATOR'S COMMENT:
 Please take the VMware discussion to private email.


===================================== END OF MODERATOR'S COMMENT
s_googlegroups@nedprod.com (Niall Douglas) writes:
[snip]
> However given your point, how about doxygen? Running the same on Linux
> and Win32 it's at least twice as fast on Win32. Even including that
> doxygen is running in VMWare which will come with some penalty (not

doxygen running in VMWare? Why? If so, it makes nonsense of your
    comparison; VMWare has almost no overhead for some ops but very high
    overhead for others.

[snip]
>> What do you think TC1 is, if not the better-labeled equivalent of a
>>     point release?
>
> I thought TC1 was no more than wording changes to the standard? ie; to
> fix ambiguities and contradictions and no more? That isn't what I'd
> call a point release, more a bugfix release.

I had thought, up to this point, that point release was a synonym for
    bugfix relase. Apparently, you think it is something else.

>
>>> 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
>>
>> IMO, 1. and 2. are serious changes. Do you think serious changes
>> belong in
>>     point releases? I don't. Note, I'm in favor of move constructors,
>>     and possibly local functions (depending on semantics) as well.
>
> Well, I suppose I'm basing it on my experience with GCC.

It's a major change to the standard because, in order to be useful,
    it needs to be extensively used in and by the standard library.

> Local
> functions would be easy enough to add, move constructors also though I
> would have difficulties with modifying the optimiser to fully make use
> of them. Of course the GCC masters aren't keen on extra-specification
> extensions right now.

Easy to add to the core language, maybe. Easy to add to all the
    appropriate spots in the standard library? I don't think so.

>
> For both the infrastructure is already there (copy constructors and
> static member functions of local classes). On most compilers it even
> has a specific warning that local functions are not supported if you
> try.
>
>>> 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)?
>>
>> A delete expression may choose the deallocation function (that's the
>>     user-definable operator delete) dynamicly, based on the runtime
>>     type of the deleted object. So a user-defined operator delete
>>     within a namespace would naturally apply to all *types* declared
>>     in said namespace, *not* to all delete-expressions in said
>>     namespace.
>
> I'm not sure I get you. Surely Koenig lookup takes care of finding
> which operator delete to use?

Not for types with virtual destructors. See 12.5/4:

    # [...] if the delete-expression is used to deallocate a class
    # object whose static type has a virtual destructor, the
    # deallocation function is the one found by the lookup in the
    # definition of the dynamic type's virtual destructor
    # (12.4). 104) [...]


> After that, if the type has a virtual
> destructor you call that, else you generate (or call) a suitable
> destructor based upon your static knowledge of the type?

The destructor is called before the deallocation function.

>
>> A desireable feature, IMO, but it potentially comes
>>     with some difficult design work, and, most importantly, design
>>     work that can't assume a delete-expression is just 'irregular
>>     call syntax' - the semantics for what function is called
>>     are also different, and a delete-expression does more than just
>>     call the deallocation function anyway.
>
> I was thinking basically that if you define a "namespace Secure" and
> within that namespace new & delete work with a special secure heap it
> would be most useful. Interestingly I didn't know this wasn't possible
> originally and it worked fine in MSVC and nearly in GCC (occasionally
> it got the wrong delete).

With GCC, the namespaced deallocation function is called if the
    delete-expression is used to deallocate an object whose static
    type has a virtual destructor. Otherwise, it is ignored.

>>>    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)?
>>
>> *shrug* C++ exception specifications seem broken beyond all repair,
>>     and in any case, it seems most all C++ programmers who use
>>     exceptions are focused on using them for non-local error
>>     handling. Why complicate their lives with a feature designed for
>>     local error handling? If C++ is to gain a feature to force
>>     specified errors to be handled locally, it shouldn't have
>>     anything to do with exceptions.
>>
>> Rather, if the committee is going to spend any time on exception
>>     specifications, they should consider deprecating them. Probably,
>>     this either isn't feasible, or isn't worth the effort, so the
>>     committee's time IMO seems better spent on other things.
>
> I quite like the "throws nothing" specifier. It's the only one I
> use. All the others from my examination of the generated assembler
> seem to generate type checking code which is inefficient.

True, but not the only thing that is wrong with exception
    specifications.

>
>> If the committee is concerned with making exceptions *safer*, I would
>>     aprreciate it if they would ask if the programmer can readily provide
>>     enough information so that the implementation can diagnose simple
>>     but common violations of exception guarantees.
>
> One thing I really dislike (and I should have included it in my top
> five, but I forgot) is what the standard mandates if you throw an
> exception while you're in the middle of handling one. That means
> programmer error causes an immediate exit of the process with no
> chance to clean up (I don't view terminate_handler() as a realistic
> way of properly cleaning up a large multithreaded application!)!

If cleanup results in an error, can you safely clean up? The standard
    assumes not.

There are surely applications for which this isn't true, but I  think
    they are a minority. I don't know if that minorty is important
    enough to justifty the work necessary to define and implement
    something smarter.

[snip]
>>> 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.
>> [snip]
>>
>> What would this achieve? The standard only defines an interface.
>
> It would achieve a migration path onto a better standard template
> library.

Sorry, I misunderstood your original statement; I didn't realize you
    intended to provide a new library, in addition to the existing
    STL.

>
>> I realize that those of you who never leave the bounds of Purified
>>     Natural Filtered Sanctified OO find the STL's favortism towards
>>     value types bizzare, confusing, and inappropriate, but those of
>>     us who don't have entity types falling out of ears generally
>>     appreciate it.
>
> Heh, I am one of the few programmers I know of who dislikes OO and
> thinks it a bad thing.

Obviously my biases are leading me to make false assumptions
    again. :-)

>
>> Again, it would be niced to see it improved in various ways, and nice
>>     to see it complemented by something that better supported entity
>>     types, but it shouldn't be removed or replaced.
>
> I'm afraid I don't know what an entity type is.

An entity has identity. Even if you and I both have the same make,
    year, model, and options on a car, my car is not your
    car. Examples include bikes, shoes, ostreams, etc.

An entity type is a type you instantiate to get an entity.

An example of a non-entity type is an int. An int is a value type;
    when dealing with ints, any two ints which have the value 5 are
    the same.

[snip]
> I vaguely remember Alexandrescu saying he was working on a STL
> reimplementation called YASLI. Did anything ever come of that?

http://www.moderncppdesign.com/code/main.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:


> I vaguely remember Alexandrescu saying he was working on a STL
> reimplementation called YASLI. Did anything ever come of that?
>
He want to create STL implementation - interfaces would remain the same
but inner parts will be cleaner/faster/using advanced techniques/etc.

/Pavel


---
[ 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 <opr8kly6q7y9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>I'm not sure I get you. Surely Koenig lookup takes care of finding
>which operator delete to use? After that, if the type has a virtual
>destructor you call that, else you generate (or call) a suitable
>destructor based upon your static knowledge of the type?


In file f1.cpp

namespace local_new {
        // contains its overrider or overload of operator new and delete
}

mytype * i_ptr = new mytype;

In file f2.cpp

extern mytype * i_ptr;

namespace local_new {
   delete i_ptr;
}

is just one example of a multitude of possible problems. Unlike classes
where the compiler sees all the declarations in the class definition
there is no requirement that the compiler sees all the declarations in a
namespace in any particular translation unit.

When you are annoyed by something in C++ it is usually a good idea to
discover why it is the way it is. We (I was part of the group whose
responsibility included this part of the core language)  very carefully
considered issues of overloading and overriding (i.e. replacing)
operator new and operator delete at namespace scope and concluded that
with the C++ separate compilation model it was impossible to implement
which is why it is not allowed.

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

s_googlegroups@nedprod.com (Niall Douglas) writes:

> 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

This is what you call a "fresh viewpoint?"  To me it sounds
unbelievably jaded and cynical.  Maybe you should break your personal
rule and come to a committee meeting to see how things actually work
before you make such judgements.  Participating in the C++ committee
and in the relationships that I developed out of it has probably been
the the most rewarding professional experience of my life.

> 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)

When we run across such a feature, maybe we'll have use for that
mechanism.  AFAICT it hasn't happened so far.  We do have technical
reports that allow us to "bless" features before officially
standardizing them.

Also, 6 months, being only the total time between committee meetings,
is a bit short to expect to give any feature full consideration, get
implementation experience, and draft appropriate specifications.
We've been working on starting a process for making progress between
meetings, similar to Boost's, but even then I think 6 months would be
too short for actually adding a new feature, no matter how much
agreement it got.

> 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.

Wow, if you think that's really small, I'd hate to see a medium-sized
feature.  I mean, it's not "templates" or anything, but move
constructors has lots of implications, and no universal agreement.
Note that nobody's even written a complete specification yet.

> 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.

There's plenty of agreement on that, but the problem is that every
feature takes more work than you seem to think, and we only have so
much volunteer manpower at our disposal.  People who "deliberately
avoid having anything to do with groups like this" but expect us to
hurry up and approve their favorite features aren't doing anything to
contribute to the solution.

> 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.

There are no powers that be; just a bunch of people who get together
every 6 months to try to make progress, and spend a lot of time having
email discussions and writing proposals in between meetings.  You can
either participate and make a difference or you can expect us to
handle the things we have the time, energy, and expertise to work on.

--
Dave Abrahams
Boost Consulting
http://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                       ]

dietmar_kuehl@yahoo.com (Dietmar Kuehl) writes:

> 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

And pairs of iterators are used to represent ranges, which are
    arguable a third concept.

> (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 :-)
[snip]

---
[ 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> writes:

> 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.

In my experience, this has far more to do with the the multiple (and
    complicated!) layers of abstraction which come with the X window
    system. Note that it is generally true for staticly linked
    executables as well as dynamicly linked. Also, the opposite is
    generally true for non-gui applications, due to more aggressive fs
    caching. I'm not saying the unecessarily visible names which
    often result from the unix model (note, not always, they can be
    made not visible) and GOT lookups and such have no effect on
    performance; (they are a performance problem) but for most apps,
    I/O overwhelms most other factors.

> 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 :(

What do you think TC1 is, if not the better-labeled equivalent of a
    point release?

>
> 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),

It seems unimportant only becuase so few are using it. :-)

Whether or not it is useful is unknown (to most C++ users),
    again, because so few are using it.

> we really could do with a point release of the
> standard to address urgent issues in a timely fashion.

In a timely fashion? They meet twice a year. Should we be funding
    them to the extent that they can work on it 40 hours/week, 50
    weeks a year? That would radicly change the amount of time it
    took for improvents to be written into the standard, but would it
    affect how quickly implementors can move to implement what is
    written. OTOH, we could then have the easiest-to-understand
    standard around (modulo the sheer complexity of C++.)

> 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

IMO, 1. and 2. are serious changes. Do you think serious changes belong in
    point releases? I don't. Note, I'm in favor of move constructors,
    and possibly local functions (depending on semantics) as well.

> 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)?

A delete expression may choose the deallocation function (that's the
    user-definable operator delete) dynamicly, based on the runtime
    type of the deleted object. So a user-defined operator delete
    within a namespace would naturally apply to all *types* declared
    in said namespace, *not* to all delete-expressions in said
    namespace. A desireable feature, IMO, but it potentially comes
    with some difficult design work, and, most importantly, design
    work that can't assume a delete-expression is just 'irregular
    call syntax' - the semantics for what function is called
    are also different, and a delete-expression does more than just
    call the deallocation function anyway.

>    Why can't you template a
>    typedef?

People in the commitee are doing good hard work to provide this to
    you.

>    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)?

*shrug* C++ exception specifications seem broken beyond all repair,
    and in any case, it seems most all C++ programmers who use
    exceptions are focused on using them for non-local error
    handling. Why complicate their lives with a feature designed for
    local error handling? If C++ is to gain a feature to force
    specified errors to be handled locally, it shouldn't have
    anything to do with exceptions.

Rather, if the committee is going to spend any time on exception
    specifications, they should consider deprecating them. Probably,
    this either isn't feasible, or isn't worth the effort, so the
    committee's time IMO seems better spent on other things.

If the committee is concerned with making exceptions *safer*, I would
    aprreciate it if they would ask if the programmer can readily provide
    enough information so that the implementation can diagnose simple
    but common violations of exception guarantees.

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

What do you mean by this? Surely your compiler supports dynamic
    initialization

>    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

Because C++ wasn't designed with metaprogramming in mind. It was an
    accident. Hopefully it will inspire a set of dedicated
    metaprogramming features, either in C++ or some other
    programming language, but for now, metaprogramming in C++ is like
    OOP in assembler.

>    (and forces stilted
>    design)? I can go on, but the "D" programming language has many
>    more good ideas here.

Some good ideas, and some bad ones. The only big advantage seems to
    be that D (like darn near every other programming language(*)) is
    much, much easier to implement tools for.

(*) I've heard algol 68, ansi common lisp, and pl/1 where harder to
    implement than C++ . I don't know what the methods behind those
    judgements were, however.

>
> 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.

Someday, you should get P.J.'s book _The Draft Standard C++ Library_,
    so you can see what the STL replaced. The library described
    therin (which AFAIK was the only other serious contender (*)) is
    well-designed in its own way, but it was sparser than
    the the library that we now have, largely due to the STL's richer
    set of containers and algorithms. (The compatibility lost due to
    the massive changes to the iostream library is IMO not the fault
    of the STL.)

Somewhat seperatly It's easy to look at e.g. Java, and think 'my, the
    C++ standard library is a desert' but it's important to remeber


(*) 'contender' in the sense that if the STL had not be voted into
    the standard, we would likely have what Plauger described in that
    book, though that is in most ways better described as a
    predecessor.

>
> 5. Speaking of which, the STL in general annoys me.

Maybe you are mis-using it? In truth, all interfaces annoy, and it is
    human nature to best recall those aspects of an interface which
    annoy.

>    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.

IMO, most of them are costing themselves time, costing their
    co-workers time, and if you work with their code, costing you time.

>    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()).

I find splice() more natural than either relink() or move(), both of
    which seem subtly wrong to me. I have to laugh at this particular
    complaint of yours, because it seems to me there are many examples
    (std::remove() anyone?) where almost everyone agrees the STL
    picked the wrong name, but you chose a place where it picked the
    right name.

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).

*Not* my idea of an improvement over the STL. If you'd like to see a
    serious alternative to the STL, you might try the NTL. (Search for
    it on sourceforge.)

However, it should be acknowledged that the STL strongly favors value
    types, which is a huge advantage for many kinds of programs, but
    is largely antithetical to certain common OO styles which
    overwhelming demand entity types.

It would be quite useful to have a complementary library of
    containers and algorithms strongly biased toward entity types.

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

What would this achieve? The standard only defines an interface.

I realize that those of you who never leave the bounds of Purified
    Natural Filtered Sanctified OO find the STL's favortism towards
    value types bizzare, confusing, and inappropriate, but those of
    us who don't have entity types falling out of ears generally
    appreciate it.

Again, it would be niced to see it improved in various ways, and nice
    to see it complemented by something that better supported entity
    types, but it shouldn't be removed or replaced.

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

From: "llewelly" <llewelly.at@xmission.dot.com>

| Rather, if the committee is going to spend any time on exception
|     specifications, they should consider deprecating them.

changing the semantics from runtime-checks to no runtime-check would be good IMO.

| It would be quite useful to have a complementary library of
|     containers and algorithms strongly biased toward entity types.

FYI  I'm working on a set of adapters that makes it possible to store
pointers in std containers without using shared_ptr. Whether this is a good idea
or not remains to be seen.

What kind of algorithms are you talking about especially for entity types?

br

Thorsten


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