digitalmars.D.announce - Article on code features in C++ by Scott Meyers + sidebar on D implementation
- Andrei Alexandrescu (2/2) Sep 23 2008 http://www.artima.com/cppsource/codefeaturesP.html
- Bill Baxter (19/26) Sep 23 2008 Cool beans. A nice intro to the power of D template metaprogramming!
- Christian Kamm (6/18) Sep 23 2008 That's exactly right. The DMD frontend seems to be developed with the Bo...
- Hoenir (2/7) Sep 24 2008 Doesn't work for me. It expects a string literal.
- Bill Baxter (14/23) Sep 24 2008 Then your implementation of declareAllFeatures is maybe not CTFE-able.
- Hoenir (5/17) Sep 24 2008 Oh I'm sorry, I should have mentioned I didn't try that particular code.
- Bill Baxter (4/23) Sep 24 2008 In that case you did something else wrong. pragma(msg, ...) works.
- Lionello Lunesu (7/9) Sep 23 2008 Very cool, and very useful.. I really wish D would support 'features'
- Walter Bright (19/23) Sep 26 2008 Both pure and nothrow are deeply embedded into the semantic analysis. I
- Lionello Lunesu (10/33) Sep 26 2008 Is see your point.
- Sergey Gromov (16/57) Sep 26 2008 Try-catch is not an ultimate protection. The nothrow requirement is
- Lionello Lunesu (2/4) Sep 26 2008 You're right.. Good point.
- Denis Koroskin (5/7) Sep 24 2008 Good, but I thought D code would look better :(
http://www.artima.com/cppsource/codefeaturesP.html Andrei
Sep 23 2008
On Wed, Sep 24, 2008 at 6:59 AM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:http://www.artima.com/cppsource/codefeaturesP.html AndreiCool 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: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:Incidentally, the same string can be generated and printed at run time using this line of code: writeln (declareAllFeatures (["Tested", "Portable"]));*runs* out of memory or *ran* out of memory. About this:the compiler run out of memory at nine featuresYou 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. --bbCompilation 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.
Sep 23 2008
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. ChristianYou 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. --bbCompilation 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.
Sep 23 2008
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.
Sep 24 2008
On Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool gmx.de> wrote:Bill Baxter schrieb: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() {} --bbyou 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.
Sep 24 2008
Bill Baxter schrieb:On Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool gmx.de> wrote: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.Bill Baxter schrieb:Then your implementation of declareAllFeatures is maybe not CTFE-able.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.
Sep 24 2008
On Thu, Sep 25, 2008 at 9:23 AM, Hoenir <mrmocool gmx.de> wrote:Bill Baxter schrieb:In that case you did something else wrong. pragma(msg, ...) works. We can't help you if you don't give us any information. --bbOn Thu, Sep 25, 2008 at 7:31 AM, Hoenir <mrmocool gmx.de> wrote: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.Bill Baxter schrieb:Then your implementation of declareAllFeatures is maybe not CTFE-able.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.
Sep 24 2008
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message news:gbbos9$1l0p$1 digitalmars.com...http://www.artima.com/cppsource/codefeaturesP.html AndreiVery 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
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
"Walter Bright" <newshound1 digitalmars.com> wrote in message news:gbjqan$2lh0$1 digitalmars.com...Lionello Lunesu wrote: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.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
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...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) { } }Lionello Lunesu wrote: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.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
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
On Wed, 24 Sep 2008 01:59:39 +0400, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:http://www.artima.com/cppsource/codefeaturesP.html AndreiGood, 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