Hello Guys,

I took a few days off over easter and I have very good news for you.
The following code will now compile and execute correctly using newCTFE.

---
class C
{
  int i() {return 1;}
}

class D : C
{
  override int i() {return 2;}
  float f() { return 1.0f; }
}

class E : D
{
  override int i() {return 3;}
  override float f() { return 2.0f; }
}


int testClassStuff ()
{
  C c1, c2, c3;
  D c4;
  c1 = new C();
  c2 = new D();
  c3 = new E();

  D e = new E();
  assert(cast(int)e.f() == 2);

  return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
---

In short this means that classes and virtual function calls work now.
albeit currently only if you don't define your own constructor, which would currently get treated as normal function and therefore not set the vtbl pointer correctly.

I'd also like to note that the vtbl handling is backend independent which means that you code your own backend for newCTFE without having to deal with the fact that vtbl and constructor stuff is going on.
To you It's just load store and call. :)

Have a nice easter.

Stefan

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
> Hello Guys,
>
> I took a few days off over easter and I have very good news for you.
> The following code will now compile and execute correctly using newCTFE.
>
> ---
> class C
> {
>   int i() {return 1;}
> }
>
> class D : C
> {
>   override int i() {return 2;}
>   float f() { return 1.0f; }
> }
>
> class E : D
> {
>   override int i() {return 3;}
>   override float f() { return 2.0f; }
> }
>
>
> int testClassStuff ()
> {
>   C c1, c2, c3;
>   D c4;
>   c1 = new C();
>   c2 = new D();
>   c3 = new E();
>
>   D e = new E();
>   assert(cast(int)e.f() == 2);
>
>   return c1.i + c2.i + c3.i;
> }
> static assert(testClassStuff == 1 + 2 + 3);
> ---
>
> In short this means that classes and virtual function calls work now.
> albeit currently only if you don't define your own constructor, which would currently get treated as normal function and therefore not set the vtbl pointer correctly.
>
> I'd also like to note that the vtbl handling is backend independent which means that you code your own backend for newCTFE without having to deal with the fact that vtbl and constructor stuff is going on.
> To you It's just load store and call. :)
>
> Have a nice easter.
>
> Stefan

How close are you to finish this?

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
> Have a nice easter.
>
> Stefan

Great, then there's hope.

On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:
> On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
>> [...]
>
> How close are you to finish this?

85 to 90% maybe.

I expect that there will many bugs which were hidden by newCTFE not supporting classes, which will now be out in the open and have to be dealt with.
Also the code is in need of cleanup before I would release it for upstream-inclusion.

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
> Hello Guys,
>
> I took a few days off over easter and I have very good news for you.
> The following code will now compile and execute correctly using newCTFE.
>
> ---
> class C
> {
>   int i() {return 1;}
> }
>
> class D : C
> {
>   override int i() {return 2;}
>   float f() { return 1.0f; }
> }
>
> class E : D
> {
>   override int i() {return 3;}
>   override float f() { return 2.0f; }
> }
>
>
> int testClassStuff ()
> {
>   C c1, c2, c3;
>   D c4;
>   c1 = new C();
>   c2 = new D();
>   c3 = new E();
>
>   D e = new E();
>   assert(cast(int)e.f() == 2);
>
>   return c1.i + c2.i + c3.i;
> }
> static assert(testClassStuff == 1 + 2 + 3);
> ---
>
> In short this means that classes and virtual function calls work now.
> albeit currently only if you don't define your own constructor, which would currently get treated as normal function and therefore not set the vtbl pointer correctly.
>
> I'd also like to note that the vtbl handling is backend independent which means that you code your own backend for newCTFE without having to deal with the fact that vtbl and constructor stuff is going on.
> To you It's just load store and call. :)
>
> Have a nice easter.
>
> Stefan

newCTFE is looking very cool. Glad to see you're still working at it.

On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:
> On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:
>> On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
>>> [...]
>>
>> How close are you to finish this?
>
> 85 to 90% maybe.
>
Ok, so it will take 90% of the total to get to the remaining 10%. So it will be ready for 2028 :-)

On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote:
> On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:
>> On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:
>>> On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
>>>> [...]
>>>
>>> How close are you to finish this?
>>
>> 85 to 90% maybe.
>>
> Ok, so it will take 90% of the total to get to the remaining 10%. So it will be ready for 2028 :-)

huh that's not quite right
The approx time I worked on it is 1.6 years.
If your proposition is correct it will take (0.9 * 1.6) years to finish
which would be 1.44 years.
meaning it should be ready 2019.

On Saturday, 31 March 2018 at 08:29:22 UTC, Stefan Koch wrote:
> On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote:
>> Ok, so it will take 90% of the total to get to the remaining 10%. So it will be ready for 2028 :-)
>
> huh that's not quite right
> The approx time I worked on it is 1.6 years.
> If your proposition is correct it will take (0.9 * 1.6) years to finish
> which would be 1.44 years.
> meaning it should be ready 2019.


> On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote
>
> it will take 90% of the total to get to the remaining 10%.

So 1.6 years is 10%, the total is 16 years, and there's 14.4 years left. So 2032.

--
  So,em

On Saturday, 31 March 2018 at 08:29:22 UTC, Stefan Koch wrote:
> On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote:
>> On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:
>>> On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:
>>>> On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:
>>>>> [...]
>>>>
>>>> How close are you to finish this?
>>>
>>> 85 to 90% maybe.
>>>
>> Ok, so it will take 90% of the total to get to the remaining 10%. So it will be ready for 2028 :-)
>
> huh that's not quite right
> The approx time I worked on it is 1.6 years.
> If your proposition is correct it will take (0.9 * 1.6) years to finish
> which would be 1.44 years.
> meaning it should be ready 2019.

The thing is, the first 90% take 10% of the time, so it's 9 * 1.6 in 14 years :-o

https://en.wikipedia.org/wiki/Ninety-ninety_rule

On Saturday, 31 March 2018 at 10:38:53 UTC, Simen Kjærås wrote:
> [snip]
>
> So 1.6 years is 10%, the total is 16 years, and there's 14.4 years left. So 2032.
>
> --
>   So,em

60% of the time, it works every time

https://www.youtube.com/watch?v=pjvQFtlNQ-M