Shop OBEX P1 Docs P2 Docs Learn Events
Unused methods are increasing code size — Parallax Forums

Unused methods are increasing code size

DavidZemonDavidZemon Posts: 2,973
edited 2014-10-09 12:57 in Propeller 1
I'm looking for a way to add printf support to PropWare's UART classes, but I certainly don't want it to balloon the code size when they aren't being used. In my latest commit I added printf support to abstractsimplexuart.h as well as a new CMake option called "AUTO_CUT_SECTIONS" which simply adds the "-ffunction-sections -fdata-sections" and "--gc-sections".

Without changing the code in the Duplex demo, size increased by ~1kB (based on the size reported by propeller-load which, though not accurate, is good enough for comparison's sake right?).

Anyone have ideas on why these unused functions aren't being deleted?

Thanks,
David

Comments

  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-04 08:58
    Removing the virtual keyword from each of the methods seems to have done the trick. I don't understand why though. Anyone understand why and care to explain?
  • David BetzDavid Betz Posts: 14,516
    edited 2014-10-04 09:00
    SwimDude0614 wrote: »
    Removing the virtual keyword from each of the methods seems to have done the trick. I don't understand why though. Anyone understand why and care to explain?
    I suspect that virtual methods are always referenced by the vtable whether or not your code actually references them.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-04 09:48
    After much searching, there appears to be no way to prune unused virtual methods :(
    There used to be an option "-fvtable-gc" but it reportedly didn't work and was removed. I tried "-fwhole-program" too and though it helped in other regards, it didn't help remove the unused virtual methods.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-04 09:56
    As much as I'd like to keep PropWare::UART as a purely abstract base class, I've chosen to move the formatted print method implementations into it so that they do not need to be virtual and can still be called by all subclasses. I think this is the least-bad compromise between form and function here.
  • Heater.Heater. Posts: 21,230
    edited 2014-10-04 10:05
    The question might be: Why put print formatting functionality into a UART class?

    Separation of concerns would suggest that a UART class does UART things and a formatted printing class does formatting things.

    That way both functionalities can be used independently and neither bloats the other.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-04 10:52
    Heater. wrote: »
    The question might be: Why put print formatting functionality into a UART class?

    Separation of concerns would suggest that a UART class does UART things and a formatted printing class does formatting things.

    That way both functionalities can be used independently and neither bloats the other.

    I'm 100% with you on that. But the next best option is way more difficult: using C++'s stream functionality. Never done it before. Any idea if it would make code size bloat up significantly?

    _Edit_
    Nevermind. Maybe you're right about creating a wrapper class that contains an instance of UART and has all of the formatted printing functionality. Hmm......
  • Heater.Heater. Posts: 21,230
    edited 2014-10-09 05:42
    I would stay away from C++ streams. I have a feeling that will drag in a load of bloat.

    In the C world we would just gave functions for formatted printing that get their actual output device from a function pointer. You can redirect output to different places by initialising them with different output functions.

    I guess in C++ you might want to do this by passing a output device object into the constructor of you printing class.

    Hmm...thinks...perhaps that what you said above:)
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-09 12:57
    Heater. wrote: »
    I would stay away from C++ streams. I have a feeling that will drag in a load of bloat.

    In the C world we would just gave functions for formatted printing that get their actual output device from a function pointer. You can redirect output to different places by initialising them with different output functions.

    I guess in C++ you might want to do this by passing a output device object into the constructor of you printing class.

    Hmm...thinks...perhaps that what you said above:)

    Yep, that's exactly what I ended up doing. I created a PrintCapable interface that UART inherits from and a Printer class that takes a PrintCapable in the constructor. It will allow you to very easily use any communication protocol you want with the printf method - the same way the Simple libraries use text_t structs. I also created an instance of a UART and a Printer in printer.cpp so that the user can just call "pwOut.printf" from their code without having to instantiate any instances of their own. I think PropWare is really coming along nicely :D

    Now if only I could get synchronous printing to work :frown:
Sign In or Register to comment.