December 08, 2017
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer wrote:
> On 12/7/17 8:11 PM, Mengu wrote:
>> On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
>>> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
>> 
>> wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
>> 
>
> You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there.
>
> Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance.
>
> -Steve

thanks for the explanation steve.

December 09, 2017
On Thursday, 7 December 2017 at 21:38:57 UTC, Daniel Kozak wrote:
> Yes using FILE* directly could be the way.  But using file.rawRead is still possible. But it is better to use static array with length one.

This can reflect absence of middle level resources like basic optimization techniques for D - it's too complex for tour and too obvious for experts. For interoperability with FILE* one must be really familiar with slices: remember in C arrays just work. And when one hears about memory allocation optimization in D one thinks about ranges, which is a bit involved already.
December 09, 2017
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer wrote:
> On 12/7/17 8:11 PM, Mengu wrote:
>> On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
>>> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
>> 
>> wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
>> 
>
> You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there.
>
> Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance.
>
> -Steve

As a new comer, I find these very educational. I wish there was a documentation or a book to warn D learners about these pitfalls.

"Effective D" when?  :D
December 09, 2017
On 12/9/17 5:55 AM, Kagamin wrote:
> On Thursday, 7 December 2017 at 21:38:57 UTC, Daniel Kozak wrote:
>> Yes using FILE* directly could be the way.  But using file.rawRead is still possible. But it is better to use static array with length one.
> 
> This can reflect absence of middle level resources like basic optimization techniques for D - it's too complex for tour and too obvious for experts. For interoperability with FILE* one must be really familiar with slices: remember in C arrays just work. And when one hears about memory allocation optimization in D one thinks about ranges, which is a bit involved already.

Yes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate.

In terms of arrays, they aren't much different in D than in C. Just with better checks for safety. In fact, you can use C arrays (T*) in D just fine, with the same syntax and problems.

-Steve
December 09, 2017
On Saturday, 9 December 2017 at 14:00:16 UTC, Steven Schveighoffer wrote:
> Yes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate.

What about this? https://dlang.org/ctod.html

December 09, 2017
On 12/9/17 12:11 PM, unleashy wrote:
> On Saturday, 9 December 2017 at 14:00:16 UTC, Steven Schveighoffer wrote:
>> Yes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate.
> 
> What about this? https://dlang.org/ctod.html
> 

Haven't read that before, and while it's a nice primer, it's focused mostly on the language, not the library (and kind of is a "look what D does better than C" post).

However, stuff like i/o, networking, string manipulation, etc would be useful.

In fact, a "recipe" guide keyed on what you want to accomplish would be cool. Maybe it already exists :)

I'm ashamed to admit I bought Adam Ruppe's book "D Cookbook" when he announced it at dconf 2014, but still haven't read it yet...

-Steve
December 11, 2017
On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote:
> On 12/7/17 6:46 AM, Daniel Kozak wrote:
>> Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author

You can see the compilation command line if you compile with ninja -v
December 12, 2017
Thanks, I will try that.

On Mon, Dec 11, 2017 at 7:34 PM, German Diago via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote:
>
>> On 12/7/17 6:46 AM, Daniel Kozak wrote:
>>
>>> Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author
>>>
>>
> You can see the compilation command line if you compile with ninja -v
>


1 2 3
Next ›   Last »