Embedded systems usually have their own rules.
Embedded systems usually have their own rules.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Having their own rules would imply that the language isn't C++, no matter how much it might otherwise look like it. So the point stands, C++ is useless on embedded, although languages which look extremely like C++ might not be.Originally Posted by CornedBee
Who said anything about dereferencing 'null' to obtain anything? (Yes, that's rhetorical; I'm just saying... I didn't.) From my perspective you can't obtain anything by dereferencing 'null'--hence the beauty of 'null'.No. Dereferencing the null pointer to get a reference is explicitly mentioned to be undefined. It doesn't matter that no hardware dereferencing actually takes place. A compiler is allowed to reject the code if it can prove you're dereferencing 0.
I have no doubt that 'type & r(*(0));' is undefined, regardless of the decoration, but that isn't what I suggested. There are handfuls of "Horrible Hacks (R)", every compiler I've ever used has a few relevant to this case, that allow you to bypass assignment of a reference. The right code, or rather the very horribly wrong code, will work in virtually every compiler; the code I suggest never manipulates the reference directly so the compiler can't complain about the assignment to 'null'--note: assignment to 'null' not assignment to '*(0)'.
Agreed. I'm just saying, if you are going to break them, break the @$%! out of them.Don't break the language rules!
Soma
You can access 0x0 on embedded systems??
I've never touched an embedded system; why are they different from regular PCs in that area?
>> No. Dereferencing the null pointer to get a reference is explicitly mentioned to be undefined. It doesn't matter that no hardware dereferencing actually takes place. A compiler is allowed to reject the code if it can prove you're dereferencing 0.
interesting. I always assumed that the compiler was guaranteed to generate a hardware access when dereferencing a pointer to get a reference. I wonder why they felt it needed to be undefined (perhaps they were anticipating precisely this type of hack)?
>> the code I suggest never manipulates the reference directly so the compiler can't complain about the assignment to 'null'--note: assignment to 'null' not assignment to '*(0)'.
ah, I misunderstood what you were saying in your earlier post. sorry about that.
>> Don't break the language rules!
>> Agreed. I'm just saying, if you are going to break them, break the @$%! out of them.
these two statements may be the moral of the story here. I shouldn't have presented this as any sort of viable programming paradigm for standard C++ program. hobby code, maybe, but nothing more.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Since references are practically always implemented as pointers in hardware, the expressioninteresting. I always assumed that the compiler was guaranteed to generate a hardware access when dereferencing a pointer to get a reference.
becomes a simple mov in machine code, if the compiler doesn't optimize the existence of the reference away completely.Code:T &r = *psomething;
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
