cppunit-devel Mailing List for CppUnit - C++ port of JUnit (Page 39)
Brought to you by:
blep
Menu
▾
▴
cppunit-devel — CppUnit Developer Mailing List
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(21) |
May
(96) |
Jun
(109) |
Jul
(42) |
Aug
(6) |
Sep
(106) |
Oct
(60) |
Nov
(20) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(7) |
Feb
(11) |
Mar
(49) |
Apr
(124) |
May
(30) |
Jun
(37) |
Jul
(53) |
Aug
(33) |
Sep
(21) |
Oct
(22) |
Nov
(19) |
Dec
(15) |
| 2003 |
Jan
(34) |
Feb
(25) |
Mar
(11) |
Apr
(12) |
May
(16) |
Jun
(24) |
Jul
(23) |
Aug
(23) |
Sep
(42) |
Oct
(7) |
Nov
(32) |
Dec
(33) |
| 2004 |
Jan
(41) |
Feb
(41) |
Mar
(24) |
Apr
(25) |
May
(18) |
Jun
(13) |
Jul
(11) |
Aug
(15) |
Sep
(22) |
Oct
(10) |
Nov
(15) |
Dec
(9) |
| 2005 |
Jan
(4) |
Feb
(15) |
Mar
(11) |
Apr
(16) |
May
(29) |
Jun
(17) |
Jul
(27) |
Aug
(12) |
Sep
(9) |
Oct
(10) |
Nov
(5) |
Dec
(6) |
| 2006 |
Jan
(2) |
Feb
(6) |
Mar
(7) |
Apr
(2) |
May
(1) |
Jun
(5) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(11) |
Nov
(15) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(22) |
Mar
(10) |
Apr
(7) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Baptiste L. <gai...@fr...> - 2002-04-19 09:51:34
|
I've been writting a lot of documentation using doxygen... And found some interesting stuff. This is the result. The tools and documentation install for cppunit 1.8.0 are available on sourcforge release. Baptiste. What is MSDN Integrator: ----------------------------------------- MSDN Integrator is a free tool created by Codejock.com software (http://www.codejock.com/) See the 'free stuff' section of their web site for details. MSDN Integrator can integrate a HTML HELP documentation with MSDN, and remove it later. If you have the source release of MSDN Integrator, you can found the documentation in Doc/MSDNIntegrator.chm. What was changed: ------------------------------- I added loading of dialog fields from a .INI file to automatize documentation installation (the user don't have to remember the GUID...). Version available (sources& binary) at: http://www.sourceforge.net/projects/cppunit/ See MSDN-CppUnit.INI for an example of .INI file. Pass the file name as a parameter on the command line. All file name can be relative to the current directory. Provides a batch file that automatically do that for end-user. Enjoy, Baptiste. -- Baptiste Lepilleur <gaiacrtn@free.> http://gaiacrtn.free.fr/index.html |
|
From: Duane M. <dua...@ma...> - 2002-04-19 06:54:51
|
--- At Fri, 19 Apr 2002 10:37:29 +0900, FUKUDA Fumiki wrote:
>--- "Re: [Cppunit-devel] questionable code @ TypeInfoHelper.cpp" / Duane
>Murphy / 2002/04/18 08:12:06 -0700 ---
>>>----- excerpt from src/cppunit/TypeInfoHelper.cpp -----
>>>std::string
>>>TypeInfoHelper::getClassName( const std::type_info &info )
>>>{
>>> static std::string classPrefix( "class " );
>>> std::string name( info.name() );
>>>
>>> bool has_class_prefix = 0 ==
>>>#if CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST
>>> name.compare( classPrefix, 0, classPrefix.length() );
>>>#else
>>> name.compare( 0, classPrefix.length(), classPrefix );
>>>#endif
>>> return has_class_prefix ? name.substr( classPrefix.length() ) : name;
>>>}
>>>------------------
>>>
>>>if info.name().length() < classPrefix.length(), an exception should be
>>thrown.
>>>I think this method should return 'name' at this condition (as follows).
>>
>>This is incorrect. string.compare() will not throw an exception under
>>these conditions. The minimum of classPrefix.length() and
>>info.name().length() will be compared. The code is fine.
>
>thanks. yes, you're correct...
>some of stdlib impl. throws exception on this case....
>
>I'm now trying to mekr 'makefile' for Borland C++ 5.5 free compiler,
>BC++5.5's stdlib throws... I think its stdlib was implemented based
>on old version of std-C++ spec.
>
>If CppUnit can add only-1-line in TypeInfoHelper.cpp,
>It make lot of BC++5.5 uses happy. please consider.
Thank you for explaining. Bad implementations of stdlib are a real pain.
This is a reasonable work around for this poor implementation.
...Duane
--
"If tyranny and oppression come to this land, it will be in the
guise of fighting a foreign enemy." - James Madison
|
|
From: FUKUDA F. <ff...@nt...> - 2002-04-19 01:38:03
|
--- "Re: [Cppunit-devel] questionable code @ TypeInfoHelper.cpp" / Duane Murphy / 2002/04/18 08:12:06 -0700 ---
>>----- excerpt from src/cppunit/TypeInfoHelper.cpp -----
>>std::string
>>TypeInfoHelper::getClassName( const std::type_info &info )
>>{
>> static std::string classPrefix( "class " );
>> std::string name( info.name() );
>>
>> bool has_class_prefix = 0 ==
>>#if CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST
>> name.compare( classPrefix, 0, classPrefix.length() );
>>#else
>> name.compare( 0, classPrefix.length(), classPrefix );
>>#endif
>> return has_class_prefix ? name.substr( classPrefix.length() ) : name;
>>}
>>------------------
>>
>>if info.name().length() < classPrefix.length(), an exception should be
>thrown.
>>I think this method should return 'name' at this condition (as follows).
>
>This is incorrect. string.compare() will not throw an exception under
>these conditions. The minimum of classPrefix.length() and
>info.name().length() will be compared. The code is fine.
thanks. yes, you're correct...
some of stdlib impl. throws exception on this case....
I'm now trying to mekr 'makefile' for Borland C++ 5.5 free compiler,
BC++5.5's stdlib throws... I think its stdlib was implemented based
on old version of std-C++ spec.
If CppUnit can add only-1-line in TypeInfoHelper.cpp,
It make lot of BC++5.5 uses happy. please consider.
-----:-----:-----:-----:-----:-----:-----:-----:-----:-----
FUKUDA (episteme) Fumiki -- magical, but never a magic...
|
|
From: Duane M. <dua...@ma...> - 2002-04-18 15:12:26
|
--- At Thu, 18 Apr 2002 16:05:54 +0900, FUKUDA Fumiki wrote:
>Hi all,
>
>----- excerpt from src/cppunit/TypeInfoHelper.cpp -----
>std::string
>TypeInfoHelper::getClassName( const std::type_info &info )
>{
> static std::string classPrefix( "class " );
> std::string name( info.name() );
>
> bool has_class_prefix = 0 ==
>#if CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST
> name.compare( classPrefix, 0, classPrefix.length() );
>#else
> name.compare( 0, classPrefix.length(), classPrefix );
>#endif
> return has_class_prefix ? name.substr( classPrefix.length() ) : name;
>}
>------------------
>
>if info.name().length() < classPrefix.length(), an exception should be
thrown.
>I think this method should return 'name' at this condition (as follows).
This is incorrect. string.compare() will not throw an exception under
these conditions. The minimum of classPrefix.length() and
info.name().length() will be compared. The code is fine.
...Duane
--
"If tyranny and oppression come to this land, it will be in the
guise of fighting a foreign enemy." - James Madison
|
|
From: Philippe L. <phi...@ca...> - 2002-04-18 13:34:03
|
Can it be added to your 'oh so small' todo list ? ;) Phil PS Or point me toward a winmain of some kind and all modify it for ya :) = I couldn't find the winmain, that's why I didn't do it in the first = place... > -----Original Message----- > From: Baptiste Lepilleur [mailto:gai...@fr...] > Sent: Wednesday, April 17, 2002 10:15 AM > To: cpp...@li... > Subject: Re: [Cppunit-devel] What are the command line arguments for > TestPluginRunner? >=20 >=20 > You should use DllTestPlugInTester. TestPlugInRunner don't=20 > take any command > line arguments. >=20 > Baptiste. >=20 >=20 > ----- Original Message ----- > From: "Philippe Lavoie" <phi...@ca...> > To: <cpp...@li...> > Sent: Tuesday, April 16, 2002 12:21 AM > Subject: [Cppunit-devel] What are the command line arguments for > TestPluginRunner? >=20 >=20 > Hi, >=20 > I'd like to add cppunit to the tools/external tools menu. >=20 > I did >=20 > Program: TestPluginRunner.exe > Arguments: $(TargetPath) > InitialDir: $(TargetDir) >=20 > where $(TargetPath) is the full qualifed name of the output dll. >=20 > What I was expecting was to have my dll preloaded with the=20 > root test node > selected. Can somebody tell me if what I'm doing is feasible ? >=20 > Thanks >=20 > Phil >=20 > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel >=20 >=20 >=20 > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel >=20 |
|
From: FUKUDA F. <ff...@nt...> - 2002-04-18 07:06:37
|
Hi all,
----- excerpt from src/cppunit/TypeInfoHelper.cpp -----
std::string
TypeInfoHelper::getClassName( const std::type_info &info )
{
static std::string classPrefix( "class " );
std::string name( info.name() );
bool has_class_prefix = 0 ==
#if CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST
name.compare( classPrefix, 0, classPrefix.length() );
#else
name.compare( 0, classPrefix.length(), classPrefix );
#endif
return has_class_prefix ? name.substr( classPrefix.length() ) : name;
}
------------------
if info.name().length() < classPrefix.length(), an exception should be thrown.
I think this method should return 'name' at this condition (as follows).
...
static std::string classPrefix( "class " );
std::string name( info.name() );
if ( name.length() < classPrefix.size() ) return name; // ADD THIS!
bool has_class_prefix = 0 == ...
-----:-----:-----:-----:-----:-----:-----:-----:-----:-----
FUKUDA (episteme) Fumiki -- magical, but never a magic...
|
|
From: Baptiste L. <gai...@fr...> - 2002-04-17 22:38:23
|
Could you point out your question, because I can not find it... Baptiste ----- Original Message ----- From: "Chris Richards" <Chr...@sy...> To: <cpp...@li...> Sent: Wednesday, April 17, 2002 10:15 AM Subject: [Cppunit-devel] help > > > -----Original Message----- > From: cpp...@li... > [mailto:cpp...@li...] > Sent: 16 April 2002 20:02 > To: cpp...@li... > Subject: Cppunit-devel digest, Vol 1 #172 - 6 msgs > > > Send Cppunit-devel mailing list submissions to > cpp...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/cppunit-devel > or, via email, send a message with subject or body 'help' to > cpp...@li... [...] |
|
From: Baptiste L. <gai...@fr...> - 2002-04-17 22:19:52
|
You should use DllTestPlugInTester. TestPlugInRunner don't take any command line arguments. Baptiste. ----- Original Message ----- From: "Philippe Lavoie" <phi...@ca...> To: <cpp...@li...> Sent: Tuesday, April 16, 2002 12:21 AM Subject: [Cppunit-devel] What are the command line arguments for TestPluginRunner? Hi, I'd like to add cppunit to the tools/external tools menu. I did Program: TestPluginRunner.exe Arguments: $(TargetPath) InitialDir: $(TargetDir) where $(TargetPath) is the full qualifed name of the output dll. What I was expecting was to have my dll preloaded with the root test node selected. Can somebody tell me if what I'm doing is feasible ? Thanks Phil _______________________________________________ Cppunit-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppunit-devel |
|
From: Chris R. <Chr...@sy...> - 2002-04-17 08:21:36
|
-----Original Message----- From: cpp...@li... [mailto:cpp...@li...] Sent: 16 April 2002 20:02 To: cpp...@li... Subject: Cppunit-devel digest, Vol 1 #172 - 6 msgs Send Cppunit-devel mailing list submissions to cpp...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/cppunit-devel or, via email, send a message with subject or body 'help' to cpp...@li... You can reach the person managing the list at cpp...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Cppunit-devel digest..." Today's Topics: 1. Re: Toward True Unicode Code... Help requested (Baptiste Lepilleur) 2. Re: Specifying coed page (was: Toward True Unicode Code... Help requested) (Baptiste Lepilleur) 3. Re: Signal handling in Linux (Baptiste Lepilleur) 4. Detecting --disable-test-plugin from configure.in (Baptiste Lepilleur) 5. Re: Toward True Unicode Code... Help requested (Duane Murphy) 6. Re: Toward True Unicode Code... Help requested (Baptiste Lepilleur) --__--__-- Message: 1 Reply-To: "Baptiste Lepilleur" <gai...@fr...> From: "Baptiste Lepilleur" <gai...@fr...> To: "CppUnit Developers" <cpp...@li...> Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested Date: Tue, 16 Apr 2002 13:51:54 +0200 Organization: Gaia Creation ----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 1:37 AM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > > >----- Original Message ----- > >From: "Duane Murphy" <dua...@ma...> > >To: "CppUnit Developers" <cpp...@li...> > >Sent: Sunday, April 14, 2002 7:35 PM > >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > [...] > I hope I understand the question. If I output a string that includes a > '\n' in a stream, and some other process is parsing that stream, will > '\n' be unique? > > The answer is yes! I was equally stunned to here this. Once a shift > character is seen that identifies that following characters as unicode, > then none of the bytes that are part of that unicode "character" will be > less than 128! This is what makes UTF-8 work. All characters <128 are > always ASCII! Great, that means even ouputters relying on that are compatible with UTF8 (CompilerOutputter which as some line wrapping code). Baptiste. --__--__-- Message: 2 Reply-To: "Baptiste Lepilleur" <gai...@fr...> From: "Baptiste Lepilleur" <gai...@fr...> To: "CppUnit Developers" <cpp...@li...> Subject: Re: [Cppunit-devel] Specifying coed page (was: Toward True Unicode Code... Help requested) Date: Tue, 16 Apr 2002 13:57:46 +0200 Organization: Gaia Creation ----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 1:37 AM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > [...] > I'm not sure where you want to specify a code page and I'm not always > clear as to what a code page means in some contexts. I think (and this is > very old memory) that the encoding of an XML file can be UTF-8. Beyond > that, I dont know. The only stuff I know to specify code page is VC++ specific: // Set the locale setlocale( LC_ALL, "jpn" ); // Set the code associated to the current locale _setmbcp( _MB_CP_LOCALE ); When you do that, VC++ is supposed to use the specified locale when doing MBCS <=> UNICODE conversion. So, if you could specify a UTF8 code page, you would have a cheap way of doing UTF8/UNICODE conversion. (understand UNICODE as wchat_t ;-) ). Baptiste. --__--__-- Message: 3 Reply-To: "Baptiste Lepilleur" <gai...@fr...> From: "Baptiste Lepilleur" <gai...@fr...> To: <cpp...@li...> Subject: Re: [Cppunit-devel] Signal handling in Linux Date: Tue, 16 Apr 2002 14:34:18 +0200 Organization: Gaia Creation ----- Original Message ----- From: "Robert Wenner" <ro...@po...> To: "Baptiste Lepilleur" <gai...@fr...>; <cpp...@li...> Sent: Tuesday, April 16, 2002 7:58 AM Subject: Re: [Cppunit-devel] Signal handling in Linux > Hi! > > On Monday 15 April 2002 23:44, Baptiste Lepilleur wrote: > > So If I understood thing well, the only hope that remains would > > compiler specific. VC++ has such a thing, have you found anything > > like that on gcc ? (I guess not, but...) > > I think it would be compiler dependent, yes. > I do not know the exact behaviour in VC++, but I did not even found > something like a workaround on g++, as my C style stuff didn't work > as expected I quickly dropped that topic and tried to have test cases > that don't result in null pointer access -- not the bes solution, I > know... VC++ as a function called _set_se_translator() which allow you to set a 'translator' that is called to handle structured exception (the equivalent of signal if I understood correctly) and convert them into C++ exception. In any case, the stack frame is always unwinded correctly. Structured exception are the equivalent for VC++ to a throw int(exception_type) (in debug mode), which explains why catch(...) works for us even though we did not set any exception translator. > > > In the meantime, I think I'll add a VerboseTestProgressListener: > > startTest(): print test name > > failure(): print ':' and 'E' or 'F' > > endTest(): new line > Better to be names BriefTestProgressListener? Done. If you have others suggestions like that one, they are welcome. One of the step that will be taken before going beta is renaming 'not so intention revealing classes' (TestResult is a primary candidate but does not have its final form yet). Thanks, Baptiste. --__--__-- Message: 4 Reply-To: "Baptiste Lepilleur" <gai...@fr...> From: "Baptiste Lepilleur" <gai...@fr...> To: <cpp...@li...> Date: Tue, 16 Apr 2002 15:52:46 +0200 Organization: Gaia Creation Subject: [Cppunit-devel] Detecting --disable-test-plugin from configure.in I was reading some of the autobook. Will adding the following code after the USE_TYPE_INFO to configure.in, will define the symbol CPPUNIT_NO_TESTPLUGIN if --disable-test-plugin is used on the command line ? AC_ARG_ENABLE(test-plugin, [ --disable-test-plugin disable support for test plug-ins], [ if test -n "$enable_test_plugin"; then enable_test_plugin=${enable_test_plugin_default-yes} fi if test "$enable_test_plugin" = no; then AC_DEFINE(NO_TESTPLUGIN) fi ]) Baptiste. --__--__-- Message: 5 From: Duane Murphy <dua...@ma...> To: Baptiste Lepilleur <gai...@fr...>, CppUnit Developers <cpp...@li...> Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested Date: Tue, 16 Apr 2002 08:28:46 -0700 --- At Tue, 16 Apr 2002 13:51:54 +0200, Baptiste Lepilleur wrote: >----- Original Message ----- >From: "Duane Murphy" <dua...@ma...> >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" ><cpp...@li...> >Sent: Tuesday, April 16, 2002 1:37 AM >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > >> --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: >> >> >----- Original Message ----- >> >From: "Duane Murphy" <dua...@ma...> >> >To: "CppUnit Developers" <cpp...@li...> >> >Sent: Sunday, April 14, 2002 7:35 PM >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested >> > >[...] >> I hope I understand the question. If I output a string that includes a >> '\n' in a stream, and some other process is parsing that stream, will >> '\n' be unique? >> >> The answer is yes! I was equally stunned to here this. Once a shift >> character is seen that identifies that following characters as unicode, >> then none of the bytes that are part of that unicode "character" will be >> less than 128! This is what makes UTF-8 work. All characters <128 are >> always ASCII! > >Great, that means even ouputters relying on that are compatible with UTF8 >(CompilerOutputter which as some line wrapping code). I want to make sure that this question is properly understood. If you are just searching for '\n' in a stream or string then that will work fine. If you are looking to insert '\n' (or any other characters) at some position then things get complicated. ...Duane -- "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison --__--__-- Message: 6 Reply-To: "Baptiste Lepilleur" <gai...@fr...> From: "Baptiste Lepilleur" <gai...@fr...> To: "CppUnit Developers" <cpp...@li...> Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested Date: Tue, 16 Apr 2002 20:28:56 +0200 Organization: Gaia Creation ----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 5:28 PM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Tue, 16 Apr 2002 13:51:54 +0200, Baptiste Lepilleur wrote: > >----- Original Message ----- > >From: "Duane Murphy" <dua...@ma...> > >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" > ><cpp...@li...> > >Sent: Tuesday, April 16, 2002 1:37 AM > >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > > > > >> --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > >> > >> >----- Original Message ----- > >> >From: "Duane Murphy" <dua...@ma...> > >> >To: "CppUnit Developers" <cpp...@li...> > >> >Sent: Sunday, April 14, 2002 7:35 PM > >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > >> > > >[...] > >> I hope I understand the question. If I output a string that includes a > >> '\n' in a stream, and some other process is parsing that stream, will > >> '\n' be unique? > >> > >> The answer is yes! I was equally stunned to here this. Once a shift > >> character is seen that identifies that following characters as unicode, > >> then none of the bytes that are part of that unicode "character" will be > >> less than 128! This is what makes UTF-8 work. All characters <128 are > >> always ASCII! > > > >Great, that means even ouputters relying on that are compatible with UTF8 > >(CompilerOutputter which as some line wrapping code). > > I want to make sure that this question is properly understood. If you are > just searching for '\n' in a stream or string then that will work fine. > If you are looking to insert '\n' (or any other characters) at some > position then things get complicated. You understood the question well. It's me who did not have all my head when I answered. Indeed I insert '\n', which make it not UTF8 compatible. This is an issue that will need to be addressed in the future. Thanks, Baptiste. > > ...Duane > > -- > "If tyranny and oppression come to this land, it will be in the > guise of fighting a foreign enemy." - James Madison > > > --__--__-- _______________________________________________ Cppunit-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppunit-devel End of Cppunit-devel Digest |
|
From: Duane M. <dua...@ma...> - 2002-04-16 21:11:07
|
--- At Tue, 16 Apr 2002 20:28:56 +0200, Baptiste Lepilleur wrote: >----- Original Message ----- >From: "Duane Murphy" <dua...@ma...> >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" ><cpp...@li...> >Sent: Tuesday, April 16, 2002 5:28 PM >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > >> --- At Tue, 16 Apr 2002 13:51:54 +0200, Baptiste Lepilleur wrote: >> >----- Original Message ----- >> >From: "Duane Murphy" <dua...@ma...> >> >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" >> ><cpp...@li...> >> >Sent: Tuesday, April 16, 2002 1:37 AM >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested >> > >> > >> >> --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: >> >> >> >> >----- Original Message ----- >> >> >From: "Duane Murphy" <dua...@ma...> >> >> >To: "CppUnit Developers" <cpp...@li...> >> >> >Sent: Sunday, April 14, 2002 7:35 PM >> >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help >requested >> >> > >> >[...] >> >> I hope I understand the question. If I output a string that includes a >> >> '\n' in a stream, and some other process is parsing that stream, will >> >> '\n' be unique? >> >> >> >> The answer is yes! I was equally stunned to here this. Once a shift >> >> character is seen that identifies that following characters as unicode, >> >> then none of the bytes that are part of that unicode "character" will >be >> >> less than 128! This is what makes UTF-8 work. All characters <128 are >> >> always ASCII! >> > >> >Great, that means even ouputters relying on that are compatible with UTF8 >> >(CompilerOutputter which as some line wrapping code). >> >> I want to make sure that this question is properly understood. If you are >> just searching for '\n' in a stream or string then that will work fine. >> If you are looking to insert '\n' (or any other characters) at some >> position then things get complicated. > >You understood the question well. It's me who did not have all my head when >I answered. Indeed I insert '\n', which make it not UTF8 compatible. This is >an issue that will need to be addressed in the future. This is where I have hopes of the standards committee adding something to the standard to address unicode support. Presently there is no standard API for identifying character boundaries. I suspect its not that hard to do by hand but its also something that most OS's provide an interface for. Maybe some kind of abstraction. All you need to do is find a place that's safe to insert characters; that's between characters not inter-character. I think most OS's provide that capability, so this would be an OS dependent abstraction. ...Duane -- "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison |
|
From: Baptiste L. <gai...@fr...> - 2002-04-16 18:21:55
|
----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 5:28 PM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Tue, 16 Apr 2002 13:51:54 +0200, Baptiste Lepilleur wrote: > >----- Original Message ----- > >From: "Duane Murphy" <dua...@ma...> > >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" > ><cpp...@li...> > >Sent: Tuesday, April 16, 2002 1:37 AM > >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > > > > >> --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > >> > >> >----- Original Message ----- > >> >From: "Duane Murphy" <dua...@ma...> > >> >To: "CppUnit Developers" <cpp...@li...> > >> >Sent: Sunday, April 14, 2002 7:35 PM > >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > >> > > >[...] > >> I hope I understand the question. If I output a string that includes a > >> '\n' in a stream, and some other process is parsing that stream, will > >> '\n' be unique? > >> > >> The answer is yes! I was equally stunned to here this. Once a shift > >> character is seen that identifies that following characters as unicode, > >> then none of the bytes that are part of that unicode "character" will be > >> less than 128! This is what makes UTF-8 work. All characters <128 are > >> always ASCII! > > > >Great, that means even ouputters relying on that are compatible with UTF8 > >(CompilerOutputter which as some line wrapping code). > > I want to make sure that this question is properly understood. If you are > just searching for '\n' in a stream or string then that will work fine. > If you are looking to insert '\n' (or any other characters) at some > position then things get complicated. You understood the question well. It's me who did not have all my head when I answered. Indeed I insert '\n', which make it not UTF8 compatible. This is an issue that will need to be addressed in the future. Thanks, Baptiste. > > ...Duane > > -- > "If tyranny and oppression come to this land, it will be in the > guise of fighting a foreign enemy." - James Madison > > > |
|
From: Duane M. <dua...@ma...> - 2002-04-16 15:29:01
|
--- At Tue, 16 Apr 2002 13:51:54 +0200, Baptiste Lepilleur wrote: >----- Original Message ----- >From: "Duane Murphy" <dua...@ma...> >To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" ><cpp...@li...> >Sent: Tuesday, April 16, 2002 1:37 AM >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > >> --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: >> >> >----- Original Message ----- >> >From: "Duane Murphy" <dua...@ma...> >> >To: "CppUnit Developers" <cpp...@li...> >> >Sent: Sunday, April 14, 2002 7:35 PM >> >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested >> > >[...] >> I hope I understand the question. If I output a string that includes a >> '\n' in a stream, and some other process is parsing that stream, will >> '\n' be unique? >> >> The answer is yes! I was equally stunned to here this. Once a shift >> character is seen that identifies that following characters as unicode, >> then none of the bytes that are part of that unicode "character" will be >> less than 128! This is what makes UTF-8 work. All characters <128 are >> always ASCII! > >Great, that means even ouputters relying on that are compatible with UTF8 >(CompilerOutputter which as some line wrapping code). I want to make sure that this question is properly understood. If you are just searching for '\n' in a stream or string then that will work fine. If you are looking to insert '\n' (or any other characters) at some position then things get complicated. ...Duane -- "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison |
|
From: Baptiste L. <gai...@fr...> - 2002-04-16 13:53:07
|
I was reading some of the autobook. Will adding the following code after the
USE_TYPE_INFO to configure.in, will define the symbol CPPUNIT_NO_TESTPLUGIN
if --disable-test-plugin is used on the command line ?
AC_ARG_ENABLE(test-plugin,
[ --disable-test-plugin disable support for test plug-ins],
[
if test -n "$enable_test_plugin"; then
enable_test_plugin=${enable_test_plugin_default-yes}
fi
if test "$enable_test_plugin" = no; then
AC_DEFINE(NO_TESTPLUGIN)
fi
])
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2002-04-16 12:39:57
|
----- Original Message ----- From: "Robert Wenner" <ro...@po...> To: "Baptiste Lepilleur" <gai...@fr...>; <cpp...@li...> Sent: Tuesday, April 16, 2002 7:58 AM Subject: Re: [Cppunit-devel] Signal handling in Linux > Hi! > > On Monday 15 April 2002 23:44, Baptiste Lepilleur wrote: > > So If I understood thing well, the only hope that remains would > > compiler specific. VC++ has such a thing, have you found anything > > like that on gcc ? (I guess not, but...) > > I think it would be compiler dependent, yes. > I do not know the exact behaviour in VC++, but I did not even found > something like a workaround on g++, as my C style stuff didn't work > as expected I quickly dropped that topic and tried to have test cases > that don't result in null pointer access -- not the bes solution, I > know... VC++ as a function called _set_se_translator() which allow you to set a 'translator' that is called to handle structured exception (the equivalent of signal if I understood correctly) and convert them into C++ exception. In any case, the stack frame is always unwinded correctly. Structured exception are the equivalent for VC++ to a throw int(exception_type) (in debug mode), which explains why catch(...) works for us even though we did not set any exception translator. > > > In the meantime, I think I'll add a VerboseTestProgressListener: > > startTest(): print test name > > failure(): print ':' and 'E' or 'F' > > endTest(): new line > Better to be names BriefTestProgressListener? Done. If you have others suggestions like that one, they are welcome. One of the step that will be taken before going beta is renaming 'not so intention revealing classes' (TestResult is a primary candidate but does not have its final form yet). Thanks, Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-04-16 12:39:54
|
----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 1:37 AM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > [...] > I'm not sure where you want to specify a code page and I'm not always > clear as to what a code page means in some contexts. I think (and this is > very old memory) that the encoding of an XML file can be UTF-8. Beyond > that, I dont know. The only stuff I know to specify code page is VC++ specific: // Set the locale setlocale( LC_ALL, "jpn" ); // Set the code associated to the current locale _setmbcp( _MB_CP_LOCALE ); When you do that, VC++ is supposed to use the specified locale when doing MBCS <=> UNICODE conversion. So, if you could specify a UTF8 code page, you would have a cheap way of doing UTF8/UNICODE conversion. (understand UNICODE as wchat_t ;-) ). Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-04-16 12:39:52
|
----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, April 16, 2002 1:37 AM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > --- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: > > >----- Original Message ----- > >From: "Duane Murphy" <dua...@ma...> > >To: "CppUnit Developers" <cpp...@li...> > >Sent: Sunday, April 14, 2002 7:35 PM > >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > [...] > I hope I understand the question. If I output a string that includes a > '\n' in a stream, and some other process is parsing that stream, will > '\n' be unique? > > The answer is yes! I was equally stunned to here this. Once a shift > character is seen that identifies that following characters as unicode, > then none of the bytes that are part of that unicode "character" will be > less than 128! This is what makes UTF-8 work. All characters <128 are > always ASCII! Great, that means even ouputters relying on that are compatible with UTF8 (CompilerOutputter which as some line wrapping code). Baptiste. |
|
From: Volker B. <vbo...@te...> - 2002-04-16 07:28:08
|
On Tue, 16 Apr 2002, Baptiste Lepilleur wrote: > Are others interested in the __PRETTY_FUNCTION__ support ? I was digging = in > the ML archive when I found that very old mail (that apparently went > unanswered :-( ). >=20 > Suggested implementation: extending SourceLine (that's a 10mn change sinc= e > everything is centralized there. What a foresight ;-) ). >=20 > The big bad thing that will take time is detecting gcc and adding the > necessary autoconf/configure thingy. Well, and may be figuring out how to > extend the Outputters... ;-) the following configure.in excerpt detects gcc and show how to use the result: AC_PROG_CXX if test X"$GXX" =3D Xyes; then echo "we're using GNU g++" fi On the other hand testing #ifdef __GNUC__ should be enough... As you see in /usr/include/assert.h there is some gcc-version dependency but this can be safely ignored I think. > ----- Original Message ----- > From: "John Carter" <joh...@ta...> [...] > > Autoconf enable/disable feature? > > configure --enable-pretty-function --enable-emacs-support I would vote for making it optional since often the template arguments makes output hard to read. Regards Volker --=20 Volker Boerchers <vbo...@te...> System Engineer TECON Systems AG, Perlengraben 2, 50676 K=F6ln, http://www.tecon.de Tel: +49-221-92007-55, Fax: +49-221-92007-77 |
|
From: Duane M. <dua...@ma...> - 2002-04-15 23:37:18
|
--- At Mon, 15 Apr 2002 23:32:29 +0200, Baptiste Lepilleur wrote: >----- Original Message ----- >From: "Duane Murphy" <dua...@ma...> >To: "CppUnit Developers" <cpp...@li...> >Sent: Sunday, April 14, 2002 7:35 PM >Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > > >> My two cents for what its worth is to do nothing. >> >> There is no "True" Unicode. There are several unicode formats. UTF-8, >> UTF-16, and the upcoming UTF-32 among others. I have been told by some >> associates that keep up with such things that UTF-16, while currently >> being used, is on its way out in favor of UTF-32. It is most often >> recommended to use the simple UTF-8 for most applications. >> >> UTF-8 will likely satisfy most of us and require absolutlely no changes. >> UTF-8 is completely compatible with ASCII (for characters < 128). UTF-8 >> fits nicely in a standard string. Anyone that is concerned about such >> things has already worked around any problems involved in using UTF-8 >> with std::string. This mostly involved parsing and locating character >> seperations which is of little concern to CppUnit. > >Just a question on the side, does that means that if you split a string into >many lines using the '\n' character, you can use the same algorithm in ANSI >and UTF8 ? (=> even two or three bytes characters encoding don't use '\n') I hope I understand the question. If I output a string that includes a '\n' in a stream, and some other process is parsing that stream, will '\n' be unique? The answer is yes! I was equally stunned to here this. Once a shift character is seen that identifies that following characters as unicode, then none of the bytes that are part of that unicode "character" will be less than 128! This is what makes UTF-8 work. All characters <128 are always ASCII! >> Another reason to do nothing is that I would hope that the C++ standards >> committee at least makes some statement about Unicode or >> internationalization. They have done lots of work to put in >> infrastructure that very few people really understand. I believe that >> they need to make some statement or show some examples of how to truly >> deal with Unicode. >> >> My recommendation is to do nothing. >> >> Is there some other driving factor behind this decision? > >My original though was that it makes it easier for outputter: AFAIK you can >not set a code page saying that you're working in UTF8 (let me know if it is >possible). I'm not sure where you want to specify a code page and I'm not always clear as to what a code page means in some contexts. I think (and this is very old memory) that the encoding of an XML file can be UTF-8. Beyond that, I dont know. >Since you have API such as fwprintf, cwerr... it wouldn't be a problem to >display the output in Unicode. So I did some testing: trying to display a >few hiragana in VC++ output window. I try two differents way: >- running the test application in post-build test, and printing with >fwprintf >- from a VC++ add-ins, using IApplication::PrintToOutputWindow, which take a >unicode string as argument. > >Same result for both, a few '?' characters, meaning that a conversion >occured from unicode to multi-byte charater, and failed to find a match for >the unicode character (the font used for the output window support those >unicode characters). > >Basically, that means using unicode doesn't make anything easier: even if >you have unicode, you need to write special application to display the >result. The same applies to UTF8, but... > >For UTF8, we already have the XmlOuputter (thanks to Fumiki suggestions, we >can now specify the encoding). > >So I agree, let's not change CppUnit. It already support UTF8 and that's >enough. If anything need to be changed, it would be the GUI TestRunner to >support UTF8 and font selection. ...Duane -- "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison |
|
From: Baptiste L. <gai...@fr...> - 2002-04-15 23:31:17
|
TestPlugInRunner, the GUI, as not been updated yet (it rely on the old test plug-in system). I waiting some answers from somebody who promised some updates ;-) (make the merging much easier). In the meantime, you can use DllTestPlugInRunner, which can be used as a post-build step. Baptiste. ----- Original Message ----- From: "Philippe Lavoie" <phi...@ca...> To: <cpp...@li...> Sent: Tuesday, April 16, 2002 12:17 AM Subject: [Cppunit-devel] [bug?] EasyTestPlugin can't be loaded from TestPluginRunner Hi, I'm using Visual Studio .NET and the EasyTestPlugin example project can't be loaded by using the TestPluginRunner. It states that it fails to load function GetTestPlugInInterface() in the easytestplugin dll. TestPlugin can be loaded without problems though. Phil PS I'm really impressed by the changes from 1.6.2 to 1.9.2, keep it up! _______________________________________________ Cppunit-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppunit-devel |
|
From: Baptiste L. <gai...@fr...> - 2002-04-15 23:27:03
|
A clean way to do this would be to redirect cout TestListener::startTest(),
and capture what was outputted by the test in TestListener::endTest(). The
capture could be associated to the test and use at a latter time.
Does anyone know if it is possible to redirect to an strstream (I guess not,
but it would be nice) ?
But are you sure you need log ? Wouldn't more advanced, specialized, or
verbose assertions do the job ?
If you need a log, it usually means that you need to back in time. If that
is the case, it is likely that your unit tests are too complex (likely more
akin to functional test).
Baptiste.
----- Original Message -----
From: "John Carter" <joh...@ta...>
To: <Cpp...@li...>
Sent: Monday, January 21, 2002 11:36 PM
Subject: [Cppunit-devel] Logging.
> While I'm on the subject, I feel that there should be a logging class.
>
> I often 'cout << ' things as I go a long, which mucks up the pretty ...'s
>
> Yes, I know UnitTest's are automagic things that happen in the dark of the
> night and know one should ever need to look at the logs.
>
> But when the nifty automagic unit test fails, one can often immediately
> see why if there was a nifty log file somewhere, and hence debug the
> problem faster.
>
> There should be a nifty way of recording things as the test goes along....
>
> Something like....
>
> DEBUG( "My pretty log message " << myObject.ToString());
>
> which results in...
>
> Some meaningful and informative header giving run date, build date,
> and hopefully useful CVS $Tag$ info.
> filename.c:120:[MyClass::MyFunction] My pretty log message Pretty Object
>
> Where DEBUG is a mix of preprocessor and a invocation of a logging
> utility....
>
> #define DEBUG(msg) do {\
>
CppUnit::Log::Instance()->PrintHeader(__FILE__,__LINE__,__PRETTY_FUNCTION__)
\
> << msg << endl; \
> } while(0)
>
> I'm planning on doing something like that, I have most of the code lying
> around anyway. What would be the best way of doing it in a manner most
> likely to gain your acceptance?
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : joh...@ta...
> New Zealand
>
> Zeitgeist shutting down for corrective maintenance, please log off.
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>
|
|
From: Baptiste L. <gai...@fr...> - 2002-04-15 23:27:02
|
Are others interested in the __PRETTY_FUNCTION__ support ? I was digging in the ML archive when I found that very old mail (that apparently went unanswered :-( ). Suggested implementation: extending SourceLine (that's a 10mn change since everything is centralized there. What a foresight ;-) ). The big bad thing that will take time is detecting gcc and adding the necessary autoconf/configure thingy. Well, and may be figuring out how to extend the Outputters... ;-) > What is the favoured manner of receiving such changes? Sending me a zip of the modified files, based on the lastest release or CVS... Baptiste. ----- Original Message ----- From: "John Carter" <joh...@ta...> To: <Cpp...@li...> Sent: Monday, January 21, 2002 11:01 PM Subject: [Cppunit-devel] GCC'ism > I'm using CppUnit-1.6.2 under the GNU gcc compiler and I would like to > inject one or two slight gcc'isms into it. > > In CPPUNIT_ASSERT macros I would like to use the __PRETTY_FUNCTION__ > keyword, this allows one to immediately see which function had the > assert failure, and more importantantly which instantiation of a > template test function had the failure. (Very useful if you are using > templates and CppUnit to enforce Bug Compatibility between two > implementations...) > > In the TextTestResult I would like to reformat the error messages to look > (at least to emacs) like gcc compiler error messages. This would enable an > Emacs user to put the cursor over the offended assert failure, hit enter > and Emacs would bring up that file at that source line. > > What is the favoured manner of making such environment specific changes to > CppUnit? Preprocessor conditionals? > > #if __GNUC__ > Do this > #else > Do that > #endif > > Autoconf enable/disable feature? > configure --enable-pretty-function --enable-emacs-support > > What is the favoured manner of receiving such changes? > --As a request, you will do it. > --No yuck, don't want that feature, only C++ pure as the driven snowy standard please! > --As a patch on 1.6.2. > --As a patch on latest CVS version. > --Here is access to the CVS tree, do it yourself. > > Thanks, > > John Carter Phone : (64)(3) 358 6639 > Tait Electronics Fax : (64)(3) 359 4632 > PO Box 1645 Christchurch Email : joh...@ta... > New Zealand > > Zeitgeist shutting down for corrective maintenance, please log off. > > > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel > |
|
From: Baptiste L. <gai...@fr...> - 2002-04-15 23:26:59
|
So If I understood thing well, the only hope that remains would compiler specific. VC++ has such a thing, have you found anything like that on gcc ? (I guess not, but...) In the meantime, I think I'll add a VerboseTestProgressListener: startTest(): print test name failure(): print ':' and 'E' or 'F' endTest(): new line Baptiste. ----- Original Message ----- From: "Robert Wenner" <ro...@po...> To: "Baptiste Lepilleur" <gai...@fr...>; <cpp...@li...> Sent: Monday, April 15, 2002 8:33 AM Subject: Re: [Cppunit-devel] Signal handling in Linux > On Saturday 13 April 2002 11:28, Baptiste Lepilleur wrote: > > Is it possible to wrap the signal logic into a class (even if it use > > global variable) ? I'm planning to add a feature to add 'custom' > > exception support (export not based on std::exception) to CppUnit. > > As far as I found something on the web on the topic of signal handling > and C++: don't do it. > Std C++ sticks to the old C behaviour of signal handling. > That means use of C++ features will result in undefined behaviour; > especially use of RTTI, member variables and exceptions. > IMHO the best way to solve the signal problems is to set a global > variable in the signal handler and return. The calling program (in > case of CppUnit) the framework has to check that variable. > Having the signal wrapper class use a list of received signals would > also be possible to throw multiple exceptions (if desired). > Ignoring some signals (such as SIG_SEGV) is considered dangerous > as the program may be left in an undefined state (e.g. what is the > result from a divide by zero?). This may be no problem with some > short test cases, though. > > > To do that, I just call a must on a class with the Test to run and > > the TestResult which 'protect ' the test run. In your case, that > > would means trapping the signal, and throwing adding a failure to > > TestResult. > I tried a little with setting the signal handler in setUp and checking > the global variable in tearDown, but signals behaved really strange > on my machine (examples for a SEGV by wrong pointer access). > - Ignoring (SIG_IGN setting ) the signal (or using no handler) crashes > the program (the default behaviour for unhandled signals) > - Catching the signal causes the handler to execute and after that > crash the program > - Catching the signal and re-installing the signal handler (it is > uninstalled by default according to the man page) or not using the > ONESHOT option in sa_flags results in endless signals received -> > program hangs. > > > I'm really interessed into this, because VC++ does this automatically > > for us in debug mode. This is not the case on Unix, and as such does > > not provide a consistent behavior across plateform. As a consequence, > > on Unix, you would need a TestListener that print the test name > > before running the test, just to now which test failed... > IMHO the C++ std is somewhat lazy / minimalistic here. :-( > By time C++ should drop these old C garbage. > Anyway I would be really interestedin a soultion, too. > > Robert > |
|
From: Baptiste L. <gai...@fr...> - 2002-04-15 23:26:59
|
----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "CppUnit Developers" <cpp...@li...> Sent: Sunday, April 14, 2002 7:35 PM Subject: Re: [Cppunit-devel] Toward True Unicode Code... Help requested > My two cents for what its worth is to do nothing. > > There is no "True" Unicode. There are several unicode formats. UTF-8, > UTF-16, and the upcoming UTF-32 among others. I have been told by some > associates that keep up with such things that UTF-16, while currently > being used, is on its way out in favor of UTF-32. It is most often > recommended to use the simple UTF-8 for most applications. > > UTF-8 will likely satisfy most of us and require absolutlely no changes. > UTF-8 is completely compatible with ASCII (for characters < 128). UTF-8 > fits nicely in a standard string. Anyone that is concerned about such > things has already worked around any problems involved in using UTF-8 > with std::string. This mostly involved parsing and locating character > seperations which is of little concern to CppUnit. Just a question on the side, does that means that if you split a string into many lines using the '\n' character, you can use the same algorithm in ANSI and UTF8 ? (=> even two or three bytes characters encoding don't use '\n') > > Another reason to do nothing is that I would hope that the C++ standards > committee at least makes some statement about Unicode or > internationalization. They have done lots of work to put in > infrastructure that very few people really understand. I believe that > they need to make some statement or show some examples of how to truly > deal with Unicode. > > My recommendation is to do nothing. > > Is there some other driving factor behind this decision? My original though was that it makes it easier for outputter: AFAIK you can not set a code page saying that you're working in UTF8 (let me know if it is possible). Since you have API such as fwprintf, cwerr... it wouldn't be a problem to display the output in Unicode. So I did some testing: trying to display a few hiragana in VC++ output window. I try two differents way: - running the test application in post-build test, and printing with fwprintf - from a VC++ add-ins, using IApplication::PrintToOutputWindow, which take a unicode string as argument. Same result for both, a few '?' characters, meaning that a conversion occured from unicode to multi-byte charater, and failed to find a match for the unicode character (the font used for the output window support those unicode characters). Basically, that means using unicode doesn't make anything easier: even if you have unicode, you need to write special application to display the result. The same applies to UTF8, but... For UTF8, we already have the XmlOuputter (thanks to Fumiki suggestions, we can now specify the encoding). So I agree, let's not change CppUnit. It already support UTF8 and that's enough. If anything need to be changed, it would be the GUI TestRunner to support UTF8 and font selection. Thanks for you feedback Duane, Baptiste. |
|
From: Philippe L. <phi...@ca...> - 2002-04-15 22:21:47
|
Hi, I'd like to add cppunit to the tools/external tools menu. I did Program: TestPluginRunner.exe Arguments: $(TargetPath) InitialDir: $(TargetDir) where $(TargetPath) is the full qualifed name of the output dll. What I was expecting was to have my dll preloaded with the root test = node selected. Can somebody tell me if what I'm doing is feasible ? Thanks Phil |
|
From: Philippe L. <phi...@ca...> - 2002-04-15 22:17:59
|
Hi, I'm using Visual Studio .NET and the EasyTestPlugin example project = can't be loaded by using the TestPluginRunner. It states that it fails to load function GetTestPlugInInterface() in the = easytestplugin dll. TestPlugin can be loaded without problems though. Phil PS I'm really impressed by the changes from 1.6.2 to 1.9.2, keep it up! |
180 messages has been excluded from this view by a project administrator.
