www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Article on code features in C++ by Scott Meyers + sidebar on D implementation

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.artima.com/cppsource/codefeaturesP.html

Andrei
Sep 23 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
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
Sep 23 2008
next sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
 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
Sep 23 2008
prev sibling parent reply Hoenir <mrmocool gmx.de> writes:
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"]));
 

Sep 24 2008
parent Hoenir <mrmocool gmx.de> writes:
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"]));


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

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.
Sep 24 2008
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"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.
Sep 23 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Sep 26 2008
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gbjqan$2lh0$1 digitalmars.com...
 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.

Is see your point. Isn't that similar, though, to the functionality of "Relaxing feature constraints" from Scott Meyer's paper? The try-catch-scope can be considered "nothrow" because it can be called from other nothrow code. But inside the try-catch scope the constraint is relaxed and not-nothrow code (code that can throw) is accepted. I know next to nothing about compilers' inner workings, but it sounds like a small rule could be attached to try scopes. L.
Sep 26 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbk27p$14n$1 digitalmars.com>, lionello lunesu.remove.com 
says...
 
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gbjqan$2lh0$1 digitalmars.com...
 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.

Is see your point. Isn't that similar, though, to the functionality of "Relaxing feature constraints" from Scott Meyer's paper? The try-catch-scope can be considered "nothrow" because it can be called from other nothrow code. But inside the try-catch scope the constraint is relaxed and not-nothrow code (code that can throw) is accepted. I know next to nothing about compilers' inner workings, but it sounds like a small rule could be attached to try scopes.

Try-catch is not an ultimate protection. The nothrow requirement is relaxed only for a class of exceptions it catches. The following code violates the nothrow contract: class Bar {} void foo() nothrow { try { throw new Bar; } catch (Exception e) { } }
Sep 26 2008
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
 Try-catch is not an ultimate protection.  The nothrow requirement is 
 relaxed only for a class of exceptions it catches.  

You're right.. Good point. L.
Sep 26 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
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).
Sep 24 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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"]));


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
Sep 24 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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"]));


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

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
Sep 24 2008