C 你写过很长的函数吗？若然，原因为何？

我正在写一篇关于这个问题的学术论文

为此，我在寻找现实生活中非常长的函数（几百条代码行）的例子，这样就不会考虑糟糕的编程（也就是说，它们不会从分派表的分解或使用中受益）。 你曾经写过或看过这样的代码吗？你能发布或链接到它，并解释为什么它这么长吗

我从这里的社区得到了惊人的帮助——任何将被纳入该项目的想法都将得到适当的认可

谢谢

---

Udi

我编写的最长函数都有一个共同点，一个非常大的switch语句。有时，您必须打开一长串的项，如果您试图将其中的一些选项重构为单独的函数，这只会使事情更难理解。拥有大的switch语句使圈复杂度达到极限，但它通常比替代实现要好。

以前的工作：一个非常长的case语句，IIRC 1000+行。这是很久以前的事了。每个选项只有几行长。拆散它会让事情变得不那么清楚。实际上，有一对这样的例程对同一组底层数据类型执行不同的操作

---

很抱歉，我没有代码了，反正也不是我可以发布的。

我可以想象，当速度很重要时（例如在内核中持有某种锁时），您不会因为函数调用的开销而希望中断函数。编译时，必须将参数推送到堆栈上，并在返回之前弹出数据。因此，出于效率考虑，您可能需要一个大型函数。

我认为最长但不可怕的函数是定制CPU虚拟机的关键方法。与@epotter一样，这涉及到一个大的switch语句。事实上，我要说的是，我发现很多方法都涉及到switch语句，它们被彻底分解或在可读性上得到改进。

不幸的是，如果在构建步骤中使用某种代码生成器自动生成这种类型的子例程，您通常不会在某个地方找到它

---

因此，请查找使用其他语言生成C的项目。

这是我被解雇之前的最后一个项目。

除了性能之外，我认为内核空间中调用堆栈的大小是8K（请验证大小）。而且，据我所知，内核中的代码是相当具体的。如果某些代码将来不太可能被重复使用，那么考虑到函数调用开销，为什么还要麻烦将其设置为函数呢。

您可能应该创建此社区wiki，因为这是一个个人问题。他不会这么做。而且他现在正在张贴复制品，这不太可能对他的研究项目有帮助。查看他的其他帖子寻找证据。没错。我看到你甚至在他之前的一个主题中提出了同样的建议。这不是昨天或前一天问的吗？是社区维基。不想复制；前面的问题不同。但是，如果您认为我应该关闭或删除该问题，我会这样做。也许，但正如Neil之前评论的那样，内联是这个问题的答案。

如果您试图将一些选项重构为单独的函数，只会使事情更难理解

我同意，但是使用案例列表和函数指针列表并映射它们怎么样？