我想知道在编写通用数据结构和C语言时，代码重复是否必定会带来麻烦？
在C中，对我而言，这绝对是我在C和C ++之间反弹的人。与C ++相比，我每天肯定会在C中复制更多琐碎的事情，但是故意地，并且我不一定认为它是“邪恶的”，因为至少有一些实际好处-我认为考虑所有事情是错误的严格来说是“好”还是“坏”-几乎所有事情都是权衡的问题。清楚地了解这些权衡是避免事后做出令人后悔的决定的关键，仅将事物标记为“好”或“邪恶”通常会忽略所有这些微妙之处。
正如其他人指出的那样，尽管问题并非C独有，但由于C中缺少比宏更宏，泛型指针无效的东西，非平凡的OOP的笨拙，C可能使问题更加恶化。 C标准库没有任何容器。在C ++中，实现自己的链表的人可能会激怒一群人，要求他们为什么不使用标准库，除非他们是学生。在C语言中，如果您不能自信地在睡眠中推出优雅的链表实现，那么您会招来愤怒的暴民，因为通常希望C程序员至少能够每天执行此类操作。它' 并不是由于对链接列表的某些奇怪的痴迷，Linus Torvalds使用SLL搜索和删除的实现，并使用双重间接作为标准来评估理解该语言并具有“良好品味”的程序员。这是因为C程序员可能需要在他们的职业生涯中实现一千多次这样的逻辑。在这种情况下，对于C来说，这就像厨师通过让新厨师准备一些鸡蛋来评估他们的技能来评估他们的技能，以了解他们是否至少掌握了所有需要做的基本事情。
例如，对于使用此分配策略的每个站点，我可能已经在C中本地实现了这种基本的“索引自由列表”数据结构十几遍（几乎我所有的链接结构都避免了一次分配一个节点并将内存减半） 64位链接的费用）：
但是在C语言中，realloc当实现一个使用该数组的新数据结构时，只需将很少的代码存储到一个可增长的数组中，并使用索引方法将这些存储池中的一些内存用于空闲列表。
现在，我用C ++实现了同样的事情，而在这里我只将它作为类模板实现了一次。但这是C ++方面非常复杂的实现，包含数百行代码以及一些外部依赖关系，这些依赖关系也跨越数百行代码。而且它更复杂的主要原因是因为我不得不针对T可能是任何可能的数据类型的想法进行编码。它可以在任何给定的时间抛出（销毁它时除外，我必须像使用标准库容器一样显式地进行销毁），我必须考虑适当的对齐方式才能为T （尽管幸运的是，这在C ++ 11起变得更加容易），它可能是不可平凡的可构造/可破坏的（要求放置新的和手动的dtor调用），我必须添加一些方法，并不是所有东西都需要，但有些东西需要，而且我必须添加迭代器，包括可变迭代器和只读（常量）迭代器，依此类推。
可增长的阵列不是火箭科学
在C ++中，人们听起来像是std::vector火箭科学家的工作，经过优化以致于死亡，但它的性能没有比针对特定数据类型编码的动态C数组更好，后者仅用于realloc通过使用十几行代码。所不同的是，要使可增长的随机访问序列完全符合标准需要非常复杂的实现，避免在未插入元素上调用ctor（异常安全），提供const和非const随机访问迭代器，使用类型对于某些整数类型的特征，可以将范围控制器的填充控制器消除歧义T，可能会使用类型特征等对POD进行不同处理。等等。实际上，您确实需要一个非常复杂的实现来仅使可增长的动态数组成为可能，但这仅是因为它试图处理所有可能的用例。从好的方面来说，如果您确实需要存储POD和非平凡的UDT，并且可以使用可用于任何兼容数据结构的基于通用迭代器的算法，则可以从所有额外的工作中受益匪浅，从异常处理和RAII中受益，至少有时std::allocator使用您自己的自定义分配器进行覆盖等。当您考虑多少收益时，它肯定会在标准库中获得回报std::vector 在使用它的人们的整个世界上都有过，但这是针对旨在满足整个世界需求的标准库中实现的。
处理非常具体的用例的更简单的实现
由于仅使用“索引的免费列表”处理了非常具体的用例，尽管在C端实现了12次此免费列表，并因此重复了一些琐碎的代码，但我编写的代码可能更少了在C中实现该功能的总次数比在C ++中实现一次的总次数要多，而维护这十几个C实现的时间却比维护一个C ++实现的时间少。C端如此简单的主要原因之一是，每当我使用此技术时，我通常都会使用C中的POD进行操作，而我通常不需要的功能比insert和erase在我在本地实施此功能的特定站点上。基本上，我可以只实现C ++版本提供的功能中最细小的子集，因为当我针对特定用途实现设计时，我可以自由地对设计的用途做更多的假设案件。
现在，C ++版本更加好用，而且类型安全，但是仍然是实现和使异常安全和双向迭代器兼容的主要PITA，例如，以一种可能会重复使用的通用实现方式在这种情况下，比实际节省的时间更多。而且，以普遍的方式实施它的大量成本不仅浪费在前期，而且以诸如每天不断增加的构建时间不断增加的形式反复浪费。
不是对C ++的攻击！
但这并不是对C ++的攻击，因为我喜欢C ++，但是在数据结构方面，我主要偏向于C ++，主要是因为我想花费很多额外的时间来预先实现这些真正不平凡的数据结构。这是一种非常通用的方法，可以针对所有可能类型的异常安全T，使符合标准的标准和可迭代性等等，在这种情况下，这种类型的前期成本确实可以以数英里的里程数回报。
但这也促进了非常不同的设计思想。在C ++中，如果我想为碰撞检测创建一个Octree，则倾向于将其推广到n级。我不只是要使其存储索引的三角形网格。当我唾手可得的超级强大的代码生成机制消除了运行时的所有抽象代价时，为什么要将它限制为只能使用一种数据类型呢？我希望它存储过程球体，多维数据集，体素，NURB表面，点云等，并尝试使其适用于所有事物，因为当您唾手可得的模板时，很想以这种方式进行设计。我什至不想将其限制为碰撞检测-光线跟踪，拾取等如何？C ++使其最初看起来“很简单” 将数据结构推广到第n级。这就是我过去在C ++中设计此类空间索引的方式。我试图设计它们以解决整个世界的饥饿需求，而我得到的通常是“万事通”，其代码极其复杂，以使其与可想到的所有可能用例保持平衡。
有趣的是，这些年来，我已经在C中实现的空间索引中得到了更多的重用，而且C ++完全没有错，而只是挖掘了该语言诱使我去做的事情。当我用C编写八叉树之类的代码时，我倾向于使它与点一起工作并对此感到满意，因为这种语言甚至很难将其推广到n级。但是由于这些趋势，多年来，我倾向于设计一些实际上更有效，更可靠的方法，并且非常适合手头的某些任务，因为它们不必担心通用性。他们成为一个专业类别的王牌，而不是所有行业的王牌。同样，这并不是C ++的错，而只是我在使用它而不是C时的人性化倾向。
但是无论如何，我喜欢两种语言，但是有不同的倾向。在CI中，有一种趋势，即不能一概而论。在C ++中，我倾向于概括太多。同时使用这两种方法可以帮助我平衡自己。
通用实现是规范，还是针对每个用例编写不同的实现？
对于一些琐碎的事情，例如使用数组中的节点或重新分配自身的数组（std::vector在C ++中与analog等效）的单链接32位索引列表，或者说是仅存储点并旨在不做任何事情的八叉树，我不会不必再泛泛到存储任何数据类型的地步。我实现了这些功能以存储特定的数据类型（尽管它可能是抽象的，并且在某些情况下使用函数指针，但至少比具有静态多态性的鸭子类型更具体）。
我对这些情况下的一点冗余感到非常满意，但前提是我要对其进行彻底的单元测试。如果我不进行单元测试，那么冗余就会变得更加不舒服，因为您可能拥有冗余代码，这些重复代码可能会重复出现错误，例如，即使您编写的代码类型不太可能需要进行设计更改，它可能仍然需要更改，因为它已损坏。我倾向于为我编写的C代码编写更全面的单元测试。
对于非同寻常的事情，通常是在接触C ++时，但是如果我要在C中实现它，我会考虑只使用void*指针，也许接受一个类型大小来知道为每个元素分配多少内存，以及可能使用copy/destroy函数指针深度复制和销毁数据，如果它们不是不可构造/不可破坏的。大多数时候，我不会打扰也不用太多的C语言来创建最复杂的数据结构和算法。
如果您经常使用一种数据结构处理特定的数据类型，则还可以将一种类型安全的版本包装在仅与位和字节以及函数指针一起使用的版本上void*，例如，通过C包装器重新施加类型安全性。
例如，我可以尝试为哈希映射编写通用实现，但是我总是发现最终结果很混乱。我还可以针对该特定用例编写专门的实现，使代码清晰易读，易于调试。后者当然会导致某些代码重复。
哈希表有点不稳定，因为如果需要自动隐式地增长表或可以预期表的大小，则哈希表的实现可能很琐碎，也可能非常复杂，具体取决于您对哈希，哈希表的需求的复杂程度。高级，无论您使用开放式寻址还是单独的链接等。但是要记住的一件事是，如果您完全根据特定站点的需求量身定制了一个哈希表，则它的实现通常不会那么复杂，并且通常会赢得如果为这些需求量身定做，它就不会那么多余。如果我在本地实现某些功能，至少这是我给自己的借口。如果不是，您可能只使用上述方法void*和函数指针来复制/销毁事物并将其概括化。
如果您的替代方案非常狭窄地适用于您的确切用例，那么通常不需要很费力气或很多代码就能击败非常通用的数据结构。举个例子，malloc用代码一次又一次地击败每个节点的使用性能绝对是微不足道的（而不是为多个节点池大量内存）即使malloc出现了更新的实现。击败它可能要花费一辈子的时间，并且编写同样复杂的代码，如果要匹配它的通用性，您必须将一生的大部分时间用于维护和更新它。
再举一个例子，我经常发现实现比Pixar或Dreamworks提供的VFX解决方案快10倍以上的解决方案非常容易。我可以在睡觉的时候做。但这不是因为我的实现出色-远非如此。对于大多数人来说，他们是完全卑鄙的。它们仅对我非常非常特定的用例而言是优越的。我的版本远不及Pixar或Dreamwork的普遍适用。这是一个荒谬的不公平的比较，因为与我的简单解决方案相比，他们的解决方案绝对出色，但这就是重点。比较不一定是公平的。如果您只需要一些非常具体的内容，则无需使数据结构处理无数无用的列表。
同质位和字节
在C语言中，由于它本质上缺乏类型安全性，因此需要加以利用的一件事是，根据位和字节的特性来均匀地存储事物。内存分配器和数据结构之间还有更多的模糊。
但是存储一堆可变大小的东西，甚至事情，只是可能是大小可变的，就像一个多态Dog及Cat，难以有效地做到。您不能假设它们可以可变大小并将它们连续存储在一个简单的随机访问容器中，因为从一个元素到另一个元素的步幅可能会有所不同。结果是要存储一个同时包含狗和猫的列表，您可能必须使用3个单独的数据结构/分配器实例（一个用于狗，一个用于猫，一个用于基本指针或智能指针的多态列表，或更糟糕的是，将每个狗和猫分配给通用分配器，然后将它们分散到整个内存中），这会变得昂贵，并招致高速缓存未命中的份额。
因此，尽管降低了类型丰富性和安全性，但在C中使用的一种策略是在位和字节级别上进行概括。您可能可以假定Dogs并Cats要求使用相同数量的位和字节，具有相同的字段以及指向函数指针表的相同指针。但是，作为交换，您可以减少对数据结构的编码，但同样重要的是，可以有效且连续地存储所有这些内容。在这种情况下，您像对待类比工会一样对待狗和猫（或者您可能实际上只是使用了工会）。
确实要付出巨大的代价来键入安全性。如果在C中我想念的比什么都重要，那就是类型安全。它越来越接近汇编级别，在该级别结构仅指示分配了多少内存以及如何对齐每个数据字段。但这实际上是我使用C的第一原因。如果您确实要控制内存布局以及所有内容的分配位置以及彼此之间相对存储的位置，那么通常只需要按位和级别考虑即可。字节，以及解决特定问题所需的位数。在那里，C的类型系统的笨拙实际上可以变得有益而不是障碍。通常情况下，最终导致要处理的数据类型要少得多，
虚假/表观重复
现在，我一直在宽松地使用“复制”来处理甚至可能不是多余的事情。我已经看到人们将“偶然/表观”重复与“实际重复”区别开来。我的看法是，在许多情况下没有如此明显的区别。我发现这种区别更像是“潜在唯一性”与“潜在重复性”之间的区别，无论哪种方式都可以。它通常取决于您希望设计和实现如何发展，以及它们将如何针对特定用例进行完美定制。但是我经常发现，在经过多次改进之后，后来看起来似乎是代码重复的东西不再是多余的。
使用realloc与的类比等效的简单可增长数组实现std::vector<int>。最初，例如std::vector<int>在C ++中使用它可能是多余的。但是您可能会发现，通过测量，预先分配64个字节以允许插入16个32位整数而不需要进行堆分配可能是有益的。现在，它不再是多余的，至少不是std::vector<int>。然后您可能会说：“但是我可以将其概括为new SmallVector<int, 16>，并且可以。但是然后我们说您发现它很有用，因为它们是用于非常短的，短寿命的数组，使堆分配的数组容量增加四倍，而不是增加1.5（大约是vector实现时使用），同时假设阵列容量始终是2的幂。现在，您的容器确实有所不同，并且可能没有像它这样的容器。也许您可以尝试通过添加越来越多的模板参数来自定义预分配繁重，自定义重新分配行为等来概括此类行为，但是到那时，与十几行简单的C语言相比，您可能会发现确实难以使用码。
甚至可能达到需要分配256位对齐和填充内存的数据结构，专门存储AVX 256条指令的POD，预先分配128字节以避免普通情况下小输入大小的堆分配，容量翻倍的数据结构的程度。已满，并允许安全覆盖超过数组大小但不超过数组容量的尾随元素。在这一点上，如果您仍在尝试推广一种解决方案，以避免重复少量的C代码，那么编程之神可能会对您的灵魂充满怜悯。
因此，在类似的情况下，当您开始量身定制解决方案以使其越来越好并更好地适合特定用例时，这种情况最初看上去就开始变得多余，而冗余完全消失了。但这仅适用于您有能力针对特定用例完美定制它们的事情。有时，我们只需要针对我们的目的将其概括的“体面”的东西，在那儿，我将从非常通用的数据结构中受益最大。但是，对于针对特定用例完美地完成的特殊事情，“通用”和“针对我的目的完美”的想法开始变得太不兼容了。
POD和基元
现在，在C语言中，我经常会找到借口将POD（尤其是图元）存储到数据结构中。这似乎是一种反模式，但实际上我发现它无意中有助于提高代码的可维护性，而这些能力是我过去在C ++中经常要做的事情的类型。
一个简单的例子是插入短字符串（这通常是用于搜索关键字的字符串的情况-它们往往很短）。为什么还要处理所有这些长度可变的字符串，这些字符串在运行时会发生变化，这意味着不平凡的构造和破坏（因为我们可能需要堆分配和释放）？如何将这些内容存储在中央数据结构中，例如仅用于字符串实习的线程安全的trie或哈希表，然后使用普通旧字符int32_t或引用这些字符串：
struct IternedString
{
int32_t index;
};
...在我们的哈希表，红黑树，跳过列表等中，如果我们不需要字典排序？现在，我们编码为与32位整数一起使用的所有其他数据结构现在都可以存储这些有效的只是32位的字符串键ints。而且我至少在用例中发现了（由于我从事射线跟踪，网格处理，图像处理，粒子系统，绑定到脚本语言，低级多线程GUI套件实现等领域，因此可能只是我的领域了-底层代码，但不像OS那样底层代码），代码恰好存储这样的索引恰好变得更加高效和简单。因此，我经常在75％的时间里以公正int32_t和float32 在我不平凡的数据结构中，或者只是存储相同大小的东西（几乎总是32位）。
当然，如果这适用于您的情况，则可以避免针对不同数据类型使用多种数据结构实现，因为一开始您将只使用很少的数据结构。
测试与可靠性
我要提供的最后一件事可能并不适合所有人，那就是赞成为这些数据结构编写测试。让他们真正擅长某事。确保它们非常可靠。
在这些情况下，一些次要的代码重复变得可以原谅，因为如果您必须对重复的代码进行级联更改，那么代码重复只是维护负担。通过确保冗余代码超可靠并且确实非常适合其工作，您消除了更改此类冗余代码的主要原因之一。
这些年来，我的审美观念发生了变化。我不再烦恼，因为我看到一个库实现了点积或已经在另一个库中实现的一些琐碎的SLL逻辑。我只会在事情测试不佳且不可靠时感到恼火，而且我发现这种思维方式更具生产力。我真正处理过的代码库是通过重复的代码来复制错误，并且看到了复制和粘贴编码的最坏情况，使原本应该微不足道的更改变成一个集中的地方，却变成了容易出错的级联更改。然而，在许多情况下，这是由于测试失败，代码未能变得可靠和擅长于其最初所做的事情而导致的。在我使用有问题的旧代码库之前，我的想法与所有形式的代码复制相关，因为它们很可能复制错误并需要级联更改。然而，即使在某个地方或那里有一些看起来很冗余的代码，微型图书馆如果做得非常好并且非常可靠，那么将来几乎不会发现需要更改的原因。当时我的工作重点没有了，那时候重复让我感到烦恼的不仅仅是质量差和缺乏测试。后面这些事情应该是头等大事。
极简代码复制？
这是一个很有趣的想法，突然出现在我的脑海中，但考虑到一种情况，我们可能会遇到一个C和C ++库，它们大致具有相同的作用：两者具有大致相同的功能，相同的错误处理量，但并不是很明显而且效率更高。最重要的是，两者均能胜任地实施，经过良好的测试和可靠。不幸的是，在这里我不得不假设地说，因为我还没有发现任何接近完美的并排比较的东西。但是，我所发现的与这种并排比较最接近的东西通常是C库比C ++等效库小得多（有时是其代码大小的1/10）。
而且我相信这样做的原因是，再次以通用方式解决问题，即处理最广泛的用例而不是一个确切的用例，可能需要数百到数千行代码，而后者可能只需要一打。尽管存在冗余，并且尽管C标准库在提供标准数据结构方面非常糟糕，但它最终最终却减少了人工编写代码来解决相同的问题，我认为这主要是由于两种语言在人类倾向上的差异。一种促进针对非常特定的用例解决问题，另一种倾向于针对最广泛的用例促进更抽象和通用的解决方案，但这些最终结果并没有
前几天，我在github上看某人的raytracer，它是用C ++实现的，所以需要这么多的玩具raytracer代码。而且我没有花太多时间在看代码，但是那里有大量的通用结构可以处理，远远超出了raytracer的需求。而且我认识到这种编码风格，因为我过去曾经以一种超级自下而上的方式使用C ++，重点是首先制作一个非常通用的数据结构的成熟库，该库首先要超越即时数据。解决眼前的问题，然后再解决实际问题。但是，尽管这些通用结构可能会在这里和那里消除一些冗余，并在新的上下文中享有很多重用性，作为交换，它们通过交换一些冗余与大量不必要的代码/功能来极大地膨胀项目，而后者不一定比前者容易维护。相反，我经常发现很难维护，因为很难维护通用设计，而通用设计必须严格平衡设计决策与可能的最广泛需求。