lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] Fix value_cast defect shown by the unit test


From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Fix value_cast defect shown by the unit test
Date: Sat, 7 Jan 2017 14:21:34 +0100

On Sat, 7 Jan 2017 13:08:55 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-06 22:53, Vadim Zeitlin wrote:
GC> [...]
GC> >  The last two warnings show that the compiler selects to use e_direct
GC> > specialization of value_cast_chooser and this means that
GC> > value_cast_choice::convertible is true, which is indeed the case because
GC> > the type of the literal "1" in the unit test, i.e. "char*" is convertible
GC> > to bool via the unfortunate inherited from C pointer-to-zero-or-not
GC> > conversion.
GC> [...]
GC> >  The simplest fix I can propose is just testing for !is_array<>
GC> 
GC> "char*" is a pointer...and testing that it's not an array fixes this?

 Yes, because a string literal is actually an array and not a pointer and,
as I was surprised (but, on balance, pleased) to discover,
std::is_pointer<> doesn't return true for arrays, in spite of the
array-to-pointer rule.

GC> I'm confused. If the problem is that "char*" is a pointer, then why
GC> wouldn't the fix need to test is_pointer<>? Or, if testing is_array<>
GC> is the fix, then is a literal "1" actually an array, not a pointer?

 Yes, a literal "1" is an array ("array of const char of size 2"), although
it does, of course, decay to pointer on request, as usual in C++.

GC> I thought this:
GC>   char* p = "1";

 If we want value_cast<>(p)  work too, we need both tests. However if you
pass "1" to value_cast<> directly, there is no decay and it is an array and
the current fix is enough.

 Hope this helps,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]