On Mon, January 22, 2007 17:11, Marcel Loose wrote: > Hmm, for some weird reason I did not get this message by email, so I > copied/pasted it from the web page.
That may be because I'm with a state-owned Internet provider that regularly changes its subscribers' IP addresses *and* fails to check for outgoing spam (it does censor Internet traffic, but things that are actually harmful are not filtered out). A few days ago I got assigned a new IP address that seems to be on spam blacklists. I'm actually logging into webmail halfway across the world, but unfortunately the client lists the http client's address in the mail header so the blacklists still pick up on it. > Jeroen, I would think twice before walking the path of multiple > inheritance. This will sooner or later cause disaster, especially > because your exception classes keep state (i.e. have data members). I > understand you're willing to adhere to the C++ standard hierarchy. The > thing is that the interpretation of what represents a logic_error and > what a runtime_error depends on point of view. I don't think I'm following you. What's the problem with having data members in exception classes with multiple bases? The extra class would be just an empty mixin--all it needs is a vtable so that RTTI can tell the difference between a libpqxx-specific exception class and any other class. IIRC the construct would even be eligible for the "empty base class" optimization if the mixin comes first in the list of base classes. Not that this is a good place to concentrate on optimization, of course. Nor do I see how the difference between a logic_error and a runtime_error affects any of this. An interesting problem, certainly, but where does it tie in to the question of distinguishing libpqxx-specific exceptions? Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
