Re: [Boost-docs] stl mini-review

Subject: Re: [Boost-docs] stl mini-review
From: David Abrahams (dave_at_[hidden])
Date: 2007-07-31 15:33:39

on Tue Jul 24 2007, Andrew Sutton <> 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).
> 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
The Astoria Seminar ==>

This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:40 UTC