Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-06 07:21:08

Vladimir Prus <ghost_at_[hidden]> writes:

> Markus Sch?pflin wrote:
>> Vladimir Prus wrote:
>>> Markus Sch?pflin wrote:
>>>>Attached patch fixes the last failure on Tru64. (See
>>>> Ok to commit?
>>> please hold on a bit. The same problem is present on intel and comeau,
>>> and I want to dig the standard to understand if the test is doing
>>> something wrong itself.
>> Anything new on this?
> Not yet. See my "Template argument deduction question" post. Unless
> anything clears up in a couple of days, I'll revert that "make
> parse_command_line const correct patch" that lead to this breakage.

Did you miss this reply from EDG? Hmm, it looks like they sent it to
me alone :(

attached mail follows:

On Jun 3, 2005, at 9:47 AM, David Abrahams wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.lib.boost.devel as well.
> Vladimir Prus <ghost_at_[hidden]> writes:
>> David Abrahams wrote:
>>>> Below is the test program:
>>>> char* cmdline3_[1] = {};
>>>> template<class charT>
>>>> void func(const charT* const argv[]) {}
>>>> int main()
>>>> {
>>>> // P is 'const charT* const argv[]'cmdline3_
>>>> // A is 'char* cmdline3_[]'
>>> I think A is 'char*[1]'
>> Yes, but it still should be converted to char** for template argument
>> deduction.
>>>> // According to
>>>> // If P is not reference type
>>>> // -If A is an array type, the pointer type produced
>>>> // by the array-to-pointer standard convertion (4.2)
>>>> // is used in place of A for type deduction.
>>>> //
>>>> // So, A should become 'char**'
>>>> // The following does not compile.
>>>> func(cmdline3_);
>>>> char** p = cmdline3_;
>>>> // This does compile, even though the argument type used for
>>>> // type deduction should be the same as in example above.
>>>> func(p);
>>>> }
>>>> Anybody can explain what's going on?
>>> It's well known that converting a char** into a char const** is a
>>> type-safety hole, so the language doesn't allow it (see D&E for the
>>> details, I think).
>> I know that. What's why the function argument is not (const charT*
>> argv[])
>> but (const charT* const argv[])
>>> 'char*[1]' converts (by array-to-pointer) to 'char**',
>>> but a 'const charT* const[]' parameter is equivalent to char const*
>>> const*', so a similar logic applies.
>> I don't think so. In the second call, passing "char**" to the same
>> function
>> works without any problems. It looks like in the first call, compiler
>> "forgets" to promote array to pointer.
> On second thought, I think you've found an EDG bug.

First, we agree that the two calls should make the same
target selection. Unfortunately, that doesn't just fall
out of a literal reading of the standard. We've opened
a Core issue to clarify that this should be the case.

The part of the standard that isn't entirely clear is (two paragraphs after the one quoted). It
specifies that normally the deduced type and the type A
transformed as "above" (i.e., as per the quoted should end up identical. However, they
are not identical in this case: There are cv-qualification
differences. For the second call, the second bullet of applies unambiguously. However, for the first
call type A is still "char*[1]" (the note that the type
should be "transformed as above" first, isn't repeated
here) and so the bullet doesn't apply since that is not
a pointer type.


        Daveed Vandevoorde
        Edison Design Group

Dave Abrahams
Boost Consulting

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