Timon Gehr | 1 Jun 2011 01:00
Picon
Picon

Re: [Article Submission] Have Your Efficiency, and Flexibility Too

Nick Sabalausky wrote:
>"Timon Gehr" <timon.gehr <at> gmx.ch> wrote in message
>news:is2lts$2fcn$1 <at> digitalmars.com...
>> bearophile wrote:
>>> ...
>>> A shorter way to write it:
>>>
>>> void addGizmos(int numPorts, bool isSpinnable, int numGizmos) {
>>>     foreach (np; TypeTuple!(1, 2, 3, 5, 10))
>>>         if (numPorts == np) {
>>>             foreach (b; TypeTuple!(true, false))
>>>                 if (isSpinnable == b)
>>>                     addGizmosTo!(np, b)(numGizmos);
>>>             return;
>>>         }
>>>
>>>     throw new Exception(text(numPorts) ~ "-port Gizmo not supported.");
>>> }
>>>
>>> Bye,
>>> bearophile
>>
>> Nice, but isSpinnable is always checked twice with your approach. Better:
>>
>> void addGizmos(int numPorts, bool isSpinnable, int numGizmos) {
>>    foreach (np; TypeTuple!(1, 2, 3, 5, 10))
>>        if (numPorts == np) {
>>                if (isSpinnable) addGizmosTo!(np, true)(numGizmos);
>>                else addGizmosTo!(np, false)(numGizmos);
>>            return;
(Continue reading)

Nick Sabalausky | 1 Jun 2011 01:24

Re: [Article Submission] Have Your Efficiency, and Flexibility Too

"Timon Gehr" <timon.gehr <at> gmx.ch> wrote in message 
news:is3rb5$1g32$1 <at> digitalmars.com...
>
> Nick Sabalausky wrote:
>>
>> "Timon Gehr" <timon.gehr <at> gmx.ch> wrote in message
>> news:is2lts$2fcn$1 <at> digitalmars.com...
>> >
>> >  <at> Article: A very good read, it does not get boring even though it is 
>> > quite
>> > long. I
>> > like it.
>> >
>>
>> Thanks :)
>>
>> > Small nitpick:
>> > mixin(declareInterface("IGizmo", "Gizmo!(numPorts, isSpinnable)"));
>> >
>> > It seems like this should be a mixin template, not a string mixin. Also
>> > you
>> > wouldn't normally want to specify ThisType. Use typeof(this):
>> >
>> > mixin template declareInterface(string interfaceName){
>> >    mixin(`enum _this_implements_interface_`~interfaceName~`=true;`);
>> >    mixin(`static assert(
>> >               is`~interfaceName~`!(typeof(this)),
>> >
>> >               "This type fails to implement `~interfaceName~`"
>> >           );`
(Continue reading)

Robert Clipsham | 1 Jun 2011 01:28
Gravatar

[Submission] Getting more fiber in your diet

Hi all,

Just posting my article submission for the article contest:

http://octarineparrot.com/article/view/getting-more-fiber-in-your-diet

It's a little piece on the usage/performance of threads and fibers in D.

--

-- 
Robert
http://octarineparrot.com/

Nick Sabalausky | 1 Jun 2011 01:32

Re: [Article Submission] Have Your Efficiency, and Flexibility Too

"Nick Sabalausky" <a <at> a.a> wrote in message 
news:is3tk5$1j2n$1 <at> digitalmars.com...
> "Timon Gehr" <timon.gehr <at> gmx.ch> wrote in message 
> news:is3rb5$1g32$1 <at> digitalmars.com...
>>
>> It works for me. Are you sure you did not accidentally break some other 
>> part of
>> your __traits(compiles,...) ?
>>
>> My minimal test case:
>>
>> template isIGizmo(T){enum isIGizmo=__traits(compiles,{static
>> assert(T._this_implements_interface_IGizmo);});}
>>
>> mixin template declareInterface(string interfaceName){
>>    mixin(`enum _this_implements_interface_`~interfaceName~`=true;`);
>>    mixin(`static assert(
>>
>>               is`~interfaceName~`!(typeof(this)),
>>
>>               "This type fails to implement `~interfaceName~`"
>>
>>           );`
>>    );
>> }
>>
>> struct Gizmo{mixin declareInterface!"IGizmo";}
>>
>> static assert(isIGizmo!Gizmo);
>>
(Continue reading)

Nick Sabalausky | 1 Jun 2011 01:52

Re: [Article Submission] Have Your Efficiency, and Flexibility Too

"Nick Sabalausky" <a <at> a.a> wrote in message 
news:is22gk$1v03$1 <at> digitalmars.com...
> Getting in just under the wire here. I seem to have misjudged the scope of 
> my topic, it ended up a bit large... Anyway, here's my entry:
>
> http://www.semitwist.com/articles/EfficientAndFlexible/SinglePage/
>

Thanks everyone for all the great suggestions. With 10 minutes now until 
midnight GMT, I've incorporated all the changes that I was able to get 
working.

Jonathan M Davis | 1 Jun 2011 02:58
Picon
Favicon

Re: [Submission] D Slices

On 2011-05-31 15:03, Andrei Alexandrescu wrote:
> On 5/31/11 4:46 PM, KennyTM~ wrote:
> > On Jun 1, 11 05:37, Andrej Mitrovic wrote:
> >> If you didn't have fallback, you would probably have to add some kind
> >> of new statement like "goto next" or "fallback" on each of those
> >> cases.
> > 
> > It already exists. It is called#
> > 
> > goto case;
> 
> Sigh. Unless it's a recent addition, I didn't know about it, Walter
> missed the case during proofreading, and consequently that's not
> documented in TDPL.

He probably always uses implicit fallthrough in his own code, and we know that 
he doesn't use fallthrough in switch statements as much as he thought that he 
did, so I suppose that it's not a great surprise that he miissed it. It would 
have been nice to have it in TDPL though.

- Jonathan M Davis

Walter Bright | 1 Jun 2011 03:38
Favicon
Gravatar

Re: [Submission] D Slices

On 5/31/2011 10:57 AM, Andrei Alexandrescu wrote:
> As I mentioned, the issues involved are of increasing subtlety.

Thanks, Andrei. I think this is a pretty awesome summary of the issues.

bearophile | 1 Jun 2011 03:51
Picon

Re: [Article Submission] Have Your Efficiency, and Flexibility Too

Nick Sabalausky:

> Error: template instance cannot use local 'np' as parameter to non-global 
> template addGizmosTo(int numPorts,bool isSpinnable)

Are you able to reduce this to a minimal test case?

Bye,
bearophile

Andrei Alexandrescu | 1 Jun 2011 03:57

Re: [Submission] D Slices

On 05/31/2011 07:58 PM, Jonathan M Davis wrote:
> On 2011-05-31 15:03, Andrei Alexandrescu wrote:
>> On 5/31/11 4:46 PM, KennyTM~ wrote:
>>> On Jun 1, 11 05:37, Andrej Mitrovic wrote:
>>>> If you didn't have fallback, you would probably have to add some kind
>>>> of new statement like "goto next" or "fallback" on each of those
>>>> cases.
>>>
>>> It already exists. It is called#
>>>
>>> goto case;
>>
>> Sigh. Unless it's a recent addition, I didn't know about it, Walter
>> missed the case during proofreading, and consequently that's not
>> documented in TDPL.
>
> He probably always uses implicit fallthrough in his own code, and we know that
> he doesn't use fallthrough in switch statements as much as he thought that he
> did, so I suppose that it's not a great surprise that he miissed it. It would
> have been nice to have it in TDPL though.
>
> - Jonathan M Davis

Probably it would be best to take this opportunity to make the language 
change and then document it in a future edition of the book. With "goto 
case;" reducing the incremental cost of falling through to near 
non-existence, I think there is no excuse to keep the current behavior.

Also, I think the runtime error on not handling all cases should be 
eliminated as well. It's very non-D-ish and error prone in the extreme 
(Continue reading)

Jonathan M Davis | 1 Jun 2011 04:11
Picon
Favicon

Re: [Submission] D Slices

On 2011-05-31 18:57, Andrei Alexandrescu wrote:
> On 05/31/2011 07:58 PM, Jonathan M Davis wrote:
> > On 2011-05-31 15:03, Andrei Alexandrescu wrote:
> >> On 5/31/11 4:46 PM, KennyTM~ wrote:
> >>> On Jun 1, 11 05:37, Andrej Mitrovic wrote:
> >>>> If you didn't have fallback, you would probably have to add some kind
> >>>> of new statement like "goto next" or "fallback" on each of those
> >>>> cases.
> >>> 
> >>> It already exists. It is called#
> >>> 
> >>> goto case;
> >> 
> >> Sigh. Unless it's a recent addition, I didn't know about it, Walter
> >> missed the case during proofreading, and consequently that's not
> >> documented in TDPL.
> > 
> > He probably always uses implicit fallthrough in his own code, and we know
> > that he doesn't use fallthrough in switch statements as much as he
> > thought that he did, so I suppose that it's not a great surprise that he
> > miissed it. It would have been nice to have it in TDPL though.
> > 
> > - Jonathan M Davis
> 
> Probably it would be best to take this opportunity to make the language
> change and then document it in a future edition of the book. With "goto
> case;" reducing the incremental cost of falling through to near
> non-existence, I think there is no excuse to keep the current behavior.
> 
> Also, I think the runtime error on not handling all cases should be
(Continue reading)


Gmane