On Tuesday, 16 July 2013 at 14:05:38 UTC, Ali Çehreli wrote:
On 07/15/2013 10:51 PM, JS wrote:
> On Tuesday, 16 July 2013 at 04:37:33 UTC, Ali Çehreli wrote:
>> On 07/15/2013 08:43 PM, JS wrote:
>>
>> > http://dpaste.dzfl.pl/7c8b0ba9
>> >
>> > Why the heck can't we use integers in ctfe's? There seems
to
>> be no
>> > simple way to create a counter and this is one of the most
>> basic
>> > programming constructs to use.. yet with ctfe's it's
>> impossible.
>> >
>> > I'd like each variable in the nested structs to be
>> incremented properly.
>>
>> I did not read the code but just from your description, the
separate
>> compilation model that D uses would preclude that. For
example,
>> compilation of a.d would not know anything about the counter
that b.d
>> has counted during its compilation.
>>
>> Ali
>
> Huh? what is a.d and b.d?
Yeah, I should have read your code before writing that. My
comment is for the general case where a.d and b.d are two
separte modules that are compiler separately. I thought that
you wanted a counter to continue counting between modules.
That wold be nice but require external storage to an ctfe which
is a limitation of ctfe's.
Ok, at least this post has helped me solve my problem. I guess
the issue was the error message given.
The problem is I can't declare my "global" int variables directly
inside the template. This does make it hard to use the same
variable across multiple functions...
template A
{
int c; // makes c near useless, can't use it like a normal
it...
}
solution, one has to use nested functions:
template A
{
string templateScope()
{
int c; // c now acts like a normal global int value to
all nested functions.
}
}
I think I understand why this works and is done this way but the
error message given obfuscates the reason. Unfortunately it
requires a messy technique to get around by using nested
functions. (The parent function holds the global state of the
child functions)
It would be nice if we had some way to data globally(in module).
e.g., __ctfestore["name"] = value;
I understand this wouldn't probably work well outside the module
since compilation order may be not be consistent. (but maybe
__ctfeVolitileStore could be used for cross module storage)
