Author: Keith Evans
Date: 14:30:18 05/28/04
Go up one level in this thread
On May 28, 2004 at 13:16:41, Uri Blass wrote:
>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?
>
>I do not understand your question.
>
>I think that in case that I want to evaluate all of the move_str() before
>printing them I can do it by the following way:
>
>stringa=move_str(a);
>stringb=move_str(b);//stringa may be changed.
>printf("%s %s ",stringa,stringb);
>
>I think that it should be different than
>
>printf("%s %s ",move_str(a),move_str(b));
>
>
>Unfortunatley it is not the case and the definition of printf means evaluate all
>argument before printing them and not evaluating first argument,printing it
>evaluating second argument,printing it.
>
>Uri
This isn't really an issue with printf. The problem is basically how could you
make it so move_str(b) would not be evaluated before calling printf? It's not
printf that's calling move_str. You're calling that to obtain a return value to
pass to printf - just like your code which assigns separately to stringa and
stringb. Think about how parameters are passed to C functions. You may want to
play with something a little simpler than printf because varargs stuff is only
going to make it more confusing.
To really understand how this stuff works you may want to compile some C code
and see what's going on underneath the hood by reading the assembler code. I
think that it will prove to be quite valuable knowledge. (BTW - Knuth gets into
this level of detail in his books.) It used to be that everyone understood this
quite well because you needed to in order to use low level debuggers. If you
plan on doing any embedded systems work then you will most likely be asked this
type of question in a job interview.
I'm a hardware guy and seldom think about this any more, so I apologize if I
can't explain it well or if I made any errors.
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.