Re: LWG Issue #387 -- std::complex
Daniel Herring ha scritto:
These two uses provide justification for adding the following to the
proposed C++ API.
typedef T (&array_type)[2]; // unable declare directly
in function prototype
array_type & c_array(); // similar to std::string::c_str()
const array_type & c_array() const ;
T & lreal(); // "l" for lvalue
const T & lreal() const;
T & limag();
const T & limag() const;
The names may need improvement, and return-by-reference may supersede
the getters and setters of the proposed API, but these basic methods are
required for C++ users to safely use the layout guarantee that Issue
#387 provides for compatibility with C and other languages. If they are
not implemented in the standard, then they will appear in user libraries.
I don't like the name of c_array(). I believe it's meant to mimic the
string::c_str() method, but the arguments that lead to the choice of the
name c_str() (namely: it returns a "C string" = null-terminated) do not
apply here. Maybe "as_array" is a more apt name. The as_xxx naming
conversion is used in several place in Boost and makes more sense, IMHO.
Moreover, I would prefer having real() and imag() return references
rather than having lreal() and limag(), although I understand that it
might change the ABI.
Note that it is not sufficient to provide
T * c_array();
Since this discards type information which may be useful for template
expansions.
That's correct and it's no problem as T[2] decays to T*, so the proposed
signature is enough to cover both cases.
Notice that we still need to cope with the requirement that an array of
std::complex<> should be equivalent as an array of T[2], but that's not
something you would find in the interface anyway.
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]