“我们不需要任何标题！” [英] "We don't need no steenking headers!"

问题描述

所以，就在不久前，我有了这种洞察力。它对我来说是个b $ b，当然一般来说，每个C ++的传统双文件头/实现分离有很好的理由



class，有些情况下这个范例没有贡献，

简单地引入额外的样板开销。


我想到的特殊情况是CppUnit试验。每个测试标题

只包含在相应的实现文件中，绝不是其他任何内容。实现文件使用

测试套件进行注册，这就是它的全部内容。所以，我根本没有想到有两个文件的原因。

我一想到这个，就问我我自己两个问题。首先，我

我错过了什么？是否有一些负面影响，我没有发生b $ b？其次，假设这不是单元测试案例所特有的现象，那么

的一般类别类别，同样的推理适用，属性是什么哪个

确定该类别的会员资格？


我很想听听别人对此的看法。我最初的估计是，这些类基本上是叶子类，没有额外的公共接口

。此外，在一个人可以构建这样一个类的情况下有限制，因为在Foo.cpp之外没有任何
代码甚至会*看到符号Foo。甚至整个

的东西都可以在匿名命名空间中！虽然有通用代码，但是有一个漏洞，

。例如，CppUnit的AutoRegisterSuite是一个

模板，它将测试类作为其类型参数，并且

实例化它。基于CRTP的设计功能类似。


所以...我没有任何令人眼花缭乱的结论。我觉得有很多一半的源代码文件似乎是值得的，因为

可理解性/维护，即使它只发生在

限制域名。我真的不想把我的设计改成

可以容纳这么精致，但这是我要考虑的事情。


无论如何，正如我所说...想法？


卢克

So, just a little while ago I had this flash of insight. It occurred
to me that, while of course in general there are very good reasons for
the conventional two-file header/implementation separation for each C++
class, there are cases in which this paradigm contributes nothing and
simply introduces extra boilerplate overhead.

The particular case I have in mind is CppUnit tests. Each test header
is only ever included by the corresponding implementation file, never
by anything else. The implementation file registers itself with the
test suite, and that''s all there is to it. So, I can''t think of any
reason at all for there to be two files.

As soon as I thought of this, I asked myself two questions. First, am
I missing anything? Is there some negative consequence that hasn''t
occurred to me? Second, assuming this isn''t a phenomenon unique to
unit test cases, that there is some general category of classes for
which the same reasoning applies, what are the properties which
determine membership in that category?

I''m interested in hearing others'' thoughts on this. My initial
estimation is that such classes will basically be leaf classes with no
additional public interface. Furthermore, there are restrictions on
the circumstances under which one can construct such a class, since no
code outside Foo.cpp will ever even *see* the symbol Foo. The whole
thing could be in an anonymous namespace, even! There is a loophole,
though -- generic code. For example, CppUnit''s AutoRegisterSuite is a
template which takes the test class as its type parameter, and
instantiates it. CRTP-based designs would function similarly.

So... I don''t have any dazzling conclusions. I think having half as
many source files to juggle seems like a worthwhile thing in terms of
comprehensibility/maintenance, even if it only takes place in
restricted domains. I don''t really see wanting to change my design to
accommodate such a nicety, but it''s something I''ll be mulling over.

Anyway, as I said... thoughts?

Luke

推荐答案

Luke Meyers写道：

Luke Meyers wrote:

所以，就在不久之前，我有了这种洞察力。我发生了这样的事情，当然一般情况下，每个C ++类的传统双文件头/实现分离都有很好的理由，有些情况下这个范例没有贡献，只是简单地引入了额外的样板开销。

我想到的特殊情况是CppUnit测试。每个测试标题
只包含在相应的实现文件中，而不是其他任何内容。实现文件将自己注册到
测试套件，而这就是它的全部内容。所以，我根本没有想到有两个文件的原因。
这取决于你构建测试套件或跑步者的位置。我的CppUnit

标题包括至少两个源文件。

我一想到这个，就问自己两个问题。首先，我错过了什么？是否有一些消极后果没有发生在我身上？其次，假设这不是单元测试用例所特有的现象，那么
有一些一般类别，同样的推理适用，哪些属性可以确定成员资格。那个类别？

当使用PIMPL习语时的实现类？

我有兴趣听听别人对此的看法。我最初的估计是这些类基本上是叶子类，没有额外的公共接口。此外，在可以构建这样一个类的情况下存在限制，因为Foo.cpp之外的代码甚至不会*看到符号Foo。整个
的东西可能在匿名命名空间中，甚至！有一个漏洞，但是 - 通用代码。例如，CppUnit的AutoRegisterSuite是一个
模板，它将测试类作为其类型参数，并实例化它。基于CRTP的设计可以起到类似的作用。

我能看到的最大问题是，如果这些

类中的一个停止成为叶子，你就会被惹恼。此外，如果您使用CppUnit，您可能需要

将私有标头包含在测试文件中。

所以...我没有任何令人眼花缭乱的结论。我认为，在可理解性/维护方面，有一半的源代码文件似乎是值得的，即使它只发生在受限制的域中。我真的不想改变我的设计以适应这种精致，但这是我要考虑的事情。

So, just a little while ago I had this flash of insight. It occurred
to me that, while of course in general there are very good reasons for
the conventional two-file header/implementation separation for each C++
class, there are cases in which this paradigm contributes nothing and
simply introduces extra boilerplate overhead.

The particular case I have in mind is CppUnit tests. Each test header
is only ever included by the corresponding implementation file, never
by anything else. The implementation file registers itself with the
test suite, and that''s all there is to it. So, I can''t think of any
reason at all for there to be two files.
That depend where you build your test suites or runners. My CppUnit
headers get include in at least two source files.
As soon as I thought of this, I asked myself two questions. First, am
I missing anything? Is there some negative consequence that hasn''t
occurred to me? Second, assuming this isn''t a phenomenon unique to
unit test cases, that there is some general category of classes for
which the same reasoning applies, what are the properties which
determine membership in that category?
Implementation classes when one is using the PIMPL idiom?
I''m interested in hearing others'' thoughts on this. My initial
estimation is that such classes will basically be leaf classes with no
additional public interface. Furthermore, there are restrictions on
the circumstances under which one can construct such a class, since no
code outside Foo.cpp will ever even *see* the symbol Foo. The whole
thing could be in an anonymous namespace, even! There is a loophole,
though -- generic code. For example, CppUnit''s AutoRegisterSuite is a
template which takes the test class as its type parameter, and
instantiates it. CRTP-based designs would function similarly.
Biggest problem I can see is that you are buggered if one of these
classes stops being a leaf. Also if you are using CppUnit, you may want
to include the private header in the test file.
So... I don''t have any dazzling conclusions. I think having half as
many source files to juggle seems like a worthwhile thing in terms of
comprehensibility/maintenance, even if it only takes place in
restricted domains. I don''t really see wanting to change my design to
accommodate such a nicety, but it''s something I''ll be mulling over.

我好猜测你可以将所有代码放在标题中（比如一些

编译器要求你做模板）并将它们全部包含在一个

源文件中进行编译。不漂亮！

-

Ian Collins。

Well I guess you could put all the code in the headers (like some
compilers require you do do with templates) and include them all in one
source file for compilation. No pretty!
--
Ian Collins.

Ian Collins写道：

Ian Collins wrote:

Luke Meyers写道：

Luke Meyers wrote:

我想到的具体案例是CppUnit测试。每个测试标题
只包含在相应的实现文件中，而不是其他任何内容。实现文件将自己注册到
测试套件，而这就是它的全部内容。所以，我完全没有想到有两个文件的原因。这取决于你构建测试套件或跑步者的位置。我的CppUnit
标题包含至少两个源文件。

The particular case I have in mind is CppUnit tests. Each test header
is only ever included by the corresponding implementation file, never
by anything else. The implementation file registers itself with the
test suite, and that''s all there is to it. So, I can''t think of any
reason at all for there to be two files.
That depend where you build your test suites or runners. My CppUnit
headers get include in at least two source files.

嗯，真的吗？我很好奇编译结构是什么样的，

以及你是否认为这是有利的。我有一个单独的

TestMain.cpp每个套件，它构建了跑步者并使用测试注册表

magic（读取：隐藏全局）来发现所有的测试，

私有地在他们自己的.cpp文件中。因此，不需要任何人来支持FooTest.h.

当使用PIMPL习惯用法时，实现类是什么？


嗯，肯定是一个没有标题的类的着名例子。我认为

这是一种不同的动物，例如小玩家

结构和其他助手。他们显然是从属的，很少与内部阶级不同。在这种情况下占主导地位的类仍然会有自己的标题。

我能看到的最大问题是如果其中一个类停止存在，你就会被惹恼一片树叶。


我认为这是一个非常温和的错误 - 所有你最终会做的是

将一个文件分成两个，没有真正的头痛。叶子类

成为基类几乎总是需要修改，

无论如何 - 引入受保护的成员，虚拟成员函数，

等。否则为什么继承？

此外，如果您使用CppUnit，您可能希望
在测试文件中包含私有标头。


你能解释一下你的意思吗？

我想你可以将所有代码都放在标题中（就像一些
编译器要求你做的那样）使用模板）并将它们全部包含在一个源文件中以进行编译。不漂亮！

Hmm, really? I''m curious what that compilation structure looks like,
and whether you feel that it''s advantageous. I have a single
TestMain.cpp per suite which builds the runner and uses test registry
magic (read: hidden globals) to discover all the tests which have,
privately within their own .cpp files. So, no need for anybody to
include FooTest.h.
Implementation classes when one is using the PIMPL idiom?
Hmm, certainly a well-known example of a class with no header. I think
this is a different sort of animal, as are for example little functor
structs and other helpers. They''re clearly subordinate, little
different from inner classes. The dominant class in such cases still
generally has its own header.
Biggest problem I can see is that you are buggered if one of these
classes stops being a leaf.
I think that''s a pretty mild buggering -- all you''d wind up doing is
splitting one file into two, no real headache involved. Leaf classes
which become base classes pretty much always require modification,
anyway -- introduction of protected members, virtual member functions,
and such. Otherwise why inherit?
Also if you are using CppUnit, you may want
to include the private header in the test file.
Could you explain what you mean?
Well I guess you could put all the code in the headers (like some
compilers require you do do with templates) and include them all in one
source file for compilation. No pretty!

是的，但这带来了一些众所周知的缺点 - 即，每次你需要重新编译下游类时，
实现

更改，而不是仅在接口更改时。而且，人们通常希望不要直接编译头文件，因此可能会导致令人头疼的问题。无论如何，对于我所描述的.cpp-only方法来说，这并不是很有用。


哦，还有一些其他解决方案到模板实例化

问题，顺便说一句。


我记得前一段时间有人发布了一篇关于
$的文章的链接b $ bC ++中的Java风格类这提出了另一个非常规的b $ b编译结构。我不记得特别相信，

但这是值得深思的。其他人有什么有趣的（ab？）使用

的C ++编译模型？


Luke

Yes, but this carries some pretty well-known drawbacks -- namely,
having to recompile downstream classes every time your implementation
changes, as opposed to only when the interface changes. Also, people
and tools generally expect not to compile header files directly, so
that could lead to headaches. Anyway, this doesn''t really have much in
common with the .cpp-only approach I described.

Oh, and there are some other solutions to the template instantiation
problem, by the way.

I recall a while ago someone posted on here a link to an essay about
"Java-style classes in C++" which proposed yet another unconventional
compilation structure. I don''t recall being particularly convinced,
but it was food for thought. Anyone else got any interesting (ab?)uses
of the C++ compilation model?

Luke

Luke Meyers写道：

Luke Meyers wrote:

Ian Collins写道：

Ian Collins wrote:

Luke Meyers写道：

Luke Meyers wrote:

我想到的特殊情况是CppUnit测试。每个测试标题
只包含在相应的实现文件中，而不是其他任何内容。实现文件将自己注册到
测试套件，而这就是它的全部内容。因此，我根本无法想到有两个文件。

这取决于您构建测试套件或跑步者的位置。我的CppUnit
标题包括至少两个源文件。

The particular case I have in mind is CppUnit tests. Each test header
is only ever included by the corresponding implementation file, never
by anything else. The implementation file registers itself with the
test suite, and that''s all there is to it. So, I can''t think of any
reason at all for there to be two files.

That depend where you build your test suites or runners. My CppUnit
headers get include in at least two source files.

嗯，真的吗？我很好奇编译结构是什么样的，
以及你是否认为它是有利的。我每个套件都有一个单独的TestMain.cpp，用于构建运行器并使用测试注册表
magic（读取：隐藏全局）来发现所有在他们自己的.cpp内私有的测试文件。所以，不需要任何人来包括FooTest.h。

Hmm, really? I''m curious what that compilation structure looks like,
and whether you feel that it''s advantageous. I have a single
TestMain.cpp per suite which builds the runner and uses test registry
magic (read: hidden globals) to discover all the tests which have,
privately within their own .cpp files. So, no need for anybody to
include FooTest.h.

我没有尝试过，也许我应该......

I haven''t tried that, maybe I should...

使用PIMPL习惯用法时的实现类？

Implementation classes when one is using the PIMPL idiom?

此外，如果您使用CppUnit，您可能希望
在测试文件中包含私有标头。

Also if you are using CppUnit, you may want
to include the private header in the test file.

你能解释一下你的意思吗？

Could you explain what you mean?

如何将单元测试作为叶班？

哦，还有一些顺便提一下模板实例化的其他解决方案。

使用一个不受它影响的编译器:)

我记得前一段时间有人发布了一篇关于
C ++中Java风格的类的文章的链接。这提出了另一种非常规的编译结构。我不记得特别相信，
但这是值得深思的。其他人有任何有趣的（ab？）使用C ++编译模型吗？

How to you unit test as leaf class?

Oh, and there are some other solutions to the template instantiation
problem, by the way.
Use a compiler that doesn''t suffer from it :)
I recall a while ago someone posted on here a link to an essay about
"Java-style classes in C++" which proposed yet another unconventional
compilation structure. I don''t recall being particularly convinced,
but it was food for thought. Anyone else got any interesting (ab?)uses
of the C++ compilation model?

嗯，这不是滥用，但如果你想简化事情 -

看到一些编译器可以在源文件中找到模板定义，

为什么C ++编译器不能使用搜索规则来查找头文件

遇到一堂课？如果你不确定我在说什么，请谷歌

" php autoload" ;.


-

Ian Collins。

Well it''s not an abuse, but if you are looking to simplify things -
seeing as some compilers can find template definitions in source files,
why can''t C++ compilers use search rules to find header files when they
encounter a class? If you''re not sure what I''m on about, google for
"php autoload".

--
Ian Collins.

这篇关于“我们不需要任何标题！”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！