Possible to require overloading of a non-pure method?

[[rob desbois]]

Hi all, I have a set of classes which implement the virtual
constructor idiom.

I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

Is there something (other than documentation) that I can do to prevent
this from happening again?

TIA,
--rob

[Pete Becker]

On 2008-04-25 06:40:20 -0400, "[rob desbois]" <ro*********@gmail.comsaid:

Hi all, I have a set of classes which implement the virtual
constructor idiom.

I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

Is there something (other than documentation) that I can do to prevent
this from happening again?

Unit testing and code reviews.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[[rob desbois]]

On Apr 25, 12:46*pm, Pete Becker <[e-mail]:

On 2008-04-25 06:40:20 -0400, "[rob desbois]" <[e-mail]:

Hi all, I have a set of classes which implement the virtual
constructor idiom.

I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

Is there something (other than documentation) that I can do to prevent
this from happening again?

Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which can
enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

--rob

[Pete Becker]

On 2008-04-25 10:59:20 -0400, "[rob desbois]" <ro*********@gmail.comsaid:

On Apr 25, 12:46*pm, Pete Becker <[e-mail]:

>On 2008-04-25 06:40:20 -0400, "[rob desbois]" <[e-mail]

:

>>

>>Hi all, I have a set of classes which implement the virtual
constructor idiom.

>>I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

>>Is there something (other than documentation) that I can do to prevent
this from happening again?

Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which can
enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

Unit tests would have helped, if they are written correctly and
reviewed correctly. What you're asking for is a language mechamism to
compensate for a weak development process. Fix the process.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Thomas J. Gritzan]

[rob desbois] schrieb:

On Apr 25, 12:46 pm, Pete Becker <[e-mail]:

>On 2008-04-25 06:40:20 -0400, "[rob desbois]" <[e-mail]:

>>Hi all, I have a set of classes which implement the virtual
constructor idiom.
I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.
Is there something (other than documentation) that I can do to prevent
this from happening again?

Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which can
enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

"Design by Contract".

Something like (untestet):

class Base
{
public:
Base* clone() const
{
Base* p = doClone();
assert(typeid(*p) == typeid(*this));
return p;
}

private:
Base* doClone() const
{
return new Base(*this);
}
}

--
Thomas

[Victor Bazarov]

Thomas J. Gritzan wrote:

[rob desbois] schrieb:

>On Apr 25, 12:46 pm, Pete Becker <[e-mail]:

>>On 2008-04-25 06:40:20 -0400, "[rob desbois]"
<[e-mail]:
Hi all, I have a set of classes which implement the virtual
constructor idiom.
I had a slicing problem which resulted when I forgot to override
the clone() function in a derived class.
Is there something (other than documentation) that I can do to
prevent this from happening again?
Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which
can enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

"Design by Contract".

Something like (untestet):

class Base
{
public:
Base* clone() const
{
Base* p = doClone();
assert(typeid(*p) == typeid(*this));
return p;
}

private:
Base* doClone() const
{
return new Base(*this);
}
}

;

First off, no virtual functions here, did you mean to make 'doClone'
virtual? And second, he needed the compile-time solution, AIUI.

And how does 'typeid' trick work? Does 'typeid' return the dynamic
type of '*this'? So, if you derive from 'Base', what then? How
does the splitting of the function in two help _forcing_ the derived
class provide the override?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[[rob desbois]]

On Apr 25, 4:58*pm, "Victor Bazarov" <[e-mail]:

Thomas J. Gritzan wrote:

[rob desbois] schrieb:

On Apr 25, 12:46 pm, Pete Becker <[e-mail]:
On 2008-04-25 06:40:20 -0400, "[rob desbois]"
<[e-mail]:
Hi all, I have a set of classes which implement the virtual
constructor idiom.
I had a slicing problem which resulted when I forgot to override
the clone() function in a derived class.
Is there something (other than documentation) that I can do to
prevent this from happening again?
Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which
can enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

"Design by Contract".

Something like (untestet):

class Base
{
public:
* *Base* clone() const
* *{
* * * Base* p = doClone();
* * * assert(typeid(*p) == typeid(*this));
* * * return p;
* *}

private:
* *Base* doClone() const
* *{
* * * return new Base(*this);
* *}
}

* * ;

First off, no virtual functions here, did you mean to make 'doClone'
virtual? *And second, he needed the compile-time solution, AIUI.

I expect he did.

And how does 'typeid' trick work? *Does 'typeid' return the dynamic
type of '*this'? *So, if you derive from 'Base', what then? *How
does the splitting of the function in two help _forcing_ the derived
class provide the override?

typeid is part of C++'s runtime type identification (RTTI)
functionality and yes, provides a dynamic type identifier of 'this'.
If I derive from Base without overriding doClone(), then the assertion
fails:
assert(typeid(*p) == typeid(*this));
because *p is a Base and *this is a Derived.

--rob

[[rob desbois]]

On Apr 25, 4:22*pm, Pete Becker <[e-mail]:

On 2008-04-25 10:59:20 -0400, "[rob desbois]" <[e-mail]:

On Apr 25, 12:46*pm, Pete Becker <[e-mail]:

On 2008-04-25 06:40:20 -0400, "[rob desbois]" <[e-mail]

:

>Hi all, I have a set of classes which implement the virtual
constructor idiom.

>I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

>Is there something (other than documentation) that I can do to prevent
this from happening again?

Unit testing and code reviews.

Allow me to clarify. I meant is there any language construct which can
enforce this requirement.

A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

Unit tests would have helped, if they are written correctly and
reviewed correctly. What you're asking for is a language mechamism to
compensate for a weak development process. Fix the process.

The language, its syntax, and libraries are there to support the
developer and the development process.
Would you suggest that using assert() is a weak development process?

Assuming that you were developing this and made the same basic mistake
that I did here -- forgot to override clone() -- where exactly would
the mistake have been spotted?
A correctly written unit test? I forgot to implement clone() so would
likely have forgotten the test for it.
A correctly reviewed unit test? In a team of 2 developers in a small
company developing specialised software, where I have the most
experience, I think it unlikely that it would've been caught.

Is there something else I could've done?

--rob

[Pete Becker]

On 2008-04-25 12:56:34 -0400, "[rob desbois]" <ro*********@gmail.comsaid:

On Apr 25, 4:22*pm, Pete Becker <[e-mail]:

>On 2008-04-25 10:59:20 -0400, "[rob desbois]" <[e-mail]

:

>>

>>On Apr 25, 12:46*pm, Pete Becker <[e-mail]:
On 2008-04-25 06:40:20 -0400, "[rob desbois]" <[e-mail]

aid

>>:

>>>>Hi all, I have a set of classes which implement the virtual
constructor idiom.

>>>>I had a slicing problem which resulted when I forgot to override the
clone() function in a derived class.

>>>>Is there something (other than documentation) that I can do to prevent

>>>>this from happening again?

>>>Unit testing and code reviews.

>>Allow me to clarify. I meant is there any language construct which can
enforce this requirement.

>>A unit test wouldn't have helped -- I'd have had to remember to write
a unit test for the new class's clone() method ensuring that the
returned pointer is castable to a pointer to the new derived type. If
I'd have remembered that I'd have remembered to code the clone method
anyway.

Unit tests would have helped, if they are written correctly and
reviewed correctly. What you're asking for is a language mechamism to
compensate for a weak development process. Fix the process.

The language, its syntax, and libraries are there to support the
developer and the development process.
Would you suggest that using assert() is a weak development process?

No.

>
Assuming that you were developing this and made the same basic mistake
that I did here -- forgot to override clone() -- where exactly would
the mistake have been spotted?

In the unit tests.

A correctly written unit test? I forgot to implement clone() so would
likely have forgotten the test for it.
A correctly reviewed unit test? In a team of 2 developers in a small
company developing specialised software, where I have the most
experience, I think it unlikely that it would've been caught.

First, accidental omissions are much more likely to be noticed by
someone who didn't write the code. That's the point of reviews: to get
fresh eyes on the code. Second, overriding clone whenever a class is
derived from Base should be part of the review checklist. So, yes, a
review would almost certainly have caught this error.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Apr 25, 5:58 pm, "Victor Bazarov" <[e-mail]:

Thomas J. Gritzan wrote:

[rob desbois] schrieb:

On Apr 25, 12:46 pm, Pete Becker <[e-mail]:
On 2008-04-25 06:40:20 -0400, "[rob desbois]"
<[e-mail]:
Hi all, I have a set of classes which implement the virtual
constructor idiom.
I had a slicing problem which resulted when I forgot to override
the clone() function in a derived class.
Is there something (other than documentation) that I can do to
prevent this from happening again?
Unit testing and code reviews.

Allow me to clarify. I meant is there any language
construct which can enforce this requirement.

A unit test wouldn't have helped -- I'd have had to
remember to write a unit test for the new class's clone()
method ensuring that the returned pointer is castable to a
pointer to the new derived type. If I'd have remembered
that I'd have remembered to code the clone method anyway.

"Design by Contract".

(That should be "Programming by Contract" here. It's a coding
issue, not a design issue.)

Something like (untestet):

class Base
{
public:
Base* clone() const
{
Base* p = doClone();
assert(typeid(*p) == typeid(*this));
return p;
}

private:
Base* doClone() const
{
return new Base(*this);
}
} ;

First off, no virtual functions here, did you mean to make
'doClone' virtual?

Obviously.

And second, he needed the compile-time solution, AIUI.

You take what you can get:-).

I think I'm the one who actually invented this technique, at
least with regards to using typeid for cloning. In practice,
however, I find that this particular bit of programming by
contract is simply not worth the extra work (although I tend to
use programming by contract fairly intensively in my work
otherwise). As Pete has said, failing to provide the clone
function is something that simply doesn't slip past code review
and unit tests.

And how does 'typeid' trick work? Does 'typeid' return the dynamic
type of '*this'?

It will if the static type is polymorphic.

So, if you derive from 'Base', what then? How does the
splitting of the function in two help _forcing_ the derived
class provide the override?

You get an assertion failure if you attempt to clone a class
which has not implemented the clone function.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Thomas J. Gritzan]

Victor Bazarov schrieb:

Thomas J. Gritzan wrote:

>[rob desbois] schrieb:

>>>>Hi all, I have a set of classes which implement the virtual
constructor idiom.
I had a slicing problem which resulted when I forgot to override
the clone() function in a derived class.
Is there something (other than documentation) that I can do to
prevent this from happening again?

"Design by Contract".

Something like (untestet):

class Base
{
public:
Base* clone() const
{
Base* p = doClone();
assert(typeid(*p) == typeid(*this));
return p;
}

private:
Base* doClone() const

virtual Base* doClone() const

> {
return new Base(*this);
}
}

;

First off, no virtual functions here, did you mean to make 'doClone'
virtual? And second, he needed the compile-time solution, AIUI.

First: Yes, I forgot the virtual. That's what code review is for :-)
Thanks for that.

Second, there is no compile-time solution for this. You can't force to
override a virtual function.

And how does 'typeid' trick work? Does 'typeid' return the dynamic
type of '*this'? So, if you derive from 'Base', what then? How
does the splitting of the function in two help _forcing_ the derived
class provide the override?

Having a polymorphic class (a class with virtual functions is
polymorphic), typeid(x) returns the dynamic type of x.

In the expression
assert(typeid(*p) == typeid(*this));

typeid(*this) returns the dynamic, run-time type of the current object,
typeid(*p) return the dynamic type of the new object. So, if the clone
doesn't have the exact same type as the current object, the
postcondition of the clone() method is violated.

--
Thomas

[Thomas J. Gritzan]

James Kanze schrieb:

On Apr 25, 5:58 pm, "Victor Bazarov" <[e-mail]:

>First off, no virtual functions here, did you mean to make
'doClone' virtual?

Obviously.

>And second, he needed the compile-time solution, AIUI.

You take what you can get:-).

I think I'm the one who actually invented this technique, at
least with regards to using typeid for cloning.

In fact, I've seen it used this way the first time in one of your postings.

In practice,
however, I find that this particular bit of programming by
contract is simply not worth the extra work (although I tend to
use programming by contract fairly intensively in my work
otherwise). As Pete has said, failing to provide the clone
function is something that simply doesn't slip past code review
and unit tests.

--
Thomas