Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Throwing Exceptions Across DLL-Boundaries
25 views
Skip to first unread message
Bonita Montero
Mar 24, 2019, 2:52:49 AM3/24/19
to
Does anyone know how throwing exceptions across DLL-boundaries does
work? If all objects would store a pointer to a virtual-method-table
together with RTTI-information like objects which have virtual methods,
identifying the species of a thrown object would be very easy. But in
this case if we would have compiled two modules in two DLLs, the VMT-
and RTTI-information would be distinct for two logically identic
objects because there VMT- and RTTI-information would exist multiple
times in memory.
But classes for exceptions don't necessarily have to have virtual
methods and thereby no VMT- and RTTI-informations. So I assume that
when I throw an exception, the object thrown I throw would get handed
along with an additional pointer to a kind of RTTI-information. But in
this case we would have the same problem that with separately compiled
DLLs this information might be distinct. So is there any way to mark a
class external in a way that this RTTI-like information is stored only
once in either DLL?
work? If all objects would store a pointer to a virtual-method-table
together with RTTI-information like objects which have virtual methods,
identifying the species of a thrown object would be very easy. But in
this case if we would have compiled two modules in two DLLs, the VMT-
and RTTI-information would be distinct for two logically identic
objects because there VMT- and RTTI-information would exist multiple
times in memory.
But classes for exceptions don't necessarily have to have virtual
methods and thereby no VMT- and RTTI-informations. So I assume that
when I throw an exception, the object thrown I throw would get handed
along with an additional pointer to a kind of RTTI-information. But in
this case we would have the same problem that with separately compiled
DLLs this information might be distinct. So is there any way to mark a
class external in a way that this RTTI-like information is stored only
once in either DLL?
Alf P. Steinbach
Mar 24, 2019, 3:14:42 AM3/24/19
to
On 24.03.2019 07:52, Bonita Montero wrote:
> Does anyone know how throwing exceptions across DLL-boundaries does
> work?
It /can/ work if everything's compiled by the same compiler that
> Does anyone know how throwing exceptions across DLL-boundaries does
> work?
supports it.
But I wouldn't rely on it.
COM defines a scheme for return types that are translated to exceptions
by the caller. I think that's the way to go. Think of a call across a
DLL boundary as a sort of remote procedure call, with marshaling and
unmarshaling of arguments, results and exceptions.
- Alf
Bonita Montero
Mar 24, 2019, 4:01:14 AM3/24/19
to
I just made a test-project with Visual Studio / VC++. I assumed that
__declspec(dllimport) / __declspec(dllexport) could be attached to
classes themselfes so that the meta-information passed alongside with
a thrown object is stored only once and all references to this infor-
mation refer to this single location. But unfortunally __declspec(
dllimport) / __declspec(dllexport) could only be applied to objects
themselfes and not classes.
So this seems to be an imperfection of the C++-compilers which should
be fixed. Maybe a platform-independent solution for this issue would
be possible.
__declspec(dllimport) / __declspec(dllexport) could be attached to
classes themselfes so that the meta-information passed alongside with
a thrown object is stored only once and all references to this infor-
mation refer to this single location. But unfortunally __declspec(
dllimport) / __declspec(dllexport) could only be applied to objects
themselfes and not classes.
So this seems to be an imperfection of the C++-compilers which should
be fixed. Maybe a platform-independent solution for this issue would
be possible.
Marcel Mueller
Mar 24, 2019, 4:35:03 AM3/24/19
to
Am 24.03.19 um 07:52 schrieb Bonita Montero:
toolset, preferable in one build process to avoid minor differences, and
if all of them share the same runtime library instance, i.e. no static
linkage.
> If all objects would store a pointer to a virtual-method-table
> together with RTTI-information like objects which have virtual methods,
> identifying the species of a thrown object would be very easy. But in
> this case if we would have compiled two modules in two DLLs, the VMT-
> and RTTI-information would be distinct for two logically identic
> objects because there VMT- and RTTI-information would exist multiple
> times in memory.
That's no big deal if they are identical.
> But classes for exceptions don't necessarily have to have virtual
> methods and thereby no VMT- and RTTI-informations. So I assume that
> when I throw an exception, the object thrown I throw would get handed
> along with an additional pointer to a kind of RTTI-information. But in
> this case we would have the same problem that with separately compiled
> DLLs this information might be distinct.
If you violate the ODR everything could happen.
> So is there any way to mark a
> class external in a way that this RTTI-like information is stored only
> once in either DLL?
I have no idea how this is implemented, but it works. I already used
this in late 90's.
The only question that arises. When all DLL modules need to be from one
build process, why are there separate modules at all? So throwing across
DLL boundaries is of little use in most cases.
Marcel
> Does anyone know how throwing exceptions across DLL-boundaries does
> work?
It works if and only if all library modules are compiled with the same
> work?
toolset, preferable in one build process to avoid minor differences, and
if all of them share the same runtime library instance, i.e. no static
linkage.
> If all objects would store a pointer to a virtual-method-table
> together with RTTI-information like objects which have virtual methods,
> identifying the species of a thrown object would be very easy. But in
> this case if we would have compiled two modules in two DLLs, the VMT-
> and RTTI-information would be distinct for two logically identic
> objects because there VMT- and RTTI-information would exist multiple
> times in memory.
> But classes for exceptions don't necessarily have to have virtual
> methods and thereby no VMT- and RTTI-informations. So I assume that
> when I throw an exception, the object thrown I throw would get handed
> along with an additional pointer to a kind of RTTI-information. But in
> this case we would have the same problem that with separately compiled
> DLLs this information might be distinct.
> So is there any way to mark a
> class external in a way that this RTTI-like information is stored only
> once in either DLL?
this in late 90's.
The only question that arises. When all DLL modules need to be from one
build process, why are there separate modules at all? So throwing across
DLL boundaries is of little use in most cases.
Marcel
Bonita Montero
Mar 24, 2019, 4:52:26 AM3/24/19
to
No, I made a little mistake.
It works, see here (VC++-2017-project):
https://www112.zippyshare.com/v/pYhqhtAT/file.html
But I don't know why this works.
It works, see here (VC++-2017-project):
https://www112.zippyshare.com/v/pYhqhtAT/file.html
But I don't know why this works.
Paavo Helde
Mar 24, 2019, 7:55:04 AM3/24/19
to
On 24.03.2019 10:34, Marcel Mueller wrote:
> The only question that arises. When all DLL modules need to be from one
> build process, why are there separate modules at all?
One reason might be that the separate modules are used as optional
> The only question that arises. When all DLL modules need to be from one
> build process, why are there separate modules at all?
plugins which are not always installed or loaded.
Another is that a separate DLL might be needed for isolating an
offending third-party library which would cause linker errors or runtime
malfunctions if compiled directly into the main executable.
A third potential cause is that a single DLL might just become too large
to manage or too slow to recompile/relink.
I'm sure there are more.
0 new messages