References, AddressOf and Object management

[Pete Vidler]

Pete Vidler wrote:
[snip]

class SafeClass
{
public:
typedef boost::shared_ptr< SafeClass > Ptr;

// Might need a static_cast here, I don't remember exactly.
Ptr Create() { return new SafeClass; }

That Create method was meant to be static, obviously.

private:
SafeClass() { ... }
};

// This should be the only way to create a SafeClass object:
SafeClass:tr safeClass1 = SafeClass::Create();

-- Pete

 

[Tim]

Pete Vidler wrote:
[snip]

class SafeClass
{
public:
typedef boost::shared_ptr< SafeClass > Ptr;

// Might need a static_cast here, I don't remember exactly.
Ptr Create() { return new SafeClass; }

That Create method was meant to be static, obviously.

private:
SafeClass() { ... }
};

// This should be the only way to create a SafeClass object:
SafeClass:tr safeClass1 = SafeClass::Create();

-- Pete

Don't we have an even worse issue here; what if someone makes a reference to
the returned temporary instead of copying it:

SafeClass:tr& safeClass1 = SafeClass::Create();

Now the instance of SafeClass is a bona-fide memory leak.

 

[Tim]

Tim Clacy wrote:
[snip]

What if somefunction assigns a static or class member to that reference...
or copies it to another thread?

[snip]

In the case of a programmer assigning static members to references, the
fool deserves everything he gets. You can protect programmers from
themselves only so far.

In the given example you cannot reassign a reference. It just isn't
legal C++. You can alter the object that the reference is of, in ways
determined by the interface of its class (providing it's a non-const
reference), but that's about it.

-- Pete

But the big problem, surely, is that when the reference goes out of scope,
the destructor of the object to which it refers is not called and we have a
lingering object. It seems much easier to make reference to instances than
to ensure that those instances are cleaned-up when its referees expire.

 

[Pete Vidler]

Tim wrote:
[snip]

Don't we have an even worse issue here; what if someone makes a reference to
the returned temporary instead of copying it:

SafeClass:tr& safeClass1 = SafeClass::Create();

Now the instance of SafeClass is a bona-fide memory leak.

[snip]

No it isn't. The standard forbids assigning a temporary to a non-const
reference. It won't even compile (with a half decent compiler).

If you used a const-reference, the object is guaranteed to survive at
least as long as the const-reference.

Besides, that isn't a memory leak even if it was allowed. The smart
pointer will always free the memory, it's just that the reference would
then be invalid. But it can't happen, so it doesn't matter.

-- Pete

 

[Old Wolf]

...hmm, don't you think robust object life-time management is just about the
most important thing to get right to help ensure a robust, quality product?

No! I'm firmly on the Murphy side (and you seem to be on the
Machiavelli side): I think the idea is to make sure the users of your
library don't screw up accidentally, but not to try and prevent them
screwing up on purpose. No matter what measures you take, there
will always be a way to get around them if someone is hell-bent on
doing so.

My experience is that if something is fragile, sooner or later, it will
break... but perhaps I've just been unlucky?

What does 'pointer' have to do with 'fragile' ?
If someone creates and deletes your objects, good on them. You
don't have to try and prevent people from forgetting to free a
pointer, for example.
IMHO, adding more complexity to your class to guard against nasty
people, is just making it more fragile.