Re: [Cppunit-devel] macros and templates

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Wednesday, June 06, 2001 3:56 PM
Subject: Re: [Cppunit-devel] macros and templates
> OK.  But here's the problem.  The file config.h is automatically
> generated (by configure) from config.h.in.  So we don't ship with
> config.h.  Can you write a small script (CONFIGURE.BAT?) for the benefit
> of WIN systems that don't run configure, that will copy config.h.in
> to config.h?
    I'll do that for development time. But I'd like to have config-win32.h
copied to config.h for the tar ball. It will make life a lot easier for
Windows users and that file can easily be removed by the configure script on
Unix.

>
> At the moment, there are in fact, TWO config.h files.  That's pretty
> confusing, I agree.  They should have different names.
    Yes that would make sense.
    config-cppunit.h ?
    config-portability.h ?

>
> The two files serve different needs.  The original config.h is the
> standard header that autoconf generates.  It is intended to contain
> stuff needed for build-time portability.  The symbol HAVE_DLFCN_H is
> defined, for example, for the benefit of libtool in creating dynamic
> libraries.
    Can you post a copy of that file ? Can it be done in such a way that
when a symbol is define it indicate the exception rather than the
"standard". That way I could leave the config file empty, and just add the
symbol when the VC++ platform does not support some standard things.

>
> The other header, <cppunit/config.h>, is intended to be installed
> along with the rest of the CppUnit header files.  It contains symbol
> definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other
> CppUnit headers.  Some of these symbols are detected automatically at
> configure time.  So, again, this file does not ship.  For systems
> that can't use the configure script, alternate arrangements are needed.
    Ah, I get it. The main difference is that we don't exactly install the
library. There is no standard place for us to put it. So most of the time,
we just add the include directory to the include path and use it from there.
That why having the config.h sitting right in in the global include space is
bothering me.
    Also setting are not hard coded in the config file (with the exception
of compiler specifics). This allow us to switch some setting at usage time.
In fact, with VC++ I have two libraries that can be generated: cppunitd.lib
(with type info), and cppunticd.lib (no type info). When you use the
library, you also define the symbol CPPUNIT_DONT_USE_TYPEINFO if your
linking against cppunitcd.lib (which is the one you use if you are going
crossplatform). The most common of this is probably for Debug/Release mode:
two libraries, one set of headers.

> >     I think we should add a CPPUNIT_ASSERT_MESSAGE macro,  which take a
> > boolean and a string which is added to the error message. This would
allow
> > the user to create new assertions. For example, you need to compare
complex
> > numbers with a tolerance.
> >
> >     What do you think ?
>
> I think assert-with-message can be useful.
>
> For the example you give, an alternative is for the user to write an
> assertion_traits class for complex numbers that provides a toleranced
> "equals" method.  In fact, one could go the same route for doubles,
> so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL.
> Bad idea?
    I don't see how you can specify the tolerance for each assertion using
the traits!?!

    It would be better to leave CPPUNIT_ASSERT_DOUBLES_EQUAL here. People
might not be familiar with traits, and the macro is self explaining.

>
>
>
> --
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>