Re: Using non-immediate constants in noexcept clauses
Am 05.11.2011 22:09, schrieb Daryle Walker:
If you write the definition of a class member function separate from
the class's definition, the "noexcept" parts of the signature between
the method's declaration and definition have to match, right? (And
the same for a free function and any forward declarations it may
have?)
Yes. If not, it would be ill-formed with required diagnostic if the
collision happens in the same translation unit and otherwise simply
ill-formed.
Meanwhile, you can build the Boolean expression for a
"noexcept" clause any way you want, right? Doesn't this mean we can
combine these concepts?
This is correct, but you have to obey still constraints of 14.5.6.1 in
regard to functional equivalent templates.
Example:
template<typename T, unsigned S>
class MyType
{
constexpr bool nothrow_default_ctr = std ::
is_nothrow_default_constructible<T> :: value;
constexpr bool nothrow_copy_ctr = std ::
is_nothrow_copy_constructible<T> :: value;
constexpr bool nothrow_value_ctr = nothrow_copy_ctr&& (!S ||
nothrow_default_ctr);
I assume these data members are supposed to be static ones, else the
noexcept specifications that follow wouldn't be well-formed.
public:
constexpr MyType() noexcept(nothrow_default_ctr) = default;
constexpr MyType( T const (&a)[S+1u] ) noexcept(nothrow_copy_ctr);
constexpr MyType( T const&c ) noexcept(nothrow_value_ctr);
These declarations are fine so far.
constexpr T& operator []( unsigned i ) noexcept
{ return this->d_[i]; }
constexpr T const& operator []( unsigned i ) const noexcept
{ return this->d_[i]; }
Unfortunately, these member declarations cannot coexist, because a
(non-static) constexpr member function is alway a const member function,
so both have the same signature except for the return type. You may want
to change them to
T& operator []( unsigned i ) noexcept
{ return this->d_[i]; }
constexpr T const & operator []( unsigned i ) noexcept
{ return this->d_[i]; }
template<typename T, unsigned S>
constexpr // Does this part have to be repeated in out-line
definitions?
MyType<T,S>::MyType( T const (&a)[S+1u] ) noexcept(nothrow_copy_ctr)
: d_{ a }
{}
Yes, the constexpr specifier must be repeated for all declarations and
the usage of noexcept is fine so far. But the implementation won't work,
because array types are not copy-constructible. You need a wrapper type
(similar to std::array) to realize that.
template<typename T, unsigned S>
constexpr
MyType<T,S>::MyType( T const&c ) noexcept(nothrow_value_ctr)
: d_{ c }
{}
This should be fine so far.
If this idea is valid, and were trying cross-version constructor
templates, then we could use some sort of traits class if we didn't
want to directly express no-throw conversions directly in the function
definitions:
The question is, what the actual "idea" is, but you can use these traits
as described.
template<typename From, typename To>
struct nothrow_convertible
{
constexpr bool value =
noexcept( static_cast<To>(declval<From>()) );
};
Yes, you can combine noexcept directly to implement a is_nothrow_*
trait. I have used this technique successfully. There is one detail that
has to be clarified by the core language, which is described by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1354
template<typename T, unsigned S>
class MyType
{
//...
template<typename U, unsigned R>
explicit MyType( MyType<U,R> const&o )
noexcept(nothrow_convertible<U,T>::value)
{
std::copy(&o[0],&o[0] + 1u + std::min(R, S),&this->d_[0] );
}
//...
};
Looking back, I guess this is the idea behind those "std ::
is_nothrow_XXX<T> :: value" expressions. (Maybe someone else can
learn from me possibly answering my own question.)
It is not the idea, but it should be a reasoanble way to implement it
efficiently as a library emulation. Note that this is neither necessary
nor required, in fact these traits could also be implemented by compiler
intrinics.
Looking back again, at a C++(11) reference site, it seems that "std ::
is_nothrow_assignable<T, U> :: value" already matches what I just made
up. (Oops.) But I'm sure someone will eventually need a type
computation not already prepared by the standard.
Yes, the specification is defined to allow this.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]