cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] assertEquals and internal compiler error...

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

Well, I finally got around that problem.

As I said in a previous mail, cppunittest example failed to compile with
the new assertEquals template member methods (got a nice compiler internal
error) on VC++ 6.0 (no service pack).

I changed TestAssert from class to namespace, and removed the TestAssert
from TestCase inheritance. It compile well and works just fine.

Does anyone see any problems with that ?

Known impact is:

for users of cppunit 1.5.5, if they don't enable NAKED_ASSERT, with TestCase
inheritance of TestAssert, they won't get any compile time error.
All the assert would work but no line number and source file would be
reported.

This is not really a problem for me since I consider it to be a rather
dangerous
behavior: the user should either enabled NAKED_ASSERT or use the new macros.

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] TestRunner

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

Quoting Bastiaan Bakker <bas...@li...>:

> Baptiste Lepilleur wrote:
> > > Namespaces can be nested.  How about CppUnit::TestRunner::Text
> > > and CppUnit::TestRunner::<name-of-UI> ?  I don't know what the
> proper
> > > UI name would be: MSVC?  MFC?
> >     How about :
> >     CppUnit::MfcUi
> >     CppUnit::QtUi
> >     CppUnit::TextUi
> >     in which you would have a TestRunner class ?
> >
> 
> Sounds good. This looks like a more practical categorization than
> CppUnit::TestRunner::<UI>
    OK. I'll move include/msvc6/TestRunner.h to 
include/CppUnit/MfcUi/TestRunner.h,
and include/cppunit/TextTestRunner.h to include/CppUnit/TextUi/TestRunner.h 
(renaming the class too).

    I'll also rename src/msvc6/TestRunner to src/MfcUi.

    Anybody see something wrong with this ?

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

[Cppunit-devel] Macro for crossplatform development

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

    Steve talking about the macros got me thinking. The main reason why they 
are an extension is that they use template member methods which is not very 
portable.

    Thinking a bit more, I realised that the macro where the way to use the 
best of your platform: if you have RTTI, then it will be used, if you don't 
then it won't. You can get the best of your platform without giving up 
portability.

    Here I propose a way to get ride of that template member method.

    The template member method is actually used to instantiate a TestCaller 
with the right fixture type when sublcassing.

    The TestCaller class has evolved since then and you can now specify the 
fixture instance in the constructor.

    What I propose is to use a factory method that returns the instance of the 
fixture to use. It would look like this:

    the CPPUNIT_TEST_SUITE would define:
    virtual TestCase *makeTestCase()
    {
        return new ThisTestCase();
    }


    void registerTests( TestSuiteBuilder<ThisTestCaseType> &suite )
    {

and the CPPUNIT_TEST macro would do:
      suite.addTest( 
          new TestCaller<ThisTestCaseType>( #method, 
                                            method, 
                                            makeTestCase() ) );
    }

    I don't have the source under my hand so some stuff might be a bit of, but 
the idea is there. You could even have a version of the macro not defining the 
method makeTestCase(), allowing you to construct the test case in a specific 
way when your subclassing a test case.

    So what do you think ?

    Baptiste.

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

Re: [Cppunit-devel] macros and templates

[Steve M. R. <ste...@vi...>]

On Fri, Jun 08, 2001 at 06:14:33PM +0200, Baptiste Lepilleur wrote:

> > /* define if library uses std::string::compare(string,pos,n) */
> > #define FUNC_STRING_COMPARE_STRING_FIRST 1
>    Which platforms need this crazy things ? 

That was because of GCC.  They claim to be moving towards compatibility
with the C++ stdlib, but clearly they ain't there as of version 2.95.4. 
 

> It frighten me that I can't even rely on a string class...

You'd be amazed at how little you can really count on, in general.
The autoconf manual is full of truly bizarre tests for library and
compiler oddities.  And C++ is even worse than C.

Regards,
-Steve


-- 
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

Re: [Cppunit-devel] config.h proposal

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

Quoting Bastiaan Bakker <bas...@li...>:

> Hi,
>  
> In order to cleanup the current config.h problems I like to propose
> the
> following approach, which is the one we also use in the log4cpp
> project:
>  
> * As usual we let autoconf & friends generate include/config.h.in and
> include/config.h. Neither will be committed to CVS, include/config.h.in
> will
> end up in the dist tar. No CppUnit source file (i.e. *.cpp) shall
> include
> <config.h>.
> * With the AC_CREATE_PREFIX_CONFIG_H macro (see
> http://cryp.to/autoconf-archive/ <http://cryp.to/autoconf-archive/> ) we
> let
> autoconf generate include/cppunit/config.h from include/config.h. This
> file
> is identical to include/config.h, except that every #define will be
> prefixed
> with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
>  This file won't go into CVS or the dist tar either, but will be
> installed
> along with the other header files. 
> * For platforms that do not have autoconf a copy of
> include/cppunit/config.h
> will be made, for example to include/cppunit/config-msvc6.h. The
> maintainer
> each platform will have to manually edit this file to the correct
> settings
> for that platform. Each such file will go in CVS, dist and install.
> * We create a new file include/cppunit/Portability.h, which, depending
> on
> the platform will include either include/cppunit/config.h or
> include/cppunit/config-<platform>.h. This file will contain global
> portability fixes for the supported platforms, e.g.
> std::ostringstream,
> '#pragma warning( disable : 4786 )', etc. It can also hold non
> autoconf
> switches like CPPUNIT_USE_TYPEINFO. All other CppUnit sources will
> include
> this file. The file itself will go in CVS, dist and install.
>  
> Using this method we don't have to check in files like
> include/config.h,
> which may accidentally be overwritten by UNIX people. Also the Windows
> folks
> don't need to manually copy  files in order to get started. 
> The only thing that does require attention is that people when people
> add
> autoconf tests and switches they update
> include/cppunit/config-<platform>.h
> too.
>  
> If anyone has objections, please make them heard. If not, I'll try to
> set
> this up later coming weekend.

  If I understand thinks well, this seems excellent to me and solve all the 
issues. Go ahead.

  Thanks,
  Baptiste.

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

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

Re: [Cppunit-devel] config.h proposal

[Steve M. R. <ste...@vi...>]

On Fri, Jun 08, 2001 at 04:30:01PM +0200, Bastiaan Bakker wrote:
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Steve M. Robbins [mailto:ste...@vi...]
> > Verzonden: Friday, June 08, 2001 3:49 PM
> > Aan: cpp...@li...
> > Onderwerp: Re: [Cppunit-devel] config.h proposal
> > 
> > 
> > On Fri, Jun 08, 2001 at 02:37:31PM +0200, Bastiaan Bakker wrote:
> > > Hi,
> > >  
> > > In order to cleanup the current config.h problems I like to 
> > propose the
> > > following approach, which is the one we also use in the 
> > log4cpp project:
> > >  
> > > * As usual we let autoconf & friends generate 
> > include/config.h.in and
> > > include/config.h. Neither will be committed to CVS, 
> > include/config.h.in will
> > > end up in the dist tar. No CppUnit source file (i.e. *.cpp) 
> > shall include
> > > <config.h>.
> > > * With the AC_CREATE_PREFIX_CONFIG_H macro (see
> > > http://cryp.to/autoconf-archive/ 
> > <http://cryp.to/autoconf-archive/> ) we let
> > > autoconf generate include/cppunit/config.h from 
> > include/config.h. This file
> > > is identical to include/config.h, except that every #define 
> > will be prefixed
> > > with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
> > >  This file won't go into CVS or the dist tar either, but 
> > will be installed
> > > along with the other header files. 
> > > * For platforms that do not have autoconf a copy of 
> > include/cppunit/config.h
> > > will be made, for example to 
> > include/cppunit/config-msvc6.h. The maintainer
> > > each platform will have to manually edit this file to the 
> > correct settings
> > > for that platform. Each such file will go in CVS, dist and install.
> > > * We create a new file include/cppunit/Portability.h, 
> > which, depending on
> > > the platform will include either include/cppunit/config.h or
> > > include/cppunit/config-<platform>.h. This file will contain global
> > > portability fixes for the supported platforms, e.g. 
> > std::ostringstream,
> > > '#pragma warning( disable : 4786 )', etc. It can also hold 
> > non autoconf
> > > switches like CPPUNIT_USE_TYPEINFO. All other CppUnit 
> > sources will include
> > > this file. The file itself will go in CVS, dist and install.
> > >  
> > > Using this method we don't have to check in files like 
> > include/config.h,
> > > which may accidentally be overwritten by UNIX people. Also 
> > the Windows folks
> > > don't need to manually copy  files in order to get started. 
> > > The only thing that does require attention is that people 
> > when people add
> > > autoconf tests and switches they update 
> > include/cppunit/config-<platform>.h
> > > too.
> > 
> > I like it!
> > 
> 
> That's nice to hear!
> 

> > With regard to file naming schemes, I have two thoughts.
> > 
> > 1.  If no code will include the autoconf-generated file, then it
> > doesn't need to be in the "include" directory.  In fact, it is
> > perhaps less confusing if it is placed elsewhere.  Maybe autoconf
> > could generate config/portability, and the prefix macro can build the
> > final header file from that.
> > 
> 
> Yes, it certainly is less confusing. 
> The only reservation I have against it is that maybe we will need <config.h>
> to protect against differences between configurations of CppUnit and the
> applications using in it. 
> In this scenario, if HAVE_CONFIG_H is defined we include <config.h> in
> <cppunit/Portability.h> ...

If you are suggesting that an installed header has

	#if HAVE_CONFIG_H
	#include <config.h>
	#endif

then I am completely against it.  I need to be able to use CppUnit
in other projects, some of which use autoconf and therefore define
HAVE_CONFIG_H.  The behaviour of CppUnit should not change based on
whether or not I use autoconf in my project.

>                         ...  and compare the values of USE_BLA and
> CPPUNIT_USE_BLA for incompatible differences. 
>
> Even though there will be no differences when compiling CppUnit, we still
> need to have the config.h file. 
> Actually, now that I'm writing this down, I see it's a dumb idea: you don't
> know which configuration checks the application performs because autoconf is
> dumb enough not to tell you wether a feature is not present or the test has
> not been performed. Both cases end up with HAVE_BLA undefined, grr.

There are further problems.  One might have built CppUnit using compiler
X and then be using it in another project with compiler Y.  The two
compilers can have different idiosyncracies, which will be reflected
in the config files for CppUnit and the project using it.  

 
> So let's move include/config.h to config/.

OK.


> > 2.  We could stick with a (more traditional?) <cppunit/config.h> if
> > the auto-generated portability header uses the same naming scheme
> > as the others, say "include/cppunit/config-auto.h".  In other words,
> 
> OK, sounds fair. It makes clear config-auto.h and config-msvc6.h, etc. are
> on the same level.
> 
> > <cppunit/config.h> takes the role of the file that you called 
> > <cppunit/portability.h>, and "auto" is just another platform.
> > 
> 
> Because of the confusion the config.h name already has caused, I rather
> avoid it. People may think that it is some product of autoconf, which it
> isn't. Also I hope the capital P in <cppunit/Portability.h> may give people
> a hint that it is a C++ header, not a C one.

Ah.  Well, the meaning of the capital 'P' completely escaped this person :-)
I'm completely used to having capital letters in C header names.

I don't think the name is going to matter much to the user of CppUnit.
A user will never have to include it directly, as I understand things.
Only CppUnit headers will include it.  Right?

-S

-- 
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

RE: [Cppunit-devel] config.h proposal

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, June 08, 2001 3:49 PM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] config.h proposal
> 
> 
> On Fri, Jun 08, 2001 at 02:37:31PM +0200, Bastiaan Bakker wrote:
> > Hi,
> >  
> > In order to cleanup the current config.h problems I like to 
> propose the
> > following approach, which is the one we also use in the 
> log4cpp project:
> >  
> > * As usual we let autoconf & friends generate 
> include/config.h.in and
> > include/config.h. Neither will be committed to CVS, 
> include/config.h.in will
> > end up in the dist tar. No CppUnit source file (i.e. *.cpp) 
> shall include
> > <config.h>.
> > * With the AC_CREATE_PREFIX_CONFIG_H macro (see
> > http://cryp.to/autoconf-archive/ 
> <http://cryp.to/autoconf-archive/> ) we let
> > autoconf generate include/cppunit/config.h from 
> include/config.h. This file
> > is identical to include/config.h, except that every #define 
> will be prefixed
> > with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
> >  This file won't go into CVS or the dist tar either, but 
> will be installed
> > along with the other header files. 
> > * For platforms that do not have autoconf a copy of 
> include/cppunit/config.h
> > will be made, for example to 
> include/cppunit/config-msvc6.h. The maintainer
> > each platform will have to manually edit this file to the 
> correct settings
> > for that platform. Each such file will go in CVS, dist and install.
> > * We create a new file include/cppunit/Portability.h, 
> which, depending on
> > the platform will include either include/cppunit/config.h or
> > include/cppunit/config-<platform>.h. This file will contain global
> > portability fixes for the supported platforms, e.g. 
> std::ostringstream,
> > '#pragma warning( disable : 4786 )', etc. It can also hold 
> non autoconf
> > switches like CPPUNIT_USE_TYPEINFO. All other CppUnit 
> sources will include
> > this file. The file itself will go in CVS, dist and install.
> >  
> > Using this method we don't have to check in files like 
> include/config.h,
> > which may accidentally be overwritten by UNIX people. Also 
> the Windows folks
> > don't need to manually copy  files in order to get started. 
> > The only thing that does require attention is that people 
> when people add
> > autoconf tests and switches they update 
> include/cppunit/config-<platform>.h
> > too.
> 
> I like it!
> 

That's nice to hear!

> With regard to file naming schemes, I have two thoughts.
> 
> 1.  If no code will include the autoconf-generated file, then it
> doesn't need to be in the "include" directory.  In fact, it is
> perhaps less confusing if it is placed elsewhere.  Maybe autoconf
> could generate config/portability, and the prefix macro can build the
> final header file from that.
> 

Yes, it certainly is less confusing. 
The only reservation I have against it is that maybe we will need <config.h>
to protect against differences between configurations of CppUnit and the
applications using in it. 
In this scenario, if HAVE_CONFIG_H is defined we include <config.h> in
<cppunit/Portability.h> and compare the values of USE_BLA and
CPPUNIT_USE_BLA for incompatible differences. 
Even though there will be no differences when compiling CppUnit, we still
need to have the config.h file. 
Actually, now that I'm writing this down, I see it's a dumb idea: you don't
know which configuration checks the application performs because autoconf is
dumb enough not to tell you wether a feature is not present or the test has
not been performed. Both cases end up with HAVE_BLA undefined, grr.

So let's move include/config.h to config/.


> 2.  We could stick with a (more traditional?) <cppunit/config.h> if
> the auto-generated portability header uses the same naming scheme
> as the others, say "include/cppunit/config-auto.h".  In other words,

OK, sounds fair. It makes clear config-auto.h and config-msvc6.h, etc. are
on the same level.

> <cppunit/config.h> takes the role of the file that you called 
> <cppunit/portability.h>, and "auto" is just another platform.
> 

Because of the confusion the config.h name already has caused, I rather
avoid it. People may think that it is some product of autoconf, which it
isn't. Also I hope the capital P in <cppunit/Portability.h> may give people
a hint that it is a C++ header, not a C one.

> 
> Regardless of the naming scheme chosen, it improves on what we now
> have in several ways.  Go for it!
> 

OK, I will!

Thanks,

Bastiaan

> -Steve
> 
> 
> -- 
> 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
> 

Re: [Cppunit-devel] config.h proposal

[Steve M. R. <ste...@vi...>]

On Fri, Jun 08, 2001 at 02:37:31PM +0200, Bastiaan Bakker wrote:
> Hi,
>  
> In order to cleanup the current config.h problems I like to propose the
> following approach, which is the one we also use in the log4cpp project:
>  
> * As usual we let autoconf & friends generate include/config.h.in and
> include/config.h. Neither will be committed to CVS, include/config.h.in will
> end up in the dist tar. No CppUnit source file (i.e. *.cpp) shall include
> <config.h>.
> * With the AC_CREATE_PREFIX_CONFIG_H macro (see
> http://cryp.to/autoconf-archive/ <http://cryp.to/autoconf-archive/> ) we let
> autoconf generate include/cppunit/config.h from include/config.h. This file
> is identical to include/config.h, except that every #define will be prefixed
> with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
>  This file won't go into CVS or the dist tar either, but will be installed
> along with the other header files. 
> * For platforms that do not have autoconf a copy of include/cppunit/config.h
> will be made, for example to include/cppunit/config-msvc6.h. The maintainer
> each platform will have to manually edit this file to the correct settings
> for that platform. Each such file will go in CVS, dist and install.
> * We create a new file include/cppunit/Portability.h, which, depending on
> the platform will include either include/cppunit/config.h or
> include/cppunit/config-<platform>.h. This file will contain global
> portability fixes for the supported platforms, e.g. std::ostringstream,
> '#pragma warning( disable : 4786 )', etc. It can also hold non autoconf
> switches like CPPUNIT_USE_TYPEINFO. All other CppUnit sources will include
> this file. The file itself will go in CVS, dist and install.
>  
> Using this method we don't have to check in files like include/config.h,
> which may accidentally be overwritten by UNIX people. Also the Windows folks
> don't need to manually copy  files in order to get started. 
> The only thing that does require attention is that people when people add
> autoconf tests and switches they update include/cppunit/config-<platform>.h
> too.

I like it!

With regard to file naming schemes, I have two thoughts.

1.  If no code will include the autoconf-generated file, then it
doesn't need to be in the "include" directory.  In fact, it is
perhaps less confusing if it is placed elsewhere.  Maybe autoconf
could generate config/portability, and the prefix macro can build the
final header file from that.

2.  We could stick with a (more traditional?) <cppunit/config.h> if
the auto-generated portability header uses the same naming scheme
as the others, say "include/cppunit/config-auto.h".  In other words,
<cppunit/config.h> takes the role of the file that you called 
<cppunit/portability.h>, and "auto" is just another platform.


Regardless of the naming scheme chosen, it improves on what we now
have in several ways.  Go for it!

-Steve


-- 
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

RE: [Cppunit-devel] please ask

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, June 08, 2001 2:46 PM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] please ask
> 
> 
> On Fri, Jun 08, 2001 at 09:34:02AM +0200, Bastiaan Bakker wrote:
> 
> > > > (yet, I still should have asked). The point is I
> > > > still don't know where or what is supposed to be in that 
> > > file (couldn't find
> > > > any config.in for that one).
> > > 
> > > Oh.  That's odd.  I did commit include/cppunit/config.h.in.
> > > Don't you see that file when you cvsup?
> > > 
> > 
> > It is not in the CVS repository on SourceForge.
> 
> One of us is confusing the original
> 

Me, me, me.

> 	include/config.h.in
> 
> which, indeed, is generated (using autoheader), with the
> new file
> 
> 	include/cppunit/config.h.in
> 
> which is NOT generated.  The latter IS in the repository
> while the former is not.
> 

You're right. I misread your message. But I hope to obsolete
include/cppunit/config.h.in anyway.
Please let me know what you think of the new config.h proposal...

Bastiaan

Re: [Cppunit-devel] please ask

[Steve M. R. <ste...@vi...>]

On Fri, Jun 08, 2001 at 09:34:02AM +0200, Bastiaan Bakker wrote:

> > > (yet, I still should have asked). The point is I
> > > still don't know where or what is supposed to be in that 
> > file (couldn't find
> > > any config.in for that one).
> > 
> > Oh.  That's odd.  I did commit include/cppunit/config.h.in.
> > Don't you see that file when you cvsup?
> > 
> 
> It is not in the CVS repository on SourceForge.

One of us is confusing the original

	include/config.h.in

which, indeed, is generated (using autoheader), with the
new file

	include/cppunit/config.h.in

which is NOT generated.  The latter IS in the repository
while the former is not.

[And neither include/config.h nor include/cppunit/config.h
 should be in the repository, either.]

> And IMHO it shouldn't be either, because it is a generated file. 
> I'll propose an alternative, which we use for log4cpp, later today. Have to
> attend a meeting now....

-S


-- 
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] config.h proposal

[Bastiaan B. <bas...@li...>]

Hi,
 
In order to cleanup the current config.h problems I like to propose the
following approach, which is the one we also use in the log4cpp project:
 
* As usual we let autoconf & friends generate include/config.h.in and
include/config.h. Neither will be committed to CVS, include/config.h.in will
end up in the dist tar. No CppUnit source file (i.e. *.cpp) shall include
<config.h>.
* With the AC_CREATE_PREFIX_CONFIG_H macro (see
http://cryp.to/autoconf-archive/ <http://cryp.to/autoconf-archive/> ) we let
autoconf generate include/cppunit/config.h from include/config.h. This file
is identical to include/config.h, except that every #define will be prefixed
with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
 This file won't go into CVS or the dist tar either, but will be installed
along with the other header files. 
* For platforms that do not have autoconf a copy of include/cppunit/config.h
will be made, for example to include/cppunit/config-msvc6.h. The maintainer
each platform will have to manually edit this file to the correct settings
for that platform. Each such file will go in CVS, dist and install.
* We create a new file include/cppunit/Portability.h, which, depending on
the platform will include either include/cppunit/config.h or
include/cppunit/config-<platform>.h. This file will contain global
portability fixes for the supported platforms, e.g. std::ostringstream,
'#pragma warning( disable : 4786 )', etc. It can also hold non autoconf
switches like CPPUNIT_USE_TYPEINFO. All other CppUnit sources will include
this file. The file itself will go in CVS, dist and install.
 
Using this method we don't have to check in files like include/config.h,
which may accidentally be overwritten by UNIX people. Also the Windows folks
don't need to manually copy  files in order to get started. 
The only thing that does require attention is that people when people add
autoconf tests and switches they update include/cppunit/config-<platform>.h
too.
 
If anyone has objections, please make them heard. If not, I'll try to set
this up later coming weekend.
 
Regards,
 
 
Bastiaan
 
 
 

Re: [Cppunit-devel] please ask

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

Quoting Baptiste Lepilleur <bl...@cl...>:

Sorry about this double mail posting. I'm having trouble with my e-mail client. 
It's hanging up the modem after while sending mail. It's driving me nuts. I'll 
probably be changing of client in a few day... Try to bear with it until then.

Thanks,
Baptiste.

> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: "CppUnit Development" <cpp...@li...>
> Sent: Wednesday, June 06, 2001 12:26 AM
> Subject: [Cppunit-devel] please ask
> 
> 
> > Hi all,
> >
> > We're going to need to start communicating, or there will be a lot
> of
> > toes begin stepped on.  Please: if something seems weird to you, ask
> > about it.  Don't assume.
> >
> > I don't want to single people out, but here's what I see recently
> > checked in:
> >
> >         * src/cppunit/TypeInfoHelper.cpp: removed #include
> <config.h>,
> >           cppunit/config.h was already included.
> >
> > This is wrong.  <config.h> and <cppunit/config.h> are two different
> files.
> > Both must be included.
> 
>     Sorry. All I can say is that I was pretty tired. I spent part of
> the
> evening putting the windows side back into shape. I wanted to "get done
> with
> it". I'll try to be more patient next time and take the time to post
> an
> mail.
> 
>     Note that this mess would not have happen if those files had been
> explained on the list ;-) (yet, I still should have asked). The point is
> I
> still don't know where or what is supposed to be in that file (couldn't
> find
> any config.in for that one).
> 
>     Baptiste.
> ---
> Baptiste Lepilleur <gai...@fr...>  
> http://gaiacrtn.free.fr/index.html
> Author of The Text Reformatter, a tool for fanfiction readers and
> writers.
> Language: English, French (Well, I'm French).
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 



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

RE: [Cppunit-devel] please ask

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, June 08, 2001 5:05 AM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] please ask
> 
> 
> On Thu, Jun 07, 2001 at 11:07:11PM +0200, Baptiste Lepilleur wrote:
> 
> >     Note that this mess would not have happen if those 
> files had been
> > explained on the list ;-) 
> 
> Touche.  Point taken.
> 
> 
> > (yet, I still should have asked). The point is I
> > still don't know where or what is supposed to be in that 
> file (couldn't find
> > any config.in for that one).
> 
> Oh.  That's odd.  I did commit include/cppunit/config.h.in.
> Don't you see that file when you cvsup?
> 

It is not in the CVS repository on SourceForge.
And IMHO it shouldn't be either, because it is a generated file. 
I'll propose an alternative, which we use for log4cpp, later today. Have to
attend a meeting now....

Bastiaan


> -S
> 
> 
> -- 
> 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
> 

Re: [Cppunit-devel] macros and templates

[Steve M. R. <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.

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.

 
> > 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 ? 

It is include/config.h, generated from include/config.h.in.  The latter
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


> 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.

 
> > 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.


> > 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.
 
>     It would be better to leave CPPUNIT_ASSERT_DOUBLES_EQUAL here. People
> might not be familiar with traits, and the macro is self explaining.

And, yes, the macro name is easy to understand.  :-)

-S


-- 
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

Re: [Cppunit-devel] please ask

[Steve M. R. <ste...@vi...>]

On Thu, Jun 07, 2001 at 11:07:11PM +0200, Baptiste Lepilleur wrote:

>     Note that this mess would not have happen if those files had been
> explained on the list ;-) 

Touche.  Point taken.


> (yet, I still should have asked). The point is I
> still don't know where or what is supposed to be in that file (couldn't find
> any config.in for that one).

Oh.  That's odd.  I did commit include/cppunit/config.h.in.
Don't you see that file when you cvsup?

-S


-- 
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

Re: [Cppunit-devel] please ask

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Wednesday, June 06, 2001 12:26 AM
Subject: [Cppunit-devel] please ask


> Hi all,
>
> We're going to need to start communicating, or there will be a lot of
> toes begin stepped on.  Please: if something seems weird to you, ask
> about it.  Don't assume.
>
> I don't want to single people out, but here's what I see recently
> checked in:
>
>         * src/cppunit/TypeInfoHelper.cpp: removed #include <config.h>,
>           cppunit/config.h was already included.
>
> This is wrong.  <config.h> and <cppunit/config.h> are two different files.
> Both must be included.

    Sorry. All I can say is that I was pretty tired. I spent part of the
evening putting the windows side back into shape. I wanted to "get done with
it". I'll try to be more patient next time and take the time to post an
mail.

    Note that this mess would not have happen if those files had been
explained on the list ;-) (yet, I still should have asked). The point is I
still don't know where or what is supposed to be in that file (couldn't find
any config.in for that one).

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] please ask

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Wednesday, June 06, 2001 12:26 AM
Subject: [Cppunit-devel] please ask


> Hi all,
>
> We're going to need to start communicating, or there will be a lot of
> toes begin stepped on.  Please: if something seems weird to you, ask
> about it.  Don't assume.
>
> I don't want to single people out, but here's what I see recently
> checked in:
>
>         * src/cppunit/TypeInfoHelper.cpp: removed #include <config.h>,
>           cppunit/config.h was already included.
>
> This is wrong.  <config.h> and <cppunit/config.h> are two different files.
> Both must be included.

    Sorry. All I can say is that I was pretty tired. I spent part of the
evening putting the windows side back into shape. I wanted to "get done with
it". I'll try to be more patient next time and take the time to post an
mail.

    Note that this mess would not have happen if those files had been
explained on the list ;-) (yet, I still should have asked). The point is I
still don't know where or what is supposed to be in that file (couldn't find
any config.in for that one).

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

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
>

Re: [Cppunit-devel] please ask

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Wednesday, June 06, 2001 12:26 AM
Subject: [Cppunit-devel] please ask


> Hi all,
>
> We're going to need to start communicating, or there will be a lot of
> toes begin stepped on.  Please: if something seems weird to you, ask
> about it.  Don't assume.
>
> I don't want to single people out, but here's what I see recently
> checked in:
>
>         * src/cppunit/TypeInfoHelper.cpp: removed #include <config.h>,
>           cppunit/config.h was already included.
>
> This is wrong.  <config.h> and <cppunit/config.h> are two different files.
> Both must be included.

    Sorry. All I can say is that I was pretty tired. I spent part of the
evening putting the windows side back into shape. I wanted to "get done with
it". I'll try to be more patient next time.

    Note that this mess would not have happen if those files had been
explained on the list ;-) . The point is I still don't know where or what is
supposed to be in that file (couldn't find any config.in for that one).

    Also the file is in the global include space (no directory prefix),
which is dangerous (you may include that file when you though you where
including another).

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] TestRunner

[Bastiaan B. <bas...@li...>]

Baptiste Lepilleur wrote:

--8<--

>
> > Namespaces can be nested.  How about CppUnit::TestRunner::Text
> > and CppUnit::TestRunner::<name-of-UI> ?  I don't know what the proper
> > UI name would be: MSVC?  MFC?
>     How about :
>     CppUnit::MfcUi
>     CppUnit::QtUi
>     CppUnit::TextUi
>     in which you would have a TestRunner class ?
>

Sounds good. This looks like a more practical categorization than
CppUnit::TestRunner::<UI>

--8<--

>
> >
> > I'm still struggling with grasping the "big picture" of CppUnit,
> > myself.  It still seems to me to have a lot of separate bits of

Well, don't feel alone. Strangly enough, I didn't have the opportunity yet to
actually use CppUnit myself, so my familiarity with all of its features and
details is limited too.

Bastiaan

Re: [Cppunit-devel] TestRunner

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Wednesday, June 06, 2001 4:12 PM
Subject: Re: [Cppunit-devel] TestRunner


> On Tue, Jun 05, 2001 at 11:35:58PM +0200, Baptiste Lepilleur wrote:
> > ----- Original Message -----
> > From: "Steve M. Robbins" <ste...@vi...>
> > To: "CppUnit Development" <cpp...@li...>
> > Sent: Sunday, June 03, 2001 2:46 AM
> > Subject: [Cppunit-devel] TestRunner
> >
> >
> > >
> > > Looking at the documentation generated using Doxygen,
> > > I see that there is ONE class defined outside the CppUnit
> > > namespace, namely TestRunner.
> > >
> > > Is this a simple oversight?
> > > Or is it intended only as example code?
> >     TestRunner is the GUI TestRunner for VC++. It is not in the CppUnit
> > namespace because I did not want to take that name within the namespace.
>
> The reason I was asking is that I thought the doxygen-docs should
> document stuff only in the CppUnit namespace.
>
> If you accept this, and I grant that it is a *personal* aesthetic,
> then either TestRunner should be in CppUnit, or it should not be in
> the documentation.
>
> That is why I asked whether it is "example" code.  Examples, like in
> the examples subdirectory, would not typically be documented.
>
> But it doesn't seem like mere example code.  It is on par with the
> TextTestRunner, isn't it?  If so, it ought to get documented.
    Yes it is, much more tightly integrated with your MFC application though
(both good and bad, but I'll correct this some day).

>
>
> >     If you have suggestions about the name/namespace, they are welcome.
>
> Namespaces can be nested.  How about CppUnit::TestRunner::Text
> and CppUnit::TestRunner::<name-of-UI> ?  I don't know what the proper
> UI name would be: MSVC?  MFC?
    How about :
    CppUnit::MfcUi
    CppUnit::QtUi
    CppUnit::TextUi
    in which you would have a TestRunner class ?

>
> I'm still struggling with grasping the "big picture" of CppUnit,
> myself.  It still seems to me to have a lot of separate bits of
> unrelated infrastructure.  So any naming scheme that clarifies
> things is most welcome!
>
> Speaking of separate bits, what is the origin of
> include/cppunit/extensions?  I find that the macros in HelperMacros.h
> are, well, incredibly helpful!  To my mind, they should be promoted as
> the primary interface, at least for newbies.

    Michael Feather's implementation (you can found it on
http://www.xprogramming.com). Like junit, it provided "extensions" in the
extensions directory (decorator...).

    When I added the macros, TestSuiteBuilder and co to CppUnitW, I put it
in there since it was not part of the "core".

    I'll send another mail about those macros soon.

>
>
> --
> 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
>

Re: [Cppunit-devel] TestRunner

[Steve M. R. <ste...@vi...>]

On Tue, Jun 05, 2001 at 11:35:58PM +0200, Baptiste Lepilleur wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: "CppUnit Development" <cpp...@li...>
> Sent: Sunday, June 03, 2001 2:46 AM
> Subject: [Cppunit-devel] TestRunner
> 
> 
> >
> > Looking at the documentation generated using Doxygen,
> > I see that there is ONE class defined outside the CppUnit
> > namespace, namely TestRunner.
> >
> > Is this a simple oversight?
> > Or is it intended only as example code?
>     TestRunner is the GUI TestRunner for VC++. It is not in the CppUnit
> namespace because I did not want to take that name within the namespace.

The reason I was asking is that I thought the doxygen-docs should
document stuff only in the CppUnit namespace.  

If you accept this, and I grant that it is a *personal* aesthetic,
then either TestRunner should be in CppUnit, or it should not be in
the documentation.

That is why I asked whether it is "example" code.  Examples, like in
the examples subdirectory, would not typically be documented.

But it doesn't seem like mere example code.  It is on par with the
TextTestRunner, isn't it?  If so, it ought to get documented.


>     If you have suggestions about the name/namespace, they are welcome.

Namespaces can be nested.  How about CppUnit::TestRunner::Text
and CppUnit::TestRunner::<name-of-UI> ?  I don't know what the proper
UI name would be: MSVC?  MFC?  

I'm still struggling with grasping the "big picture" of CppUnit,
myself.  It still seems to me to have a lot of separate bits of
unrelated infrastructure.  So any naming scheme that clarifies
things is most welcome!

Speaking of separate bits, what is the origin of
include/cppunit/extensions?  I find that the macros in HelperMacros.h
are, well, incredibly helpful!  To my mind, they should be promoted as
the primary interface, at least for newbies.


-- 
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

Re: [Cppunit-devel] macros and templates

[Steve M. R. <ste...@vi...>]

On Tue, Jun 05, 2001 at 11:50:17PM +0200, Baptiste Lepilleur wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: <cpp...@li...>
> Sent: Sunday, June 03, 2001 1:49 AM
> Subject: [Cppunit-devel] macros and templates
> 
> 
> > I've added the generic TestAssert::assertEquals() method,
> > along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL,
> > and CPPUNIT_ASSERT_DOUBLES_EQUAL.  The old naked assert and
> > friends are available by editing <cppunit/config.h>.
>     I've added a default config.h for VC++ (we don't have a configure script
> ;-( ).

Yeah.  The lack of a configure script is really unfortunate.  And it
will only get worse.  I expect that there will be an increasing number
of HAVE_xxx type of macros defined in one header or another.

> When other WIN32 compilers will be added, we can update it to detect
> the compiler and set default accordingly.

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?

At the moment, there are in fact, TWO config.h files.  That's pretty
confusing, I agree.  They should have different names.

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.  

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.


 
>     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?



-- 
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

Re: [Cppunit-devel] macros and templates

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Sunday, June 03, 2001 1:49 AM
Subject: [Cppunit-devel] macros and templates


> I've added the generic TestAssert::assertEquals() method,
> along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL,
> and CPPUNIT_ASSERT_DOUBLES_EQUAL.  The old naked assert and
> friends are available by editing <cppunit/config.h>.
    I've added a default config.h for VC++ (we don't have a configure script
;-( ). When other WIN32 compilers will be added, we can update it to detect
the compiler and set default accordingly.

    The new assert equals (I guess) make a compiler internal error in the
cppunittests example. Weird, since it works just fine in another of mine
project. I'll look into that and possible workaround (macro, namespace
instead of class) later.

    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 ?

>
> At the moment, the assertion_traits class requires string streams,
> which does not exist in GCC before version 2.95.3.  If you have any
> bright ideas about workarounds for missing <sstream>, I'm all ears.
>
> All the old CU_* got renamed to CPPUNIT_*.
> I did this with a global string replace.  This changes some of the
> MSVC files.  I hope they still work.  Let me know.
    Worked just fine.
    Thanks,
    Baptiste.

---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).