问题描述

如果变量类型重载了 operator&()，则使用 & 获取变量的地址可能会出现问题.例如，_com_ptr_ 有 operator&() 重载，具有修改对象的副作用.

Using & to get an address of a variable can be problematic if the variable type has overloaded operator&(). For example, _com_ptr_ has operator&() overloaded with a side effect of modifying the object.

现在我有一组复杂的模板，具有如下功能:

Now I have a complicated set of templates with functions like this:

template<class T>
void process( const T* object )
{
    //whatever
}    

template<class T>
void tryProcess( T& object )
{
    process( &object )
}

在 tryProcess() 中，我需要获取一个 T* 指针，该指针包含 T 类型的实际对象的地址.

In tryProcess() I need to get a T* pointer holding the address of the actual object of type T.

上述 tryProcess() 的实现只有在 class T 没有重载 operator&() 时才能正常工作.因此，如果我调用 tryProcess<_com_ptr_<Interface>>() 我会得到意想不到的结果 - 重载的 operator&() 被触发.

The above implementation of tryProcess() will only work allright if class T doesn't have operator&() overloaded. So if I call tryProcess<_com_ptr_<Interface>>() I can get unexpected results - the overloaded operator&() is triggered.

在 另一个问题 以下解决方法是建议:

In another question the following workaround is suggested:

template<class T>
T* getAddress( T& object )
{
   return reinterpret_cast<T*>( &reinterpret_cast<char&>( object ) );
}

有了这样的函数，我可以实现 tryProcess() 如下:

With such a function I can implement tryProcess() as follows:

template<class T>
void tryProcess( T& object )
{
    process( getAddress( object ) )
}

并且将始终获得与 class T 是否重载 operator&() 无关的相同行为.这在 Visual C++ 7 上引入了优化的零开销 - 编译器得到要做什么并且只得到对象地址.

and will always get the same behavior independent of whether class T has operator&() overloaded. This introduces zero overhead with optimizations on on Visual C++ 7 - the compiler gets what to do and just gets the object address.

这个问题的解决方案的可移植性和标准兼容性如何?如何改进?

How portable and standard-compilant is this solution to the problem? How could it be improved?

推荐答案

是标准的投诉.该问题已提请 ISO C++ 委员会注意，该问题与 offsetof 实现相关的问题在此方面出现了问题.所考虑的解决方案包括收紧 POD 定义，或对要与 offsetof 一起使用的类型添加额外限制.当提出 reinterpret_cast 解决方案时，这些解决方案被拒绝了.由于这提供了一种解决问题的符合标准的方法，委员会认为没有必要向 offsetof 添加额外的要求，并保留了对实现的修复.

It is standard-complaint. The issue was brought to the attention of the ISO C++ committee in relation to problems with offsetof implementations that broke on this. Amongst the solutions considered were tightening the POD definition, or adding an extra restriction on types to be used with offsetof. Those solutions were rejected when the reinterpret_cast solution was brought up. Since this offered a standard-compliant way around the problem, the committee did not see a need to add extra requirements to the offsetof, and left fixes to the implementations.

这篇关于在 C++ 中获取变量地址的最便携和可靠的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！