1

I'm developing a bare-metal C++ program for Texas Instruments' TMS320F28054M MCU, and am building my project with the TMS320C2000 C/C++ Compiler v20.2.2.LTS. I've noticed that whenever I instantiate a class with a virtual destructor, the toolchain automatically generates an 1KB .esysmem section for the heap. This is strange, since I'm not actually using dynamic memory at all; in fact, this happens even when creating a variable on the stack.

Is this a compiler bug? I'm not that familiar with the innerworkings of virtual destructors, so maybe it's something to be expected.

trincot
  • 317,000
  • 35
  • 244
  • 286
Martin
  • 940
  • 6
  • 26
  • 1
    Related: https://stackoverflow.com/questions/28909598/eliminating-instantiation-of-useless-destructor-calls That happened even for non virtual constructors, when I investigated about it. – πάντα ῥεῖ Sep 06 '20 at 08:24
  • What happens for virtual destructors for sure, is that a vtable will be created for the class. I can't tell how your compiler(linker) handles the auto generation of vtables. – πάντα ῥεῖ Sep 06 '20 at 08:31
  • @πάνταῥεῖ yes, but that question is for gcc. Notice that this happens even when creating a variable on the stack; using a static/global variable would also generate the usual __dtors code. vtables aren't a problem, since this heap section isn't generated when I remove the virtual destructor, even if I have virtual functions, etc. – Martin Sep 06 '20 at 08:43
  • Well, legacy compilers might happen to handle that even worse than gcc does. – πάντα ῥεῖ Sep 06 '20 at 08:48
  • 1
    Whole point of those virtual destructors is to handle *deleteing* of dynamically allocated objects through pointer of base class. IOW if you do not use dynamic memory then why you need virtual destructors? – Öö Tiib Sep 06 '20 at 09:27
  • @ÖöTiib why do you care? One of C++'s philosophies is "you don't pay for what you don't use". – Martin Sep 06 '20 at 21:28
  • @Martin In an embedded context, the C++ philosophy is rather "pay in advance regardless of what you plan to use". The C++ static storage duration constructor lag at start up is a typical example of C++ creating needless overhead bloat. And then the CRT likes to run that bloat before the oscillator is initialized, turning your program slower than anything... – Lundin Sep 07 '20 at 06:56
  • @martin correct we don't pay for what we don't use. So my question was why you use virtual destructors or why you dislike to pay for what you use pointlessly? – Öö Tiib Sep 12 '20 at 07:11
  • @ÖöTiib I wasn't _using_ the virtual destructors, since at no point did I use dynamic memory in the first place. Defining something isn't the same as using it. In this case, I had introduced the virtual destructor in the first place because it's an usual practice forced by design mistakes in the language. – Martin Jan 11 '22 at 10:20
  • @Martin How it is forced and by what mistake? When no object is ever created dynamically then destructors being virtual is waste. Even when there *are* dynamically created objects but none of those is deleted through pointer to base it is waste. And even when some *might* be deleted through pointer to base but each of such was created with make_shared then it is waste. Modern compilers aren't very frugal as memory is available 2GB per dollar ... so if economy matters then programmer has to pay attention. – Öö Tiib Jan 11 '22 at 12:25
  • @ÖöTiib are you serious? Being forced to manually add virtual destructors to make the language do the right thing is clearly a design mistake. 99% of the time you will need them, so they should be implicitly added whenever you have a virtual method. Maybe they're "a waste" in that 1% of the time, but then why isn't the compiler smart enough not to generate a gratuitous heap section? This didn't happen when adding e.g. virtual methods, only for the destructor, so it's not like it's an impossible feat. – Martin Jan 12 '22 at 13:11
  • @Martin I'm fully serious. Why I need virtual destructors? Where are dynamically allocated polymorphic objects in my C++ program (if it contains any)? All coding standards demand RAII so these are managed by standard smart pointers or managed by likes of boost::base_collection. It is rather tricky to cooperate with anyone if I don't use RAII. So if I supply deleters properly to unique_ptr's then I do not need any virtual destructors. Can you describe cases where I still need? Why? – Öö Tiib Jan 12 '22 at 16:43

0 Answers0