Re: [Cppunit-devel] config.h changes committed

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

On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:

> Ad. 1) My idea for config-msv6.h, etc. is that they are but replacements for
> config-auto.h: they just set some preprocessor switches and don't do
> anything else. This way it's simple to verify whether they are still
> complete with respect to config-auto.h.
> Portability.h then should contain all workarounds and hacks necessary, based
> on the switches in config-*.h
> In short: the _MSC_VER in Portability.h was intentional. 

OK.  I was worrying that a section of "#if COMPILER_X" blocks could become
a rat's nest of unreadable code.  Clearly it isn't, yet.  I won't mention
this again unless it does become one.

 
On Mon, Jun 18, 2001 at 09:38:03AM +0200, Baptiste Lepilleur wrote:

> > 3.  Is it useful to have CPPUNIT_USE_TYPEINFO as well as
> > CPPUNIT_HAVE_RTTI?  Certainly you can't define the former without the
> > latter.  Would you ever WANT to disable using RTTI, if available?  If
> > not, then we can eliminate USE_TYPEINFO in favour of HAVE_RTTI.  If
> > disabling it _is_ deemed useful, then the same comment about the extra
> > symbol applies; the stanza can be simplified to
> >
> > #ifndef CPPUNIT_USE_TYPEINFO
> > #define CPPUNIT_USE_TYPEINFO 1
> > #endif
>
>     HAVE_RTTI say that you can do dynamic_cast<...>, USE_TYPEINFO
>     say that typeinfo.name() returns a "human readable" name that
>     can be used to identify test case.

It seems that have a disagreement on definitions.  The autoconf test
in config/ac_cxx_rtti says

	If the compiler supports Run-Time Type Identification 
	(typeinfo header and typeid keyword), define HAVE_RTTI.

And, indeed, those are the two features tested for by the macro.
In particular, HAVE_RTTI says nothing about the presence or
absence of dynamic_cast.  

[There is another macro in the archive for HAVE_DYNAMIC_CAST, if we
need it.  But I don't think we do.  There are only two instances of
dynamic cast in the current sources, and both are in msv6/testrunner.]

The symbol HAVE_RTTI is nowhere used.

The symbol USE_TYPEINFO, on the other hand, is used in a few places
as a guard around code that uses typeid().  Interestingly, it
does not guard #include <typeinfo>.  In short, USE_TYPEINFO is
being used precisely as HAVE_RTTI *should* be used.

I am suggesting to eliminate one symbol in favour of the other.
If I have to choose, I would keep HAVE_RTTI because it has some
precedence: it comes from the autoconf macro archive.  But I can
see reasons for preferring to keep USE_TYPEINFO.


>    When you want maximum portability, you want to disable both.

I think it is more correct to say, "for maximum portability, you want
the library to work in both the presence and the absence of HAVE_RTTI".

The symbol HAVE_RTTI is checked for and set automatically at
installation time.  Assuming it replaces USE_TYPEINFO, HAVE_RTTI
should not be an option for the library user.  That is, it should not
appear in <cppunit/Portability.h>.  Among other reasons, you can run
into trouble if the installer builds with HAVE_RTTI = 1 (enabling RTTI
in the library .cpp files), and the user includes <cppunit/foo> with
HAVE_RTTI = 0 (not using RTTI in some inlined functions).  Or
vice-versa.


On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:
> Ad. 3) The fact that the compiler can do RTTI doesn't always mean
> you want to have it, for example when you have very tight
> environment, or the implementation is broken, etc. Anyway it seems
> useless to have multiple symbols: a --disable-rtti switch in
> autoconf could disable RTTI on the compiler and unset HAVE_RTTI.

I agree.

-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