Thread: RE: [Cppunit-devel] TestSuiteBuilder & type info...
Brought to you by:
blep
Menu
▾
▴
cppunit-devel
|
From: Bastiaan B. <bas...@li...> - 2001-05-14 08:32:57
|
-----Oorspronkelijk bericht-----
Van: Baptiste Lepilleur [mailto:bl...@cl...]
Verzonden: Sunday, May 13, 2001 11:31 AM
Aan: Cpp Unit Develpment Mailing List
Onderwerp: [Cppunit-devel] TestSuiteBuilder & type info...
I finally managed to setup WinCvs and ssh. I checked out cppunit,
Congrats.
recompile, and link against TTR...
Horror, all RTTI have been removed from TestSuiteBuilder and TestSuite
!!!
Can somebody explains me why it has been done ?
That would be me :-)
(You can check that with ViewCVS at SF by browsing the logs).
- It breaks the interface published in release 1.5.5
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.
- RTTI makes it easy to extract the name from template test case, which
is very difficult to do otherwise.
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.
- Portability is not an issue (though it should be document since you
would expect g++ to have a proper support for RTTI). Lots of people develops
for one platform only.
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.
The #ifdefs I put in where a non-elegant temporary solution, which did not
solve the development problem.
Since the actual RTTI code inside TestSuite is trivial, it may as be done
byt the caller, outside the TestSuite class. Likewise the TestSuiteBuilder
seems useful too if you don't have RTTI, so I removed it there too;
especially since the HelperMacros do not actually need the RTTI support.
For an RTTI supporting TestSuiteBuilder, I suggest subclassing it to add the
RTTI based constructor.
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!
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.
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.
Bastiaan
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).
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel
|
|
From: Baptiste L. <bl...@cl...> - 2001-05-16 19:05:33
|
> 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.
|
|
From: Bastiaan B. <bas...@li...> - 2001-05-17 22:55:49
|
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 |
|
From: Baptiste L. <gai...@fr...> - 2001-05-18 12:06:29
|
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 |
|
From: Baptiste L. <bl...@cl...> - 2001-05-18 19:40:25
|
> 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. It's done. CU_TEST_SUITE_REGISTRATION and AutoRegisterSuite can now be used without RTTI. Notes that USE_TYPEINFO have been changed to CU_USE_TYPEINFO. A configuration have been added to VC++ project to compile without typeinfo. 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). |
|
From: Bastiaan B. <bas...@li...> - 2001-05-20 23:25:21
|
Baptiste Lepilleur wrote: -8<-- > > 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 ) > OK, finally I start to understand what you mean! :-) I've mostly been doing Java programming the last few years. No generics there, so I'm not too intimate with those and some other C++ features. Thanks for the C++ Journal link. Interesting information, the author is pretty sick bastard though: calling writing a dozen basic_string implementations 'fun' :-D I must be a C++ wimp ;-) --8<-- > 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 don't care what people do on their own projects: they should be free to keep any platform dependencies they want. My worry is that the more platform dependent features get into CppUnit the more difficult it becomes to maintain: people on other platforms cannot check whether they break these features, more code than neccessary may come to depend on it, etc. ,etc. > > 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. > OK, do what's necessary for the RTTI features. Now that I understand how it may be useful, I would not want to keep excluding it from the project. > > > 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. > Indeed, it isn't. I'll see if I can get the reasoning behind from one of the g++ folks. > > > 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 ? > With the TypeInfoHelper class? Bastiaan > > --- > Baptiste Lepilleur <gai...@fr...> > http://gaiacrtn.free.fr/index.html > Language: English, French > > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > http://lists.sourceforge.net/lists/listinfo/cppunit-devel |
|
From: Baptiste L. <gai...@fr...> - 2001-05-21 16:41:34
|
Quoting Bastiaan Bakker <bas...@li...>: > Baptiste Lepilleur wrote: > > OK, finally I start to understand what you mean! :-) > I've mostly been doing Java programming the last few years. No generics > there, so > I'm not too intimate with those and some other C++ features. > Thanks for the C++ Journal link. Interesting information, the author is > pretty > sick bastard though: calling writing a dozen basic_string > implementations 'fun' > :-D > I must be a C++ wimp ;-) Well, I discovered this aspect of generic programming not so long ago and I see unit testing as a perfect way to solve many of the problems I have when pushing template this far (compilation error that appear only when you us the method, testing...). That's why I pushing that aspect forward. > I don't care what people do on their own projects: they should be free > to keep any > platform dependencies they want. > My worry is that the more platform dependent features get into CppUnit > the more > difficult it becomes to maintain: people on other platforms cannot > check whether > they break these features, more code than neccessary may come to depend > on it, > etc. ,etc. From what you said it is possible to compile with RTTI enabled for g++. Even if the result is not readable, knowing that it compile is a first step. I added a configuration to compile without RTTI on VC++, that's how I discovered that the AutoRegisterSuite did not work (that's fixed now). You could do the same for Unix. I was thinking of doing unit test to test cppunit. I once found the test cases for Junit, but I looked for them and couldn't find them ! Such unit tests would allow us to test the many aspects of cppunit ;-) (the current example barely skim the surface). > OK, do what's necessary for the RTTI features. Now that I understand how > it may be > useful, I would not want to keep excluding it from the project. This is in CVS now. > > Indeed, it isn't. I'll see if I can get the reasoning behind from one of > the g++ > folks. Yes that would be interesting. > > 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 ? > > > > With the TypeInfoHelper class? Yes I'll put it there for now, but It's buried pretty deep. I would like to have something more like a build guide that say "using CU_USE_TYPEINFO you can do this and that, but you lose multiplatform." I doubt the user would bother reading each class documentation. He doesn't even use TypeInfoHelper. Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, 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