Re: [Cppunit-devel] TestSuiteBuilder & type info...

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

Baptiste Lepilleur wrote:

> > No, it breaks the interface published in CppUnitW 1.2. The change already
> > had been made before the release of 1.5.5. I don't know whether that
> > increases or decreases your horror.
> > I'm sorry if I haven't made clear that I made these changes in preparation
> > of the 1.5.5 release. Now that you've got CVS working, missing updates
> > should be less likely.
>     Indeed, it seems that when I download the 1.5.5 release on sourceforge,
> the overwrite somehow failed and I was left with the old version you gave me
> for validation.
>
> > Whether you need RTTI depends on how/where you the need the name. For
> > example if you use your CU_TEST_SUITE HelperMacro, the Fixture name is
> > already available as the macro parameter.
>     1) macro are only there to make it easier to get started. I don't use
> CU_TEST_SUITE other than in old code (which used to be based on my old test
> framework and relied on macro to simulate reflection).

Hmm, the macros are itended to be used, aren't they? Else I see no reason to
include them in the project.

>
>     2) you can not extract template parameters that way. Trying to extract
> the name of the template parameter can be hell (at the top of my head, I'm
> thinging of traits)
>     3) you can't extract namespace that way

They only thing we need (at least for the TestSuiteBuilder) is the fully
qualified class name of the Fixture. In case of the macros we already got that.
For direct TestSuiteBuilder usage it's a question of giving it the name
yourself, not a big deal is it?

>
> > Portability is an issue: CppUnit is intented to be a cross platform
> library,
> > so the core feature set should be identical everywhere. Also the
> development
> > of CppUnit becomes messy if platform dependent code is scattered across
> core
> > classes. That's why I did not want RTTI stuff in TestSuite.
>     Ok for the removal from TestSuite, but why haven't you move it to
> TestSuiteBuilder ?
>     Why wasn't it discussed on this list ?
>

I thought I mentioned it here last week, but obviously I didn't. Sorry for
that, I was on a very thight time schedule: can't do CppUnit related stuff at
work at the moment and had to study for a computer ethics exam in the evening.
I'll try to be more communicative in the future.
About 'why not in TestSuiteBuilder': same reason as for TestSuite. The added
value is minimal: it's trivial to create the name outside the TestSuiteBuilder
class,  either with your RTTI  TypeInfoHelper or with a hand-coded string.

>
> > especially since the HelperMacros do not actually need the RTTI support.
>     Wrong, see problem with template and namespace above.

Could you elaborate a bit more about this problem? I don't see it. All I see is
just a simple name string for TestSuites.
I you do want to use RTTI in other places, please show why, where and how! I'm
not against RTTI per se, but I see little use for it so far.

>
>     Are you invocating the use of macro ;-) ?
>
> > For an RTTI supporting TestSuiteBuilder, I suggest subclassing it to add
> the
> > RTTI based constructor.
>     This would get messy, if somebody subclass TestSuiteBuilder to add some
> functionnality, it would make RTTI unusable. I don't see what's wrong by
> adding a constructor that is not available everywhere. Subclassing would be
> applying the refactoring "Introduce Local Extension" within the libary!!!
> Refer to the refactoring catalog, and you'll see there are many drawback
> with this (like the one I gave).
>

Yes, subclassing may not be ideal and not necessarily the best solution, but I
think having different interfaces for the same class on different platforms is
worse: I really want to avoid that people write extensions to CppUnit that may
be useful on all platforms in a non portable way simply because on their
platform CppUnit has a different interface.

>
> > In any case the TestSuiteBuilder is a smaller issue because it's not a
> core
> > class, and it's only a header file: no RTTI dependent code would have been
> > compiled in the CppUnit library either way.
> > That leaves the TestFactoryRegistry class, which still has the
> USE_TYPEINFO
> > #ifdef. I like to solve the issue somehow there too, before 1.5.6.
> > Suggestions are welcome!
>     This one could be removed since it is unused at the time, and I'm unsure
> of its use.
>

Do you mean removal of the 'registerFactory( TestFactory *factory )' or the
whole class?
The registerFactory method is used in AutoRegisterSuite.h and HostAppDoc, so
thes would be affected too. Please explain, or hack at will.


>
> > BTW, g++ isn't broken, the C++ standard is, because it does not specify
> > exactly what type_info::name() should return. The g++ people have simply
> > made a (for this purpose) not so useful choice of returning the mangled
> > name.
>     Sorry, I misused "proper". What I intended was more akin to "useful". I
> don't see any use for a name that can change between run and is not human
> readable.
>

The mangled name could be useful for debugging purposes. But like you, I'd
rather have a name() method that would return the fully qualified unmangled
name and and a raw_name() method that returns the mangled name, like MSVC++
does.
g++ isn't as bad as the standard allows: the type_info name does not change
between runs (and not even compilations AFAIK). But the mangled names have
changed between 2.91, 2.95 and 2.96+.

>
> > In fact, the next release of MSVC++ may return something completely
> > different from the current release as well. The underspecification of the
> > name() method, makes me suspicious of using it.
>     Well, as long as they keep it human readable there will be no problem. I
> don't think this will be a problem. Even if "class" is not prepend to class
> and template name, it will just be left. I removed it to shorten the name.
>

OK, as long as the name is only interpreted by humans, we can get away with the
variance in the name. But once the name ends up being processed automatically
somewhere, e.g. for multiplatform regression reporting, we're can run into
trouble.

A+

Bastiaan