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

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

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

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

> especially since the HelperMacros do not actually need the RTTI support.
    Wrong, see problem with template and namespace above.
    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).

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

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

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