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