Thread: RE: [Cppunit-devel] config.h changes committed
Brought to you by:
blep
Menu
▾
▴
cppunit-devel
|
From: Bastiaan B. <bas...@li...> - 2001-06-18 07:03:10
|
> -----Oorspronkelijk bericht----- > Van: Steve M. Robbins [mailto:ste...@vi...] > Verzonden: Monday, June 18, 2001 4:29 AM > Aan: cpp...@li... > Onderwerp: Re: [Cppunit-devel] config.h changes committed > > > On Mon, Jun 18, 2001 at 01:17:03AM +0200, Bastiaan Bakker wrote: > > "Steve M. Robbins" wrote: > > > > > On Sun, Jun 17, 2001 at 10:20:16PM +0200, Bastiaan Bakker wrote: > > > > > * use autoconf 2.40 or higher to rebuild aclocal.m4, > because the > > > > AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro. > > > > > > I expect you meant "2.50" ? > > > > The docs somewhere stated that AS_DIRNAME has been included in 2.40. > > Don't know whether that's a public release or not, or that it was a > > typo. I'm using 2.50 myself. > > Interesting. There was no public 2.40, certainly. In fact, there is > no mention of 2.40 anywhere in the autoconf NEWS or ChangeLog files > that I can find. > Now that I think of it, 2.40 very likely was mentioned in the docs to the > > > > > * include <cppunit/Portability.h> instead of <cppunit/config.h> > > Looks good. > > About Portability.h, I have three questions. > > > 1. Shouldn't this bit go into config-msvc6.h? > > #if _MSC_VER > 1000 // VC++ > #pragma once > #pragma ... > > > 2. Which way should the "naked assert" default? I thought the > consensus was to NOT define assert() by default. However, > Portability.h enables them by default. More importantly, the header > introduces an extra symbol, which I think is unnecessary. We could > write it as > > #ifndef CPPUNIT_ENABLE_NAKED_ASSERT > #define CPPUNIT_ENABLE_NAKED_ASSERT 0[*] > #endif > > [*] or 1, depending on the default desired. > > > > 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 > > 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. Ad. 2, 3) The code fragments for CPPUNIT_USE_NAKED_ASSERT and CPPUNIT_USE_TYPEINFO were copied verbatim from include/cppunit/config.h.in, so their settings are not new and do not express my opinion on how they should be. Ad. 2) I agree, the naked assert should be off by default. 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. Bastiaan |
|
From: Bastiaan B. <bas...@li...> - 2001-06-20 11:32:27
|
> -----Oorspronkelijk bericht----- > Van: Baptiste Lepilleur [mailto:bl...@cl...] > Verzonden: Monday, June 18, 2001 9:53 PM > Aan: cpp...@li... > Onderwerp: Re: [Cppunit-devel] config.h changes committed > > > ----- Original Message ----- > From: "Steve M. Robbins" <ste...@vi...> > To: <cpp...@li...> > Sent: Monday, June 18, 2001 7:20 PM > Subject: Re: [Cppunit-devel] config.h changes committed > > > > On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote: > > > Quoting "Steve M. Robbins" <ste...@vi...>: > > > OK. I did know what's was behind the RTTI thingy (kinda > strange, I did > not > > > though that you could have the type_info without dynamic_cast). > > > > All I'm saying is that the macro defines HAVE_RTTI based on the > > presence of typeid(). You are probably right that dynamic_cast is > > present if typeid() is present; I don't know much about > RTTI. It may > > be that the reverse is not true, however. My instinct is to assume > > dynamic_cast is available, if needed, (and without checking) until > > someone tells us otherwise. > OK. > Yes, AFAIK, having typeid() equals having dynamic_cast equals having HAVE_RTTI. > > > Well, I propose to keep USE_TYPEINFO. > > > > > > Our USE_TYPEINFO could be defined as: you have typeinfo, and the > name() > > > methode return a human readable name (that last one can't > be tested by a > > > machine unfortunately). So it's a stronger requirement > than HAVE_RTTI. > > Yes, I was mistaken in my previous mail. USE_TYPEINFO needs more than HAVE_RTTI. So, let's keep it. > > It's true that GCC can produce an ungainly type name like > > > > > t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4Gmp > zZQ24CGALt8Quo > tient1ZQ24CGAL4Gmpz.point_intersection > Yuck!!! Baastian, did you look up an explanation for this > from the gcc > folks ? (name are still useful for debugging) > I couldn't find any reasoning for the current g++ implementation in the mailing list archive and I haven't contacted the maintainers yet. Now that they have released GCC 3.0, they'll probably have more time for new features / functional improvements, so I'll try soon. > > so the idea of perhaps not using that name has merit. In that case, > > the symbol might be more appropriately-named USE_TYPEINFO_NAME. You > > may still wish to use type_info structures to test equality of > > types. > I agree, that name reveal the intention better. > Agreed. > > > > I'll have to think about this. There seem to be relatively few uses > > of using type_info::name() at present, and I'm puzzled by > some of them. > > > > For example, what is the purpose of class > CppUnit::TypeInfoHelper? Is > > there some advantage to using a class rather than a simple function > > CppUnit::getClassName() ? > Yes. I though that the class would grow, but it did not. > Actually, isn't > that the only use of name() ? > > Baptiste. Well, for debuggers the mangled name may be more interesting. But the standard does not document any use for the name() method, so we can only guess. Bastiaan |
|
From: Baptiste L. <gai...@fr...> - 2001-06-18 12:43:07
|
Quoting Bastiaan Bakker <bas...@li...>: > > 2. Which way should the "naked assert" default? I thought the > > consensus was to NOT define assert() by default. However, > > Portability.h enables them by default. More importantly, the header > > introduces an extra symbol, which I think is unnecessary. We could > > write it as > > > > #ifndef CPPUNIT_ENABLE_NAKED_ASSERT > > #define CPPUNIT_ENABLE_NAKED_ASSERT 0[*] > > #endif > > > > [*] or 1, depending on the default desired. Naked assert should be disabled by default. I don't remember why I wrote this like that (the weirdest stuff is that I remember having to make the change to the CPPUNIT macros in one of my project because the naked assert where not defined?!?). The logic behind this, is that you may need some day to use a third-party library which rely on or define "assert". If the user want a shorter form to write assertion (CPPUNIT_ASSERT_EQUAL is quite verbose), aliases to cppunit macros can easily be defined. Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, French |
|
From: Steve M. R. <ste...@vi...> - 2001-06-18 14:13:57
|
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 |
|
From: Baptiste L. <gai...@fr...> - 2001-06-18 15:16:42
|
Quoting "Steve M. Robbins" <ste...@vi...>: > On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote: > 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. OK. I did know what's was behind the RTTI thingy (kinda strange, I did not though that you could have the type_info without dynamic_cast). Well, I propose to keep USE_TYPEINFO. Our USE_TYPEINFO could be defined as: you have typeinfo, and the name() methode return a human readable name (that last one can't be tested by a machine unfortunately). So it's a stronger requirement than HAVE_RTTI. > > 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 library works on both, but some features won't be available (name extraction from type. We had rather lengthy discussion about this with Baastian a while back). The good things is that is you are using the macro, you don't have to care. So if I have a crossplatform project, I can remove USE_TYPEINFO support to make sure than only portable features are used. > 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. I agree --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, French |
|
From: Steve M. R. <ste...@vi...> - 2001-06-18 17:20:51
|
On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
>
> > On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:
> > 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.
> OK. I did know what's was behind the RTTI thingy (kinda strange, I did not
> though that you could have the type_info without dynamic_cast).
All I'm saying is that the macro defines HAVE_RTTI based on the
presence of typeid(). You are probably right that dynamic_cast is
present if typeid() is present; I don't know much about RTTI. It may
be that the reverse is not true, however. My instinct is to assume
dynamic_cast is available, if needed, (and without checking) until
someone tells us otherwise.
> Well, I propose to keep USE_TYPEINFO.
>
> Our USE_TYPEINFO could be defined as: you have typeinfo, and the name()
> methode return a human readable name (that last one can't be tested by a
> machine unfortunately). So it's a stronger requirement than HAVE_RTTI.
It's true that GCC can produce an ungainly type name like
t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4GmpzZQ24CGALt8Quotient1ZQ24CGAL4Gmpz.point_intersection
so the idea of perhaps not using that name has merit. In that case,
the symbol might be more appropriately-named USE_TYPEINFO_NAME. You
may still wish to use type_info structures to test equality of
types.
I'll have to think about this. There seem to be relatively few uses
of using type_info::name() at present, and I'm puzzled by some of them.
For example, what is the purpose of class CppUnit::TypeInfoHelper? Is
there some advantage to using a class rather than a simple function
CppUnit::getClassName() ?
-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
|
|
From: Baptiste L. <bl...@cl...> - 2001-06-18 19:36:08
|
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Monday, June 18, 2001 7:20 PM
Subject: Re: [Cppunit-devel] config.h changes committed
> On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
> > OK. I did know what's was behind the RTTI thingy (kinda strange, I did
not
> > though that you could have the type_info without dynamic_cast).
>
> All I'm saying is that the macro defines HAVE_RTTI based on the
> presence of typeid(). You are probably right that dynamic_cast is
> present if typeid() is present; I don't know much about RTTI. It may
> be that the reverse is not true, however. My instinct is to assume
> dynamic_cast is available, if needed, (and without checking) until
> someone tells us otherwise.
OK.
> > Well, I propose to keep USE_TYPEINFO.
> >
> > Our USE_TYPEINFO could be defined as: you have typeinfo, and the
name()
> > methode return a human readable name (that last one can't be tested by a
> > machine unfortunately). So it's a stronger requirement than HAVE_RTTI.
>
> It's true that GCC can produce an ungainly type name like
>
>
t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4GmpzZQ24CGALt8Quo
tient1ZQ24CGAL4Gmpz.point_intersection
Yuck!!! Baastian, did you look up an explanation for this from the gcc
folks ? (name are still useful for debugging)
> so the idea of perhaps not using that name has merit. In that case,
> the symbol might be more appropriately-named USE_TYPEINFO_NAME. You
> may still wish to use type_info structures to test equality of
> types.
I agree, that name reveal the intention better.
>
> I'll have to think about this. There seem to be relatively few uses
> of using type_info::name() at present, and I'm puzzled by some of them.
>
> For example, what is the purpose of class CppUnit::TypeInfoHelper? Is
> there some advantage to using a class rather than a simple function
> CppUnit::getClassName() ?
Yes. I though that the class would grow, but it did not. Actually, isn't
that the only use of name() ?
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).
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X