www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE a "funny" bug

reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 29 2019
parent reply sarn <sarn theartofmachinery.com> writes:
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. :)
Jan 29 2019
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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%? ;)
Jan 30 2019
parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
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.
Jan 30 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 30 2019
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 30 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 30 2019