Re: [Cppunit-devel] macros and templates

[Baptiste L. <gai...@fr...>]

Quoting "Steve M. Robbins" <ste...@vi...>:

> On Thu, Jun 07, 2001 at 10:44:17PM +0200, Baptiste Lepilleur wrote:
> > ----- 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.
> 
> That's an unorthodox approach, but it will likely work.
> I'll try it out to see how configure copes with having 
> a config.h file already there.
    OK.

> Can you write a single config-win32.h that works for all platforms
> that don't use configure?  The problem of which I'm thinking is this:
> items like CPPUNIT_USE_TYPEINFO may differ for different compilers
> on windows.  (If not this example, then future additions to this
> file may differ).  If the installer has to hand-edit the file
> anyway --- to choose the appropriate options --- then why not ask
> them to rename it as well.  You can provide customized config-msv6.h
> config-borland.h, and whatever.
    Yes it can be done. Compiler detection is a common thing (just look at 
RogueWave config header).
    To me, CPPUNIT_USE_TYPEINFO and CPPUNIT_ENABLED_NAKED_ASSERT are project 
specific, not compiler specific (though type info is restricted by your 
compiler capability). I might very well for one project use type info since I 
know it will never go crossplatform, and in antoher project which is 
crossplatform, disabled type info since it is not a portable feature.

    The way I did it, is that if the user define (in his project) the symbol 
CPPUNIT_DONT_USE_TYPEINFO, then type info won't be enabled.

> It is include/config.h, generated from include/config.h.in.  The latter
     Something is wrong there, it's was not in CVS when I updated...

> is in CVS, so you have a copy.  The generated file, on my system
> is 
> 
> /* include/config.h.  Generated automatically by configure.  */
> /* include/config.h.in.  Generated automatically from configure.in by
> autoheader 2.13.  */
> 
> /* Define if you have the <dlfcn.h> header file.  */
> #define HAVE_DLFCN_H 1
> 
> /* Name of package */
> #define PACKAGE "cppunit"
> 
> /* Version number of package */
> #define VERSION "1.5.5"
> 
> /* define if the compiler supports Run-Time Type Identification */
> #define HAVE_RTTI 1
> 
> /* define to 1 if the compiler implements namespaces */
> #define HAVE_NAMESPACES 1
> 
> /* define if library uses std::string::compare(string,pos,n) */
> #define FUNC_STRING_COMPARE_STRING_FIRST 1
   Which platforms need this crazy things ? It frighten me that I can't even 
rely on a string class...


> > 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.
> 
> Maybe.  I can't be sure this is going to always be the case.
> I can guarantee, however, that the input file --- named config.h.in ---
> will have some useful comments in it.  What you need to do is take
> config.h.in, rename it to config.h, and edit it to suite your
> environment.
   OK. That's work for me. Just make sure to keep us posted when a new symbol 
is added so I can update that file.


> > > 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.
> 
> It's not in the global include space.  This file is <cppunit/config.h>.
> It's private to cppunit, if you like.
  I'm okay with that one. I was refering to:
/* include/config.h.  Generated automatically by configure.  */
  which is <config.h> => that's the global include space I was refering to.


> > > 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!?!
> 
> You can't.  That's the one feature of the current macro that traits
> can't simulate.
    So it's better to keep the macro. Tolerance is something that is really 
specific to each assertion.

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French