#define and empty functios: will the function be optimized out by the compiler?

Projects Programming
1

Currently, I have hardware serial through usb for programming and monitoring, and AltSoftSerial to speak to my bluetooth.

I've used some defines and #ifdef to handle the different possible bluetooth scenarios, so that btSerial might be of type AltSoftSerial, of type Serial, or an alias to Serial itself. (but I don't seem to be doing it correctly; the error from later using "btSerial.begin(9600)" is included in the code below

//if we are going to program by usb, we need a pin-based serial for the AT-09

//#define useSoftwareSerial
#define useAltSoftSerial

//if using hardwar serial and we want to talk back to the serial monitor for debugging

//#define 

//types we'll need

enum srlTyps {
  NONE, HARDWARE, SOFTSERIAL, ALTSOFTSERIAL
};


//sort out the consequences ofthat choice

#ifdef useSoftwareSerial

#include <SoftwareSerial.h>
//we want an softserial. Use the rx=D8 and TX=D9 for hardware ease
#define usingSoftSer
const srlTyps btTyp=SOFTSERIAL;
SoftwareSerial btSerial (8,9);

#elif useAltSoftSerial
//we want an altsoftserial. On nano, rx=D8 and TX=D9
#include <AltSoftSerial.h>
AltSoftSerial btSerial;
#define usingSoftSer
constant srlTyps btTyp=ALTSOFTSERIAL;


#else
//we wll use the hardware serial for AT-09
#define useHardSer
//make btSerial an alias for Serial, so that we don't have t fll the code with ifDefs
const HardwareSerial  * btSerial = &Serial;//but this is wrong: "cerror: request for member 'begin' in 'btSerial', which is of pointer type 'HardwareSerial*' (maybe you meant to use '->' ?)
   btSerial.begin(9600);"
constant srlTyps btTyp=HARDWARE;

#endif

So far, so good, and I can simply have

btSerial.println("some message or another")

without switches or #ifdef

I'd like to be able to do the same for a monSerial for the monitor so that I could use, for example,

monSerial.println("the status message")

.

That's easy enough if monasterial might be any of the three serial types. But if I don't want the monitor (once deployed on battery power instead of debugging my bench), and I define a class with empty functions for println(), write(), etc., would the compiler optimize the monserial.println() above clean out of the results?

For my particular application, speed is a non-issue (other than the energy use for additional time that the chip stays powered before sleep, but that should be negligible). It's more a matter of saving bytes of memory.

2

would the compiler optimize the monserial.println() above clean out of the results?

Yes.
The compiler is very good at getting rid of dead code...

3

I had hoped so, thank you.

I recall an article in Byte decades ago, when they were still comparing compilers with a primitive benchmark, and timing the results.

One compiler recognized that the entirety of the code was not used, and optimized the entire test out :slight_smile:

4

One compiler recognized that the entirety of the code was not used, and optimized the entire test out...

Yep. It's pretty common now. Don't use a simple empty loop (or for that matter, one with trivial calculations inside) to try to do a delay!

5

dochawk:
I had hoped so, thank you.

I recall an article in Byte decades ago, when they were still comparing compilers with a primitive benchmark, and timing the results.

One compiler recognized that the entirety of the code was not used, and optimized the entire test out :slight_smile:

WOW! You must be near as old as I am. I still have the first 12 issues of Byte, but tossed all the rest. About 100 lbs of paper!

Paul

6

I remember leafing through what I think was issue 1 at the Second West Coast Computer Faire when a friend managed to finagle his mother into taking us in Jr. High, so a few years less . . . :slight_smile:

I recall a project to add an external stack to your 8008, with the claim that that was the biggest difference from an 8080 (the 8008 had an internal 8 level stack--if you included the PC itself as a level . . .). I think it boasted that it "only" took 100 chips to achieve this . . .

7

dochawk:
I remember leafing through what I think was issue 1 at the Second West Coast Computer Faire when a friend managed to finagle his mother into taking us in Jr. High, so a few years less . . . :slight_smile:

I recall a project to add an external stack to your 8008, with the claim that that was the biggest difference from an 8080 (the 8008 had an internal 8 level stack--if you included the PC itself as a level . . .). I think it boasted that it "only" took 100 chips to achieve this . . .

I bet I saw you there! I was a data communications consultant with a company in Beaverton, Oregon. They sent me and a programmer. I was charged with developing a communications front-end processor for their Data General mini-computer systems that used interactive COBOL. I met a guy in a wheel chair, was his name Bell, that had developed several plug-in cards for the Apple II, including async and sync communications, and a clock board that could also use interrupts. That convinced me to use the Apple II as the basis of the FEP.

I also remember stepping over all the drunks sleeping on the sidewalks.

Sort of a small world!

Paul

8

I wouldn't have noticed the drunks at that age.

I remember that magazine article, being given a pass by someone leaving before I bought my own (wow! at that age, a $10 freebie i a big deal! "Here, save yourself some money!" he said), some game, presumably in basic, that asked for the random seed--and discovering it started the same way each time, buying some wire-wrap sockets for the 1802 computer I was building, the "stingy floppy" (way out of my budgets), a general sense of all, and, most of all, the speech synthesizer that ran off a parallel port: "My name is vo-trax. I can say an-y-thing.")