January 06, 2012
On Thursday, 5 January 2012 at 23:12:21 UTC, bearophile wrote:
> Override usage is going to be (hopefully soon) compulsory in D (currently you need -w to see an error). So that code without both static and override is going to be refused :-)
>
> Bye,
> bearophile

I guess the question I was getting at, currently there is no way to "hide" a non-static member function like you would do in C# with 'new.' Is that intended once 'override' is required? and if not why have 'new' usable for static methods?
January 06, 2012
Jesse Phillips:

> currently there is no way to "hide" a non-static member function like you would do in C# with 'new.' Is that intended once 'override' is required? and if not why have 'new' usable for static methods?

As far as I know no other changes are planned linked to the introduction of compulsory 'override'. For the other questions probably Walter or Andrei are able to give you much better answer than me.

Bye,
bearophile
January 06, 2012
>
>    The right thing should be the default.
>> But I fundamentally disagree your choice is 'right'..
>>
>
> Sure.
>
>
>  This is obviously subjective, so I don't think that's a fair assertion.
>>
>
> By 'right', I don't necessarily mean 'the most efficient'. I mean that the code should be correct. It's ok if extra work is involved in creating the most efficient version.


But this solution is equally correct, and doesn't make any sacrifice for
the most efficient version:
  methods are not virtual by default.
  overriding any common method is an error (great, now I know if I've made
any sort of mistake)
  a method declared virtual may be overridden expected, and
virtual-ness safely confirmed by the lack of compile error.
  to override a regular method (a rare thing to do, but still your primary
safety concern), you use an explicit keyword to do it. now it's absolutely
intentional.

This provides all the same safety guarantees, ie, your 'right'-ness, and doesn't sacrifice: performance/false-virtual risk, 'final' keyword spam, risk of forgetfulness and the junior coder factor... surely this is MORE 'right', by any measure? :)


January 06, 2012
On 2012-01-05 14:59, Vladimir Panteleev wrote:
> On Thursday, 5 January 2012 at 13:40:20 UTC, Jacob Carlborg wrote:
>> The pragma is a standard way to expose non-standard features. You just
>> need to wrap it in version statements because the compiler will
>> otherwise complain about unrecognized pragmas. If that's a good thing
>> or not, I don't know.
>
> DMD has an -ignore switch:
>
> -ignore ignore unsupported pragmas
>

I had no idea.

-- 
/Jacob Carlborg
January 06, 2012
On Jan 5, 2012, at 3:56 PM, Walter Bright wrote:

> On 1/5/2012 2:57 PM, Sean Kelly wrote:
>> For the record, some compilers do optimize across asm blocks.  It's simply DMD/DMC that doesn't.  Though the lack of "volatile" makes doing this unsafe in D as a general rule.
> 
> dmd does keep track of register usage within asm blocks.

Oh right, I guess it would have to, since variables can be used by name within asm blocks.  I guess it just doesn't do code movement across asm blocks then?
January 07, 2012
On 1/5/2012 4:03 PM, Sean Kelly wrote:
> Oh right, I guess it would have to, since variables can be used by name
> within asm blocks.  I guess it just doesn't do code movement across asm
> blocks then?

Right. More generally, it does not do data flow analysis within an asm block, treating it as a black box that could do anything.
January 09, 2012
On 5 January 2012 11:40, Artur Skawina <art.08.09@gmail.com> wrote:
> On 01/05/12 02:34, Iain Buclaw wrote:
>> Regardless, there is little reason to want to use a forced inline with gdc.  Just like in c++ when you define all methods in the class definition, gdc considers all methods as candidates for inlining. Similarly, when -inline is passed, the same is also done for normal functions that are considered inlinable by the frontend.  These functions marked as inline are treated in the same way as a function declared 'inline' in C or C++, and will be treated as such by the backend.
>
> This reminded me:
>
> ------------------------------------
>
> IOW gdc completely gives up on inlining the function/method because of the "in".
> Actually, "bool empty2(T)(const T[] a)" is enough to trigger the call.
>
> This means that eg array.empty never gets inlined. "pragma(attribute, always_inline)" does not help in this case.
>
> artur

I have sorted this out.

Regards

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 09, 2012
Am 04.01.2012, 15:33 Uhr, schrieb Vladimir Panteleev <vladimir@thecybershadow.net>:

> On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu wrote:
>> Hmmm, I see that the other way around. D CTFE-generated macros are much easier to debug because you can actually print the code before mixing it in. If it looks like valid code... great.
>
> Paging Don Clugston: would it be feasable to have the compiler remember the source position of every single char/string literal or compile-time-evaluated string expression?
>
> I'm thinking that if the compiler tracks the source of every string/char literal in the source code, all across to any manipulations, debugging CTFE-generated code would be a lot easier - the compiler would emit error messages pointing inside string literals, and debuggers could step inside code in string literals. (The one thing this doesn't allow is allowing debuggers to step through a DSL with no D code in it.)
>
> The naive implementation would store the position of every character, which would blow up the memory usage by about 13 times or so on 32-bit? (For every character, add a struct with 3 fields - char* filename; int line, column). A rope-like structure could cut down on that but possibly drastically complicating the implementation.

Last time I generated big and complex mixin I let the compiler
output mixins to separate files. This gives you nicer debugging
and readable error lines.
https://github.com/D-Programming-Language/dmd/pull/426
January 09, 2012
On 9 January 2012 12:01, Martin Nowak <dawg@dawgfoto.de> wrote:

> Am 04.01.2012, 15:33 Uhr, schrieb Vladimir Panteleev < vladimir@thecybershadow.net>:
>
>  On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu wrote:
>>
>>> Hmmm, I see that the other way around. D CTFE-generated macros are much easier to debug because you can actually print the code before mixing it in. If it looks like valid code... great.
>>>
>>
>> Paging Don Clugston: would it be feasable to have the compiler remember the source position of every single char/string literal or compile-time-evaluated string expression?
>>
>> I'm thinking that if the compiler tracks the source of every string/char literal in the source code, all across to any manipulations, debugging CTFE-generated code would be a lot easier - the compiler would emit error messages pointing inside string literals, and debuggers could step inside code in string literals. (The one thing this doesn't allow is allowing debuggers to step through a DSL with no D code in it.)
>>
>> The naive implementation would store the position of every character, which would blow up the memory usage by about 13 times or so on 32-bit? (For every character, add a struct with 3 fields - char* filename; int line, column). A rope-like structure could cut down on that but possibly drastically complicating the implementation.
>>
>
> Last time I generated big and complex mixin I let the compiler
> output mixins to separate files. This gives you nicer debugging
> and readable error lines.
> https://github.com/D-**Programming-Language/dmd/pull/**426<https://github.com/D-Programming-Language/dmd/pull/426>
>

Amazing idea, this should be standard!
That totally changes my feelings towards mixins :)


January 09, 2012
On 01/09/12 10:53, Iain Buclaw wrote:
> On 5 January 2012 11:40, Artur Skawina <art.08.09@gmail.com> wrote:
>> IOW gdc completely gives up on inlining the function/method because of the "in".
>> Actually, "bool empty2(T)(const T[] a)" is enough to trigger the call.
>>
>> This means that eg array.empty never gets inlined. "pragma(attribute, always_inline)" does not help in this case.
> 
> I have sorted this out.

Works. Thank you very much, not just for this, but for quickly fixing practically every single gdc bug that i filed.

It's nice to see all the code from my example compiled to just "mov $0x1,%eax" [1] and the runtime/phobos codegen improved too, some null pointer checks gone, significantly reduced spilling, opCall()/empty() are now inlined, which means they completely disappear etc.

Thanks,

artur

[1] I guess omitting the frame pointer manipulation for (at least) just nonthrowing leaf functions that don't use any stack slots wouldn't be easy? (the vector extensions will probably make this even more important...)