Re: For those ready to take the challenge
On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro From the link: Let's show Stroustrup what small and readable program actually is. Alright, there are a lot a examples in many languagens, but those examples doesn't should handle exceptions like the original code does? Matheus.
Re: A nice D coding pattern
On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: And the @disable this() assures that a struct is correctly initialized by the constructor. In the statement: @disable this() May I understand that you're disabling the default constructor of the struct to use your own constructor? Matheus.
Re: A nice D coding pattern
On Tuesday, 25 November 2014 at 13:56:23 UTC, bearophile wrote: Right. So the instance data of the struct is more likely correct when you call its methods. Thanks. - Well I'd like to see more of these tips. My current code in D looks like C++ and of course I sure that I'm not extracting the power of D. In fact lately I was looking around the Phobos source to open my mind for new features. Matheus.
Re: How to start with d lang.
On Sunday, 2 November 2014 at 20:49:00 UTC, Kornel wrote: What learning materials do you recommend ?? http://ddili.org/ders/d.en/ Matheus.
Re: Reflections on isPalindrome
On Tuesday, 28 October 2014 at 16:07:38 UTC, MachineCode wrote: I'm very surprise. If they either equal or fast sometimes the compiler did great optizations or it's just a multicore processor that's helping or what else? the first version (from your post, the one using ranges) change in each iteration two pointers (in pop*() calls) and request r's length 3 times (in .empty calls) while the second doesn't, just run until an already know index (when enter in the loop) and access two index in each iteration. This without consider the amount of ifs. I don't know, maybe I just thinking in the C-way as that code would run. Yes, I'm curious about this too. I will check the assembly output later (When I have free time) to understand what is happening and why popFront/Back are faster than a loop. Matheus.
Re: Reflections on isPalindrome
Hi,
I don't know if I'm missing something but I did some tests with
the popFront and popBack version:
bool isPalindrome(R)(R range)
if (isBidirectionalRange!(R))
{
while (!range.empty){
if (range.front != range.back) return false;
range.popFront();
if (range.empty) break;
range.popBack();
}
return true;
}
Against the older known version (or implementation):
bool isPalindrome2(R)(R r){
auto len = r.length;
auto mid = len/2;
--len;
for(auto i=0;imid;++i){
if(r[i]!=r[len-i]){
return false;
}
}
return true;
}
And in my benchmark test, the first version is 3x slower than
the second one.
Matheus.
Re: Reflections on isPalindrome
On Tuesday, 28 October 2014 at 11:48:37 UTC, MattCoder wrote: And in my benchmark test, the first version is 3x slower than the second one. I forgot to say that I'm compiling with DMD without any compiler hints/optimizations. Matheus.
Re: Reflections on isPalindrome
On Tuesday, 28 October 2014 at 13:30:05 UTC, Nordlöw wrote: On Tuesday, 28 October 2014 at 11:51:42 UTC, MattCoder wrote: I forgot to say that I'm compiling with DMD without any compiler hints/optimizations. Try compiling with DMD flag -release and perhaps also -release -noboundscheck to get relevant results. DMD is currently not that good at inlining range primitives. Interesting! With -release the second version still faster but only by 10%. Now with: -release -noboundscheck they are equal and sometimes your version is slightly faster by ~3 milliseconds. Matheus.
Re: Reducing an array
On Friday, 18 April 2014 at 20:02:41 UTC, Tim Holzschuh via
Digitalmars-d-learn wrote:
Hi there,
I try to remove all equal elements of an array, thus [2,2] --
[2].
I thought this maybe would be possible with
std.algorithm.reduce, but at least the way I tried it doesn't
work:
arr.reduce( (a,b) = a != b );
Is there a simple solution using Phobos-functions?
Not too fancy, since I'm new in D, but I created this:
import std.stdio;
import std.array;
import std.algorithm;
static if (!is(typeof(writeln)))
alias writefln writeln;
void main(){
int myfilter(int a){
static int[] b;
if(b.find(a) == []){
b.insertInPlace(b.length, a);
return a;
}
return -1;
}
auto arr = [1,1,2,3,2,2,4,5,5,1];
auto arrFiltered = arr.filter!(a = myfilter(a) 0);
writeln(arrFiltered);
}
Tested: http://dpaste.dzfl.pl/97a1307c7fec
I'm looking for creating something like C# extensions, maybe
with alias. I'll try later!
Matheus.
Re: Reducing an array
On Saturday, 19 April 2014 at 17:12:10 UTC, Ali Çehreli wrote:
On 04/19/2014 09:55 AM, MattCoder wrote:
On Friday, 18 April 2014 at 20:02:41 UTC, Tim Holzschuh via
Digitalmars-d-learn wrote:
void main(){
int myfilter(int a){
static int[] b;
That static variable makes this solution non-reentrant...
Yes, you're completely right and I already knew that. But
remember Like I said previously, I would like to convert that
code to something close to extensions in C#, in that case I can
take the address of the array to check if it's a new Filter or
not. for example, current in D I can do this:
import std.stdio;
import std.array;
import std.range;
import std.algorithm;
void main(){
int myfilter(int[] *addr, int a){
static int[] b;
static int[] *address;
if(address != addr){
address = addr;
b.clear();
}
if(!b.canFind(a)){
b.insertInPlace(b.length, a);
return a;
}
return -1;
}
auto arr = [1,1,2,3,2,2,4,5,5,1];
auto arr2 = [3,4,3,9,9,7,4,4,4,7];
auto arrFiltered = arr.filter!(a = myfilter(arr, a) = 0);
writeln(arrFiltered);
auto arrFiltered2 = arr2.filter!(a = myfilter(arr2, a) = 0);
writeln(arrFiltered2);
}
But with extensions, the argument address (i.e: arr) on the
calling of myfilter can be avoided!
Matheus.
