http://www.artima.com/cppsource/codefeaturesP.html

Andrei

On Wed, Sep 24, 2008 at 6:59 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> http://www.artima.com/cppsource/codefeaturesP.html
>
> Andrei
>

Cool beans.  A nice intro to the power of D template metaprogramming! That was nice of Scott to put it right alongside his C++ code.

Bartoz, regarding this:

>> Incidentally, the same string can be generated and printed at run time using this line of code:
>>
>> writeln (declareAllFeatures (["Tested", "Portable"]));

you might want to also mention that you can debug such strings at *compile time* too using something like:

pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested", "Portable"]));

Usually that's much more useful than trying to print them at runtime.

Also this has a typo:

>> the compiler run out of memory at nine features

*runs* out of memory or *ran* out of memory.

About this:
>> Compilation times for the D implementation are negligible for up to seven features. The compilation of eight features took two minutes, and the compiler run out of memory at nine features.

You might want to mention that the reason is that the compile-time interpreter simply hasn't been fitted with a garbage collector yet. Actually there are hooks in DMD for using GC internally -- I think the LLVMDC folks experimented with turning it on.  It did make that CTFE problem go away, but there was another problem elsewhere that cropped up.  LLVMDC folks correct me if I'm wrong on that.

--bb

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gbbos9$1l0p$1@digitalmars.com...
> http://www.artima.com/cppsource/codefeaturesP.html
>
> Andrei

Very cool, and very useful.. I really wish D would support 'features' natively. nothrow, pure, they all share the same behaviour: nothrow function can only call other functions with nothrow; pure function can only call functions with pure.. etc... Can't this be generalized?

L. 

>>> Compilation times for the D implementation are negligible for up to seven features. The compilation of eight features took two minutes, and the compiler run out of memory at nine features.
> 
> You might want to mention that the reason is that the compile-time interpreter simply hasn't been fitted with a garbage collector yet. Actually there are hooks in DMD for using GC internally -- I think the LLVMDC folks experimented with turning it on.  It did make that CTFE problem go away, but there was another problem elsewhere that cropped up.  LLVMDC folks correct me if I'm wrong on that.
> 
> --bb

That's exactly right. The DMD frontend seems to be developed with the Boehm GC in mind and we used it at first. It kept CTFE memory usage down. However, after an LLVM upgrade we started to get unpredictable segfaults that went away when we disabled the compiler GC. Since DMD shows the same memory leaking behaviour, it must also have the GC switched off.

Christian

On Wed, 24 Sep 2008 01:59:39 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> http://www.artima.com/cppsource/codefeaturesP.html
>
> Andrei

Good, but I thought D code would look better :(
And it's not as extendable, because NoFeatures interface should know all the possible base interfaces (which is counter intuitive as well).

Bill Baxter schrieb:
> you might want to also mention that you can debug such strings at
> *compile time* too using something like:
> 
> pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested", "Portable"]));
> 
Doesn't work for me. It expects a string literal.

On Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool@gmx.de> wrote:
> Bill Baxter schrieb:
>>
>> you might want to also mention that you can debug such strings at *compile time* too using something like:
>>
>> pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested",
>> "Portable"]));
>>
> Doesn't work for me. It expects a string literal.

Then your implementation of declareAllFeatures is maybe not CTFE-able.

This works (D1.035):

string declareAllFeatures(string[] features)
{
    string ret;
    foreach(f; features) {
        ret ~= "Feature: " ~ f ~ "\n";
    }
    return ret;
}
pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested", "Portable"]));
void main() {}


--bb

Bill Baxter schrieb:
> On Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool@gmx.de> wrote:
>> Bill Baxter schrieb:
>>> you might want to also mention that you can debug such strings at
>>> *compile time* too using something like:
>>>
>>> pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested",
>>> "Portable"]));
>>>
>> Doesn't work for me. It expects a string literal.
> 
> Then your implementation of declareAllFeatures is maybe not CTFE-able.
> 
Oh I'm sorry, I should have mentioned I didn't try that particular code.
But the lua bindings available at dsource use some mixins, so the function returning the string for the mixin must be executable at compile time.

On Thu, Sep 25, 2008 at 9:23 AM, Hoenir <mrmocool@gmx.de> wrote:
> Bill Baxter schrieb:
>>
>> On Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool@gmx.de> wrote:
>>>
>>> Bill Baxter schrieb:
>>>>
>>>> you might want to also mention that you can debug such strings at *compile time* too using something like:
>>>>
>>>> pragma(msg, "FEATURE CODE:\n" ~ declareAllFeatures (["Tested",
>>>> "Portable"]));
>>>>
>>> Doesn't work for me. It expects a string literal.
>>
>> Then your implementation of declareAllFeatures is maybe not CTFE-able.
>>
> Oh I'm sorry, I should have mentioned I didn't try that particular code. But the lua bindings available at dsource use some mixins, so the function returning the string for the mixin must be executable at compile time.

In that case you did something else wrong.  pragma(msg, ...) works. We can't help you if you don't give us any information.

--bb

Lionello Lunesu wrote:
> Very cool, and very useful.. I really wish D would support 'features' natively. nothrow, pure, they all share the same behaviour: nothrow function can only call other functions with nothrow; pure function can only call functions with pure.. etc... Can't this be generalized?

Both pure and nothrow are deeply embedded into the semantic analysis. I don't see any way to generalize it. For example,

 void foo() nothrow
 {
    try
    {
          throw new Bar;
    }
    catch (Object o)
    {
    }
 }

is valid code, while:


 void foo() nothrow
 {
    throw new Bar;
 }

should issue a compile time error.