Stroustrup's talk on C++0x

[Ingo Oeser]

Craig Black wrote:

> First, D needs to at the very least match the features that are added to
> C++ with regards to parallelism and concurrency.

Yes, I already had some discussions and proposal about this in another 
thread. 

- More explicit loop notion which can do map(), reduce(), filter().
  These are well understood and known idioms, which explicitly state how the
  data dependency is with just a single keyword. OpenMP basically does just 
  this plus some thread management for advanced stuff.
  -> Easy to add now and improve later support with newer library functions.
  -> Allows also to let the compiler do the optimisation via auto 
     vectorisation for simpler cases (like shorter loop bodies).

- Please remove the inXX() and outXX() intrinsics.
  They are oneliners in asm on X86 and not present on many architectures.

- asm construct should be backend dependent.
  This will aid its optimal integration into the surrounding D code.
  Reason: asm is very seldom used this days and usually states 
        one of 3 things

  1. The optimizer of my compiler sucks
  2. I'm l33t
  3. I write sth. which can/should not be expressed in D,
     because it is highly machine dependend and a NOP on many machines.
     (e.g. inp()/outp())

  Short term acceptable is 1. and 2., but long term acceptable is only 3.
  Case 3. is "write once and never touch again" but has to integrate very 
  tightly into the surrounding code and thus has to answer many questions:

  - How many delay slots are still free?
  - Which registers are spilled, read, written?
  - Where is the result?
  - Which CPU units are used/unused?
  - In what state is the pipeline of that unit?
  ... 
  
  Even GCC asm syntax can not express all of this yet, AFAIK. Many platform
  specific hard assembly stuff is written with GCC asm syntax. So being at 
  least as powerful of defining it as opaque as a mixin might be more useful 
  here. Maybe sth. opaque like the mixin() statement, which passes 
  everything there to the backend would be better. Esp. for DSP 
  architectures.

> Other than that, fixing compiler bugs is probably the most important thing
> for D right now.  I am especially looking forward to fixes that will make
> __traits usable (if that's still what it's called).

Yes, progress there is most exciting for me at the moment and I think the
developers do a good job there.
 
> One particular feature of pesonal interest is better support for structs
> (ctors, dtors, etc.)  This will help with complex mathematical data
> structures that I use that must be uber-efficient.

ctors which only assign and MUST assign all values might be very useful.
Static initializers with C99 syntax will be very welcome, too.

> As far as these new namfangled macros, D is so powerful already, I don't
> really know exactly what this will give us over what we already have.  But
> perhaps I haven't given this as much thought as others have.

Are there any articles about the current macro design decisions?


Best Regards

Ingo Oeser