Some background:
Extending namespace std
is undefined-behaviour(UB) unless it is a template specialization [1]:
It is undefined behavior to add declarations or definitions to namespace std or to any namespace nested within std, with a few exceptions noted below
There also questions on SO which also say it's an UB and a bad idea [2, 3].
We use boost::tr1
on platforms that don't have tr1
support (e.g., WinCE, WM). Boost does exactly this: injects its own implementation into std::tr1
if tr1
is not provided.
For example in boost/tr1/memory.hpp
:
namespace std{ namespace tr1{
using ::boost::bad_weak_ptr;
using ::boost::shared_ptr;
...
} }
My questions are:
Does this mean that it is UB if
boost::tr1
is used with non-tr1 compilers?Alternatively, is it okay to inject backports into
std
as long as developer makes sure that backported functionality is unavailable?If it is okay, can one take it one step further and inject
boost::tr1
intostd
instead ofstd::tr1
?
mystd
or something instead. Then you won't have to deal with any of these questions. – Eppsstd_
solution – Tennesseetypename = std::enable_if<....>
use a enable_if located somewhere else instead? There's nousing
in signatures. That's just one case. As for whether it's UB, "do as the compiler does" and you'll at most be as much UB as them. – Alexei