- neos, conceptually speaking... - 1 Update
- std::hexfloat - 3 Updates
- offsetof - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 24 11:21PM +0100 Hi! For neos my universal compiler I am cleanrooming the project so I may be creating new original concepts including the concept of folding semantic concepts, conceptually speaking of course! :D /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: May 24 11:00PM +0200 >> the underlying hardware is physically different. But so what? What >> possible bearing does that have on C or C++ ? > Its called an analogy, look it up. An analogy is supposed to make sense and clarify the discussion. If someone has to ask the point of it, it has failed. >> No there is not. > Isn't there? So + wouldn't give rise to an add, calling a function wouldn't > create a call assembler instruction? Sometimes, sometimes not. Sometimes additions in the source code get pre-calculated, and there is no matching assembly. Sometimes they get implemented as part of addressing modes. Sometimes they are implemented with subtraction instructions. Sometimes the addition instructions are used to implement multiplication. Sometimes functions are inlined, and there is not call instruction. Sometimes parts of functions are "outlined" and get extra call instructions. Sometimes jumps are used, not calls. There is /no/ clear mapping between C and assembly except for the simplest and most basic compiler. >> What an odd example to pick, given that its behaviour is fully defined >> in all programming languages I have seen. > So is the answer 0 or 0.66666... then? Some programming languages define it to be 0, some to be 0.666... (in whatever format suits them), some to be a rational number 2 / 3, some to be an algebraic expression. But I can't imagine any programming language that would not define the behaviour. (In C and C++, it is defined to be 0.) In no sense is it undefined behaviour. >> vastly more common in my experience. > Each of the operations in the example code was perfectly valid. The optimiser > made an incorrect assumption and created non working code. I've had more sensible replies talking to a brick wall. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 25 12:09AM +0300 >> What an odd example to pick, given that its behaviour is fully defined >> in all programming languages I have seen. > So is the answer 0 or 0.66666... then? Depends on the language and its version. In Python 2 it is 0, in Python 3 it is 0.6666666666666666. Still fully defined. C and C++ are much more entrenched than Python, so you will not see the value of 2/3 changing unexpectedly in C++2100. However, I suspect your loved x86 assembler instructions might be fully forgotten by then. |
| jameskuyper@alumni.caltech.edu: May 24 03:19PM -0700 On Friday, May 24, 2019 at 1:37:43 PM UTC-4, blt_S1...@2ui.co.uk wrote: ... > Each of the operations in the example code was perfectly valid. The optimiser > made an incorrect assumption and created non working code. I realized that you've never made it clear what reason you have for reaching that conclusion. Are you 1. Denying that C's anti-aliasing rules are violated by this code. 2. Denying that C's anti-aliasing rules exist. 3. Denying that C's anti-aliasing rules have any authority over this code. 4. Have no idea what C's anti-aliasing rules are. 5. Denying ISO's authority to publish a standard containing such rules. 6. Denying that the C standard's explicit statement that such code has undefined behavior justifies implementations failing to give it the behavior that you think it should have. 7. Other - please explain. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 24 11:47PM +0300 On 24.05.2019 21:23, Marcel Mueller wrote: > has defined behavior in such cases. >> Amazing, usually C++ is much more picky! > I can't confirm this. You can do almost any dirty hack in C++. Sure, but I was assuming offsetof is one of such "dirty hacks", not a single static_cast ;-) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment