0000340: std::runtime_error not derived from std::exception

BusyBox Bug and Patch Tracking

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000340

[uClibc++] Documentation

minor

always

07-12-05 13:05

08-02-05 20:13

Reporter

tommi

View Status

public

Assigned To

gkajmowi

Priority

normal

Resolution

fixed

Status

closed

Product Version

0.1.11

Summary

0000340: std::runtime_error not derived from std::exception

Description

std::runtime_error needs to be derived from std::exception. This change follows the need to specify a throw-specifier in ~runtime_error.

By the way: is it better not to declare a virtual do-nothing-destructor at all or decleare it inline like in std::range_error or define it it the cpp-file like std::runtime_error? I feel, that removing the destructors might be best. Then the virtual table points to the destructor of the base-class std::exception and no code needs to be generated for derived destructors.

Additional Information

Attached Files

stdexcept.diff [^] (1,476 bytes) 07-12-05 13:05

Relationships

Notes
(0000289) gkajmowi 07-12-05 15:53	Fixed in SVN. As to your question, We always need a virtual destructor. If we don't create one, one will most likely be created for us. If the destructor doesn't do anything additional then I almost always inline it - the compiler will inline it out. If the destructor does something then I try and put it into the library to save a lot of space. In the end, compile and see what comes out smallest is probably your best bet.

Issue History
Date Modified	Username	Field	Change
07-12-05 13:05	tommi	New Issue
07-12-05 13:05	tommi	Status	new => assigned
07-12-05 13:05	tommi	Assigned To	=> gkajmowi
07-12-05 13:05	tommi	File Added: stdexcept.diff
07-12-05 15:53	gkajmowi	Status	assigned => resolved
07-12-05 15:53	gkajmowi	Fixed in Version	=> 0.1.12
07-12-05 15:53	gkajmowi	Resolution	open => fixed
07-12-05 15:53	gkajmowi	Note Added: 0000289
08-02-05 20:13	andersen	Status	resolved => closed