which of these compilers has a bug, according to the standard? - c++

Given the following source code:
#include <memory>
#include <iostream>
using namespace std;
struct concept
{
virtual void perform() = 0;
};
struct model : concept, enable_shared_from_this<model>
{
void perform() override {
cout << "my pointer is " << shared_from_this().get() << endl;
}
};
int main(int argc, const char * argv[])
{
// shared_ptr<concept> concept_ptr = make_shared<model>();
shared_ptr<concept> concept_ptr { new model };
concept_ptr->perform();
return 0;
}
Compiling under gcc, this code compiles and associates the internal weak_ptr with the address of model.
Under clang the code will not compile (error message included at the end)
If you replace the initialisation of concept_ptr with shared_ptr<concept> concept_ptr = make_shared<model>(); it will compile on both.
Which is correct?
edit:
My version of clang is the one that ships with Xcode:
$ clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
edit2:
Just wanted to say thanks to everyone for contributing.
If you're interested, the reason I want to do this is that I want an opaque interface to an implementation with shared-handle semantics. Some implementations (async ones) require that callback objects ensure that the implementation object still exists (argues for shared_from_this and weak_ptr::lock). Other implementations do not require this. I wanted to avoid encumbering the concept (public interface) with the enable_shared_from_this<> base class, since that couples implementation with interface - a known evil.
In most cases, it's reasonable to use make_shared to create the implementation object. In rarer cases that require a custom destructor, the following seems portable:
auto concept_ptr = static_pointer_cast<concept>(shared_ptr<model> {
new model ,
[](model* self) {
// some_deletion_operation on self;
} });
appendix:
error message on clang:
In file included from /Users/richardh/Documents/dev/Scratchpad/tryit/tryit/try2.cpp:1:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:4013:35: error: no viable overloaded '='
__e->__weak_this_ = *this;
~~~~~~~~~~~~~~~~~ ^ ~~~~~
...etc...

I understand that libstdc++ follows the standard more closely here.
Concerning the requirements for
shared_ptr<T> shared_from_this();
shared_ptr<const T> shared_from_this() const;
both N3337 §20.7.2.4 (7) and N3936 §20.8.2.5 (7) only require
enable_shared_from_this<T> shall be an accessible base class
of T. *this shall be a subobject of an object t of type T. There shall
be at least one shared_ptr instance p that owns &t.
There is no requirement named that one shared_ptr owning &t actually has to be a shared_ptr<T> or shared_ptr<A_to_T_Convertible>.
And that very function is the core of that class' functionality.
Thus, given Tp as the actual param of the enabled_shared_from_this and Tp1 as the actual parameter of that owning shared_ptr, is_convertible<Tp1, Tp>::value == true, let alone is_same<Tp1, Tp>::value == true, is not required by the standard, same for respective pointers.
And indeed, the full output of clang++ using libc++ has
/usr/local/bin/../include/c++/v1/memory:3997:35: error: no viable overloaded '='
__e->__weak_this_ = *this;
~~~~~~~~~~~~~~~~~ ^ ~~~~~
/usr/local/bin/../include/c++/v1/memory:4035:5: note: in instantiation of
function template specialization
'std::__1::shared_ptr<concept>::__enable_weak_this<model>' requested here
__enable_weak_this(__p);
^
[...]enable_shared.cxx:34:25: note: in instantiation
of function template specialization
'std::__1::shared_ptr<concept>::shared_ptr<model>' requested here
shared_ptr<concept> model_ptr1(new model);
^
/usr/local/bin/../include/c++/v1/memory:4942:15: note: candidate function not
viable: no known conversion from 'std::__1::shared_ptr<concept>' to 'const
std::__1::weak_ptr<model>' for 1st argument
weak_ptr& operator=(weak_ptr const& __r) _NOEXCEPT;
^
/usr/local/bin/../include/c++/v1/memory:4953:15: note: candidate function not
viable: no known conversion from 'std::__1::shared_ptr<concept>' to
'std::__1::weak_ptr<model>' for 1st argument
weak_ptr& operator=(weak_ptr&& __r) _NOEXCEPT;
^
/usr/local/bin/../include/c++/v1/memory:4949:9: note: candidate template
ignored: could not match 'weak_ptr' against 'shared_ptr'
operator=(weak_ptr<_Yp> const& __r) _NOEXCEPT;
^
/usr/local/bin/../include/c++/v1/memory:4960:9: note: candidate template
ignored: could not match 'weak_ptr' against 'shared_ptr'
operator=(weak_ptr<_Yp>&& __r) _NOEXCEPT;
^
/usr/local/bin/../include/c++/v1/memory:4967:13: note: candidate template
ignored: disabled by 'enable_if' [with _Yp = concept]
is_convertible<_Yp*, element_type*>::value,
^
So libc++ here wants
is_convertible<Tp1* /*= Base* = concept**/, Tp* /*= Derived* = model* */>
which of course fails here, that the run-time *this of that very shared_ptr<Tp1> would be dynamic_cast-able to Tp* is out of ansatz here.
From this perspective, it's also clear why shared_ptr<concept> concept_ptr = make_shared<model>(); doesn't suffer from that; on the rhs there is a shared_ptr<Tp /* = derived = model */> constructor and for that ptr is_convertible holds.
libstdc++ doesn't suffer from this, because it passes the argument, thus its type (= Derived = model), of the shared_ptr<Tp1 /* = Base = concept*/> constructor down to the internal weak_ptr<T /*= Derived = model*/> assignment, not the shared_ptr in construction.
https://github.com/mirrors/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr_base.h#L848
template<typename _Tp, _Lock_policy _Lp>
class __shared_ptr
{
https://github.com/mirrors/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr_base.h#L858
template<typename _Tp1>
explicit __shared_ptr(_Tp1* __p)
: _M_ptr(__p), _M_refcount(__p)
{
__glibcxx_function_requires(_ConvertibleConcept<_Tp1*, _Tp*>)
static_assert( !is_void<_Tp1>::value, "incomplete type" );
static_assert( sizeof(_Tp1) > 0, "incomplete type" );
__enable_shared_from_this_helper(_M_refcount, __p, __p);
}
https://github.com/mirrors/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr_base.h#L1459
template<typename _Tp, _Lock_policy _Lp>
class __enable_shared_from_this
{
https://github.com/mirrors/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr_base.h#L1482
private:
template<typename _Tp1>
void
_M_weak_assign(_Tp1* __p, const __shared_count<_Lp>& __n) const noexcept
{ _M_weak_this._M_assign(__p, __n); }
template<typename _Tp1>
friend void
__enable_shared_from_this_helper(const __shared_count<_Lp>& __pn,
const __enable_shared_from_this* __pe,
const _Tp1* __px) noexcept
{
if (__pe != 0)
__pe->_M_weak_assign(const_cast<_Tp1*>(__px), __pn);
}
My point of view only; comments welcome.
#Richard Hodges: +1, very interesting topic

Related

Avoiding need to specify using operator=

I'm attempting to create a base class for creating helpers around various scoped operations, and to do so the base class allows the assignment of a callable. A simple predicate determines whether or not the callable is invoked. Regardless, the dtor is always invoked.
The catch is that each derived class needs to explicitly inherit the operator=. Is there a way to write the base class so that this is not required?
#include <functional>
#include <iostream>
using callback_t = std::function<void(void)>;
struct C
{
constexpr C(bool ok) : ok_{ok} {}
bool ok_ {false};
bool operator=(callback_t fn) const noexcept {
return ok_ ? fn(), true : false;
}
~C() noexcept {
std::cout << "end\n";
}
};
struct D final : public C
{
using C::operator=;
};
int main()
{
auto predicate = [] { return true; };
D{predicate()} = [] {
std::cout << "ok\n";
};
D{false} = [] {
std::cout << "wrong\n";
};
}
(also https://gcc.godbolt.org/z/eh8ncffos)
Removing the line from struct D
using C::operator=;
causes compile errors since Ds default copy-operator preempts C's custom operator=.
<source>: In function 'int main()':
<source>:24:9: error: no match for 'operator=' (operand types are 'D' and 'main()::<lambda()>')
24 | };
| ^
<source>:14:12: note: candidate: 'constexpr D& D::operator=(const D&)'
14 | struct D final : public C
| ^
<source>:14:12: note: no known conversion for argument 1 from 'main()::<lambda()>' to 'const D&'
<source>:14:12: note: candidate: 'constexpr D& D::operator=(D&&)'
<source>:14:12: note: no known conversion for argument 1 from 'main()::<lambda()>' to 'D&&'
<source>:27:9: error: no match for 'operator=' (operand types are 'D' and 'main()::<lambda()>')
27 | };
| ^
<source>:14:12: note: candidate: 'constexpr D& D::operator=(const D&)'
14 | struct D final : public C
| ^
<source>:14:12: note: no known conversion for argument 1 from 'main()::<lambda()>' to 'const D&'
<source>:14:12: note: candidate: 'constexpr D& D::operator=(D&&)'
<source>:14:12: note: no known conversion for argument 1 from 'main()::<lambda()>' to 'D&&'
The catch is that each derived class needs to explicitly inherit the operator=. Is there a way to write the base class so that this is not required?
No, this isn't possible.
The rule is that functions in different scopes do not overload. Since the derived class will always have something named operator= (either the derived class declares one itself, or the copy assignment operator is declared implicitly... even if it would be defined as deleted). So when you do derived = x;, name lookup for operator= will start in Derived and, having found candidates, stop there. It won't keep going to look into the base class... unless you bring in that candidate with a using-declaration like you demonstrated the question.
The only way to still use operator= but stash the functionality somewhere would be to actually invert your class hierarchy. Instead of:
struct C {
// ... implementation here ...
};
struct D : C {
using C::operator=;
};
// use D
you can do:
template <typename Derived>
struct C {
// implementation here
};
struct D { }
// use C<D>
This way, C is actually the class you're interacting with, so its operator= would be the first candidate considered.
Alternatively, if you simply don't use = as the spelling for this operation, every other operator is available and they would not need a using-declaration in the derived class to work.
Given the comment about wishing to avoid parentheses, your list of binary operators that would not require one are: ->*, +, -, *, /, %, ^, &, |, &&, ||, <, >, <<, and >> (plus the compound-assignment versions of those).
I'm deliberately excluding == and <=> from the list because those are special and just don't.

Can no longer convert between std::unique_ptr<Derived> to std::unique_ptr<Base>

So I have an issue in converting between a base and derived class after adding some code to (de)serialize for JSON. I am using the nlohmann JSON library. For background, here is the general original set up (before the JSON code):
class Base;
class Derived : public Base;
std::unique_ptr<Derived> Foo(Node x) {
std::unique_ptr<Derived> result;
/* Set some fields */
return result;
}
std::unique_ptr<Base> NodeToBase(Node x) {
std::unique_ptr<Base> result = nullptr;
switch (x->type):
case (SomeType):
result = Foo(x);
return result;
}
Before adding the changes, the following assertions worked:
static_assert(std::is_convertible<Derived*, Base*>::value);
static_assert(std::is_convertible<std::unique_ptr<Derived>, std::unique_ptr<Base>>::value);
Next, I added some serialization functions to my base and derived classes as such:
class Base {
virtual nlohmann::json ToJson() const;
virtual void FromJson(const nlohmann::json &j);
}
class Derived : public Base {
nlohmann::json ToJson() const override;
void FromJson(const nlohmann::json &j) override;
}
I also removed any const quantifiers on member variables in Base and Derived to allow for deserialization.
And now, after compiling, the static_assert's above no longer worked, and I get the following error.
foo.cpp:155:14: error: no viable overloaded '='
result = Foo(x);
~~~~~~ ^ ~~~~~~~
/usr/local/Cellar/llvm#6/6.0.1/include/c++/v1/memory:2347:28: note: candidate function (the implicit copy assignment operator) not viable: no known conversion from 'unique_ptr<Derived, default_delete<Derived>>' to 'const unique_ptr<Base, default_delete<Base>>' for 1st argument
class _LIBCPP_TEMPLATE_VIS unique_ptr {
^
/usr/local/Cellar/llvm#6/6.0.1/include/c++/v1/memory:2463:15: note: candidate function not viable: no known conversion from 'unique_ptr<Derived, default_delete<Derived>>' to 'unique_ptr<Base, default_delete<Base>>' for 1st argument
unique_ptr& operator=(unique_ptr&& __u) _NOEXCEPT {
^
/usr/local/Cellar/llvm#6/6.0.1/include/c++/v1/memory:2555:15: note: candidate function not viable: no known conversion from 'std::unique_ptr<Derived>' to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument
unique_ptr& operator=(nullptr_t) _NOEXCEPT {
^
/usr/local/Cellar/llvm#6/6.0.1/include/c++/v1/memory:2474:15: note: candidate template ignored: requirement 'is_convertible<typename unique_ptr<Derived, default_delete<Derived> >::pointer, pointer>::value' was not satisfied [with _Up = Derived, _Ep = std::__1::default_delete<Derived>]
unique_ptr& operator=(unique_ptr<_Up, _Ep>&& __u) _NOEXCEPT {
^
Any help would be appreciated. The only workaround I've found that works is to replace:
result = Foo(x);
with
result = std::unique_ptr<Base>(reinterpret_cast<Base *>(Foo(x).release()));

no viable overloaded '=' for overloaded static member functions

I have this simplified code consisting of a class with a static function, which is stored in map:
#include <iostream>
#include <functional>
#include <map>
class A {
public:
static void f(const std::string &s) { std::cout << s; }
};
std::map<std::string, std::function<void(std::string const &)>> fs;
int main() {
fs["f"] = &A::f;
fs["f"]("hello");
}
This prints the expected hello.
The problem occurs if I overload f() with:
static void f(const std::string &s, int c) { while(c-->0) { std::cout << s; } }
This results in the error:
error: no viable overloaded '='
fs["f"] = &A::f;
~~~~~~~ ^ ~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:2241:7: note: candidate function not viable: no overload of 'f' matching 'const std::function<void (const std::basic_string<char> &)>' for 1st argument
operator=(const function& __x)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:2259:7: note: candidate function not viable: no overload of 'f' matching 'std::function<void (const std::basic_string<char> &)>' for 1st argument
operator=(function&& __x)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:2273:7: note: candidate function not viable: no overload of 'f' matching 'nullptr_t' for 1st argument
operator=(nullptr_t)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:2302:2: note: candidate template ignored: couldn't infer template argument '_Functor'
operator=(_Functor&& __f)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:2311:2: note: candidate template ignored: couldn't infer template argument '_Functor'
operator=(reference_wrapper<_Functor> __f) noexcept
^
However, calling both functions works:
A::f("hello ");
A::f("echo ", 3);
So, my question are:
Why this code not compiling even though the operator= seems to exist and function if I don't overload f()?
How can I get it to work without giving both functions different names?
Why this code not compiling even though the operator= seems to exist
and function if I don't overload f()?
Because the compiler doesn't know which overload to choose. How could he? There is no criterion upon which he can decide which one is suited better. Every std::function allows arbitrary function objects to be assigned and doesn't check any signatures. If you wanted to save only function pointers of this particular signature you should have declared the map appropriately.
How can I get it to work without giving both functions different
names?
As already mentioned it works by casting the expression to a function pointer of the specific type.
fs["f"] = static_cast<void(*)(std::string const&)>( &A::f );
This way no ambiguities arise; There is exactly one overload that can be casted to this function to pointer type. If this appears more often then a typedef could be feasible.
Or a little helper class template:
template <typename... Exact>
struct funptr
{
template <typename R>
constexpr auto operator()(R(*p)(Exact...)) -> decltype(p)
{ return p; }
};
fs["f"] = funptr<std::string const&>()(&A::f);
Demo.

std::throw_with_nested expects polymorphic type in C++11?

Why does this not compile (tried with Clang 3.4.2 and GCC versions 4.7.4, 4.8.3 and 4.9.1):
#include <exception>
struct E { E(int) {} };
int main() {
std::throw_with_nested(E(42));
return 0;
}
Errors from GCC 4.9.1:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/exception:163:0,
from test.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h: In instantiation of 'static const std::nested_exception* std::__get_nested_helper<_Ex>::_S_get(const _Ex&) [with _Ex = E]':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:104:51: required from 'const std::nested_exception* std::__get_nested_exception(const _Ex&) [with _Ex = E]'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:138:38: required from 'void std::throw_with_nested(_Ex) [with _Ex = E]'
test.cpp:6:31: required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:90:59: error: cannot dynamic_cast '& __ex' (of type 'const struct E*') to type 'const class std::nested_exception*' (source type is not polymorphic)
{ return dynamic_cast<const nested_exception*>(&__ex); }
^
Errors from Clang 3.4.2:
In file included from test.cpp:1:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/exception:163:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:90:16: error: 'E' is not polymorphic
{ return dynamic_cast<const nested_exception*>(&__ex); }
^ ~~~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:104:40: note: in instantiation of member function 'std::__get_nested_helper<E>::_S_get' requested here
{ return __get_nested_helper<_Ex>::_S_get(__ex); }
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/bits/nested_exception.h:138:11: note: in instantiation of function template specialization 'std::__get_nested_exception<E>' requested here
if (__get_nested_exception(__ex))
^
test.cpp:6:8: note: in instantiation of function template specialization 'std::throw_with_nested<E>' requested here
std::throw_with_nested(E(42));
^
Does std::throw_with_nested in C++11 expect an argument with polymorphic type or is this a bug in the compiler or libstdc++?
It's a bug.
When I implemented it for libstdc++ in 2009 the spec in N2619 required E to be a polymorphic type, but the final spec in the 2011 standard is different and the implementation in libstdc++ was never changed.
This would appear to be a bug.
The standard says of std::throw_with_nested:
[[noreturn]] template <class T> void throw_with_nested(T&& t);
Let U be remove_reference<T>::type.
Requires: U shall be CopyConstructible.
Throws: if U is a non-union class type not derived from nested_exception, an exception of unspecified type that is publicly derived from both U and nested_exception and constructed from std::forward<T>(t), otherwise std::forward<T>(t).
§18.8.6 [except.nested]
It does indeed look like a bug (see other answers), ref §18.8.6/7. If not already derived from std::nested_exception, an unspecified type is used that is derived from E and nested_exception.
As a proposed work around whilst it is being fixed, explicitly derive from std::nested_exception or implement the destructor as virtual;
#include <exception>
struct E : std::nested_exception { E(int) {} };
// Alternative workaround... virtual destructor
// struct E { E(int) {} virtual ~E() {} };
int main() {
try {
std::throw_with_nested(E(42));
return 0;
}
catch (E&) {
}
}
Sample here.

Copy-initialization of simple RAII wrapper with lambda fails unexpectedly under GCC and Clang

I've come across an unexpected problem while creating a trivial RAII wrapper.
Let alone the logical incompleteness of the code below (copy-constructor and assignment operator not deleted etc., this is meant to be an SSCCE), what strikes me is that copy-initialization of my wrapper with a temporary lambda results in a compilation error, while direct-initialization does not.
This behavior can be observed both on GCC 4.7.2 and on Clang 3.2, while ICC 13.0.1 and VC10 compile both versions without problems.
#include <iostream>
#include <functional>
using namespace std;
struct A
{
template<typename F>
A(F&& f) : _f(forward<F>(f)) { }
~A() { _f(); }
private:
std::function<void()> _f;
};
int main()
{
// A a = [] () { cout << "Hello" << endl; }; // ERROR!
A a([] () { cout << "Hello" << endl; }); // OK
}
Who is right, and what is the problem with those who are wrong? Is it an issue with the implementation of the C++ Standard Library, or rather a compiler issue?
References to the C++11 Standard are particularly welcome.
EDIT:
Here is the error produced by Clang 3.2:
Compilation finished with errors:
In file included from source.cpp:2:
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/functional:1925:2: error: type 'A' does not provide a call operator
(*_Base::_M_get_pointer(__functor))(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/functional:2297:33: note: in instantiation of member function 'std::_Function_handler<void (), A>::_M_invoke' requested here
_M_invoker = &_My_handler::_M_invoke;
^
source.cpp:9:16: note: in instantiation of function template specialization 'std::function<void ()>::function<A>' requested here
A(F&& f) : _f(forward<F>(f)) { }
^
source.cpp:20:7: note: in instantiation of function template specialization 'A::A<A>' requested here
A a = [] () { cout << "Hello" << endl; }; // ERROR!
^
1 error generated.
The error message (gcc 4.7.2) is reasonably informative:
c++/4.7/functional: In instantiation of 'static void std::_Function_handler<void(_ArgTypes ...), _Functor>::_M_invoke(const std::_Any_data&, _ArgTypes ...) [with _Functor = A; _ArgTypes = {}]':
c++/4.7/functional:2298:6: required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor, typename std::enable_if<(! std::is_integral<_Functor>::value), std::function<_Res(_ArgTypes ...)>::_Useless>::type) [with _Functor = A; _Res = void; _ArgTypes = {}; typename std::enable_if<(! std::is_integral<_Functor>::value), std::function<_Res(_ArgTypes ...)>::_Useless>::type = std::function<void()>::_Useless]'
source.cpp:9:32: required from 'A::A(F&&) [with F = A]'
source.cpp:22:44: required from here
c++/4.7/functional:1926:2: error: no match for call to '(A) ()'
The problem is that your class does not have an implicit move constructor available for use in copy-initialization. The implicitly defined move constructor is deleted, since A has a user-defined destructor (12.8p9b4).
Add:
A(A &&) = default;
Note that since the defaulted move constructor is selected, the destructor should check that _f is non-empty; since the move constructor of std::function does not guarantee that the target is left empty, you should also perform that change yourself:
A(A &&a): _f() { std::swap(_f, a._f); }
~A() { if (_f) _f(); }
Recall that (per 8.5p17) a copy-initialization involves the creation of a prvalue temporary, which is then used to direct-initialize the target object. The choice is between the template constructor and the implicitly defined copy constructor; the template constructor with type template argument A is preferred, since A && binds to prvalue A better than const A & does.
An alternative (possibly better) is to disable the template constructor for A arguments:
template<typename F, typename = typename std::enable_if<!std::is_same<F, A>::value>::type>
A(F&& f) : _f(forward<F>(f)) { }
In this case the implicitly defined copy constructor will be selected, so the destructor doesn't need to check the state of _f; however if the compiler does not perform copy elision then it (and _f) will be called twice.
Copy-elision is allowed (12.8p31); the non-elided form must be accessible (12.8p32) but as far as I can tell (and by omission) the compiler is not required to check that it is compilable. So it is permissible for a compiler to either compile or refuse to compile the program; if it does compile, though, it must have performed copy elision.