cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why System Includes?

[Steve M. R. <ste...@vi...>]

On Thu, Sep 27, 2001 at 07:43:57AM -0700, no...@so... wrote:
> 
> Read and respond to this message at: 
> http://sourceforge.net/forum/message.php?msg_id=238875
> By: blep
> 
> For the cpp file it is ok. #include <filename> states that include path indicate
> with /I option are search first, then those of the environment variable.

Careful -- you're getting into system-dependent behaviour here!
I've never met a C compiler that used an environment variable to change
the header include path!

 
> For the header in the /include directory, it might be a problem because that
> include directory may not be the one in the include paths.

Then put that directory on the include path.


> For example, in cppunit/extensions/HelperMacros.h, you have:
> 
> 
> 
> #include <cppunit/Portability.h>
> #include <cppunit/extensions/AutoRegisterSuite.h>
> #include <cppunit/extensions/TestSuiteBuilder.h>
> 
> 
> 
> I you replace with the quoted filename:
> 
> #include "../Portability.h"
> #include "AutoRegisterSuite.h"
> #include "TestSuiteBuilder.h"
> 
> 
> For AutoRegisterSuite.h and TestSuiteBuilder.h, it's ok, and actually what should
> be done. But I frown upon having "../" in an include filename.

Noooooo!

All the headers in include/cppunit *must* include the other headers
using <cppunit/...> notation.  Do not even think about changing this!
These headers *do* get installed into the "system" location on a unix
build.

-S

--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] FAQ / 1.8 branch

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> On Tue, Sep 25, 2001 at 05:54:02PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
> >   Yes, linking to the doc would be interesting. Can Doxygen generate a
> TOC ?
> 
> Mmmm.  If it does, I don't know how to do that.
> You can, however, make "groups" of bits of documentation, and
> you automatically get a "group" page.  That might be good enough.
> 
> But, anyway, we have only three questions at this point.  Let's just
> do _something_ now and figure out the niceties if it gets to be a
> burden.
> 
>  
> > > >   How do we go reporting fix into the 1.8.0 branch ?
> > > 
> > > Well, since there is no branch done yet, everything on the "main"
> > > trunk will appear in both the 1.6.1 and 1.8.0 release.  So please
> > > do commit bugfixes onto the CVS tree.
> > > 
> > > Once a branch is made, then the procedure is: checkout the 1.6
> branch,
> > > make the change, commit it.  Then check out the main branch and
> merge
> > > in the change just made on the 1.6 branch.  This is a mildly more
> > > difficult procedure, so I am delaying making a 1.6 branch in order
> > > that we can continue to use the simpler procedure.  
> > > 
> > > We can delay a 1.6 branch until we need to make 1.8-only changes
> to
> > > CVS.  I thought we'd give it a week or so, until the bugfixes die
> > > down.  What do you think?
> > 
> >   Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would 
> > like to 
> > add (I would target 1.8.0 for the end of next week. Expected exception
> and 
> > named suite registration only would be worth it).
> 
> Well, so far, we aren't exactly inundated with bug reports.  So making
> the change at the end of next week is probably fine.
> 
> At any rate, ONCE the branch is made, the idea is to merge 1.6.x
> bugfix changes to the main trunk (if applicable) as you do them.
> Any delay of the merge just makes it more complicated.

  Well, I was thinking about a slighlty tighter time schedule :-)
  - have the branch made this week-end, and 
  - release 1.8.0 by the end of next week-end...

  Given that scope, the following feature would be possible:
    1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
    2) CPPUNIT_TEST_FAIL( method )
    3) add a flag to TestFailure distinguishing error/failure, retain only
one collection to store result
(see other mail)
    4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName ) :
register the fixture's suite in a suite of the specified name.
    
  Given the low rate of feedback on the other topics, I can't see them being 
done "quickly". So I'd rather have a quick release with those features which 
are simple but very useful.

   I'm also thinking of adding:

   CPPUNIT_FAIL( message ) as a shortcut for
CPPUNIT_ASSERT_MESSAGE( message, false ), which is often use to indicate 
unexpected path (exception...)

> 
> -Steve
> 
> P.S. I guess the lack of bug reports is good, unless it means that
> nobody is using CppUnit.  We are getting a bunch of traffic though:
> check out the "stats" page if you haven't already done so.

  Indeed, it's been quite a climb...

  By the way, has xprogramming.org been contacted, the page haven't been 
updated ?

  Baptiste.

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

[Cppunit-devel] FAQ / 1.8 branch

[Steve M. R. <ste...@vi...>]

On Tue, Sep 25, 2001 at 05:54:02PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:

 
> > From my point of view, I prefer text.  If we find ourselves wanting
> > fancy things, like links, then we can move to straight HTML, or to
> > something that can be processed into HTML.  We could use Doxygen,
> > for example, as done in doc/other_documentation.dox.  Doxygen has
> > an easy way to make lists, I believe.  And it would be *very* easy
> > to hyperlink both to and from the CppUnit class documentation, so
> > that might be the best option.
> 
>   Yes, linking to the doc would be interesting. Can Doxygen generate a TOC ?

Mmmm.  If it does, I don't know how to do that.
You can, however, make "groups" of bits of documentation, and
you automatically get a "group" page.  That might be good enough.

But, anyway, we have only three questions at this point.  Let's just
do _something_ now and figure out the niceties if it gets to be a
burden.

 
> > >   How do we go reporting fix into the 1.8.0 branch ?
> > 
> > Well, since there is no branch done yet, everything on the "main"
> > trunk will appear in both the 1.6.1 and 1.8.0 release.  So please
> > do commit bugfixes onto the CVS tree.
> > 
> > Once a branch is made, then the procedure is: checkout the 1.6 branch,
> > make the change, commit it.  Then check out the main branch and merge
> > in the change just made on the 1.6 branch.  This is a mildly more
> > difficult procedure, so I am delaying making a 1.6 branch in order
> > that we can continue to use the simpler procedure.  
> > 
> > We can delay a 1.6 branch until we need to make 1.8-only changes to
> > CVS.  I thought we'd give it a week or so, until the bugfixes die
> > down.  What do you think?
> 
>   Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would like to 
> add (I would target 1.8.0 for the end of next week. Expected exception and 
> named suite registration only would be worth it).

Well, so far, we aren't exactly inundated with bug reports.  So making
the change at the end of next week is probably fine.

At any rate, ONCE the branch is made, the idea is to merge 1.6.x
bugfix changes to the main trunk (if applicable) as you do them.
Any delay of the merge just makes it more complicated.

-Steve

P.S. I guess the lack of bug reports is good, unless it means that
nobody is using CppUnit.  We are getting a bunch of traffic though:
check out the "stats" page if you haven't already done so.


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

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

Quoting Michael Arnoldus <ch...@mu...>:

> I think I am confused. I think I like the idea of considering this
> unicode
> stuff from the beginning.
> 
> So, why do we want unicode support in CppUnit? The reason I made the port to
> unicode in the first place, was that I was working on project on Windows
> NT,
> which used unicode. Since unicode on windows platforms requires
> different
> runtime libraries, I had to do the port, because linking with both the
> unicode and non-unicode libraries gives problems (it uses two
> different heaps, so new and delete gets all screwed up).

  So what you really want is a version of cppunit.lib and testrunner.lib that 
are compiled against the unicode version of the CRT. Not version of CppUnit 
that USE unicode.

  While linked to the unicode library, CppUnit could stick to std::string. The 
only change would be in MFC TestRunner that would need to convert 
Exception::what() to the right type (but that can be handled automatically by 
the MFC CString if I remember well).

> The way they have thought about the problem at Microsoft is: Unicode is the
> future. So NT is written using unicode - but, there are lots of non-unicode
> programs out there and there probably will be more, so we give the NT API a
> set of non-unicode functions to support those programs. Most of the
> non-unicode functions are simple wrappers which convert relevent string
> parameters to unicode and then call the unicode function.
> 
> Sun seems to think along the same lines since in Java (where the testing
> unit is originally from) you can only choose between unicode and unicode.
> 
> So - the way I think about character strings in programs is that either I am
> using Unicode or I am not! Please note that I might want to use a byte
> container in unicode programs, which is why the STL implementation with both
> a std::string and a std::wstring is fine.
> 
> I think maybe we need to agree (or disagree :-) about general principles
> before going deeper ind the code, which is why I haven't commented on
> your code-specific suggestions.
> 
> So - to make it clear. I don't like the idea of having "conceptually" the
> same string in two different representations at the same time. I don't like
> interfaces which gives room to unicode and non-unicode at the same time. I
> think the model we should use in CppUnit is "either we unittest unicode
> functions or we unittest non-unicode functions".
> 
> I know nothing about Qt - maybe they have a another (better ?) model for
> using unicode?

  The generic string class is only Unicode. But you have other classes to deal 
with legacy char *. That class can construct from const char *, and convert to 
char *. Encoder are provided to read many MBCS text encoding.

> For me it is ok that I can use only Latin1 strings in ASERT_XXX, if porting
> gets a lot easier, but if we adopt the above model, it would seem a bit
> strange to unicode users of CppUnit that they are not able to use unicode
> everywhere.
> 
> >     What bother me, is that it have a global impact on CppUnit, and having
> > string that change that way is a source of headache. What the user of
> > CppUnit should do ? Use CppUnit::String or CString, or Tools::String
> > (typedef to std::string or std::wstring like in CppUnit)....
> 
> In Windows there is no problem. CString uses unicode or not, dependent on
> the same preproc define that chooses which API (and library) to use. If you
> are writing a unicode program using STL, then you are using std::wstring
> already. But yes, the Tools::String or CppUnit::String definition might be a
> great idea as well.
> 
> Lets face it. The people using java do not have a problem, they are locked
> to unicode. When using C++ we have the advantage of being able to choose,
> which also adds the problem that we have to choose! I don't think CppUnit
> can (or should) hide the complexity inherent in this choice. I do think its
> fair though that the current users of CppUnit shouldn't be bothered about
> unicode problems. So the solution we make should make it possible to
> continue to use CppUnit in non-unicode programs without any changes (a
> property I think my solution fullfilled - no?).

  I don't agree that our application should be full Unicode. I agree that it 
makes a lot of sense to make your GUI using Unicode (makes i18n a lot easier). 
On the other hand, there are a lot of place where Unicode is not in use. For 
example, our application at work communicates with others applications by 
exchanging EDIFACT files. Those file are ANSI. The modules that create and read 
those file use ANSI string.

  While the future might be Unicode, the future is not yet there. Worth, we are 
in a transition phase were we often have to deal with both unicode, and ansi. A 
lot of tools that exists only know how to deal with ansi files, they don't have 
the first clue about unicode.

  The whole stuff with change a define and all your string change of type 
strike me as wrong. It may be suitable for a library such as MFC where it is 
preferable to use consistenly the same string type across the library. This is 
not the situation we are in our everyday application. We have to deal with and 
use many legacy or third-parties libraries which are still using ansi string. 
We need to be able to manipulate ansi string and unicode string at the same 
time.

  From a library point of view (which CppUnit is), the change your string with 
a define is the easy way out, but not the best way. I see no reason why we 
couldn't have both at the same time (of course we would still have to provide 
version linked against both unicode and ansi CRT library).

  The challenge here, is to find a way to do that. I started paving the road, 
but there still a long way to go (may be not that long ;-) ).

PS: I was not suggesting that Exception store both std::string and 
std::wstring. Exception would likely store std::wstring, but provide both in 
its interface.

  Baptiste.

> 
> Pfhhh - your turn :-)
> 
> Enjoy.
> 
>     Michael Arnoldus.



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

Re: [Cppunit-devel] returning const reference (was: CppUnit 1.8.0 features...)

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

Quoting Noel Llopis <ll...@ho...>:

> First time contributing to the list, but here it goes...

  Well, look like you hit "reply" instead of "reply all" (happen to me sometime 
too)...

  Your welcome to contribute to the list. While I found some bit of interest 
discussing the current topic, I would be more interested on having feedback on 
CppUnit design (Exception, TestFailure & co...) ;-)

> 
> > I personally disagree with lots of these comments, as do lots of
> other
> > people, whose comments you can see if you follow some of the links
> > from these Wiki pages (see UseConstMemberFunctions and
> ConstCorrectness).
> 
> Absolutely. I think doing that would be a big step backward

  I don't know if you read all the thread. CppUnit won't change in those 
aspect. I was just stating that CppUnit should not enforce users to respect the 
constness policy with their objects.

[...]
> I don't buy the idea that const gets in the way of refactoring.
> That's right up there with saying that most functions should be
> public or virtual.
> 
> const, if anything, helps refactoring by reminding you of the
> itention of the code. Isn't XP so big on self documenting code?
> What better example than the compiler yelling at you because
> you tried to modify something when somebody explicitely
> decided that it shouldn't? If you're going to change something
> as fundamental as that, you might as well remove a couple of
> const statements.

  That's because you use const to define an "immutable" interface to your 
objects. I prefer to stick to pass by value, or other interface that don't 
provide "write" access...

  And you exactly stated why it may be hard to change: "somebody explicitely 
say that it shouldn't". Yeah, but now I need to. Accessing mutable method is my 
change. How hard can that be ? Find all the callers, change the 
reference/pointer type. Might also have to search their callers, and so on...

  Of course, that time "lost" making that change have to be compared to the 
time that the compiler would save for you. I find myself doing quite well 
without that belt... And not having to think about "should I pass/use a const 
pointer or a mutable pointer" make think easier. 

> >   My guess is that it depends on the way your style of code. All I
> > know is that I have applyied those rules (my version) in my
> > development for the last 3 months (including a new project at work),
> > and found it to work pretty well.
> 
> Of course, it's all a personal preference. Some people also
> like to limit themselves to the C subset when they're using C++.
> I found that correctly using const (for references and member functions)
> has been extremely useful for me at work and in my own code.

  Yup. It has to do with convention. I found those I defined to be working 
quite well for me. They still need some rafinment, and will evolve as everyhing 
does.

[...]
> > > >> 2) prefer pass-by-value to const reference
> > > >>    => don't need to had "const" method to object.
> 
> Why would you ever want to do that? Const references have
> to be the cleanest, most efficient way of passing parameters.
> Why would you want to copy the whole object, so you
> can modify it inside the function? If so you can always make
> a local copy (although I suspect that it could be done in
> a different, much more clear and efficient way).

  With my conventions, references are pointers and allow polymorphism. My 
conventions are that pointers are used for reference objects, and pass by value 
is used for value objects. Const references may be added in optimization phase 
when need to pass value object.

  Since most of the object I have are not value object, I mostly use pointers 
around (by the way, I forgot another of my rule: public methods should never 
return NULL pointer (the null flag bug pattern)).

> > > >> 3) avoid to return const reference, prefer return by value
> > > >>    => the former make it difficult to change the implementation
> > > 
> > > Not sure I agree with that.  I think it probably varies by class.
> >   My experience is that if you have:
> >   const std::vector<Test*> &getTests()   
> > 
> >   You can not change your implementation to something else ( 
> > std::map<string,Test*> for example) without impacting client. But if
> you had:
> >   std::vector<Test*> getTests(),
> >   then it could easily be done.
> 
> I don't see how that makes it any easier to update. It seems
> that in both cases you need to update the type of the variable that
> will receive the return value.

  No. If you return a vector by value, and you store the data in a map, then 
you can create a temporary vector that you return:

sdt::vector<Test*> getTests()
{
  std::vector<Test*> tests;
  for ( iterates the map )
    tests.push_back(...)
  return tests;
}

> I usually follow the rule to return a const reference when possible,
> and a value otherwise. The nice thing abou this is that you can
> switch between the two without having to update the client code
> at all.
> 
> So const MyClass & a = something.GetA();
> will work both when a is returned by value or const reference.

  Beware of the "you can switch between the two at will". While the reference 
on a temporary is suposed to remain valid as long as the reference exist, you 
can run in some troubles. For example, return by value returns a mutable object 
( myObject.setName( file.readLine().stripSpaces(), which is not possible with 
const reference ).

  Here is an example of unwanted behavior: (note that while it can be spoted 
easily there, the actual "obj.set" can occur after a long serie of method calls 
that would finaly call back on obj)

---
#include <iostream>
#include <vector>


class Object
{
public:
//  std::vector<int> get()  // for the correct version
  const std::vector<int> &get() { return _values;}

  void set( const std::vector<int> &values ) { _values = values; }
private:
  std::vector<int> _values;
};


void main()
{
  Object obj;
  
  const std::vector<int> &values = obj.get();

  std::vector<int> otherValues( values );
  otherValues.push_back( 3 );
  // change the value in obj, with const ref&, indirectly change values!
  obj.set( otherValues );   

  Object obj2;
  obj2.set( values );

  std::cout << "obj.get() : "  << obj.get().size()  << std::endl
            << "obj2.get() : "  << obj2.get().size()  <<  std::endl;
}
--
and you get:
obj.get() : 1
obj2.get() : 1

instead of:
obj.get() : 1
obj2.get() : 0

---

Also, another source of trouble would be:

const std::vector<int> &values = obj->get();
delete obj;

Amazingly, values is still a valid reference. As before, the delete can occurs 
far away (A less likely case, I concede).

So my take is that pass-by-value provide stronger isolation, and therefore make 
refactoring somewhat easier.

Baptiste. 

> --Noel
> ll...@ho...
> 
> 

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

Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

[Michael A. <ch...@mu...>]

I think I am confused. I think I like the idea of considering this unicode
stuff from the beginning.

So, why do we want unicode support in CppUnit? The reason I made the port to
unicode in the first place, was that I was working on project on Windows NT,
which used unicode. Since unicode on windows platforms requires different
runtime libraries, I had to do the port, because linking with both the
unicode and non-unicode libraries gives problems (it uses two different
heaps, so new and delete gets all screwed up).

The way they have thought about the problem at Microsoft is: Unicode is the
future. So NT is written using unicode - but, there are lots of non-unicode
programs out there and there probably will be more, so we give the NT API a
set of non-unicode functions to support those programs. Most of the
non-unicode functions are simple wrappers which convert relevent string
parameters to unicode and then call the unicode function.

Sun seems to think along the same lines since in Java (where the testing
unit is originally from) you can only choose between unicode and unicode.

So - the way I think about character strings in programs is that either I am
using Unicode or I am not! Please note that I might want to use a byte
container in unicode programs, which is why the STL implementation with both
a std::string and a std::wstring is fine.

I think maybe we need to agree (or disagree :-) about general principles
before going deeper ind the code, which is why I haven't commented on your
code-specific suggestions.

So - to make it clear. I don't like the idea of having "conceptually" the
same string in two different representations at the same time. I don't like
interfaces which gives room to unicode and non-unicode at the same time. I
think the model we should use in CppUnit is "either we unittest unicode
functions or we unittest non-unicode functions".

I know nothing about Qt - maybe they have a another (better ?) model for
using unicode?

For me it is ok that I can use only Latin1 strings in ASERT_XXX, if porting
gets a lot easier, but if we adopt the above model, it would seem a bit
strange to unicode users of CppUnit that they are not able to use unicode
everywhere.

>     What bother me, is that it have a global impact on CppUnit, and having
> string that change that way is a source of headache. What the user of
> CppUnit should do ? Use CppUnit::String or CString, or Tools::String
> (typedef to std::string or std::wstring like in CppUnit)....

In Windows there is no problem. CString uses unicode or not, dependent on
the same preproc define that chooses which API (and library) to use. If you
are writing a unicode program using STL, then you are using std::wstring
already. But yes, the Tools::String or CppUnit::String definition might be a
great idea as well.

Lets face it. The people using java do not have a problem, they are locked
to unicode. When using C++ we have the advantage of being able to choose,
which also adds the problem that we have to choose! I don't think CppUnit
can (or should) hide the complexity inherent in this choice. I do think its
fair though that the current users of CppUnit shouldn't be bothered about
unicode problems. So the solution we make should make it possible to
continue to use CppUnit in non-unicode programs without any changes (a
property I think my solution fullfilled - no?).

Pfhhh - your turn :-)

Enjoy.

    Michael Arnoldus.

Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

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

----- Original Message -----
From: "Michael Arnoldus" <ch...@mu...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Monday, September 24, 2001 3:00 PM
Subject: Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)


>Let me see if I understand you correctly. When not changing anything in
CppUnit, you are degrading the strings in CppUnit to be simple containers
which contains "something the TestRunner know what to do with" - and
currently it just happens to be ASCII strings.

Actually, I was rather suggesting MBCS only as a work around having only
std::string (which should be able to contain MBCS string, right?). My point
was rather that unless you are doing application which essence is to
manipulate Unicode object (dictionnary, translator,...), you can probably
get away with restricting your Unicode string to latin1 for ASSERT_EQUAL and
ASSERT_MESSAGE.

>This might work, but I think it should be reflected in the design then -
f.ex. by letting the TestRunner pass the strings as a pointer to a subclass
of a specific class (or maybe a template parameter class).

Yes, but let's not consider it for now. That solution strike me as wrong
(who know what they would put in a string ;-) ).

>I personnaly do not like a design where a string is something we use to
stuff  something else into and then decode it again - this way doom lies!

Don't know much about MBCS, just that is a way to encode character set
depending on your page (meaning you need to know your page to decode).

>You are right __FILE__ are not unicode.

>Can you use unicode strings in the assert macros the way you have done it?

No. I convert the Unicode string to latin1 in my implementation of
toString(), which is not really a loss since there are just object dump and
I control their content.

>Yes, unicode use a different runtime library.

Managing all those configuration will become a source of headache:
2 DLL config.
2 static config (not yet, but requested)
*2 for unicode
*2 : cppunit and testrunner
=> if cppunit remains the same for unicode and ansi string, there twice
less...

>A while ago you asked me about Unicode programming on unix. I have found an
article about unicode on linux:
http://www-106.ibm.com/developerworks/linux/library/l-linuni.html

I'll try to give it a look. I'm using Qt (http://www.trolltech.com) for now
which implements its one Unicode support (lots better than MFC if I might
say).

>I now the first Unicode port for windows I did, was not a very good job.
I'll be willing to it right, but I need somebody who understands CppUnit to
talk to about the design.

    Nor was it a bad job. The solution could be acceptable (the definition
of the generic string/stream would need to be centralized, but that's it).

    What bother me, is that it have a global impact on CppUnit, and having
string that change that way is a source of headache. What the user of
CppUnit should do ? Use CppUnit::String or CString, or Tools::String
(typedef to std::string or std::wstring like in CppUnit)....

    Note from that point, I'm just throwing ideas around, hoping to discover
some interesting stuffs...

    I think it should be possible to design something a lots cleaner. Let's
put the fact down:

    1) User define strings that may be Unicode are:
    - result of assertion_traits::toString(), used by ASSERT_EQUAL
    - parameter of ASSERT_MESSAGE

    2) Those strings are just a way to convey additional information with
the test failure.

    Let's ignore the current implementation of ASSERTxxx for now. Let's
imagine that we have:

ASSERT_UNICODE_MESSAGE( unicodeMessage, condition );

    How to we get the unicode string to the TestRunner. The obvious answer
is using Exception, the class used to report the failure detail to the
TestRunner. Once we got that part down, then the remaining elements could be
tackle down.

    So my take would be that the first step toward adding unicode support to
CppUnit would be to add Unicode support to Exception. I believe Exception
should still provide a std::string interface to the failure message (all
TestRunner are not written to support unicode), but should also provide a
std::wstring interface.

    We would have:

    std::string what() const;
    std::wstring unicodeWhat() const

    Constructor would need to be changed to accept std::string or
std::wstring for the message. That would also impact Exception subclass:
NotEqualException take two strings at construction, so two constructors
should also be provided.
(PS:  can we do std::wstring( L"\u306b\u307b" ) ? how to you go inputing
hardcoded unicode string?)

    My guess would be that Exception would store everything as std::wstring
(the wider format). We should also have utility function to from and to
unicode (unicode to ansi could be a dummy convertion: if character code is
not in range 0-255 then replace with '?').

    For user, everything is transparent. TestRunners could use either the
ansi or the unicode version to retrieve information.

    And while I'm at it, I can think of a way to deal with ansi/const char
*conversion:

template<typename StringType>
struct convert_to_wstring
{
  std::wstring toWString( StringType str )
  {
    return str;
  }
};

template<typename StringType>
std::wstring convertToWString( StringType str )
{
    return convert_to_wstring<StringType>( str );
}

And you specialize for const char*, std::string, and possibility other user
define string... That template function could be use anywhere to uniformize
string to wstring (for exemple implementation of assertion_traits that
returns a std::string instead of std::wstring).

The only dark point would be:

      static std::string toString( const T& x )
      {
          OStringStream ost;
          ost << x;
          return ost.str();
      }

    That use an ansi stream. What would be the impact of changing that to a
wide stream ?

    What do you think ?

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

Re: [Cppunit-devel] 1.6.0 is released!

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> Salut, B-L,
  Tisba for short ;-). Learning French ?


> On Tue, Sep 25, 2001 at 12:32:21PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
> > 
> > [...]
> > > >     HTML format or text, or ... ?
> > > 
> > > Your choice.  HTML has the advantage of hyperlinks, should one so
> > > desire.  I find text quite a bit easier to edit, however, so HTML
> may
> > > put me off editing the FAQ...
> >   So let's start with text. Would XML (with XSL to generate the html)
> be 
> > suitable for you ?
> 
> I wouldn't know what to do with XML, either :-/  
> 
> I usually stay a little back of the "new technology" curve --- that
> way I can avoid travelling down all the dead-ends ;-)

  Well, with the appropriate XSL script (to generate the HTML), we could get 
automatically have a TOC generated from each question. That's what I don't like 
with HTML is that you have to manually maintain the TOC...
  Basicaly, the XML would be a subset of HTML and would be processed into HTML 
(that's heavy tools, but I think it would be quite interesting to do).

> From my point of view, I prefer text.  If we find ourselves wanting
> fancy things, like links, then we can move to straight HTML, or to
> something that can be processed into HTML.  We could use Doxygen,
> for example, as done in doc/other_documentation.dox.  Doxygen has
> an easy way to make lists, I believe.  And it would be *very* easy
> to hyperlink both to and from the CppUnit class documentation, so
> that might be the best option.

  Yes, linking to the doc would be interesting. Can Doxygen generate a TOC ?

[...]
> If you build *in* the source tree, then builddir == srcdir, so
> the Makefile variables are simpler:
> 
> 	top_srcdir   = ..
> 	srcdir       = .
> 	top_builddir = ..

  I'll try to come up with something to generate the doc (sadly, we don't have 
a standard search and replace tools...)

> >   How do we go reporting fix into the 1.8.0 branch ?
> 
> Well, since there is no branch done yet, everything on the "main"
> trunk will appear in both the 1.6.1 and 1.8.0 release.  So please
> do commit bugfixes onto the CVS tree.
> 
> Once a branch is made, then the procedure is: checkout the 1.6 branch,
> make the change, commit it.  Then check out the main branch and merge
> in the change just made on the 1.6 branch.  This is a mildly more
> difficult procedure, so I am delaying making a 1.6 branch in order
> that we can continue to use the simpler procedure.  
> 
> We can delay a 1.6 branch until we need to make 1.8-only changes to
> CVS.  I thought we'd give it a week or so, until the bugfixes die
> down.  What do you think?

  Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would like to 
add (I would target 1.8.0 for the end of next week. Expected exception and 
named suite registration only would be worth it).

  How about: 
  - continue reporting bug fix to branch 1.6
  - add feature to branch 1.8

  - each time a release of branch 1.6 is made, merge the change since the last 
release on the branch ?
  or
  - merge change that occured on branch 1.6 since branch 1.8 creation to branch 
1.8 ?

  => instead of merging each time we update 1.6, we do it only once per bug fix 
release (or we could even postpone until 1.8 release to integrate bugfix)

  Baptiste.

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

RE: [Cppunit-devel] CppUnit 1.8.0 features...

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> 
> Baptiste wrote ...
> 
> >> I'm not saying to change CppUnit as a whole. The only thing I want
> to
> change 
> >> is those part of CppUnit that would impose on the "user" policy:
> 
> Fair enough.  Was this the result of a specific problem or bug report?

  Found that one when I started wrote an assertion_traits the other day. I was 
not happy with the result...

> 
> Sorry if my last e-mail comes across badly.  I think that the work
> that's

  Sorry if it seems so, but my english tend to be a bit "rough".

> been done on CppUnit in the last few months is really positive, and am
> just wary of large-scale changes being made, such as virtuals for
> everything.

  Since I probably missworded something in my previous mails, let's just make 
some things clear:
  - CppUnit has moved toward constness, and will continue to move that way.
  - I intend for change to have has little impact has possible
  - There would be no point making everything virtual in CppUnit...
  - I want CppUnit to impose as little constraint as possible on the user 
design (consteness in the user classes should be a matter of choice for 
example).
  - I intend for change being made to brough new functionality or make CppUnit 
easier to use (I don't like to do thing that have no 'value').

  Hey Steve, Baastian, do you share my view on those points ?

  Pfiuuu, just escaped "Const War, the return" ;-)

  Baptiste.

> 
> 
> Cheers,
> Bob
> 




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

Re: [Cppunit-devel] equality of const objects

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> On Tue, Sep 25, 2001 at 02:56:55PM +0200, Baptiste Lepilleur wrote:
> 
> >   I'm not saying to change CppUnit as a whole. The only thing I want
> >   to change is those part of CppUnit that would impose on the
> >   "user" policy:
> > 
> >  struct assertion_traits 
> >   {  
> >       static bool equal( const T& x, const T& y )
> > => change to 
> >       static bool equal( T& x, T& y )
> > 
> >   and 
> >     template <class T>
> >     void assertEquals( const T& expected,
> >                        const T& actual,
> > => change to:
> >     template <class T>
> >     void assertEquals( T& expected,
> >                        T& actual,
> >  
> >   The change is invisible for user that apply the "const" policy, and
> allow 
> > user who don't to use the assertEquals without having to do
> const_cast.
> 
> Sorry Baptiste, I do not understand.  Why do you say that using const
> references makes writing equal() black magic?  Can you give us a short
> example of a class that is problematic for equal(const&,const&)?

   Example of assertion_traits for FileDependency:

      static bool equal( const FileDependency& x, const FileDependency& y )
      {
        return const_cast<FileDependency&>(x).equalsTo( 
const_cast<FileDependency *>( &y ) );
      }

      static std::string toString( const FileDependency& x )
      {
        return const_cast<FileDependency&>( x ).toString();
      }

      The const_cast are the things I call "black magic". The code would be 
much cleaner if:

      static bool equal( FileDependency& x, FileDependency& y )
      {
        return x.equalsTo( &y );
      }

      static std::string toString( FileDependency& x )
      {
        return x.toString();
      }

      But I just realized, that assertion_traits is not the problem. When 
specializing a template, you can change the function signature anyway you want. 
So I could actually write the template the right way (having non-const 
reference).      

      So that lead us to... (below)

> 
> I'm worried about making the change you propose.  I use const a lot,
> and I'm sure that I have CppUnit tests in functions that are
> passed const references:
> 
> 	foo( const T& x )
> 	{
> 	    T y(blahblah);
> 	    CPPUNIT_ASSERT_EQUAL(x,y);
> 	}
> 
> I think your proposed change would break my code, wouldn't it?

  Yes, I'm a dummy. I inverted the implicit cast. So the change can't be done 
the way I proposed (We should add some unit test for the traits I think).

  How about changing assertEquals() which is the method that actually force the 
use of const reference ?

    template <class T>
    void assertEquals( const T& expected,
                       const T& actual, ... )

=> change to :
    template <class T>
    void assertEquals( T expected,
                       T actual, ... )

    This means that pass-by-value would be use instead of const reference. 
Means that tested object should either have a copy constructor or be pointer.
  
  Baptiste.

> 
> 
> Thanks,
> -Steve

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

RE: [Cppunit-devel] Duplicated #includes

[Summerwill, B. <BSu...@eu...>]

They don't cause any trouble as such, but they will increase
compile times, maybe substantially.

On most compilers, the preprocessor will have to fully expand the
second #include (including traversing the indirect includes which
the header itself has *), before it can notice the #ifndef, and
discard the lot.

MSVC++ solves this with #pragma once, but this isn't a portable
solution.  I just wanted to point these duplications out, as
summed over the whole application, they can make a real difference
to the compile time.


Cheers,
Bob


* Just starting traversing the headers shipped with MSVC++,
including <string> also drags in ...

istream
ostream
ios
streambuf
xlocnum
cerrno
errorno.h
climits
limits.h
cstdio
stdio.h
cstdlib
stdlib.h
xiosbase
xlocale
cstring
string.h
stdexcept
exception
xstring
etc ...

So having <string> included twice may well cause an additional 20
or 30 file operations for _each_ client file which uses the
header with the duplicated include.



-----Original Message-----
From: Steve M. Robbins [mailto:ste...@vi...]
Sent: 25 September 2001 15:41
To: Cpp Unit Develpment Mailing List
Subject: Re: [Cppunit-devel] Duplicated #includes



Hello,

Sorry for being so dense this morning, but: do the duplicated includes
cause any trouble?


On Tue, Sep 25, 2001 at 02:30:33PM +0100, Summerwill, Bob wrote:
> Baptiste wrote ...
> 
> >> Shoudln't that <string> only be included if you don't have 
> >> CPPUNIT_HAVE_SSTREAM anyway ?
> 
> I'm not sure.  Presumably it's there so that the inline implementation
> of OStringStream::str() can construct the msg local variable, in which
> case you are probably correct.

Yeah, you're right, it could be protected.
 
> >> Wouldn't it be better to move the declaration of OStringStream in
> >> its one header (include/cppunit/portability, include/cppunit/tools ?),
> >> and includes it only where it is used ?

The whole reason for "Portability" is so that you can just
#include it, and then assume a whole bunch of things.  Like
class OStringStream is defined.  I would argue that including
<string> unconditionally in "Portability.h" is also a good thing.

It is true that at present, OStringStream is only used in a couple
of the CppUnit sources.  However, users that define their own
assertion_traits (i.e. ME!) also use OStringStream.  It is convenient
to include a single CppUnit header and have everything I need
defined.

As I said above: I don't understand the concern over a few extra
includes.

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Duplicated #includes

[Steve M. R. <ste...@vi...>]

Hello,

Sorry for being so dense this morning, but: do the duplicated includes
cause any trouble?


On Tue, Sep 25, 2001 at 02:30:33PM +0100, Summerwill, Bob wrote:
> Baptiste wrote ...
> 
> >> Shoudln't that <string> only be included if you don't have 
> >> CPPUNIT_HAVE_SSTREAM anyway ?
> 
> I'm not sure.  Presumably it's there so that the inline implementation
> of OStringStream::str() can construct the msg local variable, in which
> case you are probably correct.

Yeah, you're right, it could be protected.
 
> >> Wouldn't it be better to move the declaration of OStringStream in
> >> its one header (include/cppunit/portability, include/cppunit/tools ?),
> >> and includes it only where it is used ?

The whole reason for "Portability" is so that you can just
#include it, and then assume a whole bunch of things.  Like
class OStringStream is defined.  I would argue that including
<string> unconditionally in "Portability.h" is also a good thing.

It is true that at present, OStringStream is only used in a couple
of the CppUnit sources.  However, users that define their own
assertion_traits (i.e. ME!) also use OStringStream.  It is convenient
to include a single CppUnit header and have everything I need
defined.

As I said above: I don't understand the concern over a few extra
includes.

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

[Cppunit-devel] equality of const objects

[Steve M. R. <ste...@vi...>]

On Tue, Sep 25, 2001 at 02:56:55PM +0200, Baptiste Lepilleur wrote:

>   I'm not saying to change CppUnit as a whole. The only thing I want
>   to change is those part of CppUnit that would impose on the
>   "user" policy:
> 
>  struct assertion_traits 
>   {  
>       static bool equal( const T& x, const T& y )
> => change to 
>       static bool equal( T& x, T& y )
> 
>   and 
>     template <class T>
>     void assertEquals( const T& expected,
>                        const T& actual,
> => change to:
>     template <class T>
>     void assertEquals( T& expected,
>                        T& actual,
>  
>   The change is invisible for user that apply the "const" policy, and allow 
> user who don't to use the assertEquals without having to do const_cast.

Sorry Baptiste, I do not understand.  Why do you say that using const
references makes writing equal() black magic?  Can you give us a short
example of a class that is problematic for equal(const&,const&)?

I'm worried about making the change you propose.  I use const a lot,
and I'm sure that I have CppUnit tests in functions that are
passed const references:

	foo( const T& x )
	{
	    T y(blahblah);
	    CPPUNIT_ASSERT_EQUAL(x,y);
	}

I think your proposed change would break my code, wouldn't it?


Thanks,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

RE: [Cppunit-devel] CppUnit 1.8.0 features...

[Summerwill, B. <BSu...@eu...>]

Baptiste wrote ...

>> Does removing the constness check on assertertion_traits bother
>> you that much ?

Not anymore, I just thought it was part of something bigger.  Sorry
to make a fuss ;-)


Cheers,
Bob


-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: 25 September 2001 15:00
To: cpp...@li...
Subject: RE: [Cppunit-devel] CppUnit 1.8.0 features...


Quoting "Summerwill, Bob" <BSu...@eu...>:

> I personally disagree with lots of these comments, as do lots of other
> people, whose comments you can see if you follow some of the links
> from these Wiki pages (see UseConstMemberFunctions and
> ConstCorrectness).
> 
> 
> Specifically ...
> 
> 
> 1. Make all member functions virtual unless there is a compelling need
> not too.
>
----------------------------------------------------------------------------
> I can't agree with this.  If you need to subclass something, and override
a
> method, you should make the method virtual _when you need to_. Otherwise
> it's just a case of YouArentGoingToNeedIt.  The code will run slower for
no
> real gain.

  Like I said, I'd rather go back and add virtuality.

> 2. Make all functions public.
> -----------------------------
> As covered in some of the WikiWeb pages, this actually makes refactoring
> harder, because it breaks encapsulation.

  Kinda weird, I actually read "think long and hard before making a function

public"...

  Well, I agree. I usually make everything private. On the otherhand, I tend
to 
pull private method and raise them to public/protected access if I fill the 
need to (though I might rethink the interface at the time).

> 3. Avoid const on members
> -------------------------
> In my experience, having const-correct members doesn't make
> refactoring
> harder.  It does restrict your code, but this is in a good way.  The
> compiler is making additional checks that your code is doing what you
> expect.

  Well, when I apply the "rules" I gave, you don't have much "const"
remaining. 
I make thing simpler (though for value object, you usually end-up providing 
constness to be compatible with existing library (STL)). I prefer to pull up

the Immutable pattern when I need "constness". Often, const get in my way,
and 
I would end-up with many attributs being mutable. 

  My guess is that it depends on the way your style of code. All I know is
that 
I have applyied those rules (my version) in my development for the last 3 
months (including a new project at work), and found it to work pretty well.

> 4. Have uniform conventions
> ---------------------------
> I absolutely agree with this.  Following up your comments, Baptiste
> ...
> 
> 
> >> 1) avoid pass-by-value or non const reference, prefer pointer
> >>    => allow polymorphism
> 
> Yes.
> 
> >> 2) prefer pass-by-value to const reference
> >>    => don't need to had "const" method to object.
> 
> If the object you're passing to a method isn't const-correct, then
> you'll
> obviously need to do this.
> 
> >> 3) avoid to return const reference, prefer return by value
> >>    => the former make it difficult to change the implementation
> 
> Not sure I agree with that.  I think it probably varies by class.
  My experience is that if you have:
  const std::vector<Test*> &getTests()   

  You can not change your implementation to something else ( 
std::map<string,Test*> for example) without impacting client. But if you
had:
  std::vector<Test*> getTests(),
  then it could easily be done.

> I'd urge you to read more fully through all the follow-up comments to
> Michael's posting before making any changes.  What does everyone else
> think?

  Does removing the constness check on assertertion_traits bother you that 
much ?

  Baptiste.


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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] CppUnit 1.8.0 features...

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> I personally disagree with lots of these comments, as do lots of other
> people, whose comments you can see if you follow some of the links
> from these Wiki pages (see UseConstMemberFunctions and
> ConstCorrectness).
> 
> 
> Specifically ...
> 
> 
> 1. Make all member functions virtual unless there is a compelling need
> not too.
> ----------------------------------------------------------------------------
> I can't agree with this.  If you need to subclass something, and override a
> method, you should make the method virtual _when you need to_. Otherwise
> it's just a case of YouArentGoingToNeedIt.  The code will run slower for no
> real gain.

  Like I said, I'd rather go back and add virtuality.

> 2. Make all functions public.
> -----------------------------
> As covered in some of the WikiWeb pages, this actually makes refactoring
> harder, because it breaks encapsulation.

  Kinda weird, I actually read "think long and hard before making a function 
public"...

  Well, I agree. I usually make everything private. On the otherhand, I tend to 
pull private method and raise them to public/protected access if I fill the 
need to (though I might rethink the interface at the time).

> 3. Avoid const on members
> -------------------------
> In my experience, having const-correct members doesn't make
> refactoring
> harder.  It does restrict your code, but this is in a good way.  The
> compiler is making additional checks that your code is doing what you
> expect.

  Well, when I apply the "rules" I gave, you don't have much "const" remaining. 
I make thing simpler (though for value object, you usually end-up providing 
constness to be compatible with existing library (STL)). I prefer to pull up 
the Immutable pattern when I need "constness". Often, const get in my way, and 
I would end-up with many attributs being mutable. 

  My guess is that it depends on the way your style of code. All I know is that 
I have applyied those rules (my version) in my development for the last 3 
months (including a new project at work), and found it to work pretty well.

> 4. Have uniform conventions
> ---------------------------
> I absolutely agree with this.  Following up your comments, Baptiste
> ...
> 
> 
> >> 1) avoid pass-by-value or non const reference, prefer pointer
> >>    => allow polymorphism
> 
> Yes.
> 
> >> 2) prefer pass-by-value to const reference
> >>    => don't need to had "const" method to object.
> 
> If the object you're passing to a method isn't const-correct, then
> you'll
> obviously need to do this.
> 
> >> 3) avoid to return const reference, prefer return by value
> >>    => the former make it difficult to change the implementation
> 
> Not sure I agree with that.  I think it probably varies by class.
  My experience is that if you have:
  const std::vector<Test*> &getTests()   

  You can not change your implementation to something else ( 
std::map<string,Test*> for example) without impacting client. But if you had:
  std::vector<Test*> getTests(),
  then it could easily be done.

> I'd urge you to read more fully through all the follow-up comments to
> Michael's posting before making any changes.  What does everyone else
> think?

  Does removing the constness check on assertertion_traits bother you that 
much ?

  Baptiste.


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

RE: [Cppunit-devel] Duplicated #includes

[Summerwill, B. <BSu...@eu...>]

Baptiste wrote ...

>> Shoudln't that <string> only be included if you don't have 
>> CPPUNIT_HAVE_SSTREAM anyway ?

I'm not sure.  Presumably it's there so that the inline implementation
of OStringStream::str() can construct the msg local variable, in which
case you are probably correct.


>> Wouldn't it be better to move the declaration of OStringStream in
>> its one header (include/cppunit/portability, include/cppunit/tools ?),
>> and includes it only where it is used ?

Yes!  Looks like it's only used in assertion_traits<T>::toString() and
in TestFactoryRegistry::registerFactory(), so that would be sensible.
The new header file would then #include Portability.h, for its
pre-processor defines.

If that's done, then the duplicated includes information I sent would
no longer be valid, but the solution would be better, I think.


Cheers,
Bob


-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: 25 September 2001 14:06
To: Cpp Unit Develpment Mailing List
Subject: Re: [Cppunit-devel] Duplicated #includes



Quoting "Summerwill, Bob" <BSu...@eu...>:

> 
> I've just had a quick scan through CppUnit 1.6.0, and found these
> duplicated
> #includes.  The <string> ones are due to addition of a <string> #include
> in
> Portability.h, making the other ones unnecessary.

  Shoudln't that <string> only be included if you don't have 
CPPUNIT_HAVE_SSTREAM anyway ?

  Wouldn't it be better to move the declaration of OStringStream in its one 
header (include/cppunit/portability, include/cppunit/tools ?), and includes
it 
only where it is used ?

  Baptiste.

> Source file                                Duplicated include
> -----------                                ------------------
> extensions/HelperMacros.h                  string
> extensions/TestFactoryRegistry.h           string
> extensions/TestSuiteBuilder.h
> cppunit/extensions/TypeInfoHelper.h
> TestAssert.h                               string
> TestCase.cpp                               cppunit/Exception.h
> TestCase.h                                 string
> TestSuite.h                                string
> TypeInfoHelper.cpp                         string
> 
> 
> 
> Cheers,
> Bob
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] CppUnit 1.8.0 features...

[Summerwill, B. <BSu...@eu...>]

Baptiste wrote ...

>> I'm not saying to change CppUnit as a whole. The only thing I want to
change 
>> is those part of CppUnit that would impose on the "user" policy:

Fair enough.  Was this the result of a specific problem or bug report?

Sorry if my last e-mail comes across badly.  I think that the work that's
been done on CppUnit in the last few months is really positive, and am
just wary of large-scale changes being made, such as virtuals for
everything.


Cheers,
Bob


-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: 25 September 2001 13:57
To: Summerwill, Bob
Cc: Baptiste Lepilleur; Baptiste Lepilleur; Cpp Unit Develpment Mailing
List
Subject: RE: [Cppunit-devel] CppUnit 1.8.0 features...


Quoting "Summerwill, Bob" <BSu...@eu...>:

> 
> Baptiste wrote:
> 
> >> I would actually call that one a bug fix. While const is usefull when
> 
> >> manipulating value object, it is a strong constraint. Personnaly, I
> have
> taken 
> >> Michael Feather's advice on XP and C++ and don't use const on
> reference
> object 
> >> (object who don't have public copy constructor). This make
> refactoring a
> lot 
> >> easier, but writing assertion_traits black magic :-(.
> 
> Please could you clarify why you wouldn't want const references? 
> Maybe
> provide
> a link to Michael Feather's advice?
> 
> I've always found const-correctness very useful, and would see
> removing
> const-correctness from CppUnit as a backwards step.  There are a number
> of
> other
> areas in the framework which I spotted as not being const-correct.  Is
> this
> a
> policy decision, that you aren't being const-correct?

  See other mail for urls. Note that the framework was first written by
Michael 
Feather, who did not use const (which explain why the constness is shacky).

  I'm not saying to change CppUnit as a whole. The only thing I want to
change 
is those part of CppUnit that would impose on the "user" policy:

 struct assertion_traits 
  {  
      static bool equal( const T& x, const T& y )
=> change to 
      static bool equal( T& x, T& y )

  and 
    template <class T>
    void assertEquals( const T& expected,
                       const T& actual,
=> change to:
    template <class T>
    void assertEquals( T& expected,
                       T& actual,
 
  The change is invisible for user that apply the "const" policy, and allow 
user who don't to use the assertEquals without having to do const_cast.

  Baptiste.

> 
> 
> Cheers,
> Bob
> 

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

RE: [Cppunit-devel] CppUnit 1.8.0 features...

[Summerwill, B. <BSu...@eu...>]

I personally disagree with lots of these comments, as do lots of other
people, whose comments you can see if you follow some of the links
from these Wiki pages (see UseConstMemberFunctions and ConstCorrectness).


Specifically ...


1. Make all member functions virtual unless there is a compelling need not
too.
----------------------------------------------------------------------------
---
I can't agree with this.  If you need to subclass something, and override a
method, you should make the method virtual _when you need to_.  Otherwise
it's
just a case of YouArentGoingToNeedIt.  The code will run slower for no real
gain.


2. Make all functions public.
-----------------------------
As covered in some of the WikiWeb pages, this actually makes refactoring
harder, because it breaks encapsulation.


3. Avoid const on members
-------------------------
In my experience, having const-correct members doesn't make refactoring
harder.  It does restrict your code, but this is in a good way.  The
compiler is making additional checks that your code is doing what you
expect.


4. Have uniform conventions
---------------------------
I absolutely agree with this.  Following up your comments, Baptiste ...


>> 1) avoid pass-by-value or non const reference, prefer pointer
>>    => allow polymorphism

Yes.

>> 2) prefer pass-by-value to const reference
>>    => don't need to had "const" method to object.

If the object you're passing to a method isn't const-correct, then you'll
obviously need to do this.

>> 3) avoid to return const reference, prefer return by value
>>    => the former make it difficult to change the implementation

Not sure I agree with that.  I think it probably varies by class.

>> 4) never use const method.
>>    => const is often more an hinderance that help when refactoring.

Disagree.



I'd urge you to read more fully through all the follow-up comments to
Michael's posting before making any changes.  What does everyone else
think?


Cheers,
Bob


-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: 25 September 2001 13:19
To: Cpp Unit Develpment Mailing List
Subject: Re: [Cppunit-devel] CppUnit 1.8.0 features...


Quoting Volker Boerchers <boe...@we...>:

> On Tue, 25 Sep 2001, Baptiste Lepilleur wrote:
> 
> > Quoting Baptiste Lepilleur <bl...@cl...>:
> > 
> >       7) remove consteness on ASSERT_EQUAL. 
> >     I would actually call that one a bug fix. While const is usefull
> when 
> > manipulating value object, it is a strong constraint. Personnaly, I
> have taken 
> > Michael Feather's advice on XP and C++ and don't use const on
> reference object 
> > (object who don't have public copy constructor). This make refactoring
> a lot 
> > easier, but writing assertion_traits black magic :-(.
> 
> Hi Baptiste,
> 
> could you give me a reference on this subject, some online docs or so
> -
> This advice is new to me.

This is part the extreme programming challenges:
http://c2.com/cgi/wiki?ExtremeProgrammingChallenge

and the more specifically the C++ challenge (the page you're interested in):

http://c2.com/cgi/wiki?ExtremeProgrammingChallengeSeven

The comment is very short, but my current working rules are:

1) avoid pass-by-value or non const reference, prefer pointer
   => allow polymorphism
2) prefer pass-by-value to const reference
   => don't need to had "const" method to object.
3) avoid to return const reference, prefer return by value
   => the former make it difficult to change the implementation
4) never use const method.
   => const is often more an hinderance that help when refactoring.

  I still don't realy know what to do about non const reference. I usually 
avoid them (so reference are only use as optimisation to pass-by-value), but
it 
sometimes lead to clumsy code (pointer on std::vector)...

  I still haven't got around using the make everything virtual, but adding
the 
virtuality when needed is not a problem.

  Part of those rules where inferred from Michael Feather's CppUnit.

  And we still haven't our refactoring catalog (we have multiple inheritance

and template)...

  Baptiste.

> 
> Thanks and
> Thanks for your work on cppunit!
> Volker
> -- 
> Volker Boerchers, boe...@we...
> 
> 

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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Duplicated #includes

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> 
> I've just had a quick scan through CppUnit 1.6.0, and found these
> duplicated
> #includes.  The <string> ones are due to addition of a <string> #include
> in
> Portability.h, making the other ones unnecessary.

  Shoudln't that <string> only be included if you don't have 
CPPUNIT_HAVE_SSTREAM anyway ?

  Wouldn't it be better to move the declaration of OStringStream in its one 
header (include/cppunit/portability, include/cppunit/tools ?), and includes it 
only where it is used ?

  Baptiste.

> Source file                                Duplicated include
> -----------                                ------------------
> extensions/HelperMacros.h                  string
> extensions/TestFactoryRegistry.h           string
> extensions/TestSuiteBuilder.h
> cppunit/extensions/TypeInfoHelper.h
> TestAssert.h                               string
> TestCase.cpp                               cppunit/Exception.h
> TestCase.h                                 string
> TestSuite.h                                string
> TypeInfoHelper.cpp                         string
> 
> 
> 
> Cheers,
> Bob
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

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

RE: [Cppunit-devel] CppUnit 1.8.0 features...

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> 
> Baptiste wrote:
> 
> >> I would actually call that one a bug fix. While const is usefull when
> 
> >> manipulating value object, it is a strong constraint. Personnaly, I
> have
> taken 
> >> Michael Feather's advice on XP and C++ and don't use const on
> reference
> object 
> >> (object who don't have public copy constructor). This make
> refactoring a
> lot 
> >> easier, but writing assertion_traits black magic :-(.
> 
> Please could you clarify why you wouldn't want const references? 
> Maybe
> provide
> a link to Michael Feather's advice?
> 
> I've always found const-correctness very useful, and would see
> removing
> const-correctness from CppUnit as a backwards step.  There are a number
> of
> other
> areas in the framework which I spotted as not being const-correct.  Is
> this
> a
> policy decision, that you aren't being const-correct?

  See other mail for urls. Note that the framework was first written by Michael 
Feather, who did not use const (which explain why the constness is shacky).

  I'm not saying to change CppUnit as a whole. The only thing I want to change 
is those part of CppUnit that would impose on the "user" policy:

 struct assertion_traits 
  {  
      static bool equal( const T& x, const T& y )
=> change to 
      static bool equal( T& x, T& y )

  and 
    template <class T>
    void assertEquals( const T& expected,
                       const T& actual,
=> change to:
    template <class T>
    void assertEquals( T& expected,
                       T& actual,
 
  The change is invisible for user that apply the "const" policy, and allow 
user who don't to use the assertEquals without having to do const_cast.

  Baptiste.

> 
> 
> Cheers,
> Bob
> 

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

Re: [Cppunit-devel] CppUnit 1.8.0 features...

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

Quoting Volker Boerchers <boe...@we...>:

> On Tue, 25 Sep 2001, Baptiste Lepilleur wrote:
> 
> > Quoting Baptiste Lepilleur <bl...@cl...>:
> > 
> >       7) remove consteness on ASSERT_EQUAL. 
> >     I would actually call that one a bug fix. While const is usefull
> when 
> > manipulating value object, it is a strong constraint. Personnaly, I
> have taken 
> > Michael Feather's advice on XP and C++ and don't use const on
> reference object 
> > (object who don't have public copy constructor). This make refactoring
> a lot 
> > easier, but writing assertion_traits black magic :-(.
> 
> Hi Baptiste,
> 
> could you give me a reference on this subject, some online docs or so
> -
> This advice is new to me.

This is part the extreme programming challenges:
http://c2.com/cgi/wiki?ExtremeProgrammingChallenge

and the more specifically the C++ challenge (the page you're interested in): 
http://c2.com/cgi/wiki?ExtremeProgrammingChallengeSeven

The comment is very short, but my current working rules are:

1) avoid pass-by-value or non const reference, prefer pointer
   => allow polymorphism
2) prefer pass-by-value to const reference
   => don't need to had "const" method to object.
3) avoid to return const reference, prefer return by value
   => the former make it difficult to change the implementation
4) never use const method.
   => const is often more an hinderance that help when refactoring.

  I still don't realy know what to do about non const reference. I usually 
avoid them (so reference are only use as optimisation to pass-by-value), but it 
sometimes lead to clumsy code (pointer on std::vector)...

  I still haven't got around using the make everything virtual, but adding the 
virtuality when needed is not a problem.

  Part of those rules where inferred from Michael Feather's CppUnit.

  And we still haven't our refactoring catalog (we have multiple inheritance 
and template)...

  Baptiste.

> 
> Thanks and
> Thanks for your work on cppunit!
> Volker
> -- 
> Volker Boerchers, boe...@we...
> 
> 

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

RE: [Cppunit-devel] CppUnit 1.8.0 features...

[Summerwill, B. <BSu...@eu...>]

Baptiste wrote:

>> I would actually call that one a bug fix. While const is usefull when 
>> manipulating value object, it is a strong constraint. Personnaly, I have
taken 
>> Michael Feather's advice on XP and C++ and don't use const on reference
object 
>> (object who don't have public copy constructor). This make refactoring a
lot 
>> easier, but writing assertion_traits black magic :-(.

Please could you clarify why you wouldn't want const references?  Maybe
provide
a link to Michael Feather's advice?

I've always found const-correctness very useful, and would see removing
const-correctness from CppUnit as a backwards step.  There are a number of
other
areas in the framework which I spotted as not being const-correct.  Is this
a
policy decision, that you aren't being const-correct?


Cheers,
Bob

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: 25 September 2001 11:40
To: Baptiste Lepilleur
Cc: Cpp Unit Develpment Mailing List
Subject: Re: [Cppunit-devel] CppUnit 1.8.0 features...


Quoting Baptiste Lepilleur <bl...@cl...>:

>     Depending on how soon you want 1.8.0 to be, here is a list of
> feature
> that are simple to implement:
> 
>     1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
>     2) CPPUNIT_TEST_FAIL( method )
>     3) add a flag to TestFailure distinguishing error/failure, retain
> only
> one collection to store result
> (see other mail)
>     4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName
> ) :
> register the fixture's suite in a suite of the specified name.
>     5) Qt TestRunner (I've got it working, need feedback and help to
> use
> TMAKE to build a library instead of an application)
>     6) ASSERT_EQUAL support for two differents compatible types

      7) remove consteness on ASSERT_EQUAL. 
    I would actually call that one a bug fix. While const is usefull when 
manipulating value object, it is a strong constraint. Personnaly, I have
taken 
Michael Feather's advice on XP and C++ and don't use const on reference
object 
(object who don't have public copy constructor). This make refactoring a lot

easier, but writing assertion_traits black magic :-(.

      Baptiste.
   



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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

[Cppunit-devel] Duplicated #includes

[Summerwill, B. <BSu...@eu...>]

I've just had a quick scan through CppUnit 1.6.0, and found these duplicated
#includes.  The <string> ones are due to addition of a <string> #include in
Portability.h, making the other ones unnecessary.



Source file                                Duplicated include
-----------                                ------------------
extensions/HelperMacros.h                  string
extensions/TestFactoryRegistry.h           string
extensions/TestSuiteBuilder.h
cppunit/extensions/TypeInfoHelper.h
TestAssert.h                               string
TestCase.cpp                               cppunit/Exception.h
TestCase.h                                 string
TestSuite.h                                string
TypeInfoHelper.cpp                         string



Cheers,
Bob

Re: [Cppunit-devel] CppUnit 1.8.0 features...

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

Quoting Baptiste Lepilleur <bl...@cl...>:

>     Depending on how soon you want 1.8.0 to be, here is a list of
> feature
> that are simple to implement:
> 
>     1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
>     2) CPPUNIT_TEST_FAIL( method )
>     3) add a flag to TestFailure distinguishing error/failure, retain
> only
> one collection to store result
> (see other mail)
>     4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName
> ) :
> register the fixture's suite in a suite of the specified name.
>     5) Qt TestRunner (I've got it working, need feedback and help to
> use
> TMAKE to build a library instead of an application)
>     6) ASSERT_EQUAL support for two differents compatible types

      7) remove consteness on ASSERT_EQUAL. 
    I would actually call that one a bug fix. While const is usefull when 
manipulating value object, it is a strong constraint. Personnaly, I have taken 
Michael Feather's advice on XP and C++ and don't use const on reference object 
(object who don't have public copy constructor). This make refactoring a lot 
easier, but writing assertion_traits black magic :-(.

      Baptiste.
   



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

Re: [Cppunit-devel] 1.6.0 is released!

[Steve M. R. <ste...@vi...>]

Hi Baptiste,

I'm saving all the 1.8 feature ideas you have been posting 
until I have some time to think about them.

I'll try here to reply to your other messages.


On Mon, Sep 24, 2001 at 11:10:42PM +0200, Baptiste Lepilleur wrote:

> > If you wish to start one, my suggestion is to put it in the doc/
> > directory of the sources.  I can make arrangements for it to get
> > automatically updated to the web page cppunit.sf.net every so often.
> 
>     HTML format or text, or ... ?

Your choice.  HTML has the advantage of hyperlinks, should one so
desire.  I find text quite a bit easier to edit, however, so HTML may
put me off editing the FAQ...

 
> > >   Another point, I'd like to be able to generate documentation with
> doxygen on
> > > WIN32. To do so I would need to have a version Doxyfile.in where "macro"
> stuff
> > > have been replaced. Is there a way to do that in an automatized fashion
> ?
> >
> > Baptiste, maybe it is time to bite the bullet and join us in
> autoconf-land!  ;-)
> 
>     Well, If you were to give me the @@topdir@@ & co value (or semantic), it
> could probably be automatised with a simple search and replace (a slighty
> easier solution ;-) )

In the long run, I think this is not so easy, to be honest.  But MS
ain't my problem ... :-)

You want to replace @top_srcdir@ with the path to the top of the
source directory, @srcdir@ is the path to the current source dir,
etc.  Look in Makefile.in for clues to the other replacements.



On Mon, Sep 24, 2001 at 09:47:22PM +0200, Baptiste Lepilleur wrote:

> > The CVS tree is synched up with the release version, and tagged (tag
> > REL_1_6_0).  My immediate plans are to wait and see what bug reports
> > come in.  I am prepared to make a 1.6.1 release as soon as necessary,
> > and generally I plan to keep making 1.6.x releases as necessary to fix
> > bugs.
> 
>     Well, there are bugs in cppunittest/TestCallerTest (as well as a few
> memory leaks I did not spot last time), is does not check correctly the
> expected exception stuff. Should that go in 1.6.1 or 1.8.0 (with the
> exception enhancement I proposed in another mail)?

If there is a bug in 1.6.0 that you can fix without major surgery,
then yes, it should go into 1.6.1.  The 1.6.x series should fix all
bugs in 1.6.0 that are reasonable to fix.

 
> > In the meanwhile, we should kick around ideas for 1.8.0.  I generally
> > favour the "release early, release often" policy.  How about the rest
> > of you?  If we go that route though, we need to be aggressive in
> > limiting what changes will be made for 1.8.  Let's hear ideas!
> 
>     What is your definition of often ? once a month, biweekly, weekly ? 

For bugfix releases, I'm prepared to go for once a week or more, if
necessary.

For new-feature releases, the schedule will depend on what we
want to get done, and how much free time one has, and all the
rest of it.  I don't have a fixed schedule in mind, but something
on the order of a month or two is in the right ballpark, I think.


> As time go, we should strengthen our test suite. Whenever a bug is
> found, we should try to write a test for it. I already did it for
> the TestCaller thingy.

Great!  Yes, test cases for cppunit are good things.  They should also
go into the bugfix releases, IMHO.


On Mon, Sep 24, 2001 at 09:05:48PM +0200, Baptiste Lepilleur wrote:
>     Yesterday I found a bug in test caller. When an expected exception
> wasn't caught, it did:
> throw new Exception(...) instead of
> throw Exception(...).
> 
>     I went down to the test suite to see why it was not detected. Result:
> forgot to put a test case for that one. I'm in the process of correcting
> this, but there is no way I can safely distinguish if "new Exception()" or
> "Exception()" was thrown. There can only be distinguished by the message.

Is this for the test suite or for the main code?  If the former, is it
possible to simply use catch blocks for both "Exception" and
"Exception*" types?


-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants