[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