On 16 May 2016 at 08:05, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/15/2016 1:49 PM, poliklosio wrote: > >> Also I think Adam is making a very good point about generl reproducibility >> here. >> If a researcher gets a little bit different results, he has to investigate >> why, >> because he needs to rule out all the serious mistakes that could be the >> cause of >> the difference. If he finds out that the source was an innocuous >> refactoring of >> some D code, he will be rightly frustrated that D has caused so much >> unnecessary >> churn. >> >> I think the same problem can occur in mission-critical software which >> undergoes >> strict certification. > > > > Frankly, I think you are setting unreasonable expectations. Today, if you > take a standard compliant C program, and compile it with different switch > settings, or run it on a machine with a different CPU, you can very well get > different answers. If you reorganize the code expressions, you can very well > get different answers.
The argument you used against me earlier was that it was unacceptable for some C code pasted in D to behave differently than in C... but here you've just destroyed your own argument by noting that C behaves differently than itself. The rest of us would never get away with this ;) For reference: > > I think it's the only reasonable solution. > It may be, but it is unusual and therefore surprising behavior. > > What is the problem with this behaviour I suggest? > Code will do one thing in C, and the same code will do something unexpectedly > different in D. So let's reopen the discussion from my first post that you dismissed? If the situation is that C compilers produce no predictable behaviour (as you claim above, and I agree), what is the harm to applying a behaviour that actually works?
