Lutz Kretzschmar <lut### [at] stmuccom> wrote:
: Why? That's the standard way of cloning an object (standard in the
: sense of widely used). Simply invoke the copy constructor on the
: current instance. How else would you write a Clone() or Copy()
: function?

  It may be a standard way in Java. In C++ it's a standard way of getting
sure that you will get a high chance of a memory leak (specially if there's
more than one person using the library which does that). (And no, the way
Java handles object allocation and freeing is not always good.)

  As I already said in another article, one of the basic principles of
modularity is that if a module (class, whatever) allocates a resource, the
same module takes care that the resource gets freed (and gets freed only
once).
  Making a module which allocates a resource, returns a handle to this
resource outside and hopes that someone else will hopefully free it somewhere,
is a *really* bad module design (and OO design).

  The whole class hierarchy should be designed so that this kind of copying
is not needed (ie. not in this way). This usually can be done much better
and much more nicely (and specially much more safely).
  Making efforts for a good design now can save you a lot of trouble later.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message