On Fri, 11 Jun 2004 16:10:23 +0000 (UTC), do-not-spam-benh@bwsint.com
(Ben Hutchings) wrote:

>"Pavel Vozenilek" wrote:
>>
>> "Francis Glassborow" <francis@robinton.demon.co.uk> writes:
>>
>>> Niall Douglas writes
>>> >There are core language updates obvious to anyone with any experience
>>> >of C++ which could be added within no more than a year. Their details
>>> >need not be designed as they can be evolved. I am certain of it.
>>>
>>> Name one. All the experience I have says that they do not exist.
>>>
>> Maybe small things like forcing switch to deal with all members of enum:
><snip>
>
>Enumerated types may have separate enumerators for each of their legal
>values (as defined by the program, not the language) or may
>effectively be bitfields with enumerators that can be logically
>combined to make other legal values (blessed by 7.2/6).  These uses
>are not distinguished in the language so an implementation cannot know
>what the legal values of an enumerated type are.

Hence the syntax adds a special new label (which should be changed I
think):
!default:
Existing code that doesn't use that special label won't be affected.
Effectively adding the above to a switch statement forces the compiler
to check that every named enumeration value has been included as a
separate case. If not, the code is ill-formed.

End users will only use it with value set enums, not with bitfield
type enums. Basically it allows you to add new values to enums and
know that you'll get compiler errors where appropriate.

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                       ]

"Pavel Vozenilek" wrote:
>
> "Francis Glassborow" <francis@robinton.demon.co.uk> writes:
>
>> Niall Douglas writes
>> >There are core language updates obvious to anyone with any experience
>> >of C++ which could be added within no more than a year. Their details
>> >need not be designed as they can be evolved. I am certain of it.
>>
>> Name one. All the experience I have says that they do not exist.
>>
> Maybe small things like forcing switch to deal with all members of enum:
<snip>

Enumerated types may have separate enumerators for each of their legal
values (as defined by the program, not the language) or may
effectively be bitfields with enumerators that can be logically
combined to make other legal values (blessed by 7.2/6).  These uses
are not distinguished in the language so an implementation cannot know
what the legal values of an enumerated type are.

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

do-not-spam-benh@bwsint.com (Ben Hutchings) writes:

> "Pavel Vozenilek" wrote:
>>
>> "Francis Glassborow" <francis@robinton.demon.co.uk> writes:
>>
>>> Niall Douglas writes
>>> >There are core language updates obvious to anyone with any experience
>>> >of C++ which could be added within no more than a year. Their details
>>> >need not be designed as they can be evolved. I am certain of it.
>>>
>>> Name one. All the experience I have says that they do not exist.
>>>
>> Maybe small things like forcing switch to deal with all members of enum:
> <snip>
>
> Enumerated types may have separate enumerators for each of their legal
> values (as defined by the program, not the language) or may
> effectively be bitfields with enumerators that can be logically
> combined to make other legal values (blessed by 7.2/6).  These uses
> are not distinguished in the language so an implementation cannot know
> what the legal values of an enumerated type are.

Nothing's ever as simple as it looks when it comes to standardization.

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

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0406080712.689f2fba@posting.google.com>...
> tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0406071406.38550d9c@posting.google.com>...
> > kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0406070732.3fdbe679@posting.google.com>...
> > > s_googlegroups@nedprod.com (Niall Douglas) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...
> > > > On Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
> > > > <llewelly.at@xmission.dot.com> wrote:
> > > >
> > > Design without some implementation experience behind it is nearly
> > > useless. However, implementation without design always ends up in a
> > > horrible mess, if you take it too far (and most people do). It's a
> > > judgement call how much time to assign to each activity, and in what
> > > order, and my impression from your words is that you're not in the
> > > habit of assigning enough time to design, or that you are in the habit
> > > of putting it off until later than it should be
> >
> > When is it too late to design?
>
> It's too late to design, when the basic features of a system are no
> longer amenable to change. However, that's just the extreme case.
> Design costs a lot more, the later it is done.

Not necessarily. A _wrong_ design, if done prematurely, and it turns
out to be wrong, once you understand how the system actually works,
can be more costly than if you wait until you have sufficient
information. I.e. "growing the design". Here's for example a good
article on that topic: http://www.artima.com/intv/architecture.html

What I've found to be most problem in practice, is incompetence or
laziness resulting in an unstructured codebase. However, an
overgeneralised system can also be difficult to deal with. Either way,
the system is more complex than it needs to be. I'm talking especially
of local complexity, here, which is very important to the
understanding and maintenance of the system.

The book "Lean Software Development" says it as: "Delaying decisions
to the last responsible moment", and that experienced people have
typically learned to delay nonreversible (or hard to change) decisions
as long as responibly possible, whereas beginners typically try to get
everything right from the start, and typically end up with a bad or
overgeneralised design.

> It is trivially easy to
> start designing something later than the best possible time. That's
> because the best time to start design is very early in the process.

I think the term "design" may mean different things to different
people, so discussing it without a good definition may be quite
pointless. To quote from a posting by Richard Howells in a thread on
design at the accu-general mailing list:

"Well - following up on Kevlin [Henney]'s, often stated, view that all
of the software development process is design, right down to lines of
code, then clearly ALL software is designed.  (I totally agree with K
about this.)".

I completely agree with this, as well.

> It's a mistake to design in too much detail too early, but it's
> equally a mistake to design in too little detail. Since design is
> boring, and coding is fun, the second type of mistake is far more
> common than the first.

I think we may be talking on cross-purposes, and mean something
different with "design". In the mentioned thread on accu-general, Jim
Hyslop said:

Terje Sletteb   :

>> A quite frequent misunderstanding of XP/agile development is
>> that you don't design.

Jim Hyslop:

>I think a lot of the misunderstanding stems from the definition of
"design".
>To many people, "design" means "write a lot of documents that specify
>exactly what you are going to do." If there aren't tons of UML
diagrams,
>use-cases, data flow diagrams, whatever, it isn't "design".

Frankly, I don't find design boring, at all. How much you design up
front, and how much you design as you go, is, as I said in the other
posting, a judgement call. Fred Brooks (in "The Mythical Man-Month")
said that his experience was that a team can typically "grow" a larger
system in a given amount of time, than a team doing all the design up
front. It has also been said that any large successful system has
invariably been a smaller successful system.

Anyway, this discussion doesn't really belong at comp.std.c++, I
guess, but feel free to join accu-general, and raise the issue there.
:) Or, alternatively, send mail private.


Regards,

Terje

---
[ 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, 6 Jun 2004 23:53:30 +0000 (UTC), s_googlegroups@nedprod.com
(Niall Douglas) wrote:

>Here's an imaginary timeline:
>
>1. Core language change proposed. Let's take N1377 as an example.
>2. N1377 could be patched into GCC reasonably easily. Therefore it is
>farmed out into a Bugzilla database. A call for volunteers is issued via a
>mailing list and an announcement placed in slashdot etc.
>3. Volunteers generate patch for GCC implementing N1377.
>4. Volunteers download patch for GCC implementing N1377, patch their GCC,
>add in support for move constructors to their code and test. Report
>problems back to the Bugzilla database.
>5. From feedback/contributions, patch is refined.
>6. Iterate steps 4 & 5 repeatedly.

Up to here, that sounds like a reasonable way of continuing. Once an
implementation is available, it's easier to examine the ramifications
of the feature.

>7. When patch is stable and everyone is happy, volunteers generate a
>proposed amendment to the standard using the experience gained of the
>ramifications, pitfalls and other issues. Proposed amendment/report goes
>to next six-monthly ISO C++ committee.

This is the point of contention. The amendment is going to require
rewording large sections of the standard as well as adding new
sections; a new reference type is involved! This is the bit that
requires lots of debugging, not the implementation. The implementation
will have lots of implicit effects on different features, such as
overloading, templates, etc. that have to be put into unambiguous
words. It's much harder to debug specifications than code (which is
why the first patch to the standard took 5 years).

This makes it inefficient to make just that "single" change, since the
modifications must be made to TC1, which means they have to be merged
back into the working paper once the move semantics standard is
approved.

All in all, it's a big job, and not, by any means, a small, isolated
change.

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                       ]

kuyper@wizard.net (James Kuyper) wrote in message

> Also, keep in mind the golden rule: "he who has the gold, makes the
> rules". As it currently stands, the C++ standard is produced under a
> system that is funded mainly by sales of copies of the standard.

Actually, that amount is piddly and goes to the central ISO
bureaucracy. Each member of the committee pays a fee to attend (on the
order of $800 a year) plus his own cost at attending the meetings.


> That
> means that the main financial incentive the standard organizations
> have is to produce a standard that maximizes the number of people
> willing to pay for a copy of it. That strikes me as a good incentive -
> the best way to satisfy it is to produce a standard that is so
> well-designed that it becomes widely used. Of course, it's up to those
> organizations themselves to decide whether to pay attention to that
> incentive, but at least it's an incentive in the right direction.

My experience is that it is extremely hard to convince a standards
body to make a standard widely available. The ANSI electronic copy and
the Wiley books came into being after much effort from individual
members of the C++ committee; not the standards bureaucracies.

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


> With government or corporate financing, the main financial incentive
> would be to satisfy the needs of the goverment or companies providing
> the financing. The interests of other users would have little or no
> financial significance.

---
[ 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, 7 Jun 2004 22:35:30 +0000 (UTC), Terje Sletteb?
<tslettebo@hotmail.com> wrote:

> One might use the same way to evolve a standard. However, this doesn't
> mean that you necessarily _publish_ a revised standard incrementally
> like that. As has been pointed out in this thread: users and compiler
> implementers have an advantage of stability, so they know that can
> build something that lasts.
>
> Bjarne Stroustrup made that point once, where he said that typically
> language researches ask for new stuff all the time, to be added to
> C++. While, if he asks the people "in the trenches", the working
> programmers, the answer he got was: "Please, give us some stability."

Absolutely. Just because you /can/ make code breaking changes every three
years doesn't mean you actually do so. However similarly there must be
some recourse for ameliorating negative effects of a previous error in
design which allows code breaking changes when the gain is more than the
pain of the breaking change. Three years is about right to determine what
is a pain and how to fix it.

C++ has something intangible like C did before it - mojo factor. The mojo
factor of a programming language is a measure of how much people like
programming in it for totally unspecifiable reasons and while C++'s is not
as high as C's, it's still higher than most other programming languages.
It's also why C++ is more popular than Java and always will be so despite
the "cleaner" design of Java's academics like so much.

Interestingly, mojo factor strongly correlates with how evolved the design
of a language was. C was virtually designed entirely by evolution as its
name denotes. C++ also was far more evolved than designed especially in
its early days. All engineers tend to have their own box of tools and
likewise, a programming language is like a glove - each programmer chooses
based on how well it fits them.

Just some food for thought given the current thread.

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 Sun, 6 Jun 2004 23:53:51 +0000 (UTC), David Abrahams
<dave@boost-consulting.com> wrote:

>> There are core language updates obvious to anyone with any experience of
>> C++ which could be added within no more than a year. Their details need
>> not be designed as they can be evolved. I am certain of it.
>
> So, let's get down to specifics, taking move semantics for example (or
> pick another feature; I don't care).  What are you proposing, that the
> committee say "we're going to have move semantics", without nailing
> down precisely what that means or how it works?  And then what?  We
> put that phrase in the working paper, and as people find problems with
> the fact that it has no meaning, we make evolutionary adjustments
> until everyone can agree that it's well-specified and works with the
> rest of the standard text?

Sorry for the late reply. I got some manual labour work for the last few
days which left me too tired to use a computer each night (even now muscle
stiffness makes it hard to type). It did however give me another
opportunity to step back and look at this from afar - I've not replied to
many of the other replies to mine as they either make points I've already
refuted, address topics which I'd previously made clear I'm not talking
about or would require an off-topic reply. However your question for
specifics is a productive one.

I suppose the core of what I am advocating is "beta testing" of a standard
change. Through implementation of move semantics one gains an experience
and insight impossible before implementation. Ten years ago, did anyone
correctly predict how hard template export would be to implement? Or even
that it would be the last feature to be implemented by far? If I
understand correctly, warning noises began to be made only when
implementors got "close" enough to an implementation to see the dragons
which lurked within.

Life's primary function is solving problems. All biological life is
remarkably good at finding solutions to inordinately complex problems far
beyond its direct understanding. However the process of doing so is to be
alive itself and like a goldfish living in a bowl it's impossible to fully
grasp how it is we do things, only that we do do them. This is not to say
that by knowing that we can't know, we cannot substantially improve the
efficiency of what we do.

Move semantics is an ideal problem for implementationally designed/evolved
solution. Adding it should not break any existing code at all. A perfect
solution (the *correct* solution) can be arrived at by patching GCC and
running lots & lots of existing code through it, adjusting the patch
appropriately to fix problems and so on until the solution is stable. You
then simply retro-fit the perfect solution back into a generalised
specification.

If developer resources were infinite, and it took no time to implement a
specification then the whole of C++ would have been designed this way from
the outset as it generates the most perfect solution. However just because
the world isn't like that doesn't mean that for small obvious features
this mechanism can't be utilised - and you don't need to specify or even
know the specifics of the solution before you begin (or even technically
at the end).

One very handy feature of this methodology is that it manages itself and
requires virtually no oversight. You can see it all around you, from the
evolution of the Boost library to the core of what makes capitalism tick
(entrepreneurism).

What I am trying to do here in all these replies is to impart the
realisation that by organising the standardisation process differently you
can considerably improve its efficiency (a metaphor would be rotating
crops within a field each year raises the productivity of that field - a
simple operational change creates a better environment to engender
growth). I know this reply will be considered vague, overly philosophical
and not answering your point but then I wasn't succeeding by saying
"You're doing X wrong. Doing Y is better" now was I? But maybe now I have
explained why *I* can't do this, but all you who create the central
authority behind the C++ standardisation process can (I am not a network.
You all are).

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:

> On Sun, 6 Jun 2004 23:53:30 +0000 (UTC), s_googlegroups@nedprod.com
> (Niall Douglas) wrote:
>
>>Here's an imaginary timeline:
>>
>>1. Core language change proposed. Let's take N1377 as an example.
>>2. N1377 could be patched into GCC reasonably easily. Therefore it is
>>farmed out into a Bugzilla database. A call for volunteers is issued via a
>>mailing list and an announcement placed in slashdot etc.
>>3. Volunteers generate patch for GCC implementing N1377.
>>4. Volunteers download patch for GCC implementing N1377, patch their GCC,
>>add in support for move constructors to their code and test. Report
>>problems back to the Bugzilla database.
>>5. From feedback/contributions, patch is refined.
>>6. Iterate steps 4 & 5 repeatedly.
>
> Up to here, that sounds like a reasonable way of continuing. Once an
> implementation is available, it's easier to examine the ramifications
> of the feature.
>
>>7. When patch is stable and everyone is happy, volunteers generate a
>>proposed amendment to the standard using the experience gained of the
>>ramifications, pitfalls and other issues. Proposed amendment/report goes
>>to next six-monthly ISO C++ committee.
>
> This is the point of contention.

There is no contention over this point, unless you're introducing it
here.  Submitting proposed standard amendments is part of the process
today; it's always better when that comes with a report of real-world
experience.

> The amendment is going to require rewording large sections of the
> standard as well as adding new sections; a new reference type is
> involved!

Well, rewording large sections of the standard as well as adding new
sections is expected to happen during the standardization process.
The rest of what you've written below, I agree with completely.

> This is the bit that requires lots of debugging, not the
> implementation. The implementation will have lots of implicit
> effects on different features, such as overloading, templates,
> etc. that have to be put into unambiguous words. It's much harder to
> debug specifications than code (which is why the first patch to the
> standard took 5 years).
>
> This makes it inefficient to make just that "single" change, since the
> modifications must be made to TC1, which means they have to be merged
> back into the working paper once the move semantics standard is
> approved.
>
> All in all, it's a big job, and not, by any means, a small, isolated
> change.
>
> Tom

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

On Wed, 9 Jun 2004 17:25:19 +0000 (UTC), dave@boost-consulting.com
(David Abrahams) wrote:
>>>7. When patch is stable and everyone is happy, volunteers generate a
>>>proposed amendment to the standard using the experience gained of the
>>>ramifications, pitfalls and other issues. Proposed amendment/report goes
>>>to next six-monthly ISO C++ committee.
>>
>> This is the point of contention.
>
>There is no contention over this point, unless you're introducing it
>here.  Submitting proposed standard amendments is part of the process
>today; it's always better when that comes with a report of real-world
>experience.

I think I meant that it is a point of contention that an amendment
(which I understand to mean a full patch to the standard) can be
easily created by a group of volunteers working in relative isolation
from the rest of the Evolution group.

>> The amendment is going to require rewording large sections of the
>> standard as well as adding new sections; a new reference type is
>> involved!
>
>Well, rewording large sections of the standard as well as adding new
>sections is expected to happen during the standardization process.

Of course, I was just trying to demonstrate that the feature is far
from trivial. The word "reference" gets over 500 mentions in the
standard. I wonder how many will need updating to add exceptions,
differences or additions for rvalue references?

I'd be willing to help out, but I've not been to a standards meeting
yet (although I'm thinking of making enquiries through the ACCU). And
I'm not a qualified language lawyer, unless the qualification is that
I'm not a very good one... :)

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                       ]

tom_usenet@hotmail.com (tom_usenet) writes:

> On Wed, 9 Jun 2004 17:25:19 +0000 (UTC), dave@boost-consulting.com
> (David Abrahams) wrote:
>>>>7. When patch is stable and everyone is happy, volunteers generate a
>>>>proposed amendment to the standard using the experience gained of the
>>>>ramifications, pitfalls and other issues. Proposed amendment/report goes
>>>>to next six-monthly ISO C++ committee.
>>>
>>> This is the point of contention.
>>
>>There is no contention over this point, unless you're introducing it
>>here.  Submitting proposed standard amendments is part of the process
>>today; it's always better when that comes with a report of real-world
>>experience.
>
> I think I meant that it is a point of contention that an amendment
> (which I understand to mean a full patch to the standard) can be
> easily created by a group of volunteers working in relative isolation
> from the rest of the Evolution group.

Most proposals, including a great deal of proposed standard language,
gets created by small groups of volunteers (2-3) working in relative
isolation.  Once the committee decides to move proposals forward,
however, working groups within the committee often spend time
correcting the proposed language or drafting new language, usually by
collaborating with the proposal authors if they're not committee
members.

>>> The amendment is going to require rewording large sections of the
>>> standard as well as adding new sections; a new reference type is
>>> involved!
>>
>>Well, rewording large sections of the standard as well as adding new
>>sections is expected to happen during the standardization process.
>
> Of course, I was just trying to demonstrate that the feature is far
> from trivial.

Agreed.

> The word "reference" gets over 500 mentions in the
> standard. I wonder how many will need updating to add exceptions,
> differences or additions for rvalue references?

I don't know; the trick would be to make rvalue references work
uniformly enough that there would be very few changes.

> I'd be willing to help out, but I've not been to a standards meeting
> yet (although I'm thinking of making enquiries through the ACCU).

Great!

> And I'm not a qualified language lawyer, unless the qualification is
> that I'm not a very good one... :)

Yeah, it takes some experience to be able to do it effectively.
Usually it's best to team up with someone who's done it before.  Greg
Colvin was the genius behind generating minimal-but-complete language
for the exception safety proposals.  That doesn't mean you can't help
out; you just have to collaborate and be willing to learn.

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

In article <opr9b7khfhy9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>I suppose the core of what I am advocating is "beta testing" of a
>standard change. Through implementation of move semantics one gains an
>experience and insight impossible before implementation. Ten years ago,
>did anyone correctly predict how hard template export would be to
>implement? Or even that it would be the last feature to be implemented
>by far? If I understand correctly, warning noises began to be made only
>when implementors got "close" enough to an implementation to see the
>dragons which lurked within.

I think you understand that about as well as you understand the
Standards process:-) The best that 'export' ever was was a dim glimmer
at the end of a very long dark tunnel which implementors were willing to
accept as a possible way to keep a long standing promise.

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

"tom_usenet" <tom_usenet@hotmail.com> wrote in message
news:u9jec0lhcv7vvijrolo6dd8bt8qlsq0j3a@4ax.com...

> I'd be willing to help out, but I've not been to a standards meeting
> yet (although I'm thinking of making enquiries through the ACCU). And
> I'm not a qualified language lawyer, unless the qualification is that
> I'm not a very good one... :)

Not exactly, but humility is a rare and wonderful trait in a wannabee
language lawyer. It also doesn't hurt that your postings are correct
a very high percentage of the time.

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                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> writes:

> Niall Douglas writes
> >There are core language updates obvious to anyone with any experience
> >of C++ which could be added within no more than a year. Their details
> >need not be designed as they can be evolved. I am certain of it.
>
> Name one. All the experience I have says that they do not exist.
>
Maybe small things like forcing switch to deal with all members of enum:

switch (enum_or_typedef_to_enum) {
  case value_1:   ...
  case value_2:   ...
  ...
  case value_n: ...
  !default: /* nothing allowed here */
  }

Lack of this may really bite.

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

s_googlegroups@nedprod.com (Niall Douglas) wrote in message news:<opr85eqly0y9klrv@news.iol.ie>...
> On Fri, 4 Jun 2004 16:09:58 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
> =
> > We actually have a problem with maximizing the effectiveness of those
> > who already have the time and energy to participate.
>
> Ah, precisely the core of the problem I am suggesting solutions for! All
> organic life in this universe organises itself - you merely need to create
> an environment which fosters that self-organisation and the rest flows
>  from within under its own power. I'm sure Dave you have read books by Fred
> P. Brookes and witnessed the remarkable self-organising enabler of the
> internet?

You may also be familiar with "The Timeless Way of Building", which I
recently read, and I which I found very illuminating.

It has the same ideas of spontaneous self-organisation, as in
organisms, and in communities.

> >> the standardisation process nor even this newsgroup and most
> >> especially physically attending conferences. They want short
> >> duration quick in & out self-contained mini-projects. While they
> >> aren't adverse to writing prose, they'd far prefer to write code.
> >
> > But the standard isn't code.  Now it sounds like you're talking about
> > patching some code...  but we don't have a standard C++ reference
> > implementation.
>
> But then I'm not proposing the patching of the standard directly. The
> committee is the only one able to do this and indeed should do this.
>
> This isn't to say it can't be helped along. For example, if government
> wants a new law they can either draft one themselves, form a committee to
> do so or ask someone external to provide one eg; a trade body or even the
> public. It's hardly unknown for a vested interest to write the bill in its
> entirity and pass it to a government minister who then presents it as
> their own.

You may also be familiar with this in the C++ standard, as well: It's
called writing a formal proposal. ;)

Anybody can do that, and submit it to the committee. Those can even be
as detailed as containing a proposed new wording in the standard for
the change/amendment.

> You guys propose an amendment as you already do. If it's reasonably small
> and could be patched into existing compilers relatively easy you submit it
> to the Bugzilla database and on to some front web page. Volunteers create
> a patch implementing it for (say) GCC. Other volunteers apply this patch,
> add support to their code and test it, refining the patch through comments
> and further patches ie; evolutionary.
>
> One month before the biannual meeting of the ISO C++ committee reports on
> the progress of the real-world testing of the amendment are generated. You
> guys at the committee meeting review them and after you feel you have a
> handle on it, you generate a proposed amendment to the standard which is
> posted again on the Bugzilla database for review. Or perhaps a volunteer
> writes a proposed amendment which you guys review which saves you a step.
> Either way, all roads still eventually lead through the traditional ISO
> C++ committee.
>
> What you gain and you are currently lacking is an army of volunteers who
> put your ideas into practice so you can see the end results and thus can
> both prevent mistakes and considerably shorten the time required for
> finalising the form of new features.

This might be an idea, but as has been mentioned in this thread,
someone has to arrange such a thing, set up and maintain webpages,
etc. Perhaps write a proposal for this to the committee, and see what
comes out of it? If you or someone else could help arranging things,
if there's interest for this, that would probably help, as well.

> No matter how chaotic and decentralised you might think the
> C++ standardisation process is, it is still highly hierarchical. I know of
> no compiler vendor who is busy augmenting C++ with their own features as
> vendors have become burned by that in the past

Daveed Vandevoorde of EDG is working on implementing a metaprogramming
extension to an experimental version of the EDG compiler...
(http://www.vandevoorde.com/Daveed/News/Archives/000014.html)

He's also on the standards committee, with the rest of EDG, as well.

> - the D language is the
> closest thing I know to it but it's distinctly non-commercial. Like it or
> not, every compiler vendor has their eyes turned towards the standard and
> thus every C++ programmer is similarly though indirectly the same.

"typeof" is implemented in EDG (provided as a GCC compatibility
extension), and EDG is certainly a commercial compiler.

> > Then become "an expert."  You're just making lame excuses for an
> > unwillingness to but your own butt on the line.  My name meant
> > "nothing to anyone" when I decided to try to have an impact on the C++
> > committee.  Nothing other than your own insistence makes you less
> > qualified to make a difference than anyone else.
>
> There is so much wrong with this statement I don't know where to begin. I
> could indeed write this length of post just about why your statements here
> are totally incorrect and worse, are dangerous forms of thinking (see
> books by Alain de Boton). However, it would be distinctly off-topic
> despite being relevent so I will condense it heavily:-
>
> Experts don't become, they are made - just like no president of the United
> States didn't come from a privileged background. Experts become recognised
> as such because they came up with the goods at the right place & time on
> one or more occasions - in your case, an exception safe STL just when
> people were wondering if it were possible within a timeframe when doing so
> got widespread notice. If any of these factors had been out you would be
> as anonymous as I am, just as Einstein would be unknown if he had deduced
> relativity either before or after when he did.

I don't think so. Time and time again, world-famous people have said
that they got to where they are, because they burned for something,
believed in something, and worked to make their dream a reality.

I'd be inclined to agree with Disney: If you can dream it, you can do
it. :)

This has a risk of straying quite off-topic, but there's plenty of
examples of people who didn't come from a "privileged background", and
yet became great. If it wasn't like this, how could anyone ever
improve their situation?

Dave hasn't "only" come up with the exception safety specifications,
but also with other cool stuff. When you have talent, and use that
talent, these things can happen.

You said Dave's form of thinking is dangerous. I think it's the other
way around: If you think you can do something, you increase you chance
of actually succeeding. However, if you _don't_ think you can do
something, you'll give up before you start. Hence, it will become a
self-fulfilling prophecy. And _that's_ a dangerous way of thinking!
Someone having that attitude will think they'll never accomplish
anything, and, sadly, because of that belief, they'll likely be right.

> All actions are more a
> product of the culture & society in which the person is born than any
> characteristic or achievement of that individual themselves.

I don't believe that, and there's plenty of evidence to support my
claim. However, as I said, if people believe what you said, they may
also experience it, not because of any outside constraint, but because
they limit themselves.

Basically, you are what you think you are. ;)

> I know this
> reality will be alarming to anyone raised in a capitalist system where the
> false motivator of individual potential reigns supreme, but it is so
> nevertheless.

Do you have any support for this claim?

I know this kind of thinking is used in some societies/regimes to
artificically limit and oppress individuals, a "caste"-thinking. I
think the success of the capitalist system - and who it has worked
well for - show this belief not to be true.

> If you create an environment which *enables* something you desire then it
> will come about with no micro-managing required. *I* cannot create such an
> environment because I do not have the authority to do so - therefore I
> would have to both create myself as an authority and create the
> environment at the same time which is very much harder. If I were to press
> ahead alone, how could I issue press statements to media outlets in the
> name of the ISO C++ committee calling for volunteers to implement an
> amendment? How could I even run a website officially endorsed by the ISO
> C++ committee? *I* can't do any of this, but a person entitled by mandate
> of the central authority CAN and that's why it's pointless for me to do
> this alone.

_Cooperating_ with the standards committee, perhaps joining your
national body, may be a start. However, you said you don't want to
have anything to do with standards work. How can you expect the
standards committee to cooperate with you in setting this up, if you
don't want to have anything to do with them?

It sounds like you want to have your cake and eat it, too: Deciding
over the standards committee, without actually participating and
cooperating with it, yourself.

> I have "placed my butt on the line" on numerous occasions but only when I
> felt it was worth doing so in the long run. Feel free to search the
> internet and trawl up the good and bad of my history much of which is in
> the public domain. I know I cannot ever contribute anything useful to
> C++ as the standardisation process currently stands so I do not delude
> myself into thinking otherwise

If you feel this way, and don't want to join the standards process,
perhaps you could find someone already involved, and who might be
interested in what you suggest, to work for it.

Regards,

Terje

---
[ 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) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...
> On Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
> <llewelly.at@xmission.dot.com> wrote:
>
> >> What I've been saying: The previously outlined (and traditional)
> >> process is inefficient because it makes no use of the large body of
> >> programmers out there ready to volunteer their time to "patching" the
> >> standard just like any piece of free software. Such people have little
> >> wish to involve themselves in the intricaces of the standard, the
> >> standardisation process nor even this newsgroup and most especially
> >> physically attending conferences. They want short duration quick in &
> >> out self-contained mini-projects.
> >
> > However there are many interdependencies within the standard. E.g.,
> >     the presence of overloading necessitates ADL. As far as the core
> >     langauge is concerned, it is hard to see how there can be 'short
> >     duration quick in & out self-contained mini-projects'
>
> I disagree. Computer software programming is basically an exercise in
> manipulating complexity. Therefore the requisite computer programming
> skills of being able to hold in your mind all parts of a computer program
> and the likely "ripple" effect of a change is well developed by necessity
> within computer programmers.

The ripple effects of standard changes are a problem of much greater
magnitude, and most programmers I've known are nowhere near having
developed the skills needed to keep them in mind. It helps if you've
use a few dozen different computer languages, and if you've used C++
on a few dozen widely different platforms, but the number of
programmers with that kind of experience is quite rare. I'm not one of
those people, and I don't think most of the committee members are,
either. The committee achieves it's breadth of vision by being a
committee, not by having supermen for members. Even if most committee
members are unfamiliar with the problems that a given proposal might
make for one platform, they can hope that there's at least one member
who will know, and can explain those problems to the other committee
members. Without the admittedly slow committee process, such problems
would leak out into the published standard far more often than they
currently do.

..
> There appears to be a huge gulf between what the experts in this newsgroup
> view as a small obvious feature and what I do. While the likelihood is
> that I am wrong as I am the one with the least experience, I also am
> probably quite different from you guys in viewing software generation as a
> mostly organic process ie; there is very little initial planning and the
> design "grows" during the implementation of the project. By implementing
> in a highly modular fashion, one can cut out sections and replace them if
> hindsight shows you were wrong. Or indeed, occasionally, one trashes the
> software and begins again afresh.

It's all a matter of what you mean by "very little" and "initial".
Design without some implementation experience behind it is nearly
useless. However, implementation without design always ends up in a
horrible mess, if you take it too far (and most people do). It's a
judgement call how much time to assign to each activity, and in what
order, and my impression from your words is that you're not in the
habit of assigning enough time to design, or that you are in the habit
of putting it off until later than it should be, but I have no way to
know whether or not that's true.

However, I think you're missing a key point. The C++ standard is all
about design. The key purpose of the standard is to be part of the
requirements specification for implementations of C++. Implementation
experience is supposed to be taken into consideration in putting
together that specification, but standardization is not
implementation, and the quick-fix approaches that you're talking about
don't apply here.

A standard is intended to be widely used, so programs can rely on it.
It can take 5-10 years for a new standard to be widely implemented. It
doesn't make sense to make changes to it more quickly than that; doing
so simply creates a moving target that no implementation will ever
fully conform with.

---
[ 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) wrote in message news:<opr85eqzoly9klrv@news.iol.ie>...
> >> There are core language updates obvious to anyone with any experience
> >> of C++ which could be added within no more than a year. Their details
> >> need not be designed as they can be evolved. I am certain of it.
> >
> > Name one. All the experience I have says that they do not exist. Please
> > note that I specialise in trying to identify small changes, additions
> > etc. that would make C++ more usable yet I have never managed to come up
> > with a single change that has no ramifications elsewhere.
..
> 1. Core language change proposed. Let's take N1377 as an example.

You're kidding, I hope? N1377 is your idea of a small,
non-controversial change with few ramifications, that therefore
doesn't require much consideration by the committee?

You have a very long way to go before you'll understand the true
complexity of computer language specification.

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

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0406070732.3fdbe679@posting.google.com>...
> s_googlegroups@nedprod.com (Niall Douglas) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...
> > On Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
> > <llewelly.at@xmission.dot.com> wrote:
> >
> Design without some implementation experience behind it is nearly
> useless. However, implementation without design always ends up in a
> horrible mess, if you take it too far (and most people do). It's a
> judgement call how much time to assign to each activity, and in what
> order, and my impression from your words is that you're not in the
> habit of assigning enough time to design, or that you are in the habit
> of putting it off until later than it should be

When is it too late to design?

In agile development, you typically design as you develop, growing the
design, rather than having one big up front design (BUFD). It's not a
matter of design or not; there's a _lot_ of design in agile
development/XP, as well. The question is _when_ you design. In agile
devoplement, you typically hold off as long as possible, with the
design, which gives you most information to do a good design, rather
than the typical guesswork of a big up front design.

Naturally, it's a judgement call, as well.

The conventional view of the development process is typically one of:
design, code, test, debug. However, with test-first development, you
really have test, code, then design. :) (And you might more or less
dispense with the "debug" part).

The design, in this case, is much in the refactoring. As I said,
growing the design.

One might use the same way to evolve a standard. However, this doesn't
mean that you necessarily _publish_ a revised standard incrementally
like that. As has been pointed out in this thread: users and compiler
implementers have an advantage of stability, so they know that can
build something that lasts.

Bjarne Stroustrup made that point once, where he said that typically
language researches ask for new stuff all the time, to be added to
C++. While, if he asks the people "in the trenches", the working
programmers, the answer he got was: "Please, give us some stability."

Regards,

Terje

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

tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0406071406.38550d9c@posting.google.com>...
> kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0406070732.3fdbe679@posting.google.com>...
> > s_googlegroups@nedprod.com (Niall Douglas) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...
> > > On Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
> > > <llewelly.at@xmission.dot.com> wrote:
> > >
> > Design without some implementation experience behind it is nearly
> > useless. However, implementation without design always ends up in a
> > horrible mess, if you take it too far (and most people do). It's a
> > judgement call how much time to assign to each activity, and in what
> > order, and my impression from your words is that you're not in the
> > habit of assigning enough time to design, or that you are in the habit
> > of putting it off until later than it should be
>
> When is it too late to design?

It's too late to design, when the basic features of a system are no
longer amenable to change. However, that's just the extreme case.
Design costs a lot more, the later it is done. It is trivially easy to
start designing something later than the best possible time. That's
because the best time to start design is very early in the process.
It's a mistake to design in too much detail too early, but it's
equally a mistake to design in too little detail. Since design is
boring, and coding is fun, the second type of mistake is far more
common than the first.

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

davideng2004@yahoo.com (David Eng) wrote in message

> I am not joking.  You are well underestimated C++ standard name.
> Professor Dog Schmidt can raise millions dollar  for his CORBA C++
> implementation, I cannot image why C++ standard committee cannot raise
> the amount money.  There are plenty resource here, considering
> National Science Foundation, government agencies, larg corporations.
> If you haven't try, how so sure that is joking?  If C++ standard
> committee allow me to represent her to raise money, I am more glad to
> do so.

I don't think you are joking and I don't think you are trolling, but I
do think you might be underestimating the problem. The NSF, etc. funds
research in fairly well specified areas. Standardization of an "old"
language is a very long stretch.

In general, it is hard, but possible, to gain money for research -
especially for research that's seen as visionary. It is relatively
easy to get funding for development, provided you can promise a
specific product for a specific company next year; fundamental tools
such as languages and compilers are harder to fund, and note that
standards work benefits everybody - incl. the funder's competition. It
is even more easy to get funding for marketing to enhance the
perceived value of an existing product. Getting significant support
for a key part of the existing infrastructure is *hard*, getting
support for changing that is even harder.

I'm sure the committee would be happy to raise money if there was a
good reason to believe that the effort had a good chance of
succeeding. However, I doubt any of us would spend much of the
precious time left for standardization after our "day job" is done for
chasing a port of gold at the end of a rainbow. The obvious question
is: "what's your track record? how many millions have you raised? for
which purposes? and for what span of time?"


> You misunderstood my point (or I didn't represent clearly).  You have
> to funding the project.  Professors get prompted based on two facts:
> funding and research papers.  When a professor get funding, he/she can
> hire PhD students to do the research and write papers based on the
> results of the research.  C++ standard committee can select 3-5
> projects every year.  Then let Universities, research institutions, or
> individuals to bid the project.  This process is cheap because
> professors are paid by University.  The funding is to pay for PhD
> student's tuitions.  I bet there are a lot of professors will bid for
> the project.  If a professor cannot get funding, he/she will never get
> prompted.

If we have funding, the next barrier must be faced: Professors and
students are rarely competent at judging, let alone making decisions
on the evolution of real-world tools. Most have never seen a
real-world program. Knowing in which direction to turn to make
progress without doing damage like a bull in a china shop is a real
problem, maybe the harderst in the context of C++ standardization.
Assuming the professors and students could get paid, then what? One
problem would be that they would have to consider what kinds of work
leads to PhDs and tenure. Development works doesn't do much for that.
Much of the essential work on the standard would destroy academic
careers. This leaves the work to industry people, tenured professors,
and the brave few who is wiling to bet their career.

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

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

s_googlegroups@nedprod.com (Niall Douglas) writes:
[snip]
> What I've been saying: The previously outlined (and traditional)
> process is inefficient because it makes no use of the large body of
> programmers out there ready to volunteer their time to "patching" the
> standard just like any piece of free software. Such people have little
> wish to involve themselves in the intricaces of the standard, the
> standardisation process nor even this newsgroup and most especially
> physically attending conferences. They want short duration quick in &
> out self-contained mini-projects.

However there are many interdependencies within the standard. E.g.,
    the presence of overloading necessitates ADL. As far as the core
    langauge is concerned, it is hard to see how there can be 'short
    duration quick in & out self-contained mini-projects'

> While they aren't adverse to writing
> prose, they'd far prefer to write code.

Maybe there should be an organization encouraging the implementation
    of proposed features whose specification is sufficiently clear?


>
> We know from complexity theory & software management theory that
> debugging software, unlike any other part of generating software, is
> very parallelisable.

The 'debugging' part of standardization is sumbission of issues with
    the standard as described by
    http://www.jamesd.demon.co.uk/csc/faq.html#B15  (by the way, I
    could have sworn there was a description of how to open an issue
    with the standard on the wg21 web site, but I cannot find it!).

The process for submitting a DR is about as open as it can
    get. (However, like nearly all aspects of standardization, sadly
    it is not getting communicated to the majority of the C++
    comunity. ) The only non-open part I can see is that the standard
    itself has unfortunate copying restricions on it.

> If you view "C++" as a two dimensional graph
> where the left is the ISO C++ standard text and the right is the
> implementation of the same in code, one quickly realises that small
> obvious features are nearly pure software.

IMO, at least as far as the core language is, there are no 'small
    obvious features'. Whatever is added must have some interaction
    with the numerous complex features already in place, and some of
    those interactions will be subtle (Two examples: (a) Constructor
    syntax and the most 'vexing parse', and (b) namespaces and ADL.),
    and will require understanding the intricacies of the C++
    standard to design and to implement.

> Therefore the debugging of same can be parallelised.

To a certain extent, the debugging of the C++ standard has already
    been parallelised. It could be better parallelised if more of the
    C++ community was aware of the standardization process.

> Therefore if more "out in the wild" experience is needed, this is an
> area ripe for improvement by applying the same methodologies free
> software production methodologies have shown so successful. Obviously
> how well such methodologies work is directly proportional to how far
> "right" the subject matter is on the left-right graph - if it gets too
> far left, it'll break down and become useless.
>
> Hence me suggesting it's only suitable for small features which
> everyone agrees on the general form thereof ie; very right side of the
> graph. And small, so they have the least interaction with other
> features and thus unwanted knock-on effects.
[snip]

I think these kinds of features, where they can be found, are
    confined to potential standard library features, and exclude
    potential core language features. Note that Boost focuses on
    library features.

For potential standard library features, Boost serves as a de facto
    instance of the very open source methodologies you seem to wish
    for.

IOWs, much of what you ask for *already exists*, but it isn't well
    advertised.

---
[ 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) wrote in message news:<opr8zw0yfhy9klrv@news.iol.ie>...
> On Wed, 2 Jun 2004 19:12:07 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
>
> > As I mentioned in other responses to Niall, we are actually working on
> > ways to make it more efficient.  In fact *I* in particular have
> > expended a great deal of time and energy in that quest.  If you had
> > any idea how difficult it can be to get a committee to even agree on
> > informal processes for making progress between meetings, you'd be a
> > lot more sympathetic to our efforts.
>
> ...
>
> Now I can't make you all do this - so far it would seem you
> all are totally opposed to any possibility of change whatsoever and won't
> even tolerate discussion about it - but then change is hard.

Uhm, I think you're making a lot of accusations to the people of this
group, that simply isn't true. The first quote above from Dave is from
the _same_ posting, and yet you claim "it would seem you all are
totally opposed to any possibility of change whatsoever and won't even
tolerate discussion about it".

The way I read Dave's posting, is the complete opposite: A desire to
improve things, and I haven't seen anything about not tolerating a
discussion about it.

Where do you get this impression from? I haven't seen any sign of it
at all. Could you be reading something into the postings, that isn't
actually there? You mentioned there might be a culture clash, and that
there could be talking on cross-purposes. Because of this, it's extra
important not to assume something that might not be the case, and
thereby risking insulting possibly a lot of people.

I think you should either point to actual quotes backing up your above
claim, or apologise for it, because with this way of discussing - what
I consider personal attacks - you risk alienating people, and making
them stop listening to you.

This is well meant, to try to help you avoiding pissing people off.
That is, if you do care about that. It certainly won't help your
cause.

Regards,

Terje

---
[ 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, 2 Jun 2004 19:12:07 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
>
> We can all agree I think that we'd all like the standardisation
> process to move more quickly.

Yes, but I'm not sure we all agree on what we mean by that.  For
example, I don't think we should be publishing new official C++
standards every year or two.

> In particular, I and some of the experts would agree that more
> testing of proposed features "out in the wild" is especially
> desireable. The most recent friction has arisen due to strongly
> differing opinions on how to add manpower to the process.

I don't want to add manpower.  In some cases the problem is too much
manpower ;-)

We actually have a problem with maximizing the effectiveness of those
who already have the time and energy to participate.

>  From my understanding of what the experts think: Volunteers should
>  subscribe to industry magazines and should attend where possible the
>  six monthly conferences. They should participate in creating of
>  amendments to the standard either through writing one themselves
>  either alone or in conjunction with others and through reviewing,
>  pondering and discussing amongst themselves any pitfalls or
>  contraindications which may arise both within each proposal and
>  between proposals.

Or through generating proof-of-concept implementations.

> What I've been saying: The previously outlined (and traditional)
> process is inefficient because it makes no use of the large body of
> programmers out there ready to volunteer their time to "patching" the
> standard just like any piece of free software.

As you rightly point out below, the standard can't be patched "just
like any piece of free software."

> Such people have little wish to involve themselves in the intricaces
> of the standard

If you're not willing to involve yourself in the intricacies, you're
in no position to write new standard text.

> the standardisation process nor even this newsgroup and most
> especially physically attending conferences. They want short
> duration quick in & out self-contained mini-projects. While they
> aren't adverse to writing prose, they'd far prefer to write code.

But the standard isn't code.  Now it sounds like you're talking about
patching some code...  but we don't have a standard C++ reference
implementation.

> We know from complexity theory & software management theory that
> debugging software, unlike any other part of generating software, is
> very parallelisable. If you view "C++" as a two dimensional graph
> where the left is the ISO C++ standard text and the right is the
> implementation of the same in code, one quickly realises that small
> obvious features are nearly pure software.

I certainly don't realize that.

First of all, please name *one* "small obvious feature" so that we can
get this discussion off the level of your assumptions that probably
are false.  I've never seen one.  Then name two more of same so we
can get the idea that there are enough to warrant new bureaucratic
structures and whatever else you're asking for.

Second, the smallest and most-obvious features seem to me to be about
80-90% proposal and deliberation.

> Therefore the debugging of same can be parallelised.
>
> Therefore if more "out in the wild" experience is needed, this is an
> area ripe for improvement by applying the same methodologies free
> software production methodologies have shown so
> successful. Obviously how well such methodologies work is directly
> proportional to how far "right" the subject matter is on the
> left-right graph - if it gets too far left, it'll break down and
> become useless.

?? I thought you said the graph was 2-D?

>> You know, what you're describing is very much like the open-source
>> qdevelopment process, where the mantra from maintainers to those who
>> want major changes that the maintainer has no time to implement is,
>> "patches welcomed".  It's hard to understand why anyone would find
>> the same response insulting in the context of C++ standardization.
>
> Thing is, the ISO C++ standard is not a piece of software. Applying
> what you yourself and others suggested of "go do it yourself" can be
> shown historically to be most inefficable - for one thing, I have no
> ability to fork because forking is totally anti the whole point of
> having a standard (ie; most of the "value" of C++ is that it's
> *standard*). If one reads economic theory on information (I suggest
> "Information Rules" by Shapiro and Varian), it's clear that ad-hoc
> dispersed development of standards is a real no-no as indeed ISO's
> own guidelines suggest - there MUST be a centralised authority on
> all matters.

That's just wrong.  There is not today a "centralised authority on all
matters".  There is only a body voting on matters of which text ends
up in the standard.

As I said in an earlier post (which doesn't seem to be showing up),
when I made the first proof-of-concept for exception safety in the
standard library, I didn't ask for anyone's permission or blessing
first, nor did I ask the committee to set up less "primitive use of
the internet", or any of the other things you've been complaining
about.  I just did it.  It was taken seriously to the extent that it
was good, solid work.

You don't need a "centralised authority" to coordinate your efforts
either.  You've been told repeatedly that making proofs-of-concept
for proposed features (like move/forwarding --- please do it!) would
be very helpful.  You're response was basically, "why should I
believe you?"  Well, I give up.  As Terje implied, you should either
do something or stop complaining.

> That's why I see no point in working alone on this, or indeed
> anything less than a substantial number of people being
> involved.

Then it's up to you to recruit those other people.  They're not going
to volunteer to work with you just because some committee "decrees"
it -- even if we *were* to make such decrees.

> Standards are valuable because they increase interoperability &
> predictability in an uncertain world which lowers costs & everyone
> benefits. Anything which works against that will ossify as it's
> against the natural order of things - think of it like an economic
> environment where making a profit kills your company (eg; like a
> department in a university - if it doesn't go over budget, it will
> have its budget cut).

Your analogy makes no sense to me.

> The whole point of what I am saying is that by investing work now
> you can save yourselves oodles of work in the future ie; you must
> spend money to save money. Now I can't make you all do this - so far
> it would seem you all are totally opposed to any possibility of
> change whatsoever

You really haven't been reading the responses to your posts, have you?
Didn't you see the part where I wrote

    "we are actually working on ways to make it more efficient.  In
    fact *I* in particular have expended a great deal of time and
    energy in thatquest"

??

Is that not utterly inconsistent with the idea that we "all are
totally opposed to change"?

Oh, you even quoted it in your own posting.  You should really try
harder to integrate the information that's staring you in the face
before you post.

> and won't even tolerate discussion about it

Just stop it now.  The only discussion that's not well-tolerated by me
is baseless accusation that "discussion isn't tolerated".

> Also, you guys must yourselves invest this time - if you try and
> push it off onto other people

Nobody's pushing it off.  If you want it, make it happen.

> then it loses legitimacy. Your names are half of what makes the C++
> standard what it is - I can count off the top of my head at least
> ten experts by name simply because they have written articles in CUJ
> or MSDN - and when they themselves do something it is like a nexus
> and with them everyone else turns.  The name "Niall Douglas" thus
> far means nothing to anyone

It's beginning to mean something.

> and what I do has no effect on others whatsoever - hence me doing
> something as you all have proposed is pointless.

Then become "an expert."  You're just making lame excuses for an
unwillingness to but your own butt on the line.  My name meant
"nothing to anyone" when I decided to try to have an impact on the C++
committee.  Nothing other than your own insistence makes you less
qualified to make a difference than anyone else.

>> As I mentioned in other responses to Niall, we are actually working on
>> ways to make it more efficient.  In fact *I* in particular have
>> expended a great deal of time and energy in that quest.  If you had
>> any idea how difficult it can be to get a committee to even agree on
>> informal processes for making progress between meetings, you'd be a
>> lot more sympathetic to our efforts.
>
> You won't know this, but I know precisely what it's like...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0406031201.e141073@posting.google.com>...
..
> > You must be joking.  Do you have the time and expertise to raise
> > several million dollars per year?  If not, why do you assume that I
> > do?  Am I being trolled here?
>
> I am not joking.  You are well underestimated C++ standard name.
> Professor Dog Schmidt can raise millions dollar  for his CORBA C++
> implementation, I cannot image why C++ standard committee cannot raise
> the amount money.  There are plenty resource here, considering
> National Science Foundation, government agencies, larg corporations.

If you believe that this can be done, the C++ standard committee would
probably welcome you with open arms, if you were to volunteer to carry
out the fund-raising activity. I think you'll quickly find out why
they haven't done this.

Also, keep in mind the golden rule: "he who has the gold, makes the
rules". As it currently stands, the C++ standard is produced under a
system that is funded mainly by sales of copies of the standard. That
means that the main financial incentive the standard organizations
have is to produce a standard that maximizes the number of people
willing to pay for a copy of it. That strikes me as a good incentive -
the best way to satisfy it is to produce a standard that is so
well-designed that it becomes widely used. Of course, it's up to those
organizations themselves to decide whether to pay attention to that
incentive, but at least it's an incentive in the right direction.

With government or corporate financing, the main financial incentive
would be to satisfy the needs of the goverment or companies providing
the financing. The interests of other users would have little or no
financial significance.

---
[ 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 <Pine.GSO.4.58.0406032357140.25970@unix.cs.tamu.edu>, Gabriel
Dos Reis <gdr@cs.tamu.edu> writes
>We need more education, more exposure. We need better tools to support
>development in C++.

Yes, and we also need better education. That is why I am canvassing for
a technical report on teaching C++. Nothing large but as well as advice
on how C++ should be taught it could include several small APIs
specifically to allow teaching to include some graphics, keyboard, mouse
and sound. None of these are necessary for professional programmers but
each significantly adds to the potential for more positive teaching.



--
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 Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
<llewelly.at@xmission.dot.com> wrote:

>> What I've been saying: The previously outlined (and traditional)
>> process is inefficient because it makes no use of the large body of
>> programmers out there ready to volunteer their time to "patching" the
>> standard just like any piece of free software. Such people have little
>> wish to involve themselves in the intricaces of the standard, the
>> standardisation process nor even this newsgroup and most especially
>> physically attending conferences. They want short duration quick in &
>> out self-contained mini-projects.
>
> However there are many interdependencies within the standard. E.g.,
>     the presence of overloading necessitates ADL. As far as the core
>     langauge is concerned, it is hard to see how there can be 'short
>     duration quick in & out self-contained mini-projects'

I disagree. Computer software programming is basically an exercise in
manipulating complexity. Therefore the requisite computer programming
skills of being able to hold in your mind all parts of a computer program
and the likely "ripple" effect of a change is well developed by necessity
within computer programmers.

Remember, I am not saying that core language changes should be directly
entered by this process I outline. I am saying that the implementation
experience core language changes require could be outsourced who then from
that experience return their findings to the ISO C++ committee stage. This
would allow "fast tracking" of such features into the standard but with
adequate vetting by the existing ISO processes beforehand.

>> While they aren't adverse to writing
>> prose, they'd far prefer to write code.
>
> Maybe there should be an organization encouraging the implementation
>     of proposed features whose specification is sufficiently clear?

There appears to be a huge gulf between what the experts in this newsgroup
view as a small obvious feature and what I do. While the likelihood is
that I am wrong as I am the one with the least experience, I also am
probably quite different from you guys in viewing software generation as a
mostly organic process ie; there is very little initial planning and the
design "grows" during the implementation of the project. By implementing
in a highly modular fashion, one can cut out sections and replace them if
hindsight shows you were wrong. Or indeed, occasionally, one trashes the
software and begins again afresh.

You can really break your balls trying to design something of which you
have no implementation experience. You can labour, and labour, and labour
some more and you'll still cock it up. The reality is that core language
design is particularly prone to this problem - it's not like a library
where you can try out different solutions in your own time to decide on
the best one before changing the standard. I'm saying though that this
ability could be integrated into core language updates ie; introduce an
"evolutionary" element where feature specifics are designed organically
through experience.

To exhibit the potential of this way of doing things, compare typical
C++ libraries of ten or even five years ago against modern ones. Previous
C++ libraries were not exception safe, had numerous bad practices and the
poor quality of these contributed greatly to the poor name C++ holds in
academia. However through experience, modern C++ libraries have evolved
into high quality solutions - as robust, secure and efficient as those in
any other language.

> I think these kinds of features, where they can be found, are
>     confined to potential standard library features, and exclude
>     potential core language features. Note that Boost focuses on
>     library features.

You are one of many who have said this. Yet apart from some initial
comments about how I feel the STL could be improved, I have since focused
entirely on language features. It is interesting how people understand
something different from what I write, but then most have dismissed all my
arguments out of hand as the blatherings of a nincombpoop.

> For potential standard library features, Boost serves as a de facto
>     instance of the very open source methodologies you seem to wish
>     for.
>
> IOWs, much of what you ask for *already exists*, but it isn't well
>     advertised.

A library can only do what the core language permits. As experiments have
shown, implementing move semantics using existing language features is
unwieldy at best and dangerous at worst. Implementing dynamic library
support without new language features produces highly inefficient code,
hence some major compilers adding new keywords. Metaprogramming is
probably the best example at the same time of both how powerful
C++ templates are while at the same time how limited the language is in
direct support of the same.

There are core language updates obvious to anyone with any experience of
C++ which could be added within no more than a year. Their details need
not be designed as they can be evolved. I am certain of it.

I am not here to talk about libraries - if there's something I don't like
I go write it on my own and don't waste time posting in here. I am talking
exclusively about core language features whose lack thereof is limiting my
ability to get on with things - hence my efforts within here. Even if I am
booed off the stage as a malcontent, maybe I at least will sow
subconscious seeds which will sprout in the future.

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                       ]

s_googlegroups@nedprod.com (Niall Douglas) writes:

 On Mon, 31 May 2004 01:52:53 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
>
>>> I could however go patch GCC to add move constructors though
>>> unfortunately the GCC maintainers would not accept such a patch into
>>> the mainline as the standard hasn't ruled on it yet.
>>
>> I'm not sure that's a foregone conclusion. GCC already contains
>> numerous extensions beyond the official C/C++ language standards. I
>> think the libstdc++-v3 developers might welcome the opportunity to use
>> move/forwarding, too.
>
> I base that on what they said to me in response to suggestions I
> made. I understand it - I'd do the same if I were them.

Given the way you've misread peoples' responses to you in this thread
message, I don't know whether to think they actually said that, or it's
just your misinterpretation of some entirely different message.

>> You don't need a "fast track mechanism" in order to pursue that
>> course. Demonstrating implementability and usefulness, and producing
>> an implementation for reference, would in itself have a huge impact on
>> getting any feature approved.
>
> Of course I could just go do this - however would it be worthwhile in
> me doing so?

Didn't I just get finished telling you so?

> If I were going it alone then there's zero reason to
> expect anyone else would participate and every reason to expect it
> would be wasted work

OK, I give up. I tried to tell you that it wouldn't go to waste, that
it would make a huge difference. If you won't take my word for it, I
don't know what more I can do.

> especially given the GCC maintainers aren't keen on it
> either. That's why such actions need official mandate

What sort of mandate would you like?

> eg; if a certain country had sought UN approval before pressing
> ahead regardless they'd have removed many of the extra hurdles they
> now face.
>
> And besides, I was suggesting that the standardisation process overall
> would be made more efficient by setting up a generic scheme like I
> outlined

Like I said before, be my guest, but...

> to fast track the uncontentious additions.

..as I and others have also said, there are no "uncontentious
additions" that it would be appropriate to approve on the time scale
you're talking about.

> It needs to be approved by the powers-that-be

Who's that, again?

> to work properly because that brings with it instant legitimacy as
> an official arm of the standardisation process. And legitimacy is
> everything here.

Legitimacy in the standardisation process is conferred by relevance
and solid work. I didn't ask anyone to set up an administrative
structure and pass an official edict before I wrote the first
exception-safe standard library components, to prove that adding
exception safety to the standard was possible and without negative
performance impacts. You don't need any of these things you're asking
for in order to get started on core feature implementation, create
momentum, get others to participate, and be taken seriously. Results
talk, and you-know-what walks.

>>> And not just me, I can see a lot of people becoming interested
>>> because now they actually can DO something - not by talking across a
>>> period of years and spending thousands of euros visiting expensive
>>> international conferences but actually sitting down and coding.
>>
>> You make it sound like coding is the "real work". Well, it's
>> important, but someone has to design the features (a job you've
>> clearly been underestimating) and generate some agreement for them.
>
> Ach, you totally misunderstand (but you're hardly alone). Go back and
> look at my previous posts - I never once said that this process should
> be for major features.

There are no minor features for which specification is unimportant.

> It could only ever work for uncontentious
> features everyone agrees are needed

But we've already told you that those basically don't exist.

> and even then, those whose approximate form is already known ie;
> those features which need "implementational experience".

*All* features can benefit hugely from implementation experience.

> The higher level stuff should remain a committee led process. I'm
> talking purely small "obvious to everyone" features - hence my use of
> "fast-trackable" to denote them. I qualified what I meant by "fast
> track" a number of times but various posters repeatedly either twisted
> my words or ignored my explanations.

Oh, please stop. That hasn't happened. You've apparently ignored
those of us who've told you that nothing's small enough to be
fast-tracked in the way you've described.

>>> We'd also need a FREE copy of the full standard to generate diffs
>>> against
>>
>> I thought you wanted to work on code, not specifications (?)
>
> The people who do the code are surely the best placed to write the
> first draft of changes given that they would know what's required the
> most?

Not neccessarily; drafting specifications is a very different skill
from coding.

>> What kind of assurance do you _normally_ get that people will take
>> your results seriously before you start a project? You didn't ask
>> for assurance before posting here...
>
> There is a huge difference between starting/forking a project and
> contributing to an existing one.

If you say so.

> Actually, after your last post before this one I was going to revanish
> again having concluded further posts would be pointless. You all may
> not realise this, but I really respect all you guys and I'm sorry I
> seemed to have annoyed you all (but then that's precisely why I avoid
> groups like this as I stated at the outset). OTOH, I have tried to
> suggest ways you all could improve things from my point of view and
> have been singularly told "either work through 'the system' or shut
> up".

Talk about twisting words. Nobody said that to you, and you should
probably apologize to the group for claiming that they did. I've been
trying to tell you that if you want to change the world you have to
put your own butt on the line. Making suggestions about what other
(volunteer) people should do is not going to make a difference,
especially when those people are part of a group with an existing way
of working. If you want to make a difference, stop telling other
people what they ought to do, and take some initiative yourself.

> Well I'm sorry for saying this, but that's not very open-minded -
> and while I may be wrong, or be the 200th person to suggest the same,
> this angry "to question my actions is to insult me" attitude reminds
> me of the unproductive academic clique typical in most universities
> (please note Dave I am not saying this of you specifically - I have
> the very highest of regard for you - but generally of the majority of
> responses I have received).

Well, I've been as hard on you as anyone here, so it's hard to
imagine what you're referring to.

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

| We need more education, more exposure. We need better tools to support
| development in C++.

which tools are you talking about?

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                       ]

In article <opr83h12iiy9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>There are core language updates obvious to anyone with any experience
>of C++ which could be added within no more than a year. Their details
>need not be designed as they can be evolved. I am certain of it.

Name one. All the experience I have says that they do not exist. Please
note that I specialise in trying to identify small changes, additions
etc. that would make C++ more usable yet I have never managed to come up
with a single change that has no ramifications elsewhere.

--
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) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...
> On Fri, 4 Jun 2004 16:06:13 +0000 (UTC), llewelly
> <llewelly.at@xmission.dot.com> wrote:
>
> Remember, I am not saying that core language changes should be directly
> entered by this process I outline. I am saying that the implementation
> experience core language changes require could be outsourced who then from
> that experience return their findings to the ISO C++ committee stage. This
> would allow "fast tracking" of such features into the standard but with
> adequate vetting by the existing ISO processes beforehand.

This already exists! The STL is one example. By producing a working
proof of the concept, it was included into the standard, at a point
where, as I understand it, the attitude was to stop adding to the
standard and finishing it.

This is a library change, and you've said you're talking about core
language changed, but I would think the situation isn't much different
there. By creating a proof of concept, a proposal stands a much better
chance of being taken seriously, and might be processed faster (as the
"implementability"-part has been demonstrated).

> There appears to be a huge gulf between what the experts in this newsgroup
> view as a small obvious feature and what I do. While the likelihood is
> that I am wrong as I am the one with the least experience, I also am
> probably quite different from you guys in viewing software generation as a
> mostly organic process ie; there is very little initial planning and the
> design "grows" during the implementation of the project. By implementing
> in a highly modular fashion, one can cut out sections and replace them if
> hindsight shows you were wrong. Or indeed, occasionally, one trashes the
> software and begins again afresh.
>
> You can really break your balls trying to design something of which you
> have no implementation experience. You can labour, and labour, and labour
> some more and you'll still cock it up. The reality is that core language
> design is particularly prone to this problem - it's not like a library
> where you can try out different solutions in your own time to decide on
> the best one before changing the standard. I'm saying though that this
> ability could be integrated into core language updates ie; introduce an
> "evolutionary" element where feature specifics are designed organically
> through experience.

I think you'll find that many in this group (myself included), are
passionate about agile/evolutionary development. However, a standard
needs stability to be taken seriously. As you've probably heard,
there's millions of lines of code out there, and if you constantly
change the standard, possibly breaking a lot of it, then you get a
huge problem.

In short, agile/evolutionary/organic development is a great idea, but
you have to consider the context.

This doesn't mean that this approach can't be used to develop proof of
concepts of proposals, or, in the case of libraries, high-quality
libraries. You say this last point yourself, later in the posting.

> There are core language updates obvious to anyone with any experience of
> C++ which could be added within no more than a year. Their details need
> not be designed as they can be evolved. I am certain of it.

As Dave said in his posting: Name one.

There's been a lot of abstract discussion, here, and hardly any
concrete examples. Let's do it in the spirit of agile development, and
get down to the concrete stuff. :)

That'll get us something real to consider.

> Even if I am
> booed off the stage as a malcontent, maybe I at least will sow
> subconscious seeds which will sprout in the future.

So far, I haven't seen anything that could have that effect.

Regards,

Terje

---
[ 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 Fri, 4 Jun 2004 16:09:58 +0000 (UTC), David Abrahams
<dave@boost-consulting.com> wrote:
=
>> We can all agree I think that we'd all like the standardisation
>> process to move more quickly.
>
> Yes, but I'm not sure we all agree on what we mean by that.  For
> example, I don't think we should be publishing new official C++
> standards every year or two.

I see no problem with one major release every three years with two point
releases in between on a yearly basis. I base this on the cycle of
computing roughly iterating along multiples of 18 months due to Moore's
prediction. Interestingly, software in general seems to follow a similar
pattern when in a competitive environment.

I've seen a general view that C++ must not change too quickly. I
completely agree. However I would view major releases as the ONLY ones
which can break existing code - the point releases can not under any
circumstance change anything, they may only augment.

Anyone familiar with maintaining a library's ABI will know exactly what I
mean here.

>> In particular, I and some of the experts would agree that more
>> testing of proposed features "out in the wild" is especially
>> desireable. The most recent friction has arisen due to strongly
>> differing opinions on how to add manpower to the process.
>
> I don't want to add manpower.  In some cases the problem is too much
> manpower ;-)
>
> We actually have a problem with maximizing the effectiveness of those
> who already have the time and energy to participate.

Ah, precisely the core of the problem I am suggesting solutions for! All
organic life in this universe organises itself - you merely need to create
an environment which fosters that self-organisation and the rest flows
 from within under its own power. I'm sure Dave you have read books by Fred
P. Brookes and witnessed the remarkable self-organising enabler of the
internet?

>> the standardisation process nor even this newsgroup and most
>> especially physically attending conferences. They want short
>> duration quick in & out self-contained mini-projects. While they
>> aren't adverse to writing prose, they'd far prefer to write code.
>
> But the standard isn't code.  Now it sounds like you're talking about
> patching some code...  but we don't have a standard C++ reference
> implementation.

But then I'm not proposing the patching of the standard directly. The
committee is the only one able to do this and indeed should do this.

This isn't to say it can't be helped along. For example, if government
wants a new law they can either draft one themselves, form a committee to
do so or ask someone external to provide one eg; a trade body or even the
public. It's hardly unknown for a vested interest to write the bill in its
entirity and pass it to a government minister who then presents it as
their own.

You guys propose an amendment as you already do. If it's reasonably small
and could be patched into existing compilers relatively easy you submit it
to the Bugzilla database and on to some front web page. Volunteers create
a patch implementing it for (say) GCC. Other volunteers apply this patch,
add support to their code and test it, refining the patch through comments
and further patches ie; evolutionary.

One month before the biannual meeting of the ISO C++ committee reports on
the progress of the real-world testing of the amendment are generated. You
guys at the committee meeting review them and after you feel you have a
handle on it, you generate a proposed amendment to the standard which is
posted again on the Bugzilla database for review. Or perhaps a volunteer
writes a proposed amendment which you guys review which saves you a step.
Either way, all roads still eventually lead through the traditional ISO
C++ committee.

What you gain and you are currently lacking is an army of volunteers who
put your ideas into practice so you can see the end results and thus can
both prevent mistakes and considerably shorten the time required for
finalising the form of new features.

I've spelt this out in index bulleted points in my post to Francis
Glassborow.

>> If you view "C++" as a two dimensional graph
>> where the left is the ISO C++ standard text and the right is the
>> implementation of the same in code, one quickly realises that small
>> obvious features are nearly pure software.
>
> I certainly don't realize that.
>
> First of all, please name *one* "small obvious feature" so that we can
> get this discussion off the level of your assumptions that probably
> are false.  I've never seen one.  Then name two more of same so we
> can get the idea that there are enough to warrant new bureaucratic
> structures and whatever else you're asking for.

As we've discussed them already, how about two: (i) move constructors and
(ii) dynamic library support. How both should work any C++ programmer of
any experience will have an automatic instinct for.

I also am not asking for bureaucratic structures! After an initial
expenditure of effort, the system I am proposing should be nearly
self-operating and should consume virtually none of any committee member's
time. In fact, it should save substantial amounts of committee time! Why
do software projects run Bugzilla or something like it if this weren't the
case?

> Second, the smallest and most-obvious features seem to me to be about
> 80-90% proposal and deliberation.

I said this in the post I made to llewelly just before this one, but
manipulating large complex abstract sets of intertwined relationships is
precisely what computer programming is. From this viewpoint, the standard
is no different - changes will have a ripple effect which will require
mitigatory measures. Designing with little or no implementational
experience is extremely tough with a high rate of failure - therefore take
a superior approach and get yourself implementational experience - evolve
your design through practice.

Of course you yourself Dave will strongly disagree with this sentiment -
just as we disagreed on c++-sig all those months ago (it's the same core
argument). However ponder this - could you have possibly written
Boost.Python v2 without having gone through writing Boost.Python v1 first?

>> there MUST be a centralised authority on
>> all matters.
>
> That's just wrong.  There is not today a "centralised authority on all
> matters".  There is only a body voting on matters of which text ends
> up in the standard.

A centralised authority doesn't need a name nor mandate. It simply needs
to be observed by enough people and it becomes so.

No matter how chaotic and decentralised you might think the
C++ standardisation process is, it is still highly hierarchical. I know of
no compiler vendor who is busy augmenting C++ with their own features as
vendors have become burned by that in the past - the D language is the
closest thing I know to it but it's distinctly non-commercial. Like it or
not, every compiler vendor has their eyes turned towards the standard and
thus every C++ programmer is similarly though indirectly the same.

You are a centralised authority.

> As I said in an earlier post (which doesn't seem to be showing up),
> when I made the first proof-of-concept for exception safety in the
> standard library, I didn't ask for anyone's permission or blessing
> first, nor did I ask the committee to set up less "primitive use of
> the internet", or any of the other things you've been complaining
> about.  I just did it.  It was taken seriously to the extent that it
> was good, solid work.

As I've explained in other posts, third party libraries are quite
something different to core language features. And I'll be getting back to
you on good solid work done without anyone's permission or blessing first
in a few months time though it'll be in a field quite unrelated to C++.

>     "we are actually working on ways to make it more efficient.  In
>     fact *I* in particular have expended a great deal of time and
>     energy in thatquest"
>
> Is that not utterly inconsistent with the idea that we "all are
> totally opposed to change"?

I used the phrase "you all" as using "ye" isn't Queen's English anymore. I
meant the plural form of "you" which by definition doesn't mean everyone.

In fact Dave, the way you've phrased your replies has been the most
productive of all which is why I keep replying to your posts in
particular. We may or may not be making progress - I don't know, we'll
know next few posts.

>> and what I do has no effect on others whatsoever - hence me doing
>> something as you all have proposed is pointless.
>
> Then become "an expert."  You're just making lame excuses for an
> unwillingness to but your own butt on the line.  My name meant
> "nothing to anyone" when I decided to try to have an impact on the C++
> committee.  Nothing other than your own insistence makes you less
> qualified to make a difference than anyone else.

There is so much wrong with this statement I don't know where to begin. I
could indeed write this length of post just about why your statements here
are totally incorrect and worse, are dangerous forms of thinking (see
books by Alain de Boton). However, it would be distinctly off-topic
despite being relevent so I will condense it heavily:-

Experts don't become, they are made - just like no president of the United
States didn't come from a privileged background. Experts become recognised
as such because they came up with the goods at the right place & time on
one or more occasions - in your case, an exception safe STL just when
people were wondering if it were possible within a timeframe when doing so
got widespread notice. If any of these factors had been out you would be
as anonymous as I am, just as Einstein would be unknown if he had deduced
relativity either before or after when he did. All actions are more a
product of the culture & society in which the person is born than any
characteristic or achievement of that individual themselves. I know this
reality will be alarming to anyone raised in a capitalist system where the
false motivator of individual potential reigns supreme, but it is so
nevertheless.

If you create an environment which *enables* something you desire then it
will come about with no micro-managing required. *I* cannot create such an
environment because I do not have the authority to do so - therefore I
would have to both create myself as an authority and create the
environment at the same time which is very much harder. If I were to press
ahead alone, how could I issue press statements to media outlets in the
name of the ISO C++ committee calling for volunteers to implement an
amendment? How could I even run a website officially endorsed by the ISO
C++ committee? *I* can't do any of this, but a person entitled by mandate
of the central authority CAN and that's why it's pointless for me to do
this alone.

I have "placed my butt on the line" on numerous occasions but only when I
felt it was worth doing so in the long run. Feel free to search the
internet and trawl up the good and bad of my history much of which is in
the public domain. I know I cannot ever contribute anything useful to
C++ as the standardisation process currently stands so I do not delude
myself into thinking otherwise - far better to concentrate on other areas
where I could make a difference. After all, the total capacity for human
output is quite finite!

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 Sat, 5 Jun 2004 17:11:39 +0000 (UTC), Terje Sletteb?
<tslettebo@hotmail.com> wrote:

> I think you'll find that many in this group (myself included), are
> passionate about agile/evolutionary development. However, a standard
> needs stability to be taken seriously. As you've probably heard,
> there's millions of lines of code out there, and if you constantly
> change the standard, possibly breaking a lot of it, then you get a
> huge problem.

Handy thing about having a patched compiler is people can try compiling
their software on it themselves to see if it breaks their code before it
becomes part of the standard.

> In short, agile/evolutionary/organic development is a great idea, but
> you have to consider the context.

Seeing as you're agreeing with me that this is the best way to quickly
develop new core language features, why not go all the way and agree that
an easily accessible formalised mostly-automatic mechanism for processing
these would be of great benefit to all concerned?

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                       ]

>> There are core language updates obvious to anyone with any experience
>> of C++ which could be added within no more than a year. Their details
>> need not be designed as they can be evolved. I am certain of it.
>
> Name one. All the experience I have says that they do not exist. Please
> note that I specialise in trying to identify small changes, additions
> etc. that would make C++ more usable yet I have never managed to come up
> with a single change that has no ramifications elsewhere.

My whole point is that the ramifications you speak of can be identified
far more quickly with an improved process better utilising the resources
available. Ideally, a proposed revised standard could be tested in its
entirity by producing a test compiler implementing the new core language
before it was actually adopted as the standard.

While ideal, I can't see that happening without significant quantities of
additional funding and there's little commercial point in investing in
C++. However for smaller easier to implement features it should be
possible with volunteer time alone.

Here's an imaginary timeline:

1. Core language change proposed. Let's take N1377 as an example.
2. N1377 could be patched into GCC reasonably easily. Therefore it is
farmed out into a Bugzilla database. A call for volunteers is issued via a
mailing list and an announcement placed in slashdot etc.
3. Volunteers generate patch for GCC implementing N1377.
4. Volunteers download patch for GCC implementing N1377, patch their GCC,
add in support for move constructors to their code and test. Report
problems back to the Bugzilla database.
5. From feedback/contributions, patch is refined.
6. Iterate steps 4 & 5 repeatedly.
7. When patch is stable and everyone is happy, volunteers generate a
proposed amendment to the standard using the experience gained of the
ramifications, pitfalls and other issues. Proposed amendment/report goes
to next six-monthly ISO C++ committee.
8. Committee attendees review amendment/report. If they see no
contraindications with other proposed features it gets added via fast
track process. If there may be issues, they can defer addition in lieu of
new information, amend it or do whatever.

N1377 would surely take less than six months from beginning to working
implementation in GCC. Even if contraindications were found and dealt
with, it couldn't take longer than one year. Hence my original statement
above.

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                       ]

s_googlegroups@nedprod.com (Niall Douglas) wrote in message news:<opr83h12iiy9klrv@news.iol.ie>...

> There are core language updates obvious to anyone with any experience of
> C++ which could be added within no more than a year. Their details need
> not be designed as they can be evolved. I am certain of it.

So, let's get down to specifics, taking move semantics for example (or
pick another feature; I don't care).  What are you proposing, that the
committee say "we're going to have move semantics", without nailing
down precisely what that means or how it works?  And then what?  We
put that phrase in the working paper, and as people find problems with
the fact that it has no meaning, we make evolutionary adjustments
until everyone can agree that it's well-specified and works with the
rest of the standard text?

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

In article <opr85eqzoly9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>>> There are core language updates obvious to anyone with any
>>>experience  of C++ which could be added within no more than a year.
>>>Their details  need not be designed as they can be evolved. I am
>>>certain of it.
>>
>> Name one. All the experience I have says that they do not exist.
>>Please  note that I specialise in trying to identify small changes,
>>additions  etc. that would make C++ more usable yet I have never
>>managed to come up  with a single change that has no ramifications
>>elsewhere.
>
>My whole point is that the ramifications you speak of can be identified
>far more quickly with an improved process better utilising the
>resources available. Ideally, a proposed revised standard could be
>tested in its entirity by producing a test compiler implementing the
>new core language before it was actually adopted as the standard.
>
>While ideal, I can't see that happening without significant quantities
>of additional funding and there's little commercial point in investing
>in C++. However for smaller easier to implement features it should be
>possible with volunteer time alone.
>
>Here's an imaginary timeline:
>
>1. Core language change proposed. Let's take N1377 as an example.
>2. N1377 could be patched into GCC reasonably easily. Therefore it is
>farmed out into a Bugzilla database. A call for volunteers is issued
>via a mailing list and an announcement placed in slashdot etc.
>3. Volunteers generate patch for GCC implementing N1377.
>4. Volunteers download patch for GCC implementing N1377, patch their
>GCC, add in support for move constructors to their code and test.
>Report problems back to the Bugzilla database.
>5. From feedback/contributions, patch is refined.
>6. Iterate steps 4 & 5 repeatedly.
>7. When patch is stable and everyone is happy, volunteers generate a
>proposed amendment to the standard using the experience gained of the
>ramifications, pitfalls and other issues. Proposed amendment/report
>goes to next six-monthly ISO C++ committee.
>8. Committee attendees review amendment/report. If they see no
>contraindications with other proposed features it gets added via fast
>track process. If there may be issues, they can defer addition in lieu
>of new information, amend it or do whatever.
>
>N1377 would surely take less than six months from beginning to working
>implementation in GCC. Even if contraindications were found and dealt
>with, it couldn't take longer than one year. Hence my original
>statement above.


That is it. I see absolutely no point in reading any more of your posts.
You have absolutely no idea about how complex a change such as
introducing move semantics is. Note that there have been some very
bright and exceptionally talented compiler implementors involved in
working on move semantics and yet you seem to think that they are just
dragging their feet when they tell you that it is just not that simple.

WG21 has many people serving on it who know a great deal about managing
change but you seem to be convinced that you know better than all of
them. Fine go away and do the work and prove us wrong but please do not
waste our time by telling us that we do not understand the process of
language development. Or do you think that you have unique insights that
the rest of us lack?


--
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 <opr85eqly0y9klrv@news.iol.ie>, Niall Douglas
<s_googlegroups@nedprod.com> writes
>As we've discussed them already, how about two: (i) move constructors
>and (ii) dynamic library support. How both should work any C++
>programmer of any experience will have an automatic instinct for.

Yes and every single one will have a different view. Move semantics is
fairly tough, none of us have any idea about how to reconcile the
approaches of two major OSs as regards dynamic libraries. If you think
otherwise then please sit down and write a paper explaining how we
should do it because at the moment we are struggling.



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

> Here's an imaginary timeline:
>
> 1. Core language change proposed. Let's take N1377 as an example.
> 2. N1377 could be patched into GCC reasonably easily. Therefore it is
>    farmed out into a Bugzilla database. A call for volunteers is
>    issued via a mailing list and an announcement placed in slashdot
>    etc.
> 3. Volunteers generate patch for GCC implementing N1377.
> 4. Volunteers download patch for GCC implementing N1377, patch their
>    GCC, add in support for move constructors to their code and
>    test. Report problems back to the Bugzilla database.
> 5. From feedback/contributions, patch is refined.
> 6. Iterate steps 4 & 5 repeatedly.
> 7. When patch is stable and everyone is happy, volunteers generate a
>    proposed amendment to the standard using the experience gained of
>    the ramifications, pitfalls and other issues. Proposed
>    amendment/report goes to next six-monthly ISO C++ committee.
> 8. Committee attendees review amendment/report. If they see no
>    contraindications with other proposed features it gets added via
>    fast track process. If there may be issues, they can defer addition
>    in lieu of new information, amend it or do whatever.
>
> N1377 would surely take less than six months from beginning to
> working implementation in GCC.  Even if contraindications were found
> and dealt with, it couldn't take longer than one year. Hence my
> original statement above.

Now remind us again please why you can't set up a bug database and
issue a call for volunteers here, thereby beginning this process?  I
think you could get this whole thing started in a SourceForge project
in a few hours with absolutely no financial investment.

Boost was started without any official sanction from the committee or
any other investment from the committee per se.  In the beginning it
was nothing more than a mailing list on egroups (now yahoogroups).
What you're describing would fill a very similar role to the one Boost
does in the library arena.  I *know* that an effort like the one
you're describing would draw participation from interested members of
the committee, just like Boost has.

Once again:

a) It is up to those who have a clear and passionate vision of the
future to make it happen.

b) Absolutely *nothing* makes you a less-legitimate member of the C++
standardization community than anyone else, other than your saying so.

And now, I'm done with this conversation.

--
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 Fri, 4 Jun 2004 16:09:58 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
> =
>>> We can all agree I think that we'd all like the standardisation
>>> process to move more quickly.
>>
>> Yes, but I'm not sure we all agree on what we mean by that.  For
>> example, I don't think we should be publishing new official C++
>> standards every year or two.
>
> I see no problem with one major release every three years with two
> point releases in between on a yearly basis.

You don't consider the fact that most of the implementors and quite a
large community of users would be outraged to be problematic?

> I base this on the cycle of computing roughly iterating along
> multiples of 18 months due to Moore's prediction. Interestingly,
> software in general seems to follow a similar pattern when in a
> competitive environment.
>
> I've seen a general view that C++ must not change too quickly. I
> completely agree. However I would view major releases as the ONLY
> ones which can break existing code

Breaking code every three years is unthinkable.  The sentiment in the
committee at large hasn't even come around definitively to the idea of
breaking code for C++0x, a 10 year cycle.

>  - the point releases can not under any
> circumstance change anything, they may only augment.

We're barely able to do "point releases" on a 5-year basis, as
revealed by our experience with TR1.

> Anyone familiar with maintaining a library's ABI will know exactly
> what I mean here.

Since I maintain several libraries, I know exactly what you mean.
Anyone familiar with language standardization will know that even
reasonably-solid point releases aren't possible on a 1-year cycle.

>> We actually have a problem with maximizing the effectiveness of those
>> who already have the time and energy to participate.
>
> Ah, precisely the core of the problem I am suggesting solutions for!
> All organic life in this universe organises itself - you merely need
> to create an environment which fosters that self-organisation and the
> rest flows   from within under its own power. I'm sure Dave you have
> read books by Fred P. Brookes and witnessed the remarkable
> self-organising enabler of the internet?

Umm, as a founding member of Boost I don't think you need to lecture
me about that.

>>> the standardisation process nor even this newsgroup and most
>>> especially physically attending conferences. They want short
>>> duration quick in & out self-contained mini-projects. While they
>>> aren't adverse to writing prose, they'd far prefer to write code.
>>
>> But the standard isn't code.  Now it sounds like you're talking about
>> patching some code...  but we don't have a standard C++ reference
>> implementation.
>
> But then I'm not proposing the patching of the standard directly. The
> committee is the only one able to do this and indeed should do this.
>
> This isn't to say it can't be helped along. For example, if government
> wants a new law they can either draft one themselves, form a committee
> to do so or ask someone external to provide one eg; a trade body or
> even the public. It's hardly unknown for a vested interest to write
> the bill in its entirity and pass it to a government minister who then
> presents it as their own.
>
> You guys propose an amendment as you already do. If it's reasonably
> small and could be patched into existing compilers relatively easy you
> submit it to the Bugzilla database and on to some front web
> page. Volunteers create a patch implementing it for (say) GCC. Other
> volunteers apply this patch, add support to their code and test it,
> refining the patch through comments and further patches ie;
> evolutionary.
>
> One month before the biannual meeting of the ISO C++ committee reports
> on the progress of the real-world testing of the amendment are
> generated.  You guys at the committee meeting review them and after you
> feel you have a handle on it, you generate a proposed amendment to the
> standard which is posted again on the Bugzilla database for review. Or
> perhaps a volunteer writes a proposed amendment which you guys review
> which saves you a step. Either way, all roads still eventually lead
> through the traditional ISO C++ committee.

That process is entirely consistent with the structures that are
already in place.  Anyone can submit a paper for committee review.
Generate your reports and if you think you're able to write proposed
standard language, please submit it; it's always better to have
something than nothing.

> What you gain and you are currently lacking is an army of volunteers
> who put your ideas into practice so you can see the end results and
> thus can both prevent mistakes and considerably shorten the time
> required for finalising the form of new features.
>
> I've spelt this out in index bulleted points in my post to Francis
> Glassborow.

Yes, they mostly look good; all that remains is for you to put them
into play.

>> First of all, please name *one* "small obvious feature" so that we can
>> get this discussion off the level of your assumptions that probably
>> are false.  I've never seen one.  Then name two more of same so we
>> can get the idea that there are enough to warrant new bureaucratic
>> structures and whatever else you're asking for.
>
> As we've discussed them already, how about two: (i) move constructors
> and (ii) dynamic library support. How both should work any C++
> programmer of any experience will have an automatic instinct for.

I can't believe you persist in making that assertion, despite having
been told that among experienced (even expert-level) programmers
there's considerable disagreement about how both of those features
should work.

> I also am not asking for bureaucratic structures! After an initial
> expenditure of effort, the system I am proposing should be nearly
> self-operating and should consume virtually none of any committee
> member's time. In fact, it should save substantial amounts of
> committee time! Why do software projects run Bugzilla or something
> like it if this weren't the case?

Because they need to manage their bugs.  Bugzilla just saves time over
managing them on paper.  Right now, we don't have any (code) bugs to
manage, so we don't need bugzilla.  I don't see how adding code bugs
to our process is going to save any time.

>> Second, the smallest and most-obvious features seem to me to be about
>> 80-90% proposal and deliberation.
>
> I said this in the post I made to llewelly just before this one, but
> manipulating large complex abstract sets of intertwined relationships
> is precisely what computer programming is. From this viewpoint, the
> standard is no different - changes will have a ripple effect which
> will require mitigatory measures. Designing with little or no
> implementational experience is extremely tough with a high rate of
> failure - therefore take a superior approach and get yourself
> implementational experience - evolve your design through practice.
>
> Of course you yourself Dave will strongly disagree with this sentiment
> -

Of course you yourself Niall will continue to make incorrect and
marginally insulting assertions about my point-of-view.

I don't think you'll find anyone on the committee who disagrees with
the idea that standardizing things with implementations to back them
up is better.  In fact it's a core principle of how we're supposed to
be operating.

>>> there MUST be a centralised authority on all matters.
>>
>> That's just wrong.  There is not today a "centralised authority on all
>> matters".  There is only a body voting on matters of which text ends
>> up in the standard.
>
> A centralised authority doesn't need a name nor mandate. It simply
> needs to be observed by enough people and it becomes so.
>
> No matter how chaotic and decentralised you might think the C++
> standardisation process is, it is still highly hierarchical. I know
> of no compiler vendor who is busy augmenting C++ with their own
> features as vendors have become burned by that in the past

It's true that there isn't a great deal of language extension going on
but you have the reasons completely wrong: it's largely because
vendors are completely occupied just trying to catch up with the
current standard (yes, even 6 years after standardization) and/or
implementing support for new platforms, optimizations, and other
features that fit entirely within the scope of the current language
definition.  That's one reason it wouldn't be too smart to start
changing the core language every 3 years, especially not until a
substantial number of vendors have caught up to the current target.

>  - the D language is the closest thing I know to it but it's
> distinctly non-commercial. Like it or not, every compiler vendor has
> their eyes turned towards the standard and thus every C++ programmer
> is similarly though indirectly the same.
>
> You are a centralised authority.

Me, personally??

>> As I said in an earlier post (which doesn't seem to be showing up),
>> when I made the first proof-of-concept for exception safety in the
>> standard library, I didn't ask for anyone's permission or blessing
>> first, nor did I ask the committee to set up less "primitive use of
>> the internet", or any of the other things you've been complaining
>> about.  I just did it.  It was taken seriously to the extent that it
>> was good, solid work.
>
> As I've explained in other posts, third party libraries are quite
> something different to core language features.

They're different but core feature proofs-of-concept require no more
blessing from a "centralised authority" than library proofs.

> And I'll be getting back to you on good solid work done without
> anyone's permission or blessing first in a few months time though
> it'll be in a field quite unrelated to C++.

And so quite irrelevant to this discussion.

>>     "we are actually working on ways to make it more efficient.  In
>>     fact *I* in particular have expended a great deal of time and
>>     energy in thatquest"
>>
>> Is that not utterly inconsistent with the idea that we "all are
>> totally opposed to change"?
>
> I used the phrase "you all" as using "ye" isn't Queen's English
> anymore. I meant the plural form of "you" which by definition doesn't
> mean everyone.

Well then who *are* you accusing of being totally opposed to change?
Be specific.  Vaguely applied labels just amount to demagoguery.

> In fact Dave, the way you've phrased your replies has been the most
> productive of all which is why I keep replying to your posts in
> particular. We may or may not be making progress - I don't know, we'll
> know next few posts.

We're not.  You are all fired up about an idea which might even be a
good one but you still expect someone else to make it happen.

I want you to know that the only reason I keep replying is to help
avert a feeding frenzy of people jumping to the wrong conclusions
about the way the committee works.  I want to make it crystal clear to
everyone else reading these posts that you can make whatever
contribution you're willing to invest in, and that *nothing* is
stopping you other than the fact you insist that you are powerless.

>>> and what I do has no effect on others whatsoever - hence me doing
>>> something as you all have proposed is pointless.
>>
>> Then become "an expert."  You're just making lame excuses for an
>> unwillingness to but your own butt on the line.  My name meant
>> "nothing to anyone" when I decided to try to have an impact on the C++
>> committee.  Nothing other than your own insistence makes you less
>> qualified to make a difference than anyone else.
>
> There is so much wrong with this statement I don't know where to
> begin. I could indeed write this length of post just about why your
> statements here are totally incorrect and worse, are dangerous forms
> of thinking (see books by Alain de Boton). However, it would be
> distinctly off-topic despite being relevent so I will condense it
> heavily:-
>
> Experts don't become, they are made - just like no president of the
> United States didn't come from a privileged background. Experts become
> recognised as such because they came up with the goods at the right
> place & time on one or more occasions - in your case, an exception
> safe STL just when people were wondering if it were possible within a
> timeframe when doing so got widespread notice.

Yeah, because I made it an issue.  I made a big stink about it, then
argued my case, produced a reference implementation, and wrote papers
for the committee.  That's why it got noticed.  To a large extent I
created the context that made it matter.

> If any of these factors had been out you would be as anonymous as I
> am, just as Einstein would be unknown if he had deduced relativity
> either before or after when he did.

Enough philosophy.  Are you implying that move semantics isn't a hot
enough topic right now for a proof-of-concept implementation to make a
difference?

> All actions are more a product of the culture & society in which the
> person is born than any characteristic or achievement of that
> individual themselves. I know this reality will be alarming to
> anyone raised in a capitalist system where the false motivator of
> individual potential reigns supreme, but it is so nevertheless.
>
> If you create an environment which *enables* something you desire
> then it will come about with no micro-managing required. *I* cannot
> create such an environment because I do not have the authority to do
> so -

That is utter hogwash.  You have exactly as much authority to do it
for your favorite core language feature as I did for my pet library
feature.

> therefore I would have to both create myself as an authority and
> create the environment at the same time which is very much
> harder. If I were to press ahead alone, how could I issue press
> statements to media outlets in the name of the ISO C++ committee
> calling for volunteers to implement an amendment?

You don't need to.  And given your desire to get things done quickly,
waiting for the committee as a whole to officially vote on and endorse
a resolution to call for volunteers seems highly counterproductive.

> How could I even run a website officially endorsed by the ISO C++
> committee?

You don't need to.  Boost has no official endorsement, yet has a great
impact and lots of credibility.  Who _specifically_, *do* you expect to
run the website, anyway?

> *I* can't do any of this, but a person entitled by mandate of the
> central authority CAN and that's why it's pointless for me to do
> this alone.

So don't do it alone.  Ask people to join you.  Lots of people are
interested.  That's what I did on the exception-safety issue, and it
worked for me.  That's what we did with Boost.

> I have "placed my butt on the line" on numerous occasions but only
> when I felt it was worth doing so in the long run. Feel free to search
> the internet and trawl up the good and bad of my history much of which
> is in the public domain. I know I cannot ever contribute anything
> useful to C++ as the standardisation process currently stands so I do
> not delude myself into thinking otherwise - far better to concentrate
> on other areas where I could make a difference. After all, the total
> capacity for human output is quite finite!

You're certainly generating a great deal of output that is making no
difference whatsoever.  It's amazing how you continue to argue for the
impossibility of accomplishing anything on your own initiative.
That's the surest route to a self-fulfilling prophecy.

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

dave@boost-consulting.com (David Abrahams) wrote:

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

I feel insulted with your response like "either work through the
system or just shut up" when people have some suggestions or questions
about C++.  It's like when you go to a store to tell a sales person
that you want the TV have some features you wish, but the sales person
tells you that you either invent those features or just shut up.

C++ standard is a public domain and the users of C++ want C++ to be
more useful and powerful.  If you know the C++ standard committee
cannot keep up with the demands from the users, why don't you and
committee make a change instead of doing this (the current standard
process you stated above) for ever?  There is plenty of manpower if
you consider the Universities and research institutions.  C++ standard
committee can set up some full time stuffs.  I don't think there are
any problems to raise several millions dollar per year (consider
having a good C++ standard, how much money government can save).  Let
the top Universities and research institutions involve the design and
let the PhD students to implement it (just remember that the Unix, C
and C++, network, X windows were invented by these Universities and
research institutions).  This process is cheap yet you get the best
results.  This is what NASA does.  NASA has very limited research
capability.  Most projects were done through Universities and research
institutions.  NASA pays tuitions for PhD students so that Professors
have funding to do research and write papers and students are able to
get degree.  I believe that C++ standard committee is able to do the
same thing, instead of only having a bunch of people who get together
every 6 months.

I agree that it shall be conservative to change the language, but it
shall be more aggressive to add or standardize libraries.  For
example, there are dozen of thread library and hash table
implementations.  But why take so long for C++ committee to
standardize these implementations?  I also cannot believe the standard
committee doesn't have a plan to standardize a thread library in next
C++ extension.  If this is because committee doesn't have time and
volunteers, please see my suggestion above.  The standard process
shall be far more open and public, and allows more people involve but
not in the current format in which only dozen of people sit on the
committee asking for volunteer work.  That will not work considering
complex of C++ and over million of C++ programmers.  So, instead of
shut up those criticisms, you and C++ committee are better to consider
how to make C++ standard process more efficient to meet the
requirement from the users.

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

This discussion is getting a bit heated.  This article is OK, but let's
all please try to deescalate and to keep the discussion from becoming
personal.


===================================== END OF MODERATOR'S COMMENT
davideng2004@yahoo.com (David Eng) writes:

> dave@boost-consulting.com (David Abrahams) wrote:
>
>>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.
>
> I feel insulted with your response like "either work through the
> system or just shut up" when people have some suggestions or
> questions about C++.

Excuse me, but I think you owe me an apology for implying that I would
say that, or anything like it.  I never said _anything_ even a bit
like that.

I also have to wonder where this accusation originates.  It sounds
suspiciously like something Niall recently posted:

  OTOH, I have tried to suggest ways you all could improve things from
  my point of view and have been singularly told
  "either work through 'the system' or shut up". Well I'm sorry for
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  saying this, but that's not very open-minded - and while I may be
  wrong, or be the 200th person to suggest the same, this angry "to
  question my actions is to insult me" attitude reminds me of the
  unproductive academic clique typical in most universities (please
  note Dave I am not saying this of you specifically - I have the very
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  highest of regard for you - but generally of the majority of
  responses I have received).

I disagree with Niall almost completely: I don't think he got a
response like that from anyone here, but at least he had the decency
to make it clear that he wasn't claiming *I* had said those things.
Are you sure you didn't read his post and mistake his words for mine?

> It's like when you go to a store to tell a sales person that you
> want the TV have some features you wish, but the sales person tells
> you that you either invent those features or just shut up.

Excuse me, but are you going to hand me money to get these features
into the standard?  If not, there is no similarity -- even if I had
told someone to "invent feature or shut up" (which I did not)!

We at Boost Consulting, for example, would be very glad to take
contracts for development of certain C++ features and promoting their
standardization.  In the meantime, we are volunteers in the C++
standardization effort and reserve the right to decline to work on
anything we don't have time for.  We will, however, helpfully guide
those who say they want to make a difference in C++ standardization.

> C++ standard is a public domain and the users of C++ want C++ to be
> more useful and powerful.  If you know the C++ standard committee
> cannot keep up with the demands from the users, why don't you and
> committee make a change instead of doing this (the current standard
> process you stated above) for ever?

Because

   a) we don't have the resources to make the requested change by
      ourselves.

   b) the requested change might serve the demands of a few people
      who have posted here, but (in my judgement and in that of a few
      others at least) the community as a whole would be ill-served.

But mostly because of a).  I think that _some_ of the things people
have asked for would serve the community well, if they could be set
up.

> There is plenty of manpower if you consider the Universities and
> research institutions.  C++ standard committee can set up some full
> time stuffs.

No, we can't.

> I don't think there are any problems to raise several millions
> dollar per year (consider having a good C++ standard, how much money
> government can save).

You must be joking.  Do you have the time and expertise to raise
several million dollars per year?  If not, why do you assume that I
do?  Am I being trolled here?

> Let the top Universities and research institutions involve the
> design and let the PhD students to implement it (just remember that
> the Unix, C and C++, network, X windows were invented by these
> Universities and research institutions).

Long before standardization.  You

know, what you're describing is very much like the open-source
development process, where the mantra from maintainers to those who
want major changes that the maintainer has no time to implement is,
"patches welcomed".  It's hard to understand why anyone would find the
same response insulting in the context of C++ standardization.

> This process is cheap yet you get the best results.  This is what
> NASA does.  NASA has very limited research capability.

And comparatively enormous funding.

> Most projects were done through Universities and research
> institutions.  NASA pays tuitions for PhD qstudents so that
> Professors have funding to do research and write papers and students
> are able to get degree.  I believe that C++ standard committee is
> able to do the same thing, instead of only having a bunch of people
> who get together every 6 months.

We already have a significant representation in research institutions
and universities.  Among them, Bjarne Stroustrup and Gabriel Dos Reis
(Texas A&M), Jaakko Jarvi, Jeremy Siek, and Andrew Lumsdaine (Indiana
University), and Douglas Gregor (RPI).  There is no major barrier to
entry for University researchers; on the contrary, it is easier in
many ways for them to participate than people outside academia.

That said, you might be surprised at how little interest there is in
C++ among computer science researchers in general, mostly because of
"aesthetic concerns".

> I agree that it shall be conservative to change the language, but it
> shall be more aggressive to add or standardize libraries.

Interesting choice of language.  I don't know if you're a native
English speaker or not, but you should know that it comes off
sounding like a "royal decree" when you use "shall" that way.  Maybe
you mean "should"?

> For example, there are dozen of thread library and hash table
> implementations.  But why take so long for C++ committee to
> standardize these implementations?

In part because it takes that long to get the standard right.  But
there are other reasons.

> I also cannot believe the standard committee doesn't have a plan to
> standardize a thread library in next C++ extension.

Believe it.

> If this is because committee doesn't have time and volunteers,
> please see my suggestion above.

That's a very simplistic view of what I think the reasons are, but
it's basically on target.  We also don't much time or many volunteers
to go out and seek volunteers, set up new bureaucratic processes,
implement new web applications, maintain servers, etc, etc.

> The standard process shall be far more open and public
                       ^^^^^
> and allows more people involve but not in the current format in
> which only dozen of people sit on the committee asking for volunteer
> work.

Nobody's _asking_ for volunteer work.  I'm saying, "if you want
something to happen, volunteer to do something about it.  If not,
other people will do what they have time for".  I don't care whether
you volunteer or not -- OK, I care a little: more contributors doing
useful work would help.

> That will not work considering complex of C++ and over million of
> C++ programmers.  So, instead of shut up those criticisms, you and
> C++ committee are better to consider how to make C++ standard
> process more efficient to meet the requirement from the users.

As I mentioned in other responses to Niall, we are actually working on
ways to make it more efficient.  In fact *I* in particular have
expended a great deal of time and energy in that quest.  If you had
any idea how difficult it can be to get a committee to even agree on
informal processes for making progress between meetings, you'd be a
lot more sympathetic to our efforts.

--
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) wrote in message news:<opr8vnkjt8y9klrv@news.iol.ie>...
> On Mon, 31 May 2004 01:52:53 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
..
> > You don't need a "fast track mechanism" in order to pursue that
> > course.  Demonstrating implementability and usefulness, and producing
> > an implementation for reference, would in itself have a huge impact on
> > getting any feature approved.
>
> Of course I could just go do this - however would it be worthwhile in me
> doing so? If I were going it alone then there's zero reason to expect
> anyone else would participate and every reason to expect it would be
> wasted work, especially given the GCC maintainers aren't keen on it

If you're so sure it's a good idea, why are you assuming it will be
impossible to convince them that it's a good idea? You only need to
convince one person (yourself) to create a reference implementation of
a new idea. Once it exists, it can be used ot convince others that the
idea is actually worth-while.

> And besides, I was suggesting that the standardisation process overall
> would be made more efficient by setting up a generic scheme like I
> outlined to fast track the uncontentious additions. It needs to be

As someone has pointed out, uncontentious additions are too few to
justify creating a special process for fast-tracking them. A
fast-track approach won't really save much time for such additions,
because if they truly are uncontentious, even the slow-track process
currently in use will process them reasonably quickly. It's the
contentious changes that take the most time to process.

---
[ 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, 2 Jun 2004 19:12:07 +0000 (UTC), David Abrahams
<dave@boost-consulting.com> wrote:

>    a) we don't have the resources to make the requested change by
>       ourselves.
>
>    b) the requested change might serve the demands of a few people
>       who have posted here, but (in my judgement and in that of a few
>       others at least) the community as a whole would be ill-served.
>
> But mostly because of a).  I think that _some_ of the things people
> have asked for would serve the community well, if they could be set
> up.

I really don't know if it's worth me trying to explain what I am saying
again. I did point some friends of mine at this group to see if I was
being unreasonable and some said that I wasn't taking enough account of
cultural differences - that when you expert guys write what you do you
think you're saying something quite different to what it appears to me
when I read it and vice versa. Hence both sides are getting inflamed by
the other's comments - I certainly have read the replies to my views and
found them most unproductive - it seemed very much to me like I was being
shouted down and being effectively told "you're a child, you have nothing
useful to contribute here".

We can all agree I think that we'd all like the standardisation process to
move more quickly. In particular, I and some of the experts would agree
that more testing of proposed features "out in the wild" is especially
desireable. The most recent friction has arisen due to strongly differing
opinions on how to add manpower to the process.

 From my understanding of what the experts think: Volunteers should
subscribe to industry magazines and should attend where possible the six
monthly conferences. They should participate in creating of amendments to
the standard either through writing one themselves either alone or in
conjunction with others and through reviewing, pondering and discussing
amongst themselves any pitfalls or contraindications which may arise both
within each proposal and between proposals.

What I've been saying: The previously outlined (and traditional) process
is inefficient because it makes no use of the large body of programmers
out there ready to volunteer their time to "patching" the standard just
like any piece of free software. Such people have little wish to involve
themselves in the intricaces of the standard, the standardisation process
nor even this newsgroup and most especially physically attending
conferences. They want short duration quick in & out self-contained
mini-projects. While they aren't adverse to writing prose, they'd far
prefer to write code.

We know from complexity theory & software management theory that debugging
software, unlike any other part of generating software, is very
parallelisable. If you view "C++" as a two dimensional graph where the
left is the ISO C++ standard text and the right is the implementation of
the same in code, one quickly realises that small obvious features are
nearly pure software.

Therefore the debugging of same can be parallelised.

Therefore if more "out in the wild" experience is needed, this is an area
ripe for improvement by applying the same methodologies free software
production methodologies have shown so successful. Obviously how well such
methodologies work is directly proportional to how far "right" the subject
matter is on the left-right graph - if it gets too far left, it'll break
down and become useless.

Hence me suggesting it's only suitable for small features which everyone
agrees on the general form thereof ie; very right side of the graph. And
small, so they have the least interaction with other features and thus
unwanted knock-on effects.

> You
> know, what you're describing is very much like the open-source
> development process, where the mantra from maintainers to those who
> want major changes that the maintainer has no time to implement is,
> "patches welcomed".  It's hard to understand why anyone would find the
> same response insulting in the context of C++ standardization.

Thing is, the ISO C++ standard is not a piece of software. Applying what
you yourself and others suggested of "go do it yourself" can be shown
historically to be most inefficable - for one thing, I have no ability to
fork because forking is totally anti the whole point of having a standard
(ie; most of the "value" of C++ is that it's *standard*). If one reads
economic theory on information (I suggest "Information Rules" by Shapiro
and Varian), it's clear that ad-hoc dispersed development of standards is
a real no-no as indeed ISO's own guidelines suggest - there MUST be a
centralised authority on all matters.

That's why I see no point in working alone on this, or indeed anything
less than a substantial number of people being involved. Standards are
valuable because they increase interoperability & predictability in an
uncertain world which lowers costs & everyone benefits. Anything which
works against that will ossify as it's against the natural order of things
- think of it like an economic environment where making a profit kills
your company (eg; like a department in a university - if it doesn't go
over budget, it will have its budget cut).

>> If this is because committee doesn't have time and volunteers,
>> please see my suggestion above.
>
> That's a very simplistic view of what I think the reasons are, but
> it's basically on target.  We also don't much time or many volunteers
> to go out and seek volunteers, set up new bureaucratic processes,
> implement new web applications, maintain servers, etc, etc.

The whole point of what I am saying is that by investing work now you can
save yourselves oodles of work in the future ie; you must spend money to
save money. Now I can't make you all do this - so far it would seem you
all are totally opposed to any possibility of change whatsoever and won't
even tolerate discussion about it - but then change is hard.

Also, you guys must yourselves invest this time - if you try and push it
off onto other people then it loses legitimacy. Your names are half of
what makes the C++ standard what it is - I can count off the top of my
head at least ten experts by name simply because they have written
articles in CUJ or MSDN - and when they themselves do something it is like
a nexus and with them everyone else turns. The name "Niall Douglas" thus
far means nothing to anyone and what I do has no effect on others
whatsoever - hence me doing something as you all have proposed is
pointless.

> As I mentioned in other responses to Niall, we are actually working on
> ways to make it more efficient.  In fact *I* in particular have
> expended a great deal of time and energy in that quest.  If you had
> any idea how difficult it can be to get a committee to even agree on
> informal processes for making progress between meetings, you'd be a
> lot more sympathetic to our efforts.

You won't know this, but I know precisely what it's like. I participated
extensively within my university's bureaucracy during my degree as part of
the student union, within national civil rights meetings and my father is
extensively involved within one of Ireland's largest universities and thus
he is well embedded within the Irish government. In fact, I've just spent
these last three days discussing how to get some legislation through the
Irish Parliament.

I'm not saying that a magic wand can be waved and it'll all become better.
I am saying that by some investment of time now many of the small obvious
features can be outsourced both soon and for the foreseeable future - you
could get maybe a 10% efficiency improvement directly but you'd also get a
lot more happy programmers out there as they'd finally have a mechanism by
which they could straightforwardly contibute to fixing their own pet
hates. And salving that feeling of helplessness would be very good for
karma.

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                       ]

davideng2004@yahoo.com (David Eng) writes:

> C++ standard is a public domain and the users of C++ want C++ to be
> more useful and powerful.  If you know the C++ standard committee
> cannot keep up with the demands from the users, why don't you and
> committee make a change instead of doing this (the current standard
> process you stated above) for ever?  There is plenty of manpower if
> you consider the Universities and research institutions.  C++ standard
> committee can set up some full time stuffs.  I don't think there are
> any problems to raise several millions dollar per year (consider
> having a good C++ standard, how much money government can save).

One thing you might not realize is that the C++ standardization
committee's budget is less than a few million dollars a year.  A whole
lot less, in fact.  The budget is zero.  Committee members pay their
own expenses to attend meetings, and the costs of the meeting itself
(renting the meeting space, setting up the network, etc.) are paid for
by compaines that volunteer to host the meeting.  The committee has no
paid employees.

If the standards committee had a seven-figure budget and a full-time
staff, then a lot of things might be different.  Not necessarily
better, mind you, but certainly different.

---
[ 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) wrote in message news:<opr8vnkjt8y9klrv@news.iol.ie>...
> On Mon, 31 May 2004 01:52:53 +0000 (UTC), David Abrahams
> <dave@boost-consulting.com> wrote:
>
> > You don't need a "fast track mechanism" in order to pursue that
> > course.  Demonstrating implementability and usefulness, and producing
> > an implementation for reference, would in itself have a huge impact on
> > getting any feature approved.
>
> Of course I could just go do this - however would it be worthwhile in me
> doing so? If I were going it alone then there's zero reason to expect
> anyone else would participate and every reason to expect it would be
> wasted work, especially given the GCC maintainers aren't keen on it
> either.

You don't need any official mandate for this. If I were you, I'd first
tried to start a discussion about the proposed feature (or simply
starting from an existing proposal), and that way seen if there was
sufficient interest, and if there's some serious objections to it, as
well as perhaps getting a sufficiently detailed description.

Then, having done that, you could evaluate whether you felt there was
enough interest in it, to, if possible, do a proof-of-concept
implementation in GCC.

Take the Boost libraries as an example: They have no official mandate
with regards to the C++ committee, and yet, many of the libraries have
been accepted in the C++ Library TR.

> The higher level stuff should remain a committee led process. I'm talking
> purely small "obvious to everyone" features - hence my use of
> "fast-trackable" to denote them.

The problem with this is that there's hardly any "obvious to everyone"
features, at least when you get down to the detailed specification of
it. Take something like "typeof", which appears obvious, and yet
there's been much discussion about it: Should it return a reference if
the value is a reference, etc.

If you're interested, have a look in "The Design and Evolution of C++"
to see what costs even a "perfect" proposal may have (even if it's not
breaking any code, etc.). One important thing is that it should fit
well with the rest of the language.

> > I don't mean to sound callous, but the last person to make similar
> > chronic complaints -- that he couldn't make a positive contribution
> > because he couldn't afford to attend meetings because he lived in
> > Australia and he couldn't afford to leave the country -- didn't even
> > show up when we finally had a meeting in Sydney.
>
> Actually, after your last post before this one I was going to revanish
> again having concluded further posts would be pointless. You all may not
> realise this, but I really respect all you guys and I'm sorry I seemed to
> have annoyed you all (but then that's precisely why I avoid groups like
> this as I stated at the outset). OTOH, I have tried to suggest ways you
> all could improve things from my point of view and have been singularly
> told "either work through 'the system' or shut up".

I can't believe this is what you've been told. I see from Dave's
posting numerous suggestions for how you might contribute, and it's
sincerely meant. I mean, there's a lot of stuff the committee has on
its agenda, so people willing to help is understandably very welcome.

The response in the thread might instead have been more one of "put up
or shut up." In other words, don't complain that you can't contribute,
and make a difference: You can!

I haven't - at least from this thread - seen a single shred of
evidence that roadblocks have been put in your way of contribution. On
the contrary; it's been welcomed.

Therefore, I can understand it feeling frustrating and perhaps
insulting, for hard-working people in the committee and the community
in general, when they get accused of not doing enough to facilitate
people helping, something that would be most welcome.

Frankly, it sounds a little like an excuse for not doing anything with
what you criticise, or want to improve.

> Well I'm sorry for saying this, but that's not very open-minded

I'd agree if that has been expressend, but as I said, I can't believe
that has been the intention. I get the opposite impression.

> - and while I may be wrong,
> or be the 200th person to suggest the same, this angry "to question my
> actions is to insult me"

I haven't seen this, either.

> attitude reminds me of the unproductive academic
> clique typical in most universities (please note Dave I am not saying this
> of you specifically - I have the very highest of regard for you - but
> generally of the majority of responses I have received).

I suggest you may have misunderstood, and taken honest, constructive
criticism for personal criticism. I can assure you, that for any
serious, relevant proposal, there will be a _lot_ of discussion and
criticism, basically shaking it to its roots, to see if it's solid.
The same thing happens at Boost: the participants tear the proposed
libraries to shreds, and the library authors love them for it. :) It
makes the libraries so much better, whether or not they get accepted.

In short, it's important that oneself, as you suggest, have an open
mind, too, and look for the best in people, taking the criticism as an
honest feedback and contribution.

> Anyway, enough with the criticisms - I'm going to stop now. I wish you all
> the best of luck and if you ever do enact a mechanism by which I could
> usefully contribute, you'll see me again.

I haven't seen what you may feel preventing you from contributing (you
don't need GCC approval to implement a proof-of-concept), so the way I
see it is that it's possible to start here and now.


Regards,

Terje

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

dave@boost-consulting.com (David Abrahams) wrote in message news:<ufz9daj95.fsf@boost-consulting.com>...
> >>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.
> >
> > I feel insulted with your response like "either work through the
> > system or just shut up" when people have some suggestions or
> > questions about C++.
>
> Excuse me, but I think you owe me an apology for implying that I would
> say that, or anything like it.  I never said _anything_ even a bit
> like that.

I am very sorry to misunderstand your posts.  Believe me that I don't
have any disrespect toward you and committee.  In contrast, I hold
high admiration of your work and contribution to the C++.  I am
frustrated to see the popularity of C++ decreasing.  I just offer my
opinion in term of making C++ standard process more efficient in order
to compete with Java and C#.  Based on your posts (excuse me if I
mistake it due to my poor english), the problems are C++ standard
committee is lack of manpower and funding.  But I think there are some
ways to overcome them.

> > I don't think there are any problems to raise several millions
> > dollar per year (consider having a good C++ standard, how much money
> > government can save).
>
> You must be joking.  Do you have the time and expertise to raise
> several million dollars per year?  If not, why do you assume that I
> do?  Am I being trolled here?

I am not joking.  You are well underestimated C++ standard name.
Professor Dog Schmidt can raise millions dollar  for his CORBA C++
implementation, I cannot image why C++ standard committee cannot raise
the amount money.  There are plenty resource here, considering
National Science Foundation, government agencies, larg corporations.
If you haven't try, how so sure that is joking?  If C++ standard
committee allow me to represent her to raise money, I am more glad to
do so.

> > This process is cheap yet you get the best results.  This is what
> > NASA does.  NASA has very limited research capability.
>
> And comparatively enormous funding.
>
> > Most projects were done through Universities and research
> > institutions.  NASA pays tuitions for PhD qstudents so that
> > Professors have funding to do research and write papers and students
> > are able to get degree.  I believe that C++ standard committee is
> > able to do the same thing, instead of only having a bunch of people
> > who get together every 6 months.
>
> We already have a significant representation in research institutions
> and universities.  Among them, Bjarne Stroustrup and Gabriel Dos Reis
> (Texas A&M), Jaakko Jarvi, Jeremy Siek, and Andrew Lumsdaine (Indiana
> University), and Douglas Gregor (RPI).  There is no major barrier to
> entry for University researchers; on the contrary, it is easier in
> many ways for them to participate than people outside academia.
>
> That said, you might be surprised at how little interest there is in
> C++ among computer science researchers in general, mostly because of
> "aesthetic concerns".

You misunderstood my point (or I didn't represent clearly).  You have
to funding the project.  Professors get prompted based on two facts:
funding and research papers.  When a professor get funding, he/she can
hire PhD students to do the research and write papers based on the
results of the research.  C++ standard committee can select 3-5
projects every year.  Then let Universities, research institutions, or
individuals to bid the project.  This process is cheap because
professors are paid by University.  The funding is to pay for PhD
student's tuitions.  I bet there are a lot of professors will bid for
the project.  If a professor cannot get funding, he/she will never get
prompted.

> > I agree that it shall be conservative to change the language, but it
> > shall be more aggressive to add or standardize libraries.
>
> Interesting choice of language.  I don't know if you're a native
> English speaker or not, but you should know that it comes off
> sounding like a "royal decree" when you use "shall" that way.  Maybe
> you mean "should"?

You are right.  I come from a royal family.  I am joking.  Thanks for
teach me English.  I am not a native English speaker.

> > If this is because committee doesn't have time and volunteers,
> > please see my suggestion above.
>
> That's a very simplistic view of what I think the reasons are, but
> it's basically on target.  We also don't much time or many volunteers
> to go out and seek volunteers, set up new bureaucratic processes,
> implement new web applications, maintain servers, etc, etc.

It sounds like you know there are some problems, but you don't want to
make a change to correct them.  I think the current C++ standard
process will not work.  In term of supporting distributed computing,
C++ is far behind Java and C#.  If C++ standard committee still keep
doing the same way she is doing, I only can think declining of C++
will be inevitable.

> > I also cannot believe the standard committee doesn't have a plan to
> > standardize a thread library in next C++ extension.
>
> Believe it.

Yes, I believe it now!

---
[ 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, 3 Jun 2004, David Eng wrote:

| I am very sorry to misunderstand your posts.  Believe me that I don't
| have any disrespect toward you and committee.  In contrast, I hold
| high admiration of your work and contribution to the C++.  I am
| frustrated to see the popularity of C++ decreasing.

I believe the perceived decrease in popularity of C++ is best attacked
by teaching people how they can write robuster, better codes in
current standard C++.  Turning the language into much faster moving target
would be a real diservice.  I don't think a programming language meant to
be taken seriously should be released every three months.
(For research languages, it is different -- you want to publish as
frequently as possible ;-))

We need more education, more exposure. We need better tools to support
development in C++.

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

s_googlegroups@nedprod.com (Niall Douglas) writes:

> I could however go patch GCC to add move constructors though
> unfortunately the GCC maintainers would not accept such a patch into
> the mainline as the standard hasn't ruled on it yet.

I'm not sure that's a foregone conclusion.  GCC already contains
numerous extensions beyond the official C/C++ language standards.  I
think the libstdc++-v3 developers might welcome the opportunity to use
move/forwarding, too.

> If there were a fast-track mechanism based on normative addendums
> whereby it worked via a volunteer patching in support to GCC, other
> volunteers testing it and then the original volunteer writing up a
> report consisting of:
>
> 1. Impact of the patch on other areas of C++ (existing source especially)
> 2. Cost of implementation (to GCC)
> 3. Benchmarks of improvements (before & after code)
> 4. A proposed diff of the standard adding the feature
>
> .. then I could be much more useful.

You don't need a "fast track mechanism" in order to pursue that
course.  Demonstrating implementability and usefulness, and producing
an implementation for reference, would in itself have a huge impact on
getting any feature approved.

> And not just me, I can see a lot of people becoming interested
> because now they actually can DO something - not by talking across a
> period of years and spending thousands of euros visiting expensive
> international conferences but actually sitting down and coding.

You make it sound like coding is the "real work".  Well, it's
important, but someone has to design the features (a job you've
clearly been underestimating) and generate some agreement for them.

> For this, the ISO C++ committee would need a website where volunteers
> can coordinate (basically a bugzilla server).

I don't see why the committee needs to manage this.  Why don't you
just set up a sourceforge project?  Or, do it in the context of GCC
development?

> We'd also need a FREE copy of the full standard to generate diffs
> against

I thought you wanted to work on code, not specifications (?)

Anyway, sorry, nobody has control over the cost of the standard ($18
in PDF form, or you can buy hardcopy from Wiley).  ISO rules control
that.

> and much better electronic presence of proposed amendments
> so people can foresee contraindications.

What does "better presence" mean?!?
They're all posted at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

> And lastly, some assurance that work done would be taken seriously
> at the six month meetings

??

What kind of assurance do you _normally_ get that people will take
your results seriously before you start a project?  You didn't ask
for assurance before posting here...

If your work is solid and relevant, it'll be taken seriously.
Otherwise, I guess it won't.

> and perhaps crediting of those who have contributed.

Sure, people are generally credited in the papers that they write.
Any proposal will surely reference any implementations and credit
those who did the work.

>> 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.
>
> If you lament the lack of volunteers, consider how someone
> unemployed for two years can possibly afford to attend committee
> meetings?

I'm not the one doing the lamenting here.  If you lament the "lack of
progress", consider how those of us actually trying to make progress
feel!  There are other ways to make a difference than showing up at
meetings.  You may notice that Peter Dimov is a co-author on the
move/forwarding papers.  He lives in Bulgaria and has never been able
to come to a meeting.

I don't mean to sound callous, but the last person to make similar
chronic complaints -- that he couldn't make a positive contribution
because he couldn't afford to attend meetings because he lived in
Australia and he couldn't afford to leave the country -- didn't even
show up when we finally had a meeting in Sydney.

> Consider the huge obstacles placed in the way of attracting
> volunteers: total lack of immediacy (long times between proposal and
> acceptance)

It's not total.  You can get feedback long before acceptance, which is
appropriate.  No significant proposal is right when it arrives;
iteration is needed.  But, yes, the feedback could be more immediate;
we're actually working on that problem.

> primitive use of the internet

That is, in fact, a hot topic of discussion in the committee.  We
could *really* use someone with the time and expertise to improve our
networking technology.  We need searchable archives for our mailing
lists, just for example.  Would you like to volunteer to set up better
web resources for us?

>  and far too much theory and not enough coding.

Not sure why, but I find that statement somewhat insulting.  That
said, I think everyone on the committee agrees that it'd be a great
thing if we could more quickly get experience with actual
implementations of proposed features.  The problem is that few people
actually have the time and expertise to implement them in an existing
compiler.  So, if you want to make a contribution, and you have the
ability, implementing proposals in GCC would be a big help.

> People also feel deliberations go on in private as there is precious
> little evidence in public - I've only ever seen committee reports in
> (costly) trade magazines.

See Francis' answer.  But yes, deliberations do go on "in private".
ISO rules IIRC.

> The mode of production of free software is ideal for minor new
> features to the standard - it would also remove large amounts of work
> from you guys letting you focus on more major features or ruling on
> contradictions etc.

Well, no, it wouldn't.  It would however remove lots of uncertainty
and make it much easier to accept proposals quickly.

> I'd also imagine the maintainers of GCC would be very happy as
> they'd get most of implementations of small new features well ahead
> of time.

Sounds good to me.  Why don't you get started?

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

On Mon, 31 May 2004 01:52:53 +0000 (UTC), David Abrahams
<dave@boost-consulting.com> wrote:

>> I could however go patch GCC to add move constructors though
>> unfortunately the GCC maintainers would not accept such a patch into
>> the mainline as the standard hasn't ruled on it yet.
>
> I'm not sure that's a foregone conclusion.  GCC already contains
> numerous extensions beyond the official C/C++ language standards.  I
> think the libstdc++-v3 developers might welcome the opportunity to use
> move/forwarding, too.

I base that on what they said to me in response to suggestions I made. I
understand it - I'd do the same if I were them.

> You don't need a "fast track mechanism" in order to pursue that
> course.  Demonstrating implementability and usefulness, and producing
> an implementation for reference, would in itself have a huge impact on
> getting any feature approved.

Of course I could just go do this - however would it be worthwhile in me
doing so? If I were going it alone then there's zero reason to expect
anyone else would participate and every reason to expect it would be
wasted work, especially given the GCC maintainers aren't keen on it
either. That's why such actions need official mandate eg; if a certain
country had sought UN approval before pressing ahead regardless they'd
have removed many of the extra hurdles they now face.

And besides, I was suggesting that the standardisation process overall
would be made more efficient by setting up a generic scheme like I
outlined to fast track the uncontentious additions. It needs to be
approved by the powers-that-be to work properly because that brings with
it instant legitimacy as an official arm of the standardisation process.
And legitimacy is everything here.

>> And not just me, I can see a lot of people becoming interested
>> because now they actually can DO something - not by talking across a
>> period of years and spending thousands of euros visiting expensive
>> international conferences but actually sitting down and coding.
>
> You make it sound like coding is the "real work".  Well, it's
> important, but someone has to design the features (a job you've
> clearly been underestimating) and generate some agreement for them.

Ach, you totally misunderstand (but you're hardly alone). Go back and look
at my previous posts - I never once said that this process should be for
major features. It could only ever work for uncontentious features
everyone agrees are needed and even then, those whose approximate form is
already known ie; those features which need "implementational experience".

The higher level stuff should remain a committee led process. I'm talking
purely small "obvious to everyone" features - hence my use of
"fast-trackable" to denote them. I qualified what I meant by "fast track"
a number of times but various posters repeatedly either twisted my words
or ignored my explanations.

>> We'd also need a FREE copy of the full standard to generate diffs
>> against
>
> I thought you wanted to work on code, not specifications (?)

The people who do the code are surely the best placed to write the first
draft of changes given that they would know what's required the most?

> What kind of assurance do you _normally_ get that people will take
> your results seriously before you start a project?  You didn't ask
> for assurance before posting here...

There is a huge difference between starting/forking a project and
contributing to an existing one.

> I don't mean to sound callous, but the last person to make similar
> chronic complaints -- that he couldn't make a positive contribution
> because he couldn't afford to attend meetings because he lived in
> Australia and he couldn't afford to leave the country -- didn't even
> show up when we finally had a meeting in Sydney.

Actually, after your last post before this one I was going to revanish
again having concluded further posts would be pointless. You all may not
realise this, but I really respect all you guys and I'm sorry I seemed to
have annoyed you all (but then that's precisely why I avoid groups like
this as I stated at the outset). OTOH, I have tried to suggest ways you
all could improve things from my point of view and have been singularly
told "either work through 'the system' or shut up". Well I'm sorry for
saying this, but that's not very open-minded - and while I may be wrong,
or be the 200th person to suggest the same, this angry "to question my
actions is to insult me" attitude reminds me of the unproductive academic
clique typical in most universities (please note Dave I am not saying this
of you specifically - I have the very highest of regard for you - but
generally of the majority of responses I have received).

Anyway, enough with the criticisms - I'm going to stop now. I wish you all
the best of luck and if you ever do enact a mechanism by which I could
usefully contribute, you'll see me again.

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                       ]

s_googlegroups@nedprod.com (Niall Douglas) writes:

[...]

| Of course I could just go do this - however would it be worthwhile in
| me doing so? If I were going it alone then there's zero reason to
| expect anyone else would participate

If you build it, they will come.

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