public member variable vs. get/set functions

[Seungbeom Kim]

It is nowhere said that 'std::complex<float>' must be implemented as
a class with two float members. The processor may have native support
for complex arithmetic and 'std::complex' may internally use it or
it may be is more efficient to implement it as array of two floats
internally for whatever reasons.

That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387

 

[Alf P. Steinbach]

It is nowhere said that 'std::complex<float>' must be implemented as
a class with two float members. The processor may have native support
for complex arithmetic and 'std::complex' may internally use it or
it may be is more efficient to implement it as array of two floats
internally for whatever reasons.

That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387

Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".

The `reinterpret_cast` in the LWG issue spec most naturally suggests an
array, which would have to be the first member in order to have an
implementation that only relies on standard C++ functionality
(reinterpret_cast to/from first member of suitably restricted class is
supported in general for C compatibility).

The lack of a specification of size means that low level / C language
access to arrays of complex values is still not supported. That's a big
surprise. I can't believe that that's intentional.


Cheers,

- Alf

 

[Alf P. Steinbach]

On 2013-12-11 13:23, Öö Tiib wrote:
On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:

It surprises me that the real and imaginary components are not
public variables in the <complex> class template. Very unclear
to me the value of making them private.

It is nowhere said that 'std::complex<float>' must be implemented as
a class with two float members. The processor may have native support
for complex arithmetic and 'std::complex' may internally use it or
it may be is more efficient to implement it as array of two floats
internally for whatever reasons.

That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387

Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".

The `reinterpret_cast` in the LWG issue spec most naturally suggests an
array, which would have to be the first member in order to have an
implementation that only relies on standard C++ functionality
(reinterpret_cast to/from first member of suitably restricted class is
supported in general for C compatibility).

The lack of a specification of size means that low level / C language
access to arrays of complex values is still not supported. That's a big
surprise. I can't believe that that's intentional.


Cheers,

- Alf

The issue did say:

Moreover, if a is an expression of pointer type cv complex<T>* and the
expression a is well-defined for an integer expression i then:

reinterpret_cast<cv T*>(a)[2*i] designates the real part of a; and
reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a.

which effectively requires sizeof(complex<T>) = 2*sizeof(T)

Thanks, I didn't see the correct parenthesification.

Cheers,

- Alf

 

[Seungbeom Kim]

That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387

Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".

That's right. (I'm not sure if elements of a member array can officially
be considered as data members as well. )

The `reinterpret_cast` in the LWG issue spec most naturally suggests
an array, [...]

Not necessarily, though an array is certainly possible. The standard
probably does not guarantee that two data members of the same type
declared consecutively without any intervening access specifiers are
allocated adjacently, but I believe many common implementations do it,
and an implementation can ensure that for std::complex (by any magic
if necessary) since it is part of the implementation anyway.