是CppUnit un-C ++ [英] Is CppUnit un-C++
问题描述
我终于得到了这个东西。有时可以说使用
释放cvs图像。 ： - /
我开始阅读文档，这个例子让我感到震惊，因为C ++的设计基本上是糟糕的。也许从某种意义上来说，设计是否会失败，或者它无法维持。但似乎有一些事情从根本上解决了这个问题。有没有人看到我在说什么
关于这里？
class ComplexNumberTest：public CppUnit :: TestFixture {
私人：
复杂* m_10_1，* m_1_1，* m_11_2;
公开：
void setUp（）
{
m_10_1 =新复合体（10,1）;
m_1_1 =新复合体（1,1）;
m_11_2 =新复合体（ 11,2;;
}
void tearDown（）
{
删除m_10_1;
删除m_1_1;
删除m_11_2;
}
void testEquality（）
{
CPPUNIT_ASSERT（* m_10_1 == * m_10_1）;
CPPUNIT_ASSERT（！（* m_10_1 == * m_11_2））;
}
void testAddition（）
{
CPPUNIT_ASSERT（* m_10_1 + * m_1_1 == * m_11_2）;
}
};
-
" [M]不喜欢预处理器众所周知。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - B. S.
I finally got this thing to build. There''s something to be said for using
the release of the cvs image sometimes. :-/
I started reading the docs, and this example struck me as a fundamentally
bad design for C++. Perhaps it''s not bad design in the sense that it will
fail, or that it can''t be maintained. But there seems to be something
fundamentally un-C++ about this. Does anybody else see what I''m talking
about here?
class ComplexNumberTest : public CppUnit::TestFixture {
private:
Complex *m_10_1, *m_1_1, *m_11_2;
public:
void setUp()
{
m_10_1 = new Complex( 10, 1 );
m_1_1 = new Complex( 1, 1 );
m_11_2 = new Complex( 11, 2 );
}
void tearDown()
{
delete m_10_1;
delete m_1_1;
delete m_11_2;
}
void testEquality()
{
CPPUNIT_ASSERT( *m_10_1 == *m_10_1 );
CPPUNIT_ASSERT( !(*m_10_1 == *m_11_2) );
}
void testAddition()
{
CPPUNIT_ASSERT( *m_10_1 + *m_1_1 == *m_11_2 );
}
};
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
推荐答案
" Steven T. Hatton" <苏****** @ setidava.kushan.aa>在留言中写道
news：34 ******************** @ speakeasy.net ...
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:34********************@speakeasy.net...
I终于搞定了这个东西。有时候使用
释放cvs图像有一些说法。 ： - /
我开始阅读文档，这个例子让我觉得它是一个从根本上说是糟糕的C ++设计。也许它的设计在某种意义上并不会失败，或者它无法维持。但似乎有一些基本上没有C ++的东西。有没有人看到我在说什么
关于这里？
I finally got this thing to build. There''s something to be said for using
the release of the cvs image sometimes. :-/
I started reading the docs, and this example struck me as a fundamentally
bad design for C++. Perhaps it''s not bad design in the sense that it will
fail, or that it can''t be maintained. But there seems to be something
fundamentally un-C++ about this. Does anybody else see what I''m talking
about here?
< snip>
是的，它看起来像Java的。赠品是使用普通指针和新的
，而不是使用本地复杂对象，或者至少使用智能
指针。这并不奇怪，因为（IIRC）CppUnit来自
JUnit。恕我直言，这并不表示设计不好;这只是一个不好的例子，它没有使用C ++的一些更好的功能。有没有其他的东西，你不喜欢它，除了它是'b
过度使用新的并忽略潜在的内存泄漏？
-
David Hilsee
<snip>
Yes, it looks like Java. The giveaway is the use of plain pointers and new
instead of using local Complex objects or, at the very least, smart
pointers. That''s not surprising, because (IIRC) CppUnit was derived from
JUnit. IMHO, it''s not an indication of a bad design; it''s just a bad
example that isn''t using some of the better features of C++. Is there
something else that you don''t like about it, besides the fact that it''s
overusing new and ignoring potential memory leaks?
--
David Hilsee
David Hilsee写道：
David Hilsee wrote:
是的，它看起来像Java。赠品是使用普通指针和
new而不是使用本地Complex对象，或者至少使用智能指针。
我同意使用局部变量会很有意义。我在这方面遇到了与b
冲突的目标。如果我对类类型使用本地
变量，它们要求我#include标题
包含它们在包含类的标题中的定义我是
定义。也就是说，而不是简单的前向声明。这也意味着我可能会引入更多的编译器依赖关系。我不得不考虑给
一个例子，但我知道可能会因为类型类型而导致问题
作为成员，而不是指向它们的指针。
OTOH，它使资源管理变得更加简单。
这并不奇怪，因为（IIRC）CppUnit源于JUnit 。
这就是文件所说的。
恕我直言，这并不表示设计不好;它只是一个不好的例子，它没有使用C ++的一些更好的功能。除了它是否过度使用新的并忽略潜在的内存泄漏之外，还有其他你不喜欢的东西吗？
Yes, it looks like Java. The giveaway is the use of plain pointers and
new instead of using local Complex objects or, at the very least, smart
pointers.
I agree that using local variables would make a lot of sense. There are
conflicting objectives I''ve run into in this regard. If I do use local
variables for class types, they require that I #include the headers
containing their definitions in the header containing the class I''m
defining. That is, instead of simply forward declaration. It also means I
may introduce more compiler dependencies. I''d have to think a bit to give
an example, but I know there can be problems caused by having class types
as members, rather than pointers to them.
OTOH, it makes resource management much simpler.
That''s not surprising, because (IIRC) CppUnit was derived from
JUnit.
That''s what the documentation says.
IMHO, it''s not an indication of a bad design; it''s just a bad
example that isn''t using some of the better features of C++. Is there
something else that you don''t like about it, besides the fact that it''s
overusing new and ignoring potential memory leaks?
如果Complex
对象是成员变量，我正在考虑一些不会成为问题的东西。但是如果使用指针对
有一个令人信服的论点，那么事情的组织方式似乎忽略了一些在C ++中基本的b
。这是一个四个字母的缩写。
-
[M]不喜欢预处理器是众所周知的。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - BS
I was thinking about something that would not be an issue if the Complex
objects were member variables. But if there were a compelling argument for
using pointers, the way things are organized seems to neglect something
fundamental in C++. It''s a four letter acronym.
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
Steven T. Hatton写道：
Steven T. Hatton wrote:
如果我对类类型使用局部变量，它们需要我＃包含
包含其定义的标题包含我定义的类。也就是说，而不是简单的前向声明。
通常，头文件中的任何内容都不包含局部变量，
除了内联函数。如果你有一个使用
类的内联函数，假设你想调用它上面的方法 - 无论如何都需要
类的头文件。这个论点不是很强大。
这也意味着我可能会引入更多的编译器依赖。
如果编译器正在跟踪你的依赖关系，那么请高兴。
你。有关代码的示例，请参阅make手册以自动生成描述标头依赖关系的$ make文件。其他，更多
复杂的构建工具会自动执行此操作。
...但我知道可能会因类成员类型而导致问题，而不是对它们的指示。
If I do use local variables for class types, they require that I #include
the headers containing their definitions in the header containing the class I''m
defining. That is, instead of simply forward declaration.
Typically, nothing in a header file contains local variables anyway,
except inline functions. And if you have an inline function using a
class, presumedly you''d want to call methods on it - which would require
the class''s header anyway. This argument isn''t very strong.
It also means I may introduce more compiler dependencies.
Be happy if the compiler is keeping track of your dependencies instead
of you. See the make manual for an example of code to automatically
generate makefiles describing header dependencies. Other, more
sophisticated build tools do this automatically.
...but I know there can be problems caused by having class types
as members, rather than pointers to them.
实际上我认为在可能的情况下，最好包括对象而不是指针
。它通常更有效率，因为它在通话过程中避免了间接费用，并且它不容易出错，因为你不需要
必须分配或取消分配对象（虽然使用auto_ptr也
就足够了）。主要问题是如果没有指针或引用，你就不能调用数据成员的多态行为，并且每个对象都可以只有一个地方b $ b s存储（冗余及其更新问题
）。
-
Derrick Coetzee
我授予此权限新闻组发布到公共领域。我不承担所有
明示或暗示保证并承担所有责任。我不是专业人士。
Actually I think it''s preferable to include objects rather than pointers
to them, where possible. It''s often more efficient, since it avoids an
indirection during calls, and it''s less error-prone, since you don''t
have to allocate or deallocate the object (although using auto_ptr also
suffices). The main problem is that without a pointer or reference you
can''t invoke polymorphic behaviour on data members, and every object can
have only one place where it''s stored (redundancy and its update issues
aside).
--
Derrick Coetzee
I grant this newsgroup posting into the public domain. I disclaim all
express or implied warranty and all liability. I am not a professional.
这篇关于是CppUnit un-C ++的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
