Wait, you're not using the stack? ;)

Ok, back to serious mode - I'm working on small embedded stuff, and memory is either allocated statically or it's on the stack in the form of local variables. new/delete/malloc/free don't appear in my code, either.

Isn't an offer you can expect pretty close to market pricing?

IIRC, doing this will have undefined behavior. It may work the way you describe, or it may do anything else.

Depending on your platform, putting the check there might interfere with CPU load/latency constraints (and using a bigger CPU might interfere with power/cost constraints), while having the CPU just return zero as the result of division by zero can be handled later (when it doesn't interfere with CPU load/latency).

You can pick one of the two and make no promises about the other.

Or does "cross-platform" in this context mean "Linux+Windows"?

I assume by something like this:

((my_class *) (0))->somemethod();

As long as somemethod() doesn't try to access any class members, the code may even fail to show any obvious misbehavior.

If I wanted the programming language to be smarter than myself, I'd pick an appropriate language (not C++).

From a quick glance, smart pointers kind of look like local objects, but they're created on the heap instead of the stack, and whatever they point to automatically gets deleted when the smart pointer goes out of scope. Okay, that's not horribly smart. I could live with it.

I don't like the sound of that. I'm sticking with C and occasionaly bits of assembly.

Basically, only use a language feature if it provides a tangible benefit (making the code easier to understand and maintain almost always qualifies; making the code run faster qualifies if it's not running fast enough yet; "This is cool, let's try using it!" only ever qualifies in your own private projects).

If you're seeing any news, and no corresponding deletes, doesn't that mean the code leaks memory?

Easy. Just test a combination of various homeopathic agents, with one of them actually being a real drug (under a fancy homeopathic name) at high enough concentration to have an actual effect.

I have seen studies done this way. Always check the homeopathic medicine in question for barely diluted, real drugs.

a) The program needs to process bursts incoming data quickly and timely, and it is known that only nonzero output values are valid. The program combs through received data later, when there is time.

b) You need to feed an audio DAC or something, and outputting 0 will result in a barely noticable glitch, but missing several samples due to exception handling will produce a very noticable acoustic artefact.

Or maybe you have bursts of data coming in that needs to be processed in a timely manner (leaving no time for exeptions or even checks), followed by periods in which you can comb through the data packets and deal with cases of division by zero (e.g. if you know that the result is normally nonzero, any zeros showing up in your data indicate that these samples need to be handled separately).

It's all a matter of your application.