Does anybody know that whether libc++ is compatible with previous c++ language standard implementation or not? For example, I know libc++ is now support c++11, I will show a example.
http://en.cppreference.com/w/cpp/container/vector/vector. In the reference, there are two different constructors for vector,
explicit vector( size_type count, const T& value = T(), const Allocator& alloc = Allocator()); (until C++11) (1)
explicit vector( size_type count );(since C++11) (until C++14) (2)
If I use vector a(1), which one will be chosen with different c++ std command option, such as -std=c++03, -std=c++11? Actually, I can not find the (1) version in libc++ source.
In my option, both two functions should be implemented and guarded by related language level macro, but I can not find in libc++ source. So libc++ is not compatible with previous c++ language standard implementation?
I’m not sure about libc++'s support for pre-C++11, but I think it does support earlier standards. The constructor you’re asking about isn’t a great example to look at. The function signature (1) was split into two different functions in C++11 rather than using a defaulted argument. But the calling code shouldn’t be able to tell the difference. It doesn’t require any code changes on the user’s part.
It also looks like even the defaulted argument for alloc is implemented in libc++ with different signatures which is different than what the spec says. But again user code can’t tell.
As a template class, it is impossible to find the
std::vector class in libc++. When writing a template class, all the code need during compile-time should be provided in the header file; and when compiling with a template class/function, the template parameter will be replaced with the concrete type/argument. As you can see, this is just a compile-time process rather than a link-time process, much less the libc++.
Sorry to not reply to all. So FYI.
Sorry to not reply to all. So FYI.
OK, I got your meaning. Let’s summarize the interfaces declared on http://en.cppreference.com/w/cpp/container/vector/vector and then go over the implementation of libc++ version.
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());”.
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.)
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:
- 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)
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?
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.
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.
I am not aware of there being direction from the committee to make it
legal; however, that possibility has not been rejected either.