可以在指针的最低有效位中存储无关数据吗?

| 让我先说一下,我知道我将要提出的是一种致命的罪过,即使考虑到这一点,我也可能会在《编程地狱》中燃烧。 就是说,我仍然有兴趣知道是否有任何理由无法解决该问题。 情况是:我有一个引用计数智能指针类,该类在任何地方都可以使用。当前看起来像这样(注意:不完整/简化的伪代码):
class IRefCountable
{
public:
    IRefCountable() : _refCount(0) {}
    virtual ~IRefCountable() {}

    void Ref() {_refCount++;}
    bool Unref() {return (--_refCount==0);}

private:
    unsigned int _refCount;
};

class Ref
{
public:
   Ref(IRefCountable * ptr, bool isObjectOnHeap) : _ptr(ptr), _isObjectOnHeap(isObjectOnHeap) 
   { 
      _ptr->Ref();
   }

   ~Ref() 
   {
      if ((_ptr->Unref())&&(_isObjectOnHeap)) delete _ptr;
   }

private:
   IRefCountable * _ptr;
   bool _isObjectOnHeap;
};
今天,我注意到sizeof(Ref)= 16。但是,如果删除布尔成员变量_isObjectOnHeap,则sizeof(Ref)减小为8。这意味着程序中的每个Ref都浪费了7.875个RAM字节...而且我的程序中有很多很多Ref。 。 好吧,这似乎在浪费一些RAM。但是,我确实需要更多信息(好吧,使我幽默,并为讨论而做我确实会做的事情)。而且我注意到,由于IRefCountable是非POD类,因此(大概)它将始终分配在字对齐的内存地址上。因此,(_ ptr)的最低有效位应始终为零。 这让我感到奇怪...为什么没有任何理由不能将我的一小部分布尔数据放入指针的最低有效位,从而在不牺牲任何功能的情况下将sizeof(Ref)减半?当然,在取消对指针的引用之前,我必须小心将其与AND删除,这会使指针的引用效率降低,但是这可以通过以下事实来弥补:Ref现在更小,因此更多它们可以立即放入处理器的缓存中,依此类推。 这是合理的做法吗?还是我要为受伤的世界做好准备?如果是后者,那将如何伤害到我身上呢? (请注意,这是需要在所有相当现代的桌面环境中正确运行的代码,但不需要在嵌入式计算机或超级计算机或类似的任何异类中运行)     
已邀请:
        任何原因?除非最近标准中发生了变化,否则指针的值表示形式是实现定义的。当然,某个地方的某些实现可能会拉出相同的窍门,为自己的目的定义这些本来没有使用的低位。某些实现更有可能使用字指针而不是字节指针,因此,与其相邻的两个字不在\“ addresses \” 0x8640和0x8642,而在\“ addresses \” 0x4320和0x4321 。 解决该问题的一种棘手方法是使Ref成为(事实上的)抽象类,并且所有实例实际上都是RefOnHeap和RefNotOnHeap的实例。如果周围有很多引用,则用于存储三个类的代码和元数据而不是一个的额外空间将由每个Ref的一半大小所节省的空间来弥补。 (效果不是很好,如果没有虚拟方法,编译器可以忽略vtable指针,而引入虚拟方法会将4或8个字节加回到类中)。     
这里的问题是它完全依赖于机器。这不是人们经常在C或C ++代码中看到的东西,但是肯定在汇编中已经完成了很多次。旧的Lisp解释器几乎总是使用此技巧将类型信息存储在低位。 (我在C代码中看到过int,但在针对特定目标平台实施的项目中却看到过int。) 就个人而言,如果我试图编写可移植的代码,则可能不会这样做。事实是,它几乎肯定会在“所有合理的现代桌面环境”上运行。 (当然,它将在我能想到的每一个上都起作用。) 在很大程度上取决于代码的性质。如果您正在维护它,而没有其他人必须处理“痛苦的世界”,那么可能就可以了。您将必须为以后可能需要支持的任何奇怪的架构添加ifdef \。另一方面,如果您将其作为“便携式”代码发布到世界上,那将引起关注。 解决此问题的另一种方法是编写两个版本的智能指针,一个版本用于将在其上运行的计算机,另一个版本用于将不起作用的计算机。这样,只要同时维护两个版本,更改配置文件以使用16字节版本就没什么大不了的。 不用说,您必须避免编写任何其他代码,假设
sizeof(Ref)
是8而不是16。如果您使用单元测试,请在两个版本中都运行它们。     
        如果您只想使用标准功能而不依赖任何实现,那么使用C ++ 0x可以表达对齐方式(这是我最近回答的问题)。还有ѭ2可以可靠地获得足够大的无符号整数类型以容纳指针。现在保证的一件事是,从指针类型到
std::[u]intptr_t
的转换并返回到相同类型将产生原始指针。 我想您可能会争辩说,如果您可以找回原始的
std::intptr_t
(带遮罩),那么您可以得到原始的指针。我不知道这种推理有多扎实。 [编辑:仔细考虑,不能保证对齐的指针在转换为整数类型时可以采用任何特殊形式,例如一个没有设置一些位。可能在这里太多了]     
        即使此方法有效,也始终会存在不确定性,因为最终您将使用的内部体系结构可能是可移植的,也可能是不可移植的。 另一方面,要解决此问题,如果要避免使用
bool
变量,我建议使用一个简单的构造函数,
Ref(IRefCountable * ptr) : _ptr(ptr) 
{
  if(ptr != 0) 
    _ptr->Ref();
}
从代码中,我闻到只有当对象在堆上时才需要引用计数。对于自动对象,只需将
0
传递给
class Ref
,然后在构造函数/析构函数中放入适当的null检查。     
        您是否考虑过一流的存储? 根据您是否(或不必)担心多线程并控制new / delete / malloc / free的实现,可能值得尝试。 关键是,您无需维护本地计数器(对于对象而言是本地计数器),而是维护一个“ counter \”映射地址->计数,该计数将傲慢地忽略在分配区域之外传递的地址(例如,堆栈) 。 它看起来很愚蠢(MT中存在争用的空间),但由于只读对象不是仅为了计数而“修改”的,所以它在只读中也可以很好地发挥作用。 当然,我不知道您可能希望通过:p实现的性能     

要回复问题请先登录注册