Author: Keith Evans
Date: 09:58:36 05/28/04
Go up one level in this thread
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?
This page took 0.01 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.