This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: C++ PATCH: PR 20599 (1/3)

On Tue, 19 Sep 2006 10:43:09 -0400, "Doug Gregor"
<> wrote:

> On Mon, 18 Sep 2006 19:27:09 -0400, "Doug Gregor"
>>GCC could break this stale-mate by including experimental
>>implementations of these features. Then, the community at large can
>>experiment and better understand these features, finding (and fixing!)
>>problems before the ink dries on C++0x.
>I mostly agree without your analysis. But I think it also matters
>having a relatively long period of experimentation.
> I don't think it's the length of time for experimentation, but the
>amount of time spent in aggregate. If 100 people play with the feature
>for 2-3 hours, we'll get a much better sense of its capabilities and
>limitations than if one person spends 300 hours using that feature.

Yes, absolutely. Some minimum time is still important though (I
suppose one can't get that 300-hour effect if 3000 people play with it
for 6 minutes --that's an exaggeration, of course; I hope it
illustrates the point).

>It's extremely hard to get people to download and install a new
>compiler to try out a language feature. I've found this with
>ConceptGCC: each time I give a talk or a demonstration, people would
>come up to me and say how much they want to have this feature in their
>compiler. But few... very few... actually go download the compiler to
>try it. The barrier of installing a new compiler is just to high.

I'm not sure there's a real technical barrier but again that's true.
Personally I'm guilty of that as well. I'm familiar with building gcc,
yet I get quite lazy when it becomes time to.

In this specific case, there's even more added value to this feature,
in that it is helpful (in terms of code clarity, simplicity and thus
_reliability_) to the implementation of the library itself. So I'm all
for inclusion in a release too.

> [...]
>> This time it seems to me that there's too much time pressure,
>> both for the committee and for vendors
> By "this time" do you mean this committee meeting? This standard?
>This feature?

I meant this standard (thus this meeting as well)

> If you mean this committee meeting, then I agree, somewhat. The issue
>is that we keep counting backward from 2009 (the last year in which
>we're supposed to ship C++0x), and realizing that there isn't much
>time left.

I know. So why not postponing the date a bit? Everyone hates slipping
schedules, of course. But if meeting the date means risks of errors...

> I don't know the complete details, but there's at least a
>year's lag in approving the working draft, so we really need to have
>the draft final by 2008.

Yes, that's what I remember reading from Herb Sutter too (perhaps
something like 18 months spent in bureaucratic procedures).

>On the other side, once the Evolution Working
>Group accepts a feature in principle, it takes at least a year before
>we can get suitable "standardese" to put it in the working draft. So
>if everything that will be C++0x gets accepted in Portland, we'd have
>a year in the middle to make sure everything works together. Ask
>someone who understands ISO rules better and you'll get a bleaker
>picture :)

Yeah :-)

>> (speaking about the former I'm seriously worried for the
>> thread specification, for instance). Don't you think so?
> It very much depends on the feature. I'm actually not that worried
>about threads, because there is a lot of interest in this do-or-die
>feature, and many smart people are working to make that happen.

Sure they are. But experience has shown that it doesn't matter how
good one is. Errors just happen (well, not that it doesn't matter at
all: normally the error rate is lower :-)). Exception specifications,
ADL gotchas, export... are all, in different measures, errors which
has happened. So I'm not a big fan of "rush" when it comes to
ratifying what is likely to (I'd say _sure to_) affect our work for
the next 20 years.

I, for one, gave up making a proposal for dynamic_bitset, as I think
that with the current interface it was an experiment that failed. I
also have a new version of it, with what I consider a much better
design; yet I didn't propose it: I want to make it widely available
first. Now a bitset facility is nothing vaguely comparable for
technical difficulty and extension to a thread specification, so I
guess that gives an idea of my perplexities.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]