shared_ptr without RTTI?

2019-02-22 00:10发布

问题:

Im trying to use shared_ptr in an embedded project which is build with xc32 1.34 (a derivative of gcc 4.5.2). The project has RTTI disabled with -fno-rtti.

#include <memory>

Just including the header gives me the following errors:

/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory: In member function 'virtual void* std::tr1::_Ref_count_del<_Ty, _Dx>::_Get_deleter(const std::type_info&) const':
In file included from APP/MODULES/LIGHT_MANAGER/LightManager.cpp:13:0:
/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory:1264:39: error: cannot use typeid with -fno-rtti
/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory: In member function 'virtual void* std::tr1::_Ref_count_del_alloc<_Ty, _Dx, _Alloc>::_Get_deleter(const std::type_info&) const':
/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory:1299:39: error: cannot use typeid with -fno-rtti
/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory: In function '_Dx* std::tr1::get_deleter(const std::tr1::shared_ptr<_Ty2>&)':
/Applications/microchip/xc32/v1.34/bin/bin/../../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/include/Cpp/memory:1956:44: error: cannot use typeid with -fno-rtti

So what i want to know is: is it generally impossible to use shared_ptr without RTTI, or am I doing something wrong?

回答1:

The problem is the get_deleter free function:

template<class D, class T> D* get_deleter(const shared_ptr<T>& p) noexcept;

Returns: If p owns a deleter d of type cv-unqualified D, returns std:addressof(d); otherwise returns nullptr. The returned pointer remains valid as long as there exists a shared_ptr instance that owns d.

Obviously, the most straightforward implementation of this is to store the typeid of the deleter in the control block. While there are other possible implementations they would (a) be more complicated, (b) lose binary compatibility with RTTI-enabled code, and (c) be against the "spirit" of -fno-rtti.

Another problematic function is dynamic_pointer_cast, which calls dynamic_cast on the stored pointer.

However, the main functionality of shared_ptr is implementable without the use of RTTI features, and indeed as Sergei Nikulov mentions above, the shared_ptr shipped with gcc 4.8.5 works with -fno-rtti, with the exception of the get_deleter and dynamic_pointer_cast functions; as long as you do not use those facilities there is no reason you should not be able to use shared_ptr. This can be contrasted with e.g. any, which is not implementable without the use of typeid.

It is the responsibility of your vendor to provide a standard library that works in all configurations of their compiler, including non-standard ones if they are supporting their use. However, if your vendor is noncooperative you still have a few options:

  • Patch the supplied standard library to remove the broken get_deleter code;
  • Use an alternative standard library (e.g. more recent libstdc++ or libc++);
  • Use an alternative smart pointer facility (e.g. Boost) or write one yourself.