On Oct 30, 6:39 pm, "george.r...@gmail.com" <george.r...@gmail.com> wrote:
> On Oct 29, 6:26 pm, James Kanze <james.ka...@gmail.com> wrote: > > all. IMHO, the best approach would be for a (very) small group > > of extremely capable individuals to go off and do the work, then > > integrate it, without considering alternative approaches (unless > > there is some serious error in their results, which can't easily > > be fixed). > Isn't that opposed to the ISO concept of developing a standard > based on consensus?
In some ways. But the consensus that is required really only concerns the final product. Public approval is necessary, but you don't want a case of too many cooks spoiling the broth---the public's role should be more or less one of deciding up front what should go into the soup, and then tasting the results, but leaving the actual cooking and preparation to the expert chefs.
-- James Kanze
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
On Oct 30, 8:01 pm, Hyman Rosen <hyro...@mail.com> wrote:
> James Kanze wrote: > > All of the places I know stuck with g++ 2.7 something > > through the entire EGCS debacle, only updating with 2.95.2. > > Similarly, most stayed with 2.95.2 until 3.2 something, or > > beyond. > There is no reason for characterizing the EGCS fork as a debacle.
I'm afraid my wording wasn't very clear. The fork itself wasn't a debacle, and of course, much of 2.95.2 stems from work which was done in it. The way it was managed, with new versions almost every day, was a debacle, however, and pretty much meant that it couldn't be used in any serious development.
> On the contrary, your statement above demonstrates that there > was no useful new release from the old GCC maintainers at all, > until EGCS became the official version.
The fact that there was no serious maintenance on gcc was a problem, albeit not as bit a one as might be imagined; the C compiler was already pretty good, and the C++ compiler was usable, provided you avoided the more complicated cases.
> > It just leaves out a few details, like the fact that in > > production work, you don't want a compiler whose development > > is "vigorous"; you want one which is stable, and not > > changing. > But you also want a compiler which is able to compile the > programming language you choose to use, not a poorly-defined > subset of it.
A compiler which compiles it one way one day, and another way another day, is worse than no compiler.
> People who wanted that were royally fed up with the glacial > lack of progress from the GCC developers, and took matters > into their own hands, successfully. > Whether or not to use EGCS for production work would have > depended on how important its newly developed features were as > compared to its lack of stability. That's a decision to be > made case by case. > I happen to know from reading your many posts that you value > stability very highly and program very conservatively, but I > think you're projecting what you value onto others who do not > feel that way.
EGCS represents a radical extreme with regards to instability. I know that there are compromizes to be made, but almost regardless of the application, the extremes are to be avoided. There are certainly exceptions for some critical applications, where extreme stability is required, and I suppose that the opposite extreme could be justified in an experimental laboratory in a university---and is obviously necessary within the compiler development group, if any progress is to be made. The problem with EGCS wasn't that they were developing too fast; it was that they were making too many intermediate steps open and available, without distinguishing what was really experimental, and what was stable.
-- James Kanze
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
On Oct 30, 6:32 pm, Ken Penpal <penpal....@googlemail.com> wrote:
> James Kanze wrote: > > Perhaps, but in that case, I'd suggest the opposite > > approach. From what I've seen, most of the problems are due > > to too many divergent approaches, with the standard trying > > to adopt them all. IMHO, the best approach would be for a > > (very) small group of extremely capable individuals to go > > off and do the work, then integrate it, without considering > > alternative approaches (unless there is some serious error > > in their results, which can't easily be fixed). > Could an approach similar to the one used by the Boost project > be used instead?
Perhaps. It certainly seems to work for Boost.
> Even if only a select few C++ geniuses were allowed to do the > core work or to decide on the core issues, the entire work > could still be open to the general public from the beginning. > Among others, the mailing list archives and all the > communications could be completely open.
I think that wide participation is a good thing at both ends: what features are needed, and then a final review of their implementation and integration. Where I think things are blocking is in the middle, when all of the details are getting worked out.
-- James Kanze
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
On Nov 2, 1:42 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Oct 30, 6:32 pm, Ken Penpal <penpal....@googlemail.com> wrote: > > Could an approach similar to the one used by the Boost project > > be used instead?
> Perhaps. It certainly seems to work for Boost.
However the Boost process doesn't have the added burden of being a formal part of the language, and as such doesn't effect the public's impression of, or dependence on, the C++ standard itself (I hope). I can always opt not to use a Boost library for reasons of design, however I would expect features that are formally in the language to be more top-notch. Boost can always replace libraries with better versions if necessary in a manner that is much easier and has less repercussions than for the standard.
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
george.r...@gmail.com wrote: > I would expect features that are formally in the language to > be more top-notch.
If the standardization process were more public, there would still be the same small number of core people doing all the work. That wouldn't change. What would change is that problems would come to light more quickly.
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Hyman Rosen wrote: > george.r...@gmail.com wrote: >> I would expect features that are formally in the language to >> be more top-notch.
> If the standardization process were more public, there would > still be the same small number of core people doing all the > work. That wouldn't change. What would change is that problems > would come to light more quickly.
What part of the current process do you feel should be made public exactly?
As Ville Voutilainen pointed out in a previous post there are many ways to contribute to the standardisation process without actually attending meetings.
At the outer level, you have this and other newsgroups. There are often mails to the main reflectors with the following:
"After a discussion on comp.std.c++..." or "After a discussion on comp.lang.c++.moderated...".
So, if you think you have found a problem with a paper or the current draft and this is confirmed here then that will be seen by the members of the committee.
The second point is that the majority of work completed by the committee is public. Changes to the standard require a paper, and from what I have seen these papers are publicly available.
And of course, you have the public draft standard which you can also review.
Regards,
Richard
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2953.html#In...> Paper N2904 examined the generation of default copy and move operations when elements are combined into an aggregate. The proposal was discussed extensively in the July 2009 meeting, and several changes were suggested at that meeting. In addition, several changes surfaced in analysis after the meeting.
The cycle of "think hard, write a paper, discuss at the next meeting, fix, repeat" would benefit from some kind of public discussion board. First, feedback would come more quickly, and second, preserving the discussion makes it available to inform others.
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
On Nov 5, 7:26 pm, Hyman Rosen <hyro...@mail.com> wrote:
> The cycle of "think hard, write a paper, discuss at the next > meeting, fix, repeat" would benefit from some kind of public > discussion board. First, feedback would come more quickly, > and second, preserving the discussion makes it available to > inform others.
Good idea in theory, but the risk is that the practice of typing all of the discussions into a forum takes longer to do than any benefit gained from having every thought public. It's much quicker for those involved to have a group discussion in person than it is to type out long essays to each other.
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
george.r...@gmail.com wrote: > typing all of the discussions into a forum
You're missing the point. With a properly set up system, the discussions would happen continually on line.
-- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
|
