January 17, 2010
W dniu 2010-01-17 12:54, Lutger pisze:
> On 01/17/2010 01:38 AM, Simen kjaeraas wrote:
>> Lutger <lutger.blijdestijn@gmail.com> wrote:
>>
>>> Perhaps this is or should be a bug. You can override dup to work in
>>> ctfe:
>>>
>>> char[] dup(string str)
>>> {
>>> return str.dup;
>>> }
>>>
>>> class Test {
>>> string t1 = "test"; //Ok!
>>> char[] t2 = "test".dup; //Compile error
>>> char[] t3 = "test".dup(); //Ok!
>>> }
>>
>> The problem with this approach is that you now have a pointer to mutable
>> data, the contents of which are stored in the static data segment, and
>> thus
>> actually immutable.
>>
>> Second (and this is related to the first), the pointer will be the
>> same for
>> all instances, and thus changing the contents of one will change the
>> contents of all.
>>
>> IOW, what one (probably) wants in this situation, is a constructor.
>>
>
>
> Thanks man, this is a big error of mine. Trying to manipulate the char[]
> does indeed do a segfault! I can't seem to find an explanation in the
> spec of how initializers are supposed to work, so I assumed incorrectly
> it would be ok.
>
> I find it a bit disturbing that you can end up with a mutable reference
> to immutable data so easily, without casting or anything.

Well, I don't get it...

IMHO .dup makes mutable copy of data (so copy of "test") in mutable area of memory. And it should mean that every pointer points to different area of memory...

Am I wrong?

BR
Marcin Kuszczak
(aarti_pl)
January 17, 2010
W dniu 2010-01-17 19:38, Don pisze:
> aarti_pl wrote:
>>
>> class Test {
>> string t1 = "test"; //Ok!
>> char[] t2 = "test".dup; //Compile error
>> }
>>
>> void main(char[][] args) {
>> }
>>
>> Error:
>> hello.d(3): Error: cannot evaluate _adDupT((&
>> D12TypeInfo_Aya6__initZ),"test") at compile time
>> hello.d(3): Error: cannot evaluate _adDupT((&
>> D12TypeInfo_Aya6__initZ),"test") at compile time
>>
>> Is there workaround?
>>
>> BR
>> Marcin Kuszczak
>> (aarti_pl)
>
> Workaround: It works in dmd2, svn 337 and later <g>.

Wow. I even could not report it as a bug. That is really fast bug fixing :-)

Could you please explain what has initialization of variables to do with CTFE? As far as I understand it should be done on runtime... So why is there compile time execution involved?

And other questions. Would it be possible to initialize more complex types with better CTFE? I see it as quite major issue when I can not write in class definition or in global scope:

auto serializer = new Serializer!(TextArchive)();

BR
Marcin Kuszczak
(aarti_pl)
January 17, 2010
aarti_pl <aarti@interia.pl> wrote:

> Well, I don't get it...
>
> IMHO .dup makes mutable copy of data (so copy of "test") in mutable area of memory. And it should mean that every pointer points to different area of memory...
>
> Am I wrong?

You're mostly right. However, this happens at compile time, so the mutable
data is mutable no longer once its been stored in the executable. IOW,
"Test".dup is executed once at compile time, and the result stored in
Test.init. Then, at runtime, Test.init is copied onto each new instance of
the struct/class. "Test".dup is not executed at runtime.

As Lutger pointed out, this smells of a bug. Sadly, fixing that bug would
not overcome the problem of having no default constructors for structs.

--
Simen
January 18, 2010
W dniu 2010-01-17 20:56, Simen kjaeraas pisze:
> aarti_pl <aarti@interia.pl> wrote:
>
>> Well, I don't get it...
>>
>> IMHO .dup makes mutable copy of data (so copy of "test") in mutable
>> area of memory. And it should mean that every pointer points to
>> different area of memory...
>>
>> Am I wrong?
>
> You're mostly right. However, this happens at compile time, so the mutable
> data is mutable no longer once its been stored in the executable. IOW,
> "Test".dup is executed once at compile time, and the result stored in
> Test.init. Then, at runtime, Test.init is copied onto each new instance of
> the struct/class. "Test".dup is not executed at runtime.
>
> As Lutger pointed out, this smells of a bug. Sadly, fixing that bug would
> not overcome the problem of having no default constructors for structs.
>
> --
> Simen

Well, in such a case you are right. It's not what I would like to have...

It will be indeed source of bugs.

BR
Marcin Kuszczak
(aarti_pl)
January 20, 2010
aarti_pl wrote:
> W dniu 2010-01-17 19:38, Don pisze:
>> aarti_pl wrote:
>>>
>>> class Test {
>>> string t1 = "test"; //Ok!
>>> char[] t2 = "test".dup; //Compile error
>>> }
>>>
>>> void main(char[][] args) {
>>> }
>>>
>>> Error:
>>> hello.d(3): Error: cannot evaluate _adDupT((&
>>> D12TypeInfo_Aya6__initZ),"test") at compile time
>>> hello.d(3): Error: cannot evaluate _adDupT((&
>>> D12TypeInfo_Aya6__initZ),"test") at compile time
>>>
>>> Is there workaround?
>>>
>>> BR
>>> Marcin Kuszczak
>>> (aarti_pl)
>>
>> Workaround: It works in dmd2, svn 337 and later <g>.
> 
> Wow. I even could not report it as a bug. That is really fast bug fixing :-)

It wasn't specifically a fix of this bug. Some long-standing CTFE limitations were fixed, which make lots of things start working.

> Could you please explain what has initialization of variables to do with CTFE? As far as I understand it should be done on runtime... So why is there compile time execution involved?

It shouldn't be happening. There's a bug somewhere.

> And other questions. Would it be possible to initialize more complex types with better CTFE? I see it as quite major issue when I can not write in class definition or in global scope:
> 
> auto serializer = new Serializer!(TextArchive)();

If you can't do that now, that's a serious bug.
But classes will eventually work in CTFE.
1 2
Next ›   Last »