C++: Brauchen Virtuelle Funktionen dynamischen Speicher? Alternativen?

[Niklas G. (erlkoenig)]

Hallo Forum,

ich versuche mit der gcc-arm Toolchain ein C++ Programm für den STM32F4 
zu kompilieren. Sobald ich jedoch eine Klasse mit virtuellen 
Member-Funktionen erstelle, gibt es einen Linkerfehler bezüglich SBRK, 
also des Syscalls für dynamische Speicherverwaltung. Liegt das wirklich 
an den virtuellen Funktionen? Die vtable ist doch im Endeffekt nur eine 
statische Tabelle aus Funktionspointern?
Da ich nicht vorhatte, dynamische Speicherverwaltung einzubauen, gibt es 
eine Möglichkeit, das zu umgehen? Manuell mit einer Tabelle aus 
Funktionspointern herumzubasteln ist etwas unelegant...

[(prx) A. K. (prx)]

Niklas Gürtler schrieb:

> Member-Funktionen erstelle, gibt es einen Linkerfehler bezüglich SBRK,
> also des Syscalls für dynamische Speicherverwaltung.

Definiere sbrk() als Dummy-Funktion, die auf einen Fehlschlag läuft. 
Möglicherweise ist es aber effektiver, die globalen new/delete 
Funktionen als Dummies zu definieren, damit der Speicherallokationskram 
komplett entfällt.

[Niklas G. (erlkoenig)]

So, hatte jetzt wieder Zeit mich damit nochmal zu beschäftigen und für 
den Fall, dass jemand das hier findet, meine Lösung:

Sobald das Programm eine rein virtuelle Funktion verwendet (also sowas 
wie: void send () = 0;)  wird der Code um ~80KB größer, und es gibt 
undefinierte Referenzen zu _sbrk, getpid, exit, etc. - die es auf einem 
Embedded System ohne OS nicht gibt. Auch wenn man die alle als leere 
Funktionen definiert hat man die 80KB Overhead. Die Verwendung eines OS 
dürfte es noch schlimmer machen, und vielleicht braucht man sonst auch 
gar keins.
Der Grund für das ganze ist folgendes: Rein virtuelle Funktionen zeigen 
per default auf die Funktion __cxa_pure_virtual, die eine Exception 
wirft, für den Fall, dass man es irgendwie (wilde casts oder so) doch 
geschafft hat, die Funktion aufzurufen. Der Code zum Behandeln von 
Exceptions ist dann groß und braucht _sbrk etc. Indem man 
__cxa_pure_virtual als Dummy-Funktion mit Endlosschleife definiert, 
vermeidet man den ganzen Exception-Kram, und kann immerhin mit einem 
Debugger dort unterbrechen um den Absturzgrund zu finden. zB so:

.weak __cxa_pure_virtual
__cxa_pure_virtual:
b __cxa_pure_virtual

[Johann L. (gjlayde)]

Und -fno-exceptions?

[Niklas G. (erlkoenig)]

Johann L. schrieb:
> Und -fno-exceptions?
Hatte ich schon die ganze Zeit an, bringt nix - wohl weil das ein 
Compiler-Flag ist, und der Library-Code, der __cxa_pure_virtual enthält, 
schon compiliert ist.