Few time ago I had open http://versusit.org site about comparison of languages and technologies. I have some stuff about D, but still not directly compared with C++. If anybody want to help me with articles and systematization of material I would very thanks.

Am 01.07.2013 03:07, schrieb Kapps:
> If you're concerned about performance, I'd recommend against
> using DMD for your release builds. GDC and LDC will give much
> better performance, and GDC works perfectly fine on Windows. LDC
> has some problems with exception handling AFAIK on Windows.

GDC got the same Exception problems like LDC - no support for SEH
but Exceptions are working - only the Windows-internal-Exception -> D-Exception transition is not working properbly

but even using Visual Studio you need to add special flags or using __try, __catch to get these - so normaly not a problem

On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:
> On Monday, July 01, 2013 04:37:43 Mehrdad wrote:
>> On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
>> > sometimes faster
>> 
>> Would love an example that demonstrates it!
>
> Anything involving taking a lot of substrings is likely to be faster in D
> thanks to slices (which is one of the main reasons that Tango's xml parser is
> so lightning fast). You could write the same code in C++, but it's harder,
> because slices aren't built-in, and you have no GC, probably forcing you to
> create your own string type that supports slices and does reference counting
> if you want a similar effect.
>
> - Jonathan M Davis

Well... in "C++", a slice is called an iterator pair. If you just:
typedef std::pair<std::string::const_iterator, const_itrator> string_slice;

Then there is no reason you can't do it... The only "problem" is that it is not a standard semantic in C++, so nobody ever thinks about doing this, and much less actually ever does it. There is a *little* bit of barrier to entry too.

I've done this once about two years ago (before I knew about D) because I needed a "subview" of a vector. My typedef's name was "shallow_vector". It was a fun experience given I didn't know about the range concept back then :)

In any case, if you *do* want to go there, it doesn't really require you creating that much new stuff, especially not your own string/vector type.

On Monday, July 01, 2013 08:28:54 monarch_dodra wrote:
> On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:
> > On Monday, July 01, 2013 04:37:43 Mehrdad wrote:
> >> On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:
> >> > sometimes faster
> >> 
> >> Would love an example that demonstrates it!
> > 
> > Anything involving taking a lot of substrings is likely to be
> > faster in D
> > thanks to slices (which is one of the main reasons that Tango's
> > xml parser is
> > so lightning fast). You could write the same code in C++, but
> > it's harder,
> > because slices aren't built-in, and you have no GC, probably
> > forcing you to
> > create your own string type that supports slices and does
> > reference counting
> > if you want a similar effect.
> > 
> > - Jonathan M Davis
> 
> Well... in "C++", a slice is called an iterator pair. If you just: typedef std::pair<std::string::const_iterator, const_itrator> string_slice;
> 
> Then there is no reason you can't do it... The only "problem" is that it is not a standard semantic in C++, so nobody ever thinks about doing this, and much less actually ever does it. There is a *little* bit of barrier to entry too.
> 
> I've done this once about two years ago (before I knew about D) because I needed a "subview" of a vector. My typedef's name was "shallow_vector". It was a fun experience given I didn't know about the range concept back then :)
> 
> In any case, if you *do* want to go there, it doesn't really require you creating that much new stuff, especially not your own string/vector type.

It does if you don't want to code your stuff in a manner that there's a specific piece of code which owns the string, since you've now separated the string from the slice. Sure, it's feasible, but it's not the same thing and requires you to code differently than you'd do it in D. Regardless, it requires you to code very differently from how you'd do it in C++, so while it's quite possible to do something similar to slices in C++, pretty much no one does.

- Jonathan M Davis

On Monday, 1 July 2013 at 04:50:29 UTC, Jonathan M Davis wrote:
> On Monday, July 01, 2013 06:27:15 Marco Leise wrote:
>> Am Sun, 30 Jun 2013 22:55:26 +0200
>> 
>> schrieb "Gabi" <galim120@bezeqint.net>:
>> > I wonder why is that.. Why would deleting 1 million objects in
>> > C++ (using std::shared_ptr for example) have to be slower than
>> > the garbage collection freeing a big chunk of million objects all
>> > at once.
>> 
>> I have no numbers, but I think especially when you have complex graph
>> structures linked with pointers, the GC needs a while to follow all
>> the links and mark the referenced objects as still in use. And this
>> will be done every now and then when you allocate N new objects.
>
> The other thing to consider is that when the GC runs, it has to figure out
> whether anything needs to be collected. And regardless of whether anything
> actually needs to be collected, it has to go through all of the various
> references to mark them and then to sweep them. With deterministic
> destruction, you don't have to do that. If you have a fairly small number of
> heap allocations in your program, it's generally not a big deal. But if you're
> constantly allocating and deallocating small objects, then the GC is going to
> be run a lot more frequently, and it'll have a lot more objects to have to
> examine. So, having lots of small objects which are frequently being created
> and destroyed is pretty much guaranteed to tank your performance if they're
> being allocated by the GC. You really want reference counting for those sorts
> of situations.

This is only true in the current D GC's situation.

Modern parallel compacting GCs don't suffer from this.

--
Paulo

On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz@gmx.net> wrote:
>
> Am 01.07.2013 03:07, schrieb Kapps:
>
>> If you're concerned about performance, I'd recommend against using DMD for your release builds. GDC and LDC will give much better performance, and GDC works perfectly fine on Windows. LDC has some problems with exception handling AFAIK on Windows.
>
>
> GDC got the same Exception problems like LDC - no support for SEH but Exceptions are working - only the Windows-internal-Exception ->
D-Exception transition is not working properbly
>
> but even using Visual Studio you need to add special flags or using
__try, __catch to get these - so normaly not a problem
>

Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
AFAIK, structured exception handling support in gcc is being developed to
overcome the weaknesses of both dw2 and sjlj.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2013-07-01 01:14, Steven Schveighoffer wrote:

> I think memory usage is still important.  Many people don't consider
> that their computer is running hundreds of programs at a time.  If each
> one of those "didn't care" about memory usage, the one that you are
> currently interested in would not have any breathing room.

I quite often run out of memory at work on my machine with 6GB of RAM when coding Ruby on Rails. I don't know if there's something I do with the code but sometimes something happens in the Ruby code making the Rails server take over 1GB of RAM from 300MB, the same thing happens with the web browser at the same time. Suddenly it decided to eat 2GB of extra RAM.

-- 
/Jacob Carlborg

On Monday, 1 July 2013 at 06:11:20 UTC, dennis luehring wrote:
> Am 01.07.2013 03:07, schrieb Kapps:
>> If you're concerned about performance, I'd recommend against
>> using DMD for your release builds. GDC and LDC will give much
>> better performance, and GDC works perfectly fine on Windows. LDC
>> has some problems with exception handling AFAIK on Windows.
>
> GDC got the same Exception problems like LDC - no support for SEH
> but Exceptions are working - only the Windows-internal-Exception -> D-Exception transition is not working properbly
>
> but even using Visual Studio you need to add special flags or using __try, __catch to get these - so normaly not a problem

Could you please elaborate on this? What should I beware/avoid of when using GDC under Windows ?

On 1 July 2013 11:18, Gabi <galim120@bezeqint.net> wrote:
> On Monday, 1 July 2013 at 06:11:20 UTC, dennis luehring wrote:
>>
>> Am 01.07.2013 03:07, schrieb Kapps:
>>>
>>> If you're concerned about performance, I'd recommend against using DMD for your release builds. GDC and LDC will give much better performance, and GDC works perfectly fine on Windows. LDC has some problems with exception handling AFAIK on Windows.
>>
>>
>> GDC got the same Exception problems like LDC - no support for SEH but Exceptions are working - only the Windows-internal-Exception -> D-Exception transition is not working properbly
>>
>> but even using Visual Studio you need to add special flags or using __try, __catch to get these - so normaly not a problem
>
>
> Could you please elaborate on this? What should I beware/avoid of when using GDC under Windows ?

Mixing MSVC and GCC when C++ linkage is involved. :)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am 01.07.2013 10:14, schrieb Iain Buclaw:
> On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz@gmx.net> wrote:
>>
>> Am 01.07.2013 03:07, schrieb Kapps:
>>
>>> If you're concerned about performance, I'd recommend against
>>> using DMD for your release builds. GDC and LDC will give much
>>> better performance, and GDC works perfectly fine on Windows. LDC
>>> has some problems with exception handling AFAIK on Windows.
>>
>>
>> GDC got the same Exception problems like LDC - no support for SEH
>> but Exceptions are working - only the Windows-internal-Exception ->
> D-Exception transition is not working properbly
>>
>> but even using Visual Studio you need to add special flags or using
> __try, __catch to get these - so normaly not a problem
>>
>
> Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
> AFAIK, structured exception handling support in gcc is being developed to
> overcome the weaknesses of both dw2 and sjlj.

"...is being developed" thats means gcc got Windows-SEH support?