Re: libstdc++ not conforming with --enable-concepts-check?

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Thu, Sep 23, 2004 at 12:57:28AM +0200, Paolo Carlini wrote:

> Jonathan Wakely wrote:
> 
> >Because std::deque's value_type needn't be DefaultConstructible, unless
> >using the default argument for the fill ctor.
> >
> >Oh ... and unless you explicitly instantiate the container and the
> >implementation happens to have taken the option of implementing the
> >fill ctor with more than one function (see my other mail in this thread).
> > 
> >
> I'm finding this last point of yours very interesting: thanks for the 
> observation.
> I need time to do some bib search and study the specific issue in 
> detail. I hope
> someone else will shed light in the meanwhile...

17.4.4.4 allows the function specified in the standard to become two
functions, and says that taking the address of a member has unspecified
type since it might have different number of args to the signature given
in the standard. It doesn't say anything about whether explicit
instantiation should be affected. There is one DR for 17.4.4.4 but it
wasn't about this either and was closed as NAD anyway.

AFAICT this effect allows user code to detect whether the implementation
provides the exact signature in the standard or multiple equivalent
ones, which I didn't think was possible. (Not that "what jon thinks is
possible" is in any way normative! :)

14.5(2) and other clauses talk about default arguments in template
functions, but I'm not really sure what it means by "default arguments
... are considered definitions"

14.7.2 [temp.explicit] says

    -9- An explicit instantiation does not constitute a use of a default
    argument, so default argument instantiation is not done. [Example:

    char* p = 0;
    template<class T> T g(T = &p);
    template int g<int>(int);       //  OK even though  &p  isn't an
    int.

    --- end example]

(Is that text the same in the final standard? My copies are at home, so
I''m reading a draft now)

That explains why it is OK for a default-constructed
non-DefaultConstructible type to be used as a default argument
i.e. why this is OK:

   deque(size_type n, value_type val = value_type())
   { _M_fill_initialized(n, val); }

but not this:

   deque(size_type n)
   { _M_fill_initialized(n, value_type()); }

If it turns out we're violating the standard in this respect, could we
make _M_fill_initialized()'s second parameter default to value_type(),
so we can use it like this:

   deque(size_type n)
   { _M_fill_initialized(n); }

It might be possible to move all occurrences of default-ctor calls to
default args (I think this is an case where "implementations go to a
great deal of effort to make sure that they don't require it by accident"
as Matt Austern said.)

I don't know if that's desirable though, and the v3 behaviour might be
OK by the standard anyway.

> >>>Because deque (and vector, and so on...) individually have really 
> >>>**minimal** concept checks, right now. We can endeavour working on 
> >>>this, if we (you?) consider it a worthy project...
> >>>     
> >>>
> >Hmm, I don't know - I think the concept checks are pretty complete. This
> >is the second one this month that has been removed for being _too_
> >restrictive!
> > 
> >
> :) I meant the concept_check present in the individual containers (vs 
> algorithms
> and iterators): don't you agree?

Ah, I see - yes.

jon


-- 
"Never attribute to malice that which is adequately explained by stupidity."
	- Hanlon's Razor