"James Kanze" <james.ka...@gmail.com> wrote in message
news:e787b266-b834-4cb9-8adb-860270958060@u26g2000yqu.googlegroups.com...
On Jun 21, 1:54 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:VqSdnUMbWKmfwoLRnZ2dnUVZ8oqdnZ2d@giganews.com...
Your function template is preferable to what the OP
suggests yes (yours is not a hack), however it might be
desirable to use destructors and constructors if for some
reason you don't want to write assignment operators for
the class and its members, although I cannot really think
of a good reason for not writing assignment operators if
I'm honest.
The only reason I can think of for not wanting to write an
assignment operator is if the compiler generated one is
sufficient in which case assignment to a default
constructed object is sufficient for resetting anyway.
I'm not sure I've understood what you're saying correctly,
because I'm pretty sure you know this, but there are lots of
reasons why a class might not want to support assignment:
most polymorphic classes shouldn't, and of course,
singletons won't.
I was not thinking and/or expressing myself clearly, my reply
else-thread: "I agree, what you said is more or less what
I was fishing for: of course an assignment operator is not
always suitable for a given type and writing one just to
support "resetting" it can be both tedious and present
a confusing interface compared to just employing the OP's
hack, however instead of employing the hack the addition of
a reset() function is more appropriate IMO."
Exactly. If a class supports "reset", then it should have
a reset function. Inversely, if it doesn't have a reset
function, we should assume that it doesn't support reset.
Trying to hack it some other way just doesn't cut it. You can't