Re: [boost] Re: container design (Was: std::complex design (Was: N-Dimensional array))

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-08 17:57:44

----- Original Message -----
From: "rwgk" <rwgk_at_[hidden]>

> --- In boost_at_y..., Howard Hinnant <hinnant_at_t...> wrote:
> > than it creates?  It may be simpler to just create your own
> container
> > that tolerates indeterminant scalars.
>
> That is what I am beginning to think...
> The nature of language-lawyerism that I am experiencing
> here is quite overwhelming for someone who is trying to
> get a job done.
> Take the example of natural language: It is full of
> exceptions to the rule and shortcuts because apparently
> that is what works best. Rules are necessary, but it is
> important to make compromises, to find a balance that
> fosters /productive/ creativity (as opposed to introverted
> creativity (no examples mentioned here)). IMO C++ is overdoing
> the job of "protecting" the user. The weight given to
> the principle of encapsulation relative to other things
> such as efficiency and easy of use is too high.

This seems to reflect a narrow perspective which is shaped by the
application domain in which you (we) work. You probably missed a recent
c.l.c++.m thread called "Safe C++" from someone who takes the opposite
view. I think most people consider it an important ease-of-use element
that, given a vector<T>, and a T whose requirements match those for
vector elements, they can insert new elements without invoking undefined
behavior. The principle that a constructed object maintains its
invariants is something I personally worked hard for and without which
useful standard library exception-safety guarantees would not have been
possible.

Making decisions which serve the broad range of C++ users well is
difficult. The territory of standard containers with uninitialized
objects is completely unexplored. If you bring up a subject like this
one, you should expect to generate a lot of conversation. We've only
been talking for a couple of days. I think it's unrealistic to expect
that the solution you find expedient is going to be appropriate for the
standard (as determined by committee consensus) if it opens new doors to
undefined behavior, though I might be mistaken. In any case, if you want
to convince the LWG that you have a good solution, it would make sense
to try to find a way to deal with the objections that come up other than
saying "encapsulation isn't really so important", because to some
people, it is.

> The other big deficiency from my viewpoint is the overall
> klunky support for compile-time introspection. I view
> typeof() as an important step in the right direction.
> More of that, please! Please give me more powerful tools
> to work with, and stop being like an overly protective
> mother. A bruise here and there is part of growing up
> and much preferred to being trapped like a prisoner.

The answer for you is the same as for anyone who wants to change things:
stop venting and start writing papers and defect reports, and attend
committee meetings, if you want to impact the standard. Numerics support
in the standard is lacking because the closest thing we had to numerics
experts gave us numeric_limits<> and valarray<> and then stopped
participating in standardization.

> Sorry for venting, but it had to be done.

Are you sure?

-Dave