Experimental Physics and
Industrial Control System

[email protected] · Wed, 2 Sep 2009 12:30:19 +0800

But if we provide a factory method in gdd class, shall
we also provide the same method in gdd's two subclasses: gddScalar and
gddArray. gddScalar has 4 constructors and gddArray has 6 constructors.
So there are 16 constructors to handle in total. Here is one thing comes
into my mind, is it better to introduce an independent factory class which
is responsible for creating gdd and its subclass instances and returning
smartGDDPointers?
> Why not add a gdd factory method to the smartGDDPointer
API, so the user

> never needs to do a 'new gdd' themselves?

> 

> smartGDDPointer pDD1;            
    // Empty

> pDD1.newGdd();              

   // Create one

I did mention, in my message, that a factory was the first option. 

I suspect that we can all agree (based on the advantage of hindsight) that
a factory producing a smart pointer would have been a better design. The
controversy arises when considering what to do about the reference and
un-reference interface in gdd, which appears to be somewhat broken by modern
convention. In Jim's defense - some time has passed since he implemented
the gdd interface, and I added a smart pointer a few years after gdd was
written. The controversy arises, of course, surrounding changing the gdd
interface which is in use.

Unfortunately, unless one removes referencing, and also new, from the gdd
interface, then this still does not prevent someone from inadvertently
doing this. This type of unfortunate pitfall is what Alex and others have
experienced - and complained about.

gdd * pGDD = new gdd();

...

smartGDDPointer pDD1;            
    // Empty

pDD1.newGdd(); //create 1st one

...

smartGDDPointer pDD1 = pGDD; // replace with 2nd, woops forgot to call
pGDD->unreferenced()

Admittedly, adding the factory, but not amending the gdd interface (maybe
in sum what you are advocating) might be slightly safer because the user
would be better guided into a mainstream usage pattern.

BTW: Is there a reason why you have a preference:

// this

smartGDDPointer pDD1;            
    // Empty

pDD1.newGdd();              

   // Create one

// versus this (what I would probably implement lacking further input)

smartGDDPointer pDD1 = gdd :: factory (); // Create one

A messy aspect of factories is that one must replicate all of the various
ctor signatures for the various modes of the target. I think that there
are six of them with gdd. Maybe not so bad.

Jeff

______________________________________________________

Jeffrey O. Hill           Email    
   [email protected]

LANL MS H820              Voice  
     505 665 1831

Los Alamos NM 87545 USA   FAX          505
665 5107

Message content: TSPA

> -----Original Message-----

> From: Andrew Johnson [
mailto:[email protected]
]

> Sent: Friday, August 28, 2009 11:56 AM

> To: Jeff Hill

> Cc: [email protected]; Core-Talk

> Subject: Re: About the reference counting in GDD smart pointer

> 

> Hi Jeff,

> 

> On Friday 28 August 2009 10:55:04 Jeff Hill wrote:

> >

> > Some options

> > ------------

> 

> Why not add a gdd factory method to the smartGDDPointer API, so the
user

> never needs to do a 'new gdd' themselves?

> 

> smartGDDPointer pDD1;            
    // Empty

> pDD1.newGdd();              

   // Create one

> 

> > // the smart pointer maintains the ref count

> > smartGDDPointer pDD2 = pDD1;

> > smartGDDPointer pDD3 = pDD2;

> > pDD2 = pDD3;

> 

> - Andrew

> --

> The best FOSS code is written to be read by other humans -- Harold
Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System