[cfe-dev] Fwd: [libc++] Is libc++ compatible with previous c++ language standard implementation

Zeson Wu via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 8 07:31:48 PST 2018


Yes, how about the result? So I do not know the way libc++ source do that
losing semantic of copy construction is legal or not.

BTW, hmmmm, interesting email address name. 😀😂

2018-03-08 23:01 GMT+08:00 Hubert Tong <hubert.reinterpretcast at gmail.com>:

> This sounds related to http://cplusplus.github.io/LWG/lwg-active.html#2695
> .
>
> -- HT
>
> On Thu, Mar 8, 2018 at 2:49 AM, Zeson Wu via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> I don't know whether it is a bug, or the execution of copy constructor
>> does not matter.
>>
>> In c++ standard, there are such rules:
>>
>>>
>>>    1.
>>>
>>>    An implementation may declare additional non-virtual member function
>>>    signatures within a class:
>>>
>>>
>>>    -
>>>
>>>    (2.1)  —  by adding arguments with default values to a member
>>>    function signature;187 [ Note: An implementation may not add
>>>    arguments with default values to virtual, global, or non-member functions. —
>>>    end note ]
>>>    -
>>>
>>>    (2.2)  —  by replacing a member function signature with default
>>>    values by two or more member function signa-tures with *equivalent
>>>    behavior*; and
>>>
>>>            (2.3)  — by adding a member function signature for a member
>>> function name.
>>>
>>
>> So as the (2.2) said, for *pre* c++11, "explicit vector( size_type
>> count, const T& value = T(), const Allocator& alloc = Allocator());", could
>> be replaced by such 3 functions ((1), (3), (4)) as libc++ did.
>>
>> explicit vector(size_type __n);  // (1)
>>> #if _LIBCPP_STD_VER > 11
>>>     explicit vector(size_type __n, const allocator_type& __a);  // (2)
>>> #endif
>>>     vector(size_type __n, const_reference __x);  // (3)
>>>     vector(size_type __n, const_reference __x, const allocator_type&
>>> __a);  // (4)
>>
>>
>>  So now I am wondering whether the execution of copy constructor is
>> countered as *equivalent behavior*?
>>
>> 2018-03-08 14:40 GMT+08:00 alan snape <alansnape3058 at gmail.com>:
>>
>>> In clang, only format (1) will be used, so there is not copy
>>>> construction in *pre* c++11, but there should be a copy construction
>>>> as the reference declare "explicit vector( size_type count, const T&
>>>> value = T(), const Allocator& alloc = Allocator());".
>>>>
>>> I don't know either why they did not... (Maybe this is the reason why
>>> this project was started. :-) )
>>> The behavior is different, but the interfaces are compatible.
>>> I suggest you to read the C++ standard, and maybe submit a patch to
>>> handle this issue. (If you would like to do that.)
>>>
>>
>>
>>
>> --
>> Zeson
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>


-- 
Zeson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180308/211c9f95/attachment.html>


More information about the cfe-dev mailing list