I predict that settlements on Mars will be connected by trains instead of fancy hyperloops. Simple, proven technology (electrically powered), and it's easy to expand the system and add more stops if necessary.
Public transportation need to be reliable and on time first, and affordable second. I don't care whether the ride is free if I wind up wasting 30-60 minutes due to delays once every ten rides.
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.
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).
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.
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).
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.
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.
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).
Fix your damn program to check for a dividend of zero, or at least trap the exception and handle it then.
If you have the CPU cycles for this, it is the better option. Depending on the application, you may not have this luxury (really low latency signal processing where trapping an exception will break the real-time behavior of the system).
It is not trivial, and in real world situations could be deadly.
Not ignoring the problem could be deadly, too, or at least very costly. It all depends on the application.
Why do you think ARM put a mode in their CPUs where they just return zero on a division by zero? Does ARM leave their CPU design to idiots? I don't think so.
Would you prefer the subroutine to report the speed as 0
Yes. Because other parts of the cruise control algorithm can recognize a speed of zero as a point where the cruise control should not be operating at all and disengage it.
The other options would be:
Report an arbitrary value. This leads to horrible results as the arbitrary value may be below the set speed, but still in a range where the cruise control operates.
Report the maximum value. This may lead to funny results if the programmer did not pay close attention to signed/unsigned datatypes.
Do random stuff, crash, require restart before cruise control can be re-engaged: This doesn't immediately lead to horrible results, but to lots of unhappy customers wondering why their car needs resets/power cycling like their Windows computer does.
Slashdot Mirror
I predict that settlements on Mars will be connected by trains instead of fancy hyperloops. Simple, proven technology (electrically powered), and it's easy to expand the system and add more stops if necessary.
Though, I suppose if you're a millionaire, you can afforde the tax advisors that sort things out for you.
Public transportation need to be reliable and on time first, and affordable second. I don't care whether the ride is free if I wind up wasting 30-60 minutes due to delays once every ten rides.
Also, it's no good airplanes. Do you really want to be on the receiving end of an acute case of motion sickness?
Project Pluto was supposed to be used on Earth. You know, if the Americans can't have it, then at least the commies wouldn't have it, either.
https://en.wikipedia.org/wiki/...
Tritium.
https://en.wikipedia.org/wiki/...
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?
Not paying anyone for overtime would be so freakishly illegal where I live.
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?
Masters know they don't know everything, and only use language features they know they can use without introducing bugs.
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.
If you have the CPU cycles for this, it is the better option. Depending on the application, you may not have this luxury (really low latency signal processing where trapping an exception will break the real-time behavior of the system).
Not ignoring the problem could be deadly, too, or at least very costly. It all depends on the application.
Why do you think ARM put a mode in their CPUs where they just return zero on a division by zero? Does ARM leave their CPU design to idiots? I don't think so.
Yes. Because other parts of the cruise control algorithm can recognize a speed of zero as a point where the cruise control should not be operating at all and disengage it.
The other options would be:
Report an arbitrary value. This leads to horrible results as the arbitrary value may be below the set speed, but still in a range where the cruise control operates.
Report the maximum value. This may lead to funny results if the programmer did not pay close attention to signed/unsigned datatypes.
Do random stuff, crash, require restart before cruise control can be re-engaged: This doesn't immediately lead to horrible results, but to lots of unhappy customers wondering why their car needs resets/power cycling like their Windows computer does.