Mus*_*ful 6 c++ pointers memory-management cross-platform 32bit-64bit
我希望就如何处理我即将进行的设计提出一些高级建议.
解决我的问题的直接方法将导致数以百万计的指针.在64位系统上,这些可能是64位指针.但就我的应用程序而言,我认为我不需要超过32位的地址空间.我仍然希望系统能够利用64位处理器算法(假设这是我在64位系统上运行得到的).
我正在实现一个树状数据结构,其中每个"节点"包含一个8字节的有效负载,但也需要指向四个相邻节点(父节点,左子节点,中间子节点,右子节点)的指针.在使用64位指针的64位系统上,这相当于32字节,仅用于将8字节有效负载链接到树中 - "链接开销"为400%.
数据结构将包含数百万个这样的节点,但我的应用程序除此之外不需要太多内存,因此所有这些64位指针看起来都很浪费.该怎么办？有没有办法在64位系统上使用32位指针？
我考虑过了
将有效载荷存储在数组中,使得索引暗示(并暗示)"树地址",并且可以使用该索引上的简单算术计算给定索引的邻居.不幸的是,这需要我根据树的最大深度调整数组的大小,这是我事先不知道的,并且由于较低级别中的空节点元素,它可能会产生更大的内存开销,因为不是树的所有分支走到同样的深度.
将节点存储在一个足够大的数组中以保存所有节点,然后使用索引而不是指针链接邻居.AFAIK这里的主要缺点是每个节点都需要数组的基地址才能找到它的邻居.所以他们要么需要存储它(一百万次),要么需要传递每个函数调用.我不喜欢这个.
假设所有这些指针中最重要的32位为零,如果不是则抛出异常,并且仅存储最低有效32位.因此可以根据需要重建所需的指针.该系统可能使用超过4GB,但该过程永远不会.我只是假设指针偏离了进程基地址,并且不知道这对于通用平台(Windows,Linux,OSX)有多安全(如果有的话).
存储64位和64位指针之间的差异this,假设这个差异将在int32_t(并且如果不是)的范围内.然后任何节点都可以通过添加该偏移来找到它的邻居this.
有什么建议？关于最后一个想法(我目前认为这是我最好的候选人),我可以假设在一个使用少于2GB的进程中,动态分配的对象将彼此相差2 GB以内吗？或者根本不是吗？
结合问题中的想法2和4，将所有节点放入一个大数组中，并存储eg int32_t neighborOffset = neighborIndex - thisIndex。然后你可以从 获取邻居*(this+neighborOffset)。这消除了 2 和 4 的缺点/假设。