[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-docs
Subject:    Re: [Boost-docs] stl mini-review
From:       David Abrahams <dave () boost-consulting ! com>
Date:       2007-07-31 15:33:39
Message-ID: 87fy3437vw.fsf () grogan ! peloton
[Download RAW message or body]


on Tue Jul 24 2007, Andrew Sutton <asutton-AT-cs.kent.edu> wrote:

>> Examples are VITAL - without this most peoples reaction is "Huh"?
>>
>> And there needs to be LOTS of examples, and LOTS of comments saying  
>> what the examples show, however obvious it may seem to those who
>> write the C++ Standard ;-)
>>
>> What about examples of user defined types?
>>
>> Perhaps discuss How would you tell if something is default  
>> constructible?  By Test?  By examining code?
>
> I completely rewrote the DefaultConstructible concept doc this  
> morning - it's taken 3 this morning. Please, re-review that one page:  
> it's here (and it's committed this time).
>
> http://tinyurl.com/2rb477
>
> Changes include:
> 	1. Mostly rewriting the entire concept to get rid of the word  
> 'instance' and it derivatives.
> 	2. Added lots of stuff about initialization - it's probably wrong.
> 	3. Examples.
>
> There are some other changes.
>
> I do have a concern that the idea of default-initialized, zero- 
> initialized, value-initialized, and uninitialized may dominate the  
> concept more than the notion of default construct-ability. My  
> experience is that algorithms requiring default construction will do  
> so without actual regard for the initial value because they assign  
> values later, and so an in-depth discussion of initialization within  
> this concept may be out of place. 

I think your instincts are good here.  One thing to remember above all
about concept documentation is that the very existence of concepts is
100% driven by algorithm requirements.  

If the DefaultConstructible concept doesn't say anything about the
value of a default constructed object, then algorithms requiring
DefaultConstructible<T> aren't making any assumptions about that
value.  I'm sure all those algorithms also require Assignable<T>.

It may be that there are some semantic requirements missing from
algorithms that require DefaultConstructible, because, IIRC, there's a
lot you can't do with a default-constructed pointer: it might not even
be copiable without invoking undefined behavior (look it up because I
may have forgotten the details).  IIRC you can only assign to and
destroy a default-constructed pointer.  So an algorithm requiring
DefaultConstructible<T>, Assignable<T>, and CopyConstructible<T> may
be slightly overspecified, unintentionally requiring that a
default-constructed T be copiable.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


[prev in list] [next in list] [prev in thread] [next in thread]