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

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

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

> Hmm, the macros are itended to be used, aren't they? Else I see no
> reason to
> include them in the project.
  The macro have been design for 2 (3) things:
  - make first contact with cppunit easier. You don't have to understand the 
whole framework (notes that has drawback, you don't get to know the framework 
and may stick to macro instead of exploring the framework possibilities).
  - make it easy to write basic test.
  - (unoffical: easy conversion of my old unit test writen with my old unit 
testing framework).

  There is drawback though: you can only do what the macro have been designed 
to do: you can not use decorator, orthodox... You lose cppunit awesome 
flexibility.

> >     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.
  You don't need to specify the full name in the macro. This would be hell when 
you need five lines of code to specify that name. Even if you do, you don't get 
the actual template parameter type.

  For example:
  template<class StringType>
  class StringTest;

  Test *testStringChar = StringTest<char>::suite();
  Test *testStringWChar = StringTest<wchar_t>::suite();

  In the macro you would get the same name for both suite, with RTTI you get 
StringTest<char> and StringTest<unsigned short> (with VC++), which is very 
useful when one fail but not the other.

  This become important when you have 4 or 5 parameters which might themself be 
template (see this month expert column on generic programming in cuj for 
example: http://www.cuj.com/experts/1906/alexandr.htm?
topic=experts&topic=experts )

> 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 understand that, I have a hard jungling between projects and finding time 
for them too.

> 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.
  See my remarks above. 
  I made change to fix the whole stuff yesterday evening. It doesn't break any 
code, and TestSuite is not impacted.
  I modified the macro so it use RTTI if allowed, and use the macro parameter 
name otherwise. I also fixed TestFactoryRegistry so it doesn't use RTTI anymore 
(dummy name are generated instead).
  I'll commit the whole thing this evening.

> 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.
  See notes about template. It also works for namespace.

> 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.
  I'm not saying that on windows you should only use RTTI. If you do a project 
that might be ported to Unix then you must not use RTTI. But RTTI provides 
useful functionnality when working with template and namespace and when you 
know that you will never go for another platform with a project you might as 
well use them.
  I've added a configuration to VC++ projects that do not use RTTI (that how I 
found out that AutoRegisterSuite did not work without RTTI).
  It will be in this evening commit too.

> 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.
  Euhh... I completly forgot it was used but I've done a workaround. see 
somewhere above.

> 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+.
  OK. This is better than I though it was. Yet, not very usable for cppunit.


> 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.
  If I were to do multiplatform, I think I would name the test by hand to 
ensure that they have the same name. That is the cost of multiplatform, you 
must stick to the lowest common factor. The problem is often to find that 
lowest common factor. For cppunit, it is easily identified: do not use RTTI if 
you are doing multiplatform. We just have to stick it somewhere in the 
documentation (I'll put it in TestSuiteBuilder at the current time). But I 
would put it somewhere else. This fact is binded to the CU_USE_TYPEINFO macro, 
not TestSuiteBuilder. Any Suggestions on where to put that ?

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