Author: James Swafford
Date: 08:40:25 05/29/04
Go up one level in this thread
On May 28, 2004 at 17:30:18, Keith Evans wrote:
>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.
Not quite the same thing I guess, but functional languages use
lazy evaluation (as opposed to strict evaluation) all the time.
What if I had a function f(x,y), that (for whatever reason)
didn't depend on the value of y? What if y were a function
(such as move_str()???). SHould I evaluate it? Of course
not.
It's called 'outside in evaluation'...
--
James
>
>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.