|
|
|
 |

February 26th, 2004, 10:52 AM
|
Sergeant
|
|
Join Date: Dec 2003
Posts: 201
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
How about :
a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...
Don't tell me there's a compiler around daft enough to evaluate b before a in this case !
|

February 26th, 2004, 10:55 AM
|
 |
Major General
|
|
Join Date: Jan 2004
Location: twilight zone
Posts: 2,247
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
Quote:
Originally posted by General Tacticus:
How about :
a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...
Don't tell me there's a compiler around daft enough to evaluate b before a in this case !
|
This should work just fine, under normal conditions.
EDIT: caveat: it actually is possible to force the compilers I've used into screwing this up. It involves tweaking settings so the compiler re-orders the statements so that it reads ...
b = a = 2d6
Which, of course, looks the same as your example to anyone who's not a gamer or mathematician. We know that 2 calls to "d6" do not necessarily return the same answer. 
[ February 26, 2004, 09:01: Message edited by: Arryn ]
|

February 26th, 2004, 11:37 AM
|
Sergeant
|
|
Join Date: Dec 2003
Posts: 201
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
|

February 26th, 2004, 11:41 AM
|
 |
Major General
|
|
Join Date: Jan 2004
Location: twilight zone
Posts: 2,247
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
|

February 26th, 2004, 12:03 PM
|
 |
Brigadier General
|
|
Join Date: Aug 2003
Location: Mictlan
Posts: 1,767
Thanks: 12
Thanked 165 Times in 22 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
Quote:
Originally posted by General Tacticus:
How about :
a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...
|
That's the one that is used now. Easy to read and it should be foolproof.
|

February 26th, 2004, 12:14 PM
|
 |
First Lieutenant
|
|
Join Date: Sep 2003
Location: Bordeaux, France
Posts: 794
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
Quote:
Originally posted by General Tacticus:
And you can also make them believe that '<' means '>', or for that matter that "=" in the code means 'print("I'm a genius")' . But we are here to help compilers do the right thing, not to screw their settings and help them be total idiots
|
You've obviously never had to work on optimizing a compiler... (neither have I, but I do occasionally teach some programming)
Warning: Tech speak coming up. If you're only into computer games and not programming, maybe you should skip this. Well, maybe you should skip the whole thread, apart from the "we found the bug and it will be corrected in the next patch" bit.
If your function calls are guaranteed to not have any side effects, the rearrangement Arryn "suggested" is actually a good move; it makes the compiled program faster by saving a (potentially costly) function call. This is a case of the compiler "helping" a sloppy programmer (and all programmers are sloppy).
Of course, if your function call has a side effect, it's a very bad move because one call will not have the same side effect as two calls. In this case, calling the dice-rolling function has a side effect, since it modifies the state of the random generator, so it's pretty important.
I don't know enough of the C specification to say whether there's a keyword to let the compiler know that a given function call is guaranteed to not have any side effects, but I suppose some compilers can be tweaked to assume that they are...
[And I don't even know whether "side effect" is the correct English translation for the French "effet de bord"; all my teaching is done in French, I admit...]
|

February 26th, 2004, 12:32 PM
|
 |
Major General
|
|
Join Date: Jan 2004
Location: twilight zone
Posts: 2,247
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: 2.08 and Incompatible Battle Reports
Philippe, "side effect" is the correct translation, AFAIK.
And I'm glad that at least one person who's been reading this thread "gets it" with regards to compiler optimization, and possible pitfalls. Thanks for posting.
BTW, AFAIK, there aren't any C/C++ keywords that affect the sort of optimizations that can cause these troubles. The best way to avoid them is understanding how functions pass back values, most importantly, what all the various optimization switches do (and which ones you have turned "on"), and how the compiler actually optimizes the code (which is done at the assembly-code level, not source-code level).
Breaking complex expressions into separate and simple statements will go a long ways to avoiding possible problems too. It takes a little longer to write the code, but the end result is easier to read and maintain.
|
Thread Tools |
|
Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is On
|
|
|
|
|