Comments on: When to provide an empty destructor https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/ Boris Kolpackov's blog about software Sat, 28 Oct 2023 17:47:34 +0000 http://wordpress.org/?v=2.2.2 By: Andrea https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1968 Andrea Mon, 09 Apr 2012 16:53:30 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1968 Ok, that makes sense now. Thanks for your clarification Ok, that makes sense now. Thanks for your clarification

]]> By: Boris Kolpackov https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1963 Boris Kolpackov Sun, 08 Apr 2012 08:22:22 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1963 Andrea, I am not comparing this to the case where the constructor calls are actually inlined. Instead, I am comparing it to the case were we provide our own, non-inline empty definition. In this case we will only have one instance of the function in one object file. Andrea, I am not comparing this to the case where the constructor calls are actually inlined. Instead, I am comparing it to the case were we provide our own, non-inline empty definition. In this case we will only have one instance of the function in one object file.

]]> By: Andrea https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1960 Andrea Fri, 06 Apr 2012 21:48:29 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1960 Boris, thanks for your explanation, but I think I'm still missing the point. As you say, for the first approach (which I agree: is what most of the mainstream compiler follow) "... then it instantiates the function in every translation unit that calls it ...". So why is this worse than the case where destructor calls were actually inlined? If destructor calls are really inlined, their code is expanded at _every_ call site, even in the same TU. In the first approach that you describe, they're expanded _once_ in every TU that calls it. Sorry to insist, but I think I'm missing what you're trying to say and since I'm really interested in this subject I'd reallly like to fully understand... Thanks, Andrea. Boris, thanks for your explanation, but I think I’m still missing the point. As you say, for the first approach (which I agree: is what most of the mainstream compiler follow) “… then it instantiates the function in every translation unit that calls it …”. So why is this worse than the case where destructor calls were actually inlined? If destructor calls are really inlined, their code is expanded at _every_ call site, even in the same TU. In the first approach that you describe, they’re expanded _once_ in every TU that calls it. Sorry to insist, but I think I’m missing what you’re trying to say and since I’m really interested in this subject I’d reallly like to fully understand…
Thanks,
Andrea.

]]> By: Boris Kolpackov https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1959 Boris Kolpackov Thu, 05 Apr 2012 10:41:12 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1959 Andrea, when a compiler decides not to inline a function, then it must "instantiate" this function as if it was non-inline. Or, in other words, as you said, the compiler will generate a call instruction to the function but this function that is being called must be created somehow (i.e., it must end up in the program text). The way this is done depends on the implementation but generally there are two methods. If the compiler uses the first approach, then it instantiates the function in every translation unit that calls it and then weeds out duplicates at the link stage. With the second approach the compiler maintains some sort of a code database. When it compiles the first translation unit that calls our function, it instantiates this function and then adds it to this database. When another translation unit calls the same function, the compiler checks the database and sees that it has already been instantiated. Most popular C++ compilers (e.g., GCC, VC++) use the first method, which can lead to the situation I described. Andrea, when a compiler decides not to inline a function, then it must “instantiate” this function as if it was non-inline. Or, in other words, as you said, the compiler will generate a call instruction to the function but this function that is being called must be created somehow (i.e., it must end up in the program text).

The way this is done depends on the implementation but generally there are two methods. If the compiler uses the first approach, then it instantiates the function in every translation unit that calls it and then weeds out duplicates at the link stage. With the second approach the compiler maintains some sort of a code database. When it compiles the first translation unit that calls our function, it instantiates this function and then adds it to this database. When another translation unit calls the same function, the compiler checks the database and sees that it has already been instantiated. Most popular C++ compilers (e.g., GCC, VC++) use the first method, which can lead to the situation I described.

]]> By: Andrea https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1958 Andrea Thu, 05 Apr 2012 08:17:19 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1958 Nice and interesting article. I got a bit confused on the "Class with non-virtual destructor case". I'm perfectly on track when you say "...However, chances are good a C++ compiler will not actually inline calls to such a destructor due to its complexity.", but then the following: "In this case, object files corresponding to translation units that call such a destructor may end up containing multiple instances of the destructor" got me lost. Isn't the case that if the compiler didn't inline calls to such destructors, the TU that call those destructors will only have a "call" (to be resolved by the linker) and not the whole copy of the destructor code in the generated object file? Am I mis-reading what you said? Thanks, Andrea. Nice and interesting article. I got a bit confused on the “Class with non-virtual destructor case”.
I’m perfectly on track when you say “…However, chances are good a C++ compiler will not actually inline calls to such a destructor due to its complexity.”, but then the following: “In this case, object files corresponding to translation units that call such a destructor may end up containing multiple instances of the destructor” got me lost.
Isn’t the case that if the compiler didn’t inline calls to such destructors, the TU that call those destructors will only have a “call” (to be resolved by the linker) and not the whole copy of the destructor code in the generated object file?
Am I mis-reading what you said?
Thanks,
Andrea.

]]> By: Boris Kolpackov https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1957 Boris Kolpackov Thu, 05 Apr 2012 06:56:39 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1957 Alex, it is not the shared_ptr declaration (actually, unique_ptr in my example) that the compiler cannot see. It is the object::impl declaration. C++ requires that the class should be complete when an instance of this class is freed using delete. In our case, if the object's destructor is inline, then when an instance of object is destroyed somewhere in user code, the inline destructor calls impl_'s destructor which in turn calls delete on a pointer to call object::impl, which is incomplete. Alex, it is not the shared_ptr declaration (actually, unique_ptr in my example) that the compiler cannot see. It is the object::impl declaration. C++ requires that the class should be complete when an instance of this class is freed using delete. In our case, if the object’s destructor is inline, then when an instance of object is destroyed somewhere in user code, the inline destructor calls impl_’s destructor which in turn calls delete on a pointer to call object::impl, which is incomplete.

]]> By: Alex Turner https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1956 Alex Turner Thu, 05 Apr 2012 06:27:08 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1956 I your pimpl example is a bit short on explanation. Why cannot the destructor see the shared_ptr declaration as that declaration is in the class declaration and so the template should be instantiated there? I your pimpl example is a bit short on explanation. Why cannot the destructor see the shared_ptr declaration as that declaration is in the class declaration and so the template should be instantiated there?

]]> By: Boris Kolpackov https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1955 Boris Kolpackov Wed, 04 Apr 2012 20:15:28 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1955 Gregory, yes, that makes sense if a compiler-provided destructor is trivial (which means there is nothing to call). Gregory, yes, that makes sense if a compiler-provided destructor is trivial (which means there is nothing to call).

]]> By: Gregory https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1954 Gregory Wed, 04 Apr 2012 18:42:35 +0000 https://codesynthesis.com/~boris/blog//2012/04/04/when-provide-empty-destructor/#comment-1954 I faced situations where MSVC++ would refuse to force inline a function returning an object with an empty destructor by value because it considered the object to be unwindable hence EH generated code went in the way of the optimizer see http://stackoverflow.com/a/2322314/216063 I faced situations where MSVC++ would refuse to force inline a function returning an object with an empty destructor by value because it considered the object to be unwindable hence EH generated code went in the way of the optimizer

see http://stackoverflow.com/a/2322314/216063

]]>