Re: Knowing the approach to solve a D challenge

On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? In micro-level, it's usually fairly idiomatic from get-go. Usually no heap allocations at inner loops, for-looping, static

Re: Knowing the approach to solve a D challenge

On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? As idiomatic

Re: Knowing the approach to solve a D challenge

I don't write much D code, but here are my answers for _any_ language. On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style

Re: Knowing the approach to solve a D challenge

On 16/02/2018 9:44 AM, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? 2. Do you find yourself mostly

Knowing the approach to solve a D challenge

D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? 2. Do you find yourself mostly rolling out your own implementation

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On 2/15/18 2:11 PM, Seb wrote: I reworded the entire paragraph and it now shows the AST: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d/#4-whats-up-with-this-enforce eh... "string which is an alias for an array of const(char) elements" It's not actu

Re: The Expressive C++17 Coding Challenge in D

On Thursday, 15 February 2018 at 16:22:17 UTC, Steven Schveighoffer wrote: On 2/13/18 6:35 PM, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so

Re: The Expressive C++17 Coding Challenge in D

On 2/13/18 6:35 PM, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge

Re: The Expressive C++17 Coding Challenge in D

On 2/13/2018 3:35 PM, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 20:37:24 UTC, bachmeier wrote: There's (almost) no such thing as bad publicity... Programming languages and operating systems have a long history of hot advocacy... not sure how it relates to adoption, but it affects perception. E.g. vocal mac users gave

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 20:14:41 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 14 February 2018 at 19:40:12 UTC, Seb wrote: https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d It is getting shot down… That's implied when someone says it's

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 19:40:12 UTC, Seb wrote: https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d It is getting shot down…

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 18:55:23 UTC, bachmeier wrote: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 18:33:33 UTC, Jacob Carlborg wrote: On 2018-02-14 19:00, Ola Fosheim Grøstad wrote: For a fair comparison Swift should only use libraries that are available both on macOS and Linux. Are any projects using Swift outside of the Mac eco system? Would it be more

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On 2018-02-14 19:00, Ola Fosheim Grøstad wrote: For instance, Swift drags in all of Os-X on the default platform, so writing an audio/video loader would be relatively short in comparison to other languages. Would that be fair or instructive? Of course not. The Os-X libraries are quite

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele wrote: But even then, I don't think you should discount or put off using std.csv as "cheating". Yes and no. The problem with all these exercises is that they say nothing about the language and a lot about some default library,

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele wrote: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 14:17:31 UTC, Seb wrote: changed the text to: ...and D even supports native interoperability with C and most of C++. Great!

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 10:17:21 UTC, psychoticRabbit wrote: I believe the programming langauges of the future, and the ones people should invest their time learning, are those that can be best understood in the least amount of time. Yes, I would say so, unless they bring something

Re: The Expressive C++17 Coding Challenge in D

On Wed, 2018-02-14 at 13:21 +, Seb via Digitalmars-d-announce wrote: > On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder > wrote: > > Seb, > > > > I believe this blog post would make a great article for > > Overload or CVu. > > Cool idea, but I'm not so familiar with these.

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 08:06:13 UTC, Mike Franklin wrote: Aren’t you concered that Rust is faster in this benchmark? Not at all. The challenge was to write expressive code and if performance really matters I can always opt to optimize the hot path of the program and don’t need

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder wrote: Seb, I believe this blog post would make a great article for Overload or CVu. Cool idea, but I'm not so familiar with these. What can/should I do to make this happen? We can also talk in private (seb [at] wilzba [dot]

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much I first looked into C++ and Rust examples

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 09:50:31 UTC, Ola Fosheim Grøstad wrote: If C++ isn't viewed as a competitor, why bother with repetitive complaining about C++? Because it doesn't get enough criticism ;-) I believe the programming langauges of the future, and the ones people should invest

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 09:28:48 UTC, psychoticRabbit wrote: yeah.. even the more modern C++ code still makes me want to stay clear of it...(perhaps even more so). I just never get the same feeling when I look at D programs. I get the same feeling from both languages, to be honest.

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

Seb, I believe this blog post would make a great article for Overload or CVu. On Tue, 2018-02-13 at 23:35 +, Seb via Digitalmars-d-announce wrote: > Someone revived the Expressive C++17 Coding Challenge thread > today and I thought this is an excellent opportunity to revive my

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote: 14.02.2018 11:45, Ola Fosheim Grøstad пишет: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote: It's sadly that using most C++17 features fails to provide clean and compact solution... I don't usually use iostream, but this "challenge" was a reasonable fit for it. If you look over the 4 submissions then the io

Re: The Expressive C++17 Coding Challenge in D

14.02.2018 11:45, Ola Fosheim Grøstad пишет: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 06:42:23 UTC, Arun Chandrasekaran wrote: It takes a lot of time and effort to write such quality content. Thanks for detailed explanations. Thanks :) Now if we had a magic automaton that makes more of these ... // import std.algorithm, std.exception,

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 07:11:08 UTC, Nicholas Wilson wrote: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 02:57:28 UTC, ketmar wrote: Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 03:40:41 UTC, jmh530 wrote: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02

Re: The Expressive C++17 Coding Challenge in D

On 02/13/2018 03:35 PM, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge

The Expressive C++17 Coding Challenge in D

Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted

Re: For fun: Expressive C++ 17 Coding Challenge in D

Another solution using dlangs builtin csv support for reading. import std.csv; import std.file; import std.algorithm : map; import std.range; string csvWrite(Header, Rows)(Header header, Rows rows) { return header.join(",") ~ "\n" ~ rows.map!(r => header.map!(h =>

Re: For fun: Expressive C++ 17 Coding Challenge in D

I am a total beginner but I want to post that a lot. auto autoCorrelation(R)(R range) if (isRandomAccessRange!R) { import std.numeric : fft, inverseFft; import std.range : chain, repeat, zip, dropBack; import std.algorithm : map; import std.complex;

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Wednesday, 4 October 2017 at 19:20:12 UTC, Jesse Phillips wrote: On Wednesday, 4 October 2017 at 15:26:02 UTC, Ali Çehreli wrote: On 10/04/2017 02:04 AM, Biotronic wrote: ... Hey where is the list of features used e.g: ranges, ufcs... Features used: D. But sure, added them to the gist:

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Wednesday, 4 October 2017 at 15:30:08 UTC, Ali Çehreli wrote: the hidden \r characters at the ends Those got me too! Here's my less than optimal solution: int main(string[] args) { import std.stdio; import std.algorithm.iteration : map, splitter, joiner, each; import

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Wednesday, 4 October 2017 at 15:26:02 UTC, Ali Çehreli wrote: On 10/04/2017 02:04 AM, Biotronic wrote: ... Hey where is the list of features used e.g: ranges, ufcs...

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Wednesday, 4 October 2017 at 15:30:08 UTC, Ali Çehreli wrote: On 10/04/2017 02:26 AM, Atila Neves wrote: > in D so trivial it'd probably make me sleep out of boredom. I spent more time on this obviously trivial program than necessary. :( In addition to facing known template resolution

Re: For fun: Expressive C++ 17 Coding Challenge in D

On 10/04/2017 02:26 AM, Atila Neves wrote: > in D so trivial it'd probably make me sleep out of boredom. I spent more time on this obviously trivial program than necessary. :( In addition to facing known template resolution issues, the hidden \r characters at the ends of some of the fields in

Re: For fun: Expressive C++ 17 Coding Challenge in D

On 10/04/2017 02:04 AM, Biotronic wrote: > I opted for writing to stdout instead, because 1) it's easier, x) it's > less code, and b) it's more flexible. Exactly! :) > a simple replacement of readText with an mmapped equivalent should > enable humongous file support with no other code change

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Wednesday, 4 October 2017 at 09:04:58 UTC, Biotronic wrote: Since the code uses ranges though, a simple replacement of readText with an mmapped equivalent should enable humongous file support with no other code change required. Drop-in replacement for readText: struct MmText { import

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Tuesday, 3 October 2017 at 19:25:56 UTC, Ali Çehreli wrote: Found on Reddit: https://www.reddit.com/r/programming/comments/740617/the_expressive_c17_coding_challenge/ How would you do it in D? Ali P.S. You can ignore the following note from the challenge text; I don't think it applies

Re: For fun: Expressive C++ 17 Coding Challenge in D

On Tuesday, 3 October 2017 at 19:25:56 UTC, Ali Çehreli wrote: Found on Reddit: https://www.reddit.com/r/programming/comments/740617/the_expressive_c17_coding_challenge/ How would you do it in D? Ali P.S. You can ignore the following note from the challenge text; I don't think it applies

For fun: Expressive C++ 17 Coding Challenge in D

Found on Reddit: https://www.reddit.com/r/programming/comments/740617/the_expressive_c17_coding_challenge/ How would you do it in D? Ali P.S. You can ignore the following note from the challenge text; I don't think it applies to D. Honestly, I don't think it matters for C++17 either

Challenge on Russian Stack Overflow

I found funny (from my point of view) challenge in Russian Stack Overflow. Any language accepted. You need to make the loop for (int x=0; x<3; ++x) {} endless. Rules: - you can't modify the loop's code itself; - you can't modify the loop's variable inside the body of loop; - you can't w

Re: Challenge

On 6 October 2016 at 01:07, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, October 06, 2016 00:38:54 Manu via Digitalmars-d wrote: >> I thought there was a distinction between typetuple and alias? Some >> expression can be captured by a typetuple, but not by

Re: Challenge

On Thursday, October 06, 2016 00:38:54 Manu via Digitalmars-d wrote: > I thought there was a distinction between typetuple and alias? Some > expression can be captured by a typetuple, but not by alias? > There must be a reason for that horrible and prolific pattern "(T...) > if(T.length == 1) {

Re: Challenge

On 5 October 2016 at 19:45, Jonathan M Davis via Digitalmars-d wrote: > On Wednesday, October 05, 2016 09:24:56 John Colvin via Digitalmars-d wrote: >> > It _is_ however recommended to use __traits(getMember, T, >> > member) over manually building it with strings with

Re: Challenge

On Wednesday, October 05, 2016 09:24:56 John Colvin via Digitalmars-d wrote: > > It _is_ however recommended to use __traits(getMember, T, > > member) over manually building it with strings with something > > like T.stringof ~ "." ~ member, because the string manipulation > > falls about in corner

Re: Challenge

On Wednesday, 5 October 2016 at 02:15:13 UTC, Jonathan M Davis wrote: On Wednesday, October 05, 2016 11:20:44 Manu via Digitalmars-d wrote: > While you're at it, might I suggest also adding > std.traits.isProperty? > > Something like: > template isProperty(T, string member) > { > > import

Re: Challenge

On Wednesday, 5 October 2016 at 02:15:13 UTC, Jonathan M Davis wrote: The AliasSeq muck is there because for some reason you can't alias the result of __traits, so doing something like alias sym = __traits(getMember, T, member); isn't legal. So, this has nothing to do with a recommendation

Re: Challenge

On Wednesday, October 05, 2016 11:20:44 Manu via Digitalmars-d wrote: > > While you're at it, might I suggest also adding std.traits.isProperty? > > > > Something like: > > template isProperty(T, string member) > > { > > > > import std.meta : AliasSeq; > > import std.traits : FunctionTypeOf;

Re: Challenge

On 4 October 2016 at 22:48, Manu wrote: > On 4 October 2016 at 14:40, Jonathan M Davis via Digitalmars-d > wrote: >> On Tuesday, October 04, 2016 14:24:59 Manu via Digitalmars-d wrote: >>> On 4 October 2016 at 12:30, Jonathan M Davis via

Re: Challenge

On 4 October 2016 at 14:40, Jonathan M Davis via Digitalmars-d wrote: > On Tuesday, October 04, 2016 14:24:59 Manu via Digitalmars-d wrote: >> On 4 October 2016 at 12:30, Jonathan M Davis via Digitalmars-d >> >> wrote: >> > On Tuesday,

Re: Challenge

On 4 October 2016 at 14:40, Jonathan M Davis via Digitalmars-d wrote: > [...] > For that matter, even testing whether something is a variable is > surprisingly difficult. True story! I've written that one before... I spent ages trying to get it right! When people say

Re: Challenge

On Tuesday, October 04, 2016 14:24:59 Manu via Digitalmars-d wrote: > On 4 October 2016 at 12:30, Jonathan M Davis via Digitalmars-d > > wrote: > > On Tuesday, October 04, 2016 11:13:36 Manu via Digitalmars-d wrote: > >> I'm feeling John's solution is a little bit

Re: Challenge

On 4 October 2016 at 12:30, Jonathan M Davis via Digitalmars-d wrote: > On Tuesday, October 04, 2016 11:13:36 Manu via Digitalmars-d wrote: >> I'm feeling John's solution is a little bit simpler. But nice work, thanks! > > So, it is. LOL. I'd actually glanced over

Re: Challenge

On Tuesday, October 04, 2016 11:13:36 Manu via Digitalmars-d wrote: > I'm feeling John's solution is a little bit simpler. But nice work, thanks! So, it is. LOL. I'd actually glanced over that post while I was in the middle of getting my version to work, and I read it too quickly, because I

Re: Challenge

On 4 October 2016 at 05:01, Jonathan M Davis via Digitalmars-d wrote: > On Monday, October 03, 2016 11:13:52 Jonathan M Davis via Digitalmars-d wrote: >> template isStaticMember(T, string member) >> { >> static if (!__traits(hasMember, T, member)) >> enum

Re: Challenge

On 4 October 2016 at 00:25, John Colvin via Digitalmars-d wrote: > On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: >> >> Fill in the blank... >> I'm having a really hard time with this. I've made it work with a >> mountain of code, and I want to see what others

Re: Challenge

On Monday, October 03, 2016 11:13:52 Jonathan M Davis via Digitalmars-d wrote: > template isStaticMember(T, string member) > { > static if (!__traits(hasMember, T, member)) > enum bool isStaticMember = false; > else > { > import std.meta : AliasSeq; > import

Re: Challenge

On 10/03/2016 07:41 AM, Seb wrote: On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... If you succeed, put it in std.traits! Recommend, use

Re: Challenge

On Monday, October 03, 2016 08:38:22 Jonathan M Davis via Digitalmars-d wrote: > On Monday, October 03, 2016 23:19:19 Manu via Digitalmars-d wrote: > > Fill in the blank... > > I'm having a really hard time with this. I've made it work with a > > mountain of code, and I want to see what others

Re: Challenge

On Monday, October 03, 2016 23:19:19 Manu via Digitalmars-d wrote: > Fill in the blank... > I'm having a really hard time with this. I've made it work with a > mountain of code, and I want to see what others come up with... It's certainly possible that this misses something, but it passes all of

Re: Challenge

On Monday, October 03, 2016 23:19:19 Manu via Digitalmars-d wrote: > Fill in the blank... > I'm having a really hard time with this. I've made it work with a > mountain of code, and I want to see what others come up with... > > If you succeed, put it in std.traits! > > Recommend, use latest DMD

Re: Challenge

On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... If you succeed, put it in std.traits! Recommend, use latest DMD nightly. I find

Re: Challenge

On 3 October 2016 at 23:48, Manu wrote: > On 3 October 2016 at 23:41, Manu wrote: >> I'm finding this rather annoying: >> >> struct S >> { >> static @property int p() { return 10; } >> } >> >> pragma(msg, typeof()); // prints: int function() @property

Re: Challenge

On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... template isStaticMember(T, string member) { mixin(`alias mem = T.` ~ member ~

Re: Challenge

On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... [...] Dere's a typo static assert( isStaticMember!(S, "iosm"), "!"); Should be iosf

Re: Challenge

On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote: I'm finding this rather annoying: struct S { static @property int p() { return 10; } } pragma(msg, typeof()); // prints: int function() @property pragma(msg, is(typeof() == function)); // prints: false It looks like a function... but I

Re: Challenge

On 3 October 2016 at 23:50, John Colvin via Digitalmars-d wrote: > On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote: >> >> I'm finding this rather annoying: >> >> struct S >> { >> static @property int p() { return 10; } >> } >> >> pragma(msg, typeof()); //

Re: Challenge

On Monday, 3 October 2016 at 13:50:26 UTC, John Colvin wrote: The problem is that function pointers in "is" expressions don't match "function" or "delegate". static assert (is(void delegate() == delegate)); //passes static assert (is(void function() == function)); //fails static assert

Re: Challenge

On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote: I'm finding this rather annoying: struct S { static @property int p() { return 10; } } pragma(msg, typeof()); // prints: int function() @property pragma(msg, is(typeof() == function)); // prints: false It looks like a function... but I

Re: Challenge

On 3 October 2016 at 23:41, Manu wrote: > I'm finding this rather annoying: > > struct S > { > static @property int p() { return 10; } > } > > pragma(msg, typeof()); // prints: int function() @property > pragma(msg, is(typeof() == function)); // prints: false > > It looks

Re: Challenge

On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote: I'm finding this rather annoying: struct S { static @property int p() { return 10; } } pragma(msg, typeof()); // prints: int function() @property pragma(msg, is(typeof() == function)); // prints: false It looks like a function... but I

Re: Challenge

On Monday, 3 October 2016 at 13:19:19 UTC, Manu wrote: Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... If you succeed, put it in std.traits! Pretty easy: template isStaticMember(T, string

Re: Challenge

I'm finding this rather annoying: struct S { static @property int p() { return 10; } } pragma(msg, typeof()); // prints: int function() @property pragma(msg, is(typeof() == function)); // prints: false It looks like a function... but I can't identify it as a function!

Challenge

Fill in the blank... I'm having a really hard time with this. I've made it work with a mountain of code, and I want to see what others come up with... If you succeed, put it in std.traits! Recommend, use latest DMD nightly. I find differences with latest nightly vs release.

Re: Challenge: fair partition function

would have if r were sorted. Also, r[0 .. x] contains stuff no greater than r[x] and r[x + 1 .. $] contains stuff no less than r[x]. The challenge is to implement such a function with fairness: if several elements are equal to r[pivot], return the index closest to r.length / 2. The fu

Challenge: fair partition function

r than r[x] and r[x + 1 .. $] contains stuff no less than r[x]. The challenge is to implement such a function with fairness: if several elements are equal to r[pivot], return the index closest to r.length / 2. The function should be efficient, minimize calls to less and swap, etc. A v

Re: Challenge

= [1,2,3]; assert(test.foo(3).equal(only(4,5,6))); } Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map Ok, so now I feel stupid. Not only

Challenge

import std.algorithm, std.range; auto foo(R)(R a, immutable int b) { return a.map!(x = x + b); } unittest @nogc @safe { int[] test = [1,2,3]; assert(test.foo(3).equal(only(4,5,6))); } Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc

Re: Challenge

On Sunday, 30 August 2015 at 11:21:34 UTC, Russel Winder wrote: On Sun, 2015-08-30 at 10:38 +, John Colvin via Digitalmars-d wrote: On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote: [...] Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I

Re: Challenge

On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote: import std.algorithm, std.range; auto foo(R)(R a, immutable int b) { return a.map!(x = x + b); } unittest @nogc @safe { int[] test = [1,2,3]; assert(test.foo(3).equal(only(4,5,6))); } Challenge: reimplement `foo

<    1   2   3   4   5   6   7   >