Features in the following libraries are really good.
IT would be really good if phobos incorporates what they have.

Just put here for reference:

General Pourpose:
POCO
http://pocoproject.org/features.html
It's a c++ library that is under Boost Software License 1.0.

JUCE
http://www.rawmaterialsoftware.com/jucefeatures.php
Good lib

Graphics and Windows.

Anti-Grain Geometry 2D
http://www.antigrain.com/
Used this before.

MigLayout - Java Layout Manager
http://www.miglayout.com
GUI layout management done right.

Winn32++
http://win32-framework.sourceforge.net/index.htm

Aswang - Win32 Wrapper
http://aswang.sourceforge.net/
Simple and straight forward.

Zz

On Friday, 16 March 2012 at 12:48:39 UTC, Zz wrote:
> Features in the following libraries are really good.
> IT would be really good if phobos incorporates what they have.
>
> Just put here for reference:
>
> General Pourpose:
> POCO
> http://pocoproject.org/features.html
> It's a c++ library that is under Boost Software License 1.0.
>
> JUCE
> http://www.rawmaterialsoftware.com/jucefeatures.php
> Good lib
>
> Graphics and Windows.
>
> Anti-Grain Geometry 2D
> http://www.antigrain.com/
> Used this before.
>

I don't know what the license is, but this guy doing U++ development did his own implementation of the subpixel rendering technique described by agg.  He says it added about 100 lines of code to his Painter library.  He discusses it in these posts.

  http://www.ultimatepp.org/forum/index.php?t=msg&goto=20174&

It looks pretty nice to me when used in one of the graphing project in their examples.

http://www.ultimatepp.org/srcdoc$PlotLib$PlotLib$en-us.html

On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

btw, the u++ page claims in the link below to be faster than D by 70% on some operations, which they attribute to their STL rewrite. Maybe someone should take a look at what they've done.  Or maybe this comparison is out of date...

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

 On 03/16/2012 02:39 PM, Jay Norwood wrote:
> On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:
>
> btw, the u++ page claims in the link below to be faster than D by 70% on
> some operations, which they attribute to their STL rewrite. Maybe
> someone should take a look at what they've done. Or maybe this
> comparison is out of date...
>
> http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
>

"Means C++ is still well ahead of D (by 70%) if not being hold back by standard library design and average implementation..."

They explain the former results with differences in implementations and their new results with differences in languages, after having optimized the implementation in one language but not in the other. x)

On 3/16/12 8:39 AM, Jay Norwood wrote:
> On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:
>
> btw, the u++ page claims in the link below to be faster than D by 70% on
> some operations, which they attribute to their STL rewrite. Maybe
> someone should take a look at what they've done. Or maybe this
> comparison is out of date...
>
> http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch.

Andrei

On Friday, 16 March 2012 at 14:26:19 UTC, Andrei Alexandrescu wrote:
>> http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
>
> The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch.
>
> Andrei

In fact the claim is no longer true.  I pulled down their latest build and tested with a large Alice (duplicated many times to get it up to measureable consistently). I used the library stopwatch measurements for each.  The results come out about the same ... theirs is a few msec faster on 10MB of input with their optimizations for speed turned on. This is on a win7-64 corei7 box, but compiling for 32 bit with msvc for their code.

this is for upp, 4193 build
G:\upp\out\MyApps\MSC9.Force_Speed.Sse2>alice2
     lines      words      bytes file
    224160    1825140   10050960 alice2.txt
time: 93 ms
skey: zip sval: 60
map size;3482


this is for d 2.058
G:\d\alice2\alice2\alice2\Release>alice2
     lines      words      bytes file
    224160   1825140  10050960 alice2.txt
time: 97 ms
skey: zip sval: 60
dictionary length:3482

On Friday, 16 March 2012 at 14:26:19 UTC, Andrei Alexandrescu wrote:
> On 3/16/12 8:39 AM, Jay Norwood wrote:
>> On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:
>>
>> btw, the u++ page claims in the link below to be faster than D by 70% on
>> some operations, which they attribute to their STL rewrite. Maybe
>> someone should take a look at what they've done. Or maybe this
>> comparison is out of date...
>>
>> http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
>
> The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch.
>
> Andrei

Ok, but maybe the the upp arrayMap is pretty efficient for certain things ... by their benchmarks 4x faster than STL on whatever they were doing.  I tried  rewriting the D example code, and upp is consistently a bit  faster when running on a single core.
http://www.ultimatepp.org/src$Core$ArrayMap$en-us.html

 A D std.parallelism library rewrite of the example runs about 2x faster than the current upp example code on a corei7 box, if you give it several files to work on.  The execution doesn't scale as much as I expected, probably because the dictionary gets duplicated in the parallel case, while the single thread just increments counts in the same dictionary.

 I believe the TDPL book mentioned some research on non-locking, shared memory containers, but I didn't see anything documented in the D libraries.  There is the workerLocalStorage area ... but it wouldn't help with the problem of the dictionary getting duplicated in this case.  It look like there would be a reduce step required to merge the dictionary counts at the end.