Author: James Swafford
Date: 08:33:01 05/29/04
Go up one level in this thread
On May 28, 2004 at 12:58:36, Keith Evans wrote:
>On May 28, 2004 at 11:00:45, Uri Blass wrote:
>
>>On May 28, 2004 at 07:23:28, Richard Pijl wrote:
>>
>>>On May 28, 2004 at 05:54:43, Uri Blass wrote:
>>>
>>>>On May 27, 2004 at 20:11:52, Filip Tvrzsky wrote:
>>>>
>>>>>On May 27, 2004 at 19:05:42, Uri Blass wrote:
>>>>>
>>>>>>On May 27, 2004 at 18:41:59, Randall Shane wrote:
>>>>>>
>>>>>>>On May 27, 2004 at 18:10:47, Uri Blass wrote:
>>>>>>><snippage>
>>>>>>>>
>>>>>>>>I do not get the same move twice when I have
>>>>>>>>printf("%s ",move_str(0));
>>>>>>>>printf("%s ",move_str(1));
>>>>>>>>
>>>>>>>>I thought that
>>>>>>>>printf("%s %s ",move_str(0),move_str(1));
>>>>>>>>should be exactly the same instruction.
>>>>>>>>
>>>>>>>>I understand now that it is not and the second printf does not print move_str(1)
>>>>>>>>immediatly after it calculates it but calculates also move_str(0) and change the
>>>>>>>>value of move_str(1) by doing it.
>>>>>>>>
>>>>>>>>I think that it is a bug in the language or in the compiler because it is clear
>>>>>>>>that the programmer mean the same in both cases.
>>>>>>>>
>>>>>>>>
>>>>>>>>correct compiler can solve the problem by translating
>>>>>>>>
>>>>>>>>printf("%s %s ",move_str(0),move_str(1));
>>>>>>>>to
>>>>>>>>printf("%s ",move_str(0));
>>>>>>>>printf("%s ",move_str(1));
>>>>>>>>
>>>>>>>>I see no logical reason not to translate it in that way from human point of
>>>>>>>>view.
>>>>>>>
>>>>>>>Ah, but how is the compiler supposed to know that you didn't mean to overwrite
>>>>>>>the array, which is defined internal to your move_str routine?
>>>>>> Without
>>>>>>>extensive and deep analysis of the routines, it can't make that assumption.
>>>>>>
>>>>>>
>>>>>>I think it can make this assumption.
>>>>>>I see no reason to write one printf of 2 strings and to mean different thing
>>>>>>than the thing that is done by 2 printf.
>>>>>>
>>>>>>It is a confusing code.
>>>>>
>>>>>Uri, I am sorry, but this is really YOUR fault, not compiler fault. I am also
>>>>>little bit suprised at your complaints about compiler behaviour knowing your
>>>>>strictly logical style of thinking. Because when you read language specification
>>>>>and think thoroughly about it then you should realize that compiler does exactly
>>>>>what is supposed to do and not what it could assume to be your wish. And thank
>>>>>God for it! Because I am sick of software which knows better than me what I
>>>>>want.
>>>>>Filip
>>>>
>>>>In that case it is a mistake in defining the language.
>>>>
>>>>I did not read language specification and I simply generalized based on previous
>>>>experience.
>>>>
>>>>I also think that the compiler should at least give a warning in that case
>>>>because I guess that I am not the first person and not the last person to do
>>>>that kind of mistake.
>>>
>>>If you really think that is the case you should probably use a language like
>>>Pascal or Modula-II instead. Or perhaps Java? Those languages prevent a lot of
>>>these mistakes by not allowing the constructions that cause them.
>>>
>>>Point is that C gives you a lot of possibilities in fiddling with data and data
>>>access. That gives great flexibility, but asks of the programmer to take care
>>>when using those tricks.
>>>
>>>move_str() returns a pointer. And the memory location will contain the stuff you
>>>have asked for. In principle you don't care where it is located. The
>>>disadvantage is that you should be aware of the limited validity of this
>>>content. In this case until the next call to move_str().
>>>
>>>If you do not want this restriction, you have to rewrite move_str by either
>>>supplying a memory location that the calling function controls, or by
>>>dynamically allocation memory to store the string (slow!!) where you should not
>>>forget to free that memory again when you no longer need it (i.e. after the
>>>printf).
>>>
>>>>I guess that in big majority of the cases that programmers write printf("%s %s
>>>>",a,b);
>>>>they mean printf("%s ",a); orintf(" %s ",b);
>>>
>>>printf is a function. Printf is a special function because it allows an
>>>unspecified number of parameters, and handles them correctly.
>>>Before a function is called, all of its arguments are evaluated.
>>
>>It is exactly the problem.
>>
>>I did not know that printf works in that way and I thouhgt that it prints an
>>argument immediately after it is evaluated and only later goes to the next
>>argument.
>>
>>It seems more logical to define printf in that way and it does not prevent the
>>programmer to first evaluate all argument before printing by special varaibles
>>that have the evaluation result.
>>
>>Uri
>
>How would you pass arguments to a function in an unevaluated state? Can you draw
>a stack frame showing exactly what would be done?
The problem (well, Uri's problem) is the order in which the compiler
evaluates the expression tree. Think of 'printf' as a node in a tree
with the parameters as children.
Apparently the children are evaluated first (bottom up), and since
they share memory, voila...
I think printf could do something like:
While (unevaluated parameter) {
evaluate parameter
copy results to buffer
}
print buffer
Not as efficient, but it would work.
Note I am _not_ saying it _should_ work this way!
--
James
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.