Re: std::complex design (Was: N-Dimensional array library

From: rwgk (rwgk_at_[hidden])
Date: 2002-03-07 15:45:12

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
*** I wrote this last night before David wrote his other messages
but was not able to post earlier because of the unreliable
yahoo server.
I will follow David's suggestion and write a proposal
following my convictions.

From the paper:
> This definition is appropriate for local variables, but not
> for objects that are initialized as a result of executing
> expressions of the form T(), because the objects yielded by
> such expressions will be copied immediately, and should
> therefore have values that are assured of being copyable.

Why is this a problem for built-in types. Isn't it that we
are just copying bytes? I am thinking "no constructor, no
copy constructor, no destructor, no problem." What am I
missing?

Interesting to see how much back-and-forth there was.
However, the paper does not convince me that the global
optimum was found, only a domain-specific optimum: much of
the argumentation is based on addressing the particular
needs of certain applications.  I view the examples
(map<int, int>, struct Customer) as evidence of a strong
bias towards a certain domain.  Not much attention is payed
to huge arrays of built-in types. Only here (where I think
the standard got it right):

>  struct T {
>    int x[100000];
>  };
>  Everyone agreed that
>    T t;
>  should not cause any initialization,

But vector<int>(100000), which is generally much more
useful, provides no facility to avoid the initialization?
This makes no sense at all. In my universe this "is too
much of a violation of the principle of least surprise."
Also, I cannot believe that an array package must be 120000
lines long (Blitz++), in part to make the implementation of
map<int, int> simpler.

However, it is clear that the rules are essentially carved
in stone and that any more criticism of the basic concepts
is futile. So what could be done to make C++ more suitable
for numeric applications? I see two areas that should be
addressed:

1. The standard containers should provide a facility to
   avoid the initialization of the data if they meet
   certain conditions (such as is-a-POD or, more generally,
   has-a-destructor-that-does-nothing).

2. We need a predictable layout for certain non-POD types,
   foremost the topic of this thread (std::complex), but
   this would also be generally useful for applications
   that integrate C++ with e.g. C or Fortran, or, oops(!),
   assembler (as recommended by B. Stroustrup (see the the
   ublas front-page)).

That would be a great start.

Ralf