Re: Implicitly defined functions properties
On 9 Apr., 21:21, Olivier Langlois <olangl...@sympatico.ca> wrote:
Thank you everyone for your explanations. I have a better
understanding of this aspect of C++ but there still a detail that I am
not sure. I have written a small test program to observe what the
compiler is doing:
Be warned, that debugger information and further compiler-specific
diagnostics do *not* belong what is usually called observable
behavior. I want to add this remark, because you should not
come to false conclusions given your experiment.
C.h:
class C
{
public:
C() : a(0), b(0), c(0), d(0), e(0) {}
// virtual ~C() {}
private:
int a;
int b;
int c;
int d;
int e;
};
f.cpp:
#include "C.h"
C f()
{
C a;
C b = a;
return b;
}
g.cpp:
#include "C.h"
C g()
{
C a;
C b = a;
return b;
}
main.cpp:
#include "C.h"
C f();
C g();
int main(int argc, char *argv[])
{
f();
g();
return 0;
}
g++ -c f.cpp
nm -a -C f.o
00000000 t
00000000 d
00000000 b
00000000 t
00000000 n
00000000 n
00000000 a f.cpp
00000000 T f()
00000000 W C::C()
No sign of the copy constructor. I am guessing that the compiler make
the copy constructor inline because it is trivial.
According to the standard the implicit copy constructor *is*
always inline, see [class.copy]/5:
"[..] An implicitly-declared copy constructor is an inline public
member of its class."
Please note that your interpretation is not exactly
right. The c'tor *is* inline, but inline is just a
hint. On the other side, even, if you would have provided
a (non-trivial) definition of the copy c'tor, the compiler
would have been allowed to "eliminate" it under given
circumstances (listed in [class.copy]/15).
I am adding a
virtual destructor to make the copy constructor non-trivial:
00000000 T f()
U operator delete(void*)
00000000 W C::C(C const&)
00000000 W C::C()
00000000 W C::~C()
00000000 W C::~C()
00000000 V typeinfo for C
00000000 V typeinfo name for C
00000000 V vtable for C
U vtable for __cxxabiv1::__class_type_info
Now g.o and f.o have a copy of C copy constructor and the linker will
link fine and only one copy of the function will find its way in the
final executable file. How comes the compiler is exempted from its own
ODR rule. If I try to link 2 object files containing the same
function, the linker complains about the duplicated symbols!
Although the copy c'tor is non-trivial in this case, it
is inline and it is the compiler's job to ensure that no
violation of the ODR occurs, provided that the programmer
did follow the rules of the standard. You did so in this
example[1], so everything is fine.
We had an interesting discussion concerning linkage of
c'tors in this thread and my current view is still, that
there is no need to define linkage for these things,
provided all remaining rules are complete. In case of the
ODR rule, I think that the current wording is incomplete,
if my assumption is correct that linkage is not defined
for c'tors and d'tors. [basic.def.odr]/5 says:
"There can be more than one definition of a class type
(clause 9), enumeration type (7.2), inline function with
external linkage (7.1.2), class template (clause 14),
non-static function template (14.5.5), static data member
of a class template (14.5.1.3), member function of a class
template (14.5.1.1), or template specialization for which
some template parameters are not specified (14.7, 14.5.4)
in a program provided that each definition appears in a
different translation unit, and provided the definitions
satisfy the following requirements.[..]"
The part, which I want to point the focus on, is
"inline function with external linkage", which does
include member functions. If linkage of c'tors and d'tors
is not defined, it seems that this paragraph would not
hold for these entities. Some bullets would indirectly
refer to at least the c'tors, but e.g. the very first
bullet "each definition of D shall consist of the same
sequence of tokens; and [..]" would not be applicable
to them, which seems wrong. E.g. it seems to allow the
following program (and have a special look on what is
marked with [1] and [2]):
-----------------------
// c.h:
struct C {
int i;
inline ~C();
};
// a.h:
#include <c.h>
extern C ca;
// a.cpp:
#include <a.h>
#include <iostream>
inline C::~C() {
std::cout << i << std::endl; // [1]
}
C ca;
// b.h:
#include <c.h>
extern C cb;
// b.cpp:
#include <c.h>
#include <iostream>
inline C::~C() {
i *= -1; //[2]
std::cout << i << std::endl;
}
C cb;
// main.cpp
#include <a.h>
#include <b.h>
int main() {
ca.i = cb.i = 42;
}
-----------------------
IMO we have all required conditions of the
ODR: The d'tors are *used* according to
[basic.def.odr]/2 and 12.4 (by reference),
and p. 3: "An inline function shall be defined in
every translation unit in which it is used."
is also valid.
So the question arises: Shall we explicitly
define linkage for c'tors and d'tors or shall
we fix [basic.def.odr]/5? Actually it seems very
easy to fix the ODR. My proposal is to replace
"inline function with external linkage (7.1.2)"
by
"inline function with external linkage, inline
constructor or inline destructor (7.1.2)"
Any comments?
Greetings from Bremen,
Daniel Kr?gler
[1] E.g. you did not violate 3.2-[basic.def.odr]/5, 5th
bullet:
"if D is a class with an implicitly-declared constructor
(12.1), it is as if the constructor was implicitly defined
in every translation unit where it is used, and the implicit
definition in every translation unit shall call the same
constructor for a base class or a class member of D."
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]