Skip to main content
bistromat
bistromat
Associate
November 13, 2008
Question

C++ new/delete operators, exception handling

  • November 13, 2008
  • 1 reply
  • 703 views
Posted on November 13, 2008 at 21:20

C++ new/delete operators, exception handling

    This topic has been closed for replies.

    1 reply

    bistromat
    bistromatAuthor
    Associate
    May 17, 2011
    Posted on May 17, 2011 at 12:52

    Okay. Thanks to lanchon and the excellent eLua tutorial, I rolled my own dev environment based on g++, the lanchon/raisonance link scripts, OpenOCD, newlib, and eclipse. It works like a charm when nothing else (Anglia, RIDE, CodeSourcery) seemed to work out of the box. It was a royal f'in pain to set up but now it's done and working just fine.

    I moved to C++ for this project because I love the abstraction that OO provides, and discovered that I can create very clean, portable, easy-to-read code in this way. Great. But some of the features of C++ are, in short, enormous code space hogs, and I'm hoping one of you can tell me why.

    So say I have a program that compiles to 30K code space. If I add just one simple throw() to my code, I get a whopping 56K output. 26K of overhead for just one exception. Jesus H. Christ in a chicken basket. Not cool. I understand exception handling and stack unwinding and all that takes some space, but you can code the autopilot for the Space Shuttle in less than that. WTF? Is my linker script including some debug crap it doesn't need to, or is this (cringe) normal?

    The same thing applies if I use one simple new. Instant code bloat. I have a feeling it is due to the new/delete operators implementing new/delete using exceptions. I can use malloc()/free() with only a minimal increase in code size, so why is new/delete so much more bloated?

    Come to think of it, where is my new/delete defined? Seems to work fine, but where is it being implemented from? Newlib implements libc and should have nothing to do with new/delete, right?

    And one more thing, while I'm on a tear: using virtual functions cost me 3K of code space. I can't tell you why, but I'm using them anyway because they make my life so much easier. Screw vtable and function-pointer overhead, I could give a rip. I'm running the functions out of RAM anyway. Being able to overload objects dynamically is a huge benefit to readable, portable code. But, again, they cost me.

    Terms & ConditionsAccessibility statement