Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type (and the generic one should suffice).
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type (and the generic one should suffice).
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type (and the generic one should suffice).
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type (and the generic one should suffice).
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type.
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type (and the generic one should suffice).
Note: Personal opinions done matter. Just voicing them.
Personally I don't like (runtime) asserts (checks that disappear in production just asking for trouble and if something goes wrong you can't reproduce it in debug mode now). But OK its better than no checks.
Personally I don't like hiding throwing exceptions inside macros.
All the work you do to build the exception could be done inside the exception constructor.
I have not seen multiple inheritance in exceptions before. But then again I have not used boost::exception so that may be normal. But I don't see the need for virtual inheritance as they don't have a common root base (as they are both base classes). What does your catch look like that you need to inherit from both?
You are obviously trying to have zero cost when asserts are disabled, yet you are using the function: void print_diagnostic_info(std::ostream& o, EXCEPTION const& e). To be consistent with your other usage why is this not a macro (god I hate saying that since I hate using macros as function calls when we have template functions to solve that problem, but I think this is a unique type of situation where we are explicitly trying for zero overhead when asserts are disabled).
No point in this:
#else
#define PROJECT_ASSERT(expr) do {} while(false)
#endif
// Just do this:
#else
#define PROJECT_ASSERT(expr)
#endif
Is there any point in this:
struct BaseError : virtual boost::exception, virtual std::exception {};
struct FatalError : BaseError {};
struct AssertionError : FatalError {};
The only reason to have an exception hierarchy is if there is the ability to catch and explicitly recover from particular types of error. As this is an assertion you (by definition) can't recover so there is only the need for one exception type.