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

[Zeson Wu via cfe-dev]

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