Hi Guys,

I have exciting news for you.

I've made huge progress on issues which were confusing me for a while.

The following is a description of the problem:

class A { int f1; }
class B : A { int f2; }

int[2] f()
{
  B b;
  b.f2 = 2;
  b.f1 = 1;
  return [b.f2, b.f1];
}

pragma(msg, f()); // this had the output [1, 1]

What was indeed going on here looked like an ABI issue, but went deeper.
In order the have a stable ABI, I cannot relay on the class-sizes or field-offsets which dmd gives me.
Therefore I build my own representation of types and store them in type-tables.

when I get the request to store something in a field, I'll go look the type up in the type table and get the offset from the field information for that particular type.
For the above code this would have gone like this (code simplified):
> {b.f2 = 2};  const type = classes.indexOf(B); // would be 3 because there are 3 classes known (A, B and Object)
> const fieldIndex = type.fieldIndex(f2) // would be 1 because f2 is the first Field in B
> const fieldOffset = type.offsetOf(fieldIndex) // would be 0 because there is no field preceeding f2
> memoryLocationOf(b) + fieldOffset = 2; // same as memoryLocationOf(b) becaue fieldOffset is zero
and then for the next statement
> {b.f2 = 2};  const type = classes.indexOf(B); // would be 3 because there are 3 classes known (A, B and Object)
> const fieldIndex = type.fieldIndex(f2) // can't find in B so look in A; would be 1 because f1 is the first Field in A and therfore falls onto the same index as f2
> const fieldOffset = type.offsetOf(fieldIndex) // would be 0 because there is no field preceeding f2 in B
> memoryLocationOf(b) + fieldOffset = 1; // same as memoryLocationOf(b) because fieldOffset is zero
lastly:
> Return(CreateArrayOf([memoryLocation(b) + 0, memoryLocation(b) + 0])); // this location has been set to one in the previous statement.

In the actual code there is a multi-level lookup in a few diffrent tables going on, therefore this was much less straight forward to find as it seems.
Now that I have tracked down the root-cause of this problem is should not be too hard to fix.

Though it should be noted that about 40% of complexity in newCTFE is entirely for oop support, another 40% being delegates!

While I do think that delegates are genuinely useful I cannot the same about classes.
One of the reasons it took me so long to even notice this issue, is because I don't classes often myself, much less multi-level inheritance.

Cheers,

Stefan

P.S. I currently on a short vacation and working on getting newCTFE to a state where I can release it with a clear consciousness.

On Tuesday, 29 January 2019 at 20:13:12 UTC, Stefan Koch wrote:
> Though it should be noted that about 40% of complexity in newCTFE is entirely for oop support, another 40% being delegates!

This makes me wonder where the next 40% of complexity is. :)

On Tuesday, 29 January 2019 at 22:02:11 UTC, sarn wrote:
> On Tuesday, 29 January 2019 at 20:13:12 UTC, Stefan Koch wrote:
>> Though it should be noted that about 40% of complexity in newCTFE is entirely for oop support, another 40% being delegates!
>
> This makes me wonder where the next 40% of complexity is. :)

Because D has a total complexity rate of 120%? ;)

On 1/30/19 10:00 AM, Bastiaan Veelo wrote:
> On Tuesday, 29 January 2019 at 22:02:11 UTC, sarn wrote:
>> On Tuesday, 29 January 2019 at 20:13:12 UTC, Stefan Koch wrote:
>>> Though it should be noted that about 40% of complexity in newCTFE is entirely for oop support, another 40% being delegates!
>>
>> This makes me wonder where the next 40% of complexity is. :)
> 
> Because D has a total complexity rate of 120%? ;)

Hmm, if we claim a high number for D then C++ will start getting a complexity complex.

On Wed, Jan 30, 2019 at 10:35:40AM -0700, David Gileadi via Digitalmars-d wrote:
> On 1/30/19 10:00 AM, Bastiaan Veelo wrote:
> > On Tuesday, 29 January 2019 at 22:02:11 UTC, sarn wrote:
> > > On Tuesday, 29 January 2019 at 20:13:12 UTC, Stefan Koch wrote:
> > > > Though it should be noted that about 40% of complexity in newCTFE is entirely for oop support, another 40% being delegates!
> > > 
> > > This makes me wonder where the next 40% of complexity is. :)
> > 
> > Because D has a total complexity rate of 120%? ;)
> 
> Hmm, if we claim a high number for D then C++ will start getting a complexity complex.

"Complexity complex" sounds like an apt description of C++. :-D

We may divide overall complexity by the number of cleanly-designed, orthogonal features to get an estimate of the complexity each language feature brings.  In the case of C++, I fear it may end up being infinity.  :-P


T

-- 
Some days you win; most days you lose.

On Wednesday, 30 January 2019 at 17:53:27 UTC, H. S. Teoh wrote:
> 
> "Complexity complex" sounds like an apt description of C++. :-D
>
> We may divide overall complexity by the number of cleanly-designed, orthogonal features to get an estimate of the complexity each language feature brings.  In the case of C++, I fear it may end up being infinity.  :-P
>
>
> T

I would not go that far, infact as may warts an corner cases as C++ has,
it does go to heroic efforts to define the wired corner cases.

D manages to put a weider runtime-library blanket over the complexity and the syntax is nicer.
But in the end it's all there. I assume there's just because less people who peer under the blanket and write a blog-post.

On Wed, Jan 30, 2019 at 10:00:34PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Wednesday, 30 January 2019 at 17:53:27 UTC, H. S. Teoh wrote:
> > "Complexity complex" sounds like an apt description of C++. :-D
> > 
> > We may divide overall complexity by the number of cleanly-designed, orthogonal features to get an estimate of the complexity each language feature brings.  In the case of C++, I fear it may end up being infinity.  :-P
> > 
> > 
> > T
> 
> I would not go that far, infact as may warts an corner cases as C++ has, it does go to heroic efforts to define the wired corner cases.
> 
> D manages to put a weider runtime-library blanket over the complexity
> and the syntax is nicer.
> But in the end it's all there. I assume there's just because less
> people who peer under the blanket and write a blog-post.
[...]

Haha, well, I *have* seen some of the weird corner cases in D, and there certainly are dark corners in the language that I avoid like the plague. But overall, D lets me get the job done without shoving the weird corner cases in my face all the time and forcing me to decide between equally weird behaviours when I'm trying to focus on the problem domain. For the most part, it does it right, and it gives you tools like built-in unittests or alternative constructions to work around the problems that do surface.

With C++, however, I feel like most of my mental effort is spent wrestling with the language rather than getting work done in the problem domain, which is a very frustrating feeling.


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth