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
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
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
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
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
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
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