Re: Should the assignment of an exception class call std::exception::operator=?
Should the assignment operator of a custom exception class derived
from std::exception, do an std::exception assignment?
Alberto Ganesh Barbati replied:
Any derived class implementing operator= should call the inherited
operator= in a way or another. It's not a matter of style, omitting
to do so would produce incorrect results.
I don't think that's true for /any/ derived class. For instance if its base
class doesn't contain any data...
class MyException : public std::exception
{
public:
MyException & operator=(const MyException & arg)
{
// Good Coding Style?
static_cast<std::exception &>(*this) = arg;
return *this;
}
};
Alberto wrote:
A better syntax avoiding the cast would be:
std::exception::operator=(arg);
but it's known to confuse some older compilers, especially when the
base class does not define operator= explicitly.
Okay, thanks!
I'm asking because there's a bug in the std::exception::operator=
implementation I'm currently using, as reported by Jouni Kiviniemi at
connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=328570
Actually my problem isn't just the memory leak reported by Jouni Kiviniemi. I
still need to support MSVC 2003, which has a slightly different problem, as I
just posted at microsoft.public.vc.language: "VC7.1 std::exception assignment
operator bug (crash) a known issue?"
http://groups.google.com/group/microsoft.public.vc.language/browse_thread/thread/92d84b7d568f7033
You are facing a lost battle. If you don't call the base operator= the
code will produce the wrong result, because you won't be copying the
string to the target object. Yet, if you do call operator= you have a
memory leak...
Well... my example class, MyException, was overly simplified. The actual class
I was working on, itk::ExceptionObject, has its own string data, and overrides
the what() function. Feel free to take a look:
www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkExceptionObject.h?root=Insight&view=markup
www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkExceptionObject.cxx?root=Insight&view=markup
Given that this is a bug Microsoft should fix, the only workaround is
to avoid calling std::exception::operator=. For example:
class MyException : public std::exception
{
public:
MyException & operator=(const MyException & arg)
{
if (this != arg)
{
// This is only to work around a bug in the base class
// NOT a generally valid approach to assignment
this->~MyException();
new(this) MyException(arg.what());
}
return *this;
}
};
Thanks! Please note that you assume that std::exception has a constructor that
accepts a char pointer. Which is a Microsoft specific extension. But still,
I wonder if I can't just get away with skipping the std::exception assignment,
and only copy the derived exception data... Let's forget about compiler
issues for a moment. Why would a custom exception class need to do an
std::exception assignment in the first place? The current Working Draft
(www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2606.pdf) specifies
std::exception's assignment as follows [exception]:
exception& operator=(const exception&) throw();
Effects: Copies an exception object.
Remarks: The effects of calling what() after assignment are
implementation-defined.
What does it mean to copy an std::exception object? std::exception isn't
specified to have any data. It does not even seem to be EqualityComparable.
(Please correct me if I'm wrong! It doesn't have any comparison operator,
right?) So what difference does it make, assigning or not?
Kind regards,
Niels
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]