This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
RE: Use of strings in new exception implementation (report libstd c++/1972)
- To: "'libstdc++ at gcc dot gnu dot org'" <libstdc++ at gcc dot gnu dot org>, "'ncm at cantrip dot org'" <ncm at cantrip dot org>
- Subject: RE: Use of strings in new exception implementation (report libstd c++/1972)
- From: Greg Bumgardner <bumgard at roguewave dot com>
- Date: Wed, 14 Feb 2001 22:27:22 -0800
Then I guess it follows that the member used to store the what-arg string
(in logic_error and runtime_error) must itself support assignment, so using
std::string is probably the easiest and most obvious way to do it.
-g.b.
> -----Original Message-----
> From: Nathan Myers [mailto:ncm@nospam.cantrip.org]
> Sent: Wednesday, February 14, 2001 7:11 PM
> To: libstdc++@gcc.gnu.org
> Subject: Re: Use of strings in new exception implementation (report
> libstd c++/1972)
>
>
> On Wed, Feb 14, 2001 at 04:30:08PM -0800, Greg Bumgardner wrote:
> > I'm also curious about the handling of assignment
> operators. The standard
> > shows that exception has an assignment operator, even
> though it has nothing
> > to assign, but none of the derived classes have them. If
> we don't design
> > these classes to correctly support assignment, then the
> operator should
> > probably be declared private.
>
> The standard mentions assignment and copy ctor when it has something
> to say about their semantics. The assumption (as documented in
> chapter 17) is that if you do something under the hood that would
> make the compiler-generated version do the wrong thing, it's your
> responsibility (as implementor) to cover up by defining one that
> works right.
>
> Nathan Myers
> ncm at cantrip dot org
>