Embedded systems usually have their own rules.
Printable View
Embedded systems usually have their own rules.
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.Quote:
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'.Quote:
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.Quote:
Don't break the language rules!
Soma
You can access 0x0 on embedded systems??Quote:
Originally Posted by brewbuck
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 :D)?
>> 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.
Since references are practically always implemented as pointers in hardware, the expressionQuote:
interesting. 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;