> Well and somefunction ? It does modify teh value of a too. Is it executed > before ? after ? What is the value at the end of all that ?
Obviously it will be incremented first. The order is dependent of the rules by which the conditions are evaluated at compile-time. For example, the compiler will build a depth-first list of the import tree and evaluate code sequentially in each module. As i already said, it works just like at run-time. Is it so hard to imagine taking the compile-time code, run it during compilation separately with the exact same rules as it would during compilation? > Well, if you don't see any problem, you should probably just stop trying to > provide a solution. Ok, this is just ridiculous. Are you serious about this question or are you trolling to say the least? In either way, I don't see any problem in _having mutable compile-time values_. On Mon, Nov 7, 2011 at 7:49 PM, deadalnix <deadal...@gmail.com> wrote: > Le 07/11/2011 15:30, Gor Gyolchanyan a écrit : >>> >>> now what is the value of a ? At run time ? At compile ime ? If some other >>> CTFE uses a ? If a CTFE from another module uses a or worse, update it ? >> >> Run-time: Whatever _a_ ends up with by the time CTFE is done. There's >> a very handy _COUNTER_ macro in Visual C++ compiler, that uses this >> very feature internally. >> Compile-time: The same, that it would have if run in run-time: >> sequentially updated after the compile-time value (naturally). >> >>> What the hell this program is supposed to print at run time ? >> >> Assuming that somefunction was never called, this would print -1. >> That's because _a_ has a resulting compile-time value if -1 due to >> having decremented once by the someotherfunction() inside the static >> if and b is being initialized by -1. >> > > Well and somefunction ? It does modify teh value of a too. Is it executed > before ? after ? What is the value at the end of all that ? > >> I don't see any problems in either of these cases. >> The whole point of a mutable compile-time value is to have essentially >> two values, one of which is computed at compile-time and the other, >> which is statically initialized by the first one. >> > > Well, if you don't see any problem, you should probably just stop trying to > provide a solution. >