Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re: C++ is never the right tool (Score 1) 296 296

Once memory is allocated in an embedded system, it cannot be de-allocated.

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.

Comment: Re:Division Has A Meaning (Score 1) 1067 1067

Put the check there.

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).

Comment: Contradiction ... (Score 1) 296 296

The main reasons I have for this are the needs to manage memory usage and disk access at a very granular level and a desire to be cross-platform.

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

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

Comment: Re:Given how C++ is taught. (Score 0) 345 345

Why not?

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.

Comment: Re:Knowing when not to (Score 2) 345 345

Knowing when not to use templates, virtualization, [insert favorite c++ function here], etc.

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).

Comment: Re:Scientific worldview undermining own credibilit (Score 1) 668 668

Come back when you find a repeatable RCT of a homeopathic remedy that shows an effect better than placebo

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.

Comment: Re:I'm with you to some extent (Score 1) 1067 1067

Could you give an example of when x/0 can be safely treated as 0?

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.

Comment: Re:Infinity (Score 1) 1067 1067

Of course. Then do your check for zero before the division, if your latency requirements can handle it. If either option doesn't meet spec, then your specifications are where the "bug" is...

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.

There are never any bugs you haven't found yet.

Working...