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

Hubert Tong via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 8 07:01:45 PST 2018


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180308/c9f8dd44/attachment.html>


More information about the cfe-dev mailing list