Kövesdi György schrieb:
2007. június 25. 12.59 dátummal Daniel Lohmann ezt írta:
1) I am not sure if I understand your problem. Can you give an exampel
for such an (automatically generated) destructore that implicitly calls
delete?
It is just a test class:
class valami
{
public:
valami();
virtual ~valami();
virtual void kiir();
int adat;
};
The source:
valami::~valami()
{
}
Those instances of destructors are generated:
00000142 <valami::~valami()>:
142: fc 01 movw r30, r24
144: 84 e0 ldi r24, 0x04 ; 4
146: 91 e0 ldi r25, 0x01 ; 1
148: 91 83 std Z+1, r25 ; 0x01
14a: 80 83 st Z, r24
14c: cf 01 movw r24, r30
14e: 0e 94 67 00 call 0xce <operator delete(void*)>
152: 08 95 ret
00000154 <valami::~valami()>:
154: fc 01 movw r30, r24
156: 84 e0 ldi r24, 0x04 ; 4
158: 91 e0 ldi r25, 0x01 ; 1
15a: 91 83 std Z+1, r25 ; 0x01
15c: 80 83 st Z, r24
15e: 08 95 ret
00000160 <valami::~valami()>:
160: fc 01 movw r30, r24
162: 84 e0 ldi r24, 0x04 ; 4
164: 91 e0 ldi r25, 0x01 ; 1
166: 91 83 std Z+1, r25 ; 0x01
168: 80 83 st Z, r24
16a: 08 95 ret
2) If they aren't necessary anyway, why don't you just provide your own
(empty) implementations of new and delete to avoid the inclusion of
whatever runtime library?
It is a solution, but it just increases the number of unnecessary function
calls. The number of constructors/destructors is discussed in an other
thread, it would be another optimization step. As far as I understand, the
different constructors/destructors are useful for different purposes. If I
avoid using the new() and delete() operators, I can save their space. It
would be useful to disable the corresponding constructors/destructors in this
case.
1) Do you actually need your destructors to be virtual? As you do not use
the heap you most probably do not destroy polymorphic instances. Hence,
virtual destructors are not necessary. (There is a switch to suppress the
annoying warning that newer gcc versions issue in case of a non-virtual
destructor.)
Especially on the AVR platform virtual function induce a significant
overhead. You should try to avoid them as far as possible. On the caller
side, each call to a virtual function requires (compared to an inlined
function) at least 16 additional byte (text). On the callee side, virtual
function tables have to be provided (4 byte + 2 byte per entry, data),
object instances need to carry a pointer to the
virtual function table (2 byte per instance, data), and even if otherwise
not needed constructors have to be generated to initialize the vtable
pointer of an instance have to be generated (at least 24 byte per class, text).
2) If they are not virtual, unused variants of the destructor should go
away by means of function-level linking (on gcc by compiling with
-ffunction-sections and linking with --gc-sections).
Daniel
