On Fri, Mar 1, 2024 at 12:50 PM, Jan Schultke wrote:
> Furthermore, wouldn't it make more sense to specify exception_ptr in
> more detail? Perhaps we could get away with specifying it as a class
> type that has a "type_info()" member function. That seems more
> reasonable than a separate free function, if this mechanic is 100%
> tied to exception_ptr anyway.
I'd be in favour of this so long as it's not an ABI break. But also it
would mean that "exception_ptr" can't be something as simple as a
typedef for "shared_ptr<void>".
Yes, FWIW, P2927 shied away from trying to add member functions to exception_ptr, precisely because we figured there must be a reason it's not defined as a class type today. Off the top of my head I'm not sure if it's allowed to be a type alias for `shared_ptr<void>`, but if it is allowed, then that would be a good reason "adding a member function" isn't trivial.
I'm not aware of any vendors that make `exception_ptr` anything but a plain old class named `exception_ptr`. I'd wholeheartedly support a paper to just define it that way in the Standard, if anyone's interested in bringing one.
On Fri, Mar 1, 2024 at 12:58 PM, Matthew Taylor wrote:
> Also, while I'm not against the core idea I'm not entirely convinced by your motivation.
On Fri, Mar 1, 2024 at 4:41 PM, Arthur O'Dwyer wrote:
> - What is the motivation for this facility? It doesn't seem useful to get a typeid, because you can't do anything with a typeid.
Let's say I write a program, something big along the lines of Autodesk
Maya for making 3D models, and let's say I allow the user to load
3rd-party plugins at runtime. So I use 'dlopen' at runtime to load one
of these plugins, and I don't know until runtime that the plugin is
called 'FieryShadow'. An exception is thrown from somewhere, and I can
at least see the type's name:
The plugin should throw an exception derived from std::exception. Then you can catch it:
} catch (const std::exception& pluginEx) {
and just ask it for all its stuff:
puts(pluginEx.what()); // prints something like "FieryShadow: access out of bounds" or whatever
const auto& ti = typeid(pluginEx); // gives you the type_info for FieryShadowError or whatever its dynamic type is
If the plugin is throwing random stuff that's not derived from std::exception, then
- The plugin has a bug; get them to fix it.
- All bets are off, anyway. They might be throwing `int`, or `std::optional<std::string>`, or `std::nullptr_t` — you have no idea.
When it comes to logging exceptions when debugging (or even in release
builds), I would like if we could get a raw pointer to the exception
object along with the size of the exception object, so that we can
print its hex bytes
You can get a raw pointer to the first byte of the most-derived object via `dynamic_cast<void*>(&pluginEx)`.
Unfortunately I don't think you can get the size of the most-derived object in any way; all you know for sure is that it's no smaller than sizeof(pluginEx).
–Arthur