Boost logo

Boost :

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2002-03-08 10:05:26

"David Abrahams" <david.abrahams_at_[hidden]> writes:

| ----- Original Message -----
| From: "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]>
| >
| > IMO complex<double>() should behave like double().
| Agreed.

I'm perfectly fine with having complex<> default initialised as
currently done. If there are needs not to initialize a large array of
complex<>s then, in my opinion, appropritae constructs should be used
instead of making complex<> in general not default initialized.


| > 1. complex<T> proposal:
| > a. predictable layout to facilitate use of existing code
| > b. members should be directly accessible (T& real() { return
| re; })
| Yes, though you only really need part a. to get part b.

But, it would be much less plain if b. also is provided.

| > 2. propose additional constructors for containers (vector<T> and
| valarray<T>):
| > vector(size_t n, no_initialization_flag);
| > valarray(size_t n, no_initialization_flag);
| > - with compile time assertion that T has a trivial destructor.

In general, I think valarray<> should be extended so that one of its
constructor can take a "procedural" initializing expressions.


| [John]
| PODs are supposed to be basically C structs, and can be manipulated
| using mechanisms like memcpy. If a class has a constructor, the
| thought is that you should be using constructors for things like
| copying.

However, we need a way to make C++ complex<> behave sufficently similar
to C99's _Complex, in particular we would like to be able to use
constructors to initialise a complex<> and at the same time have the
latitude to treat it like a C struct.

-- Gaby

Boost list run by bdawes at, gregod at, cpdaniel at, john at