jan.devaan

Nice video! It is a bit of a pity so many people are moving away C++ just when we are finding out how powerful it really is.

 

One question about the code though:

When casting from a large signed type to a smaller type (int to unsigned char), SafeInt now does a two-sided compare. Why not cast the int to a uchar, and check if its the same when cast again to an int? That's one if statement less. Should be smaller and a tiny bit faster.

I like the covariance extensions. I think it is also useful that C# is extended to consume COM interfaces, and integrate with dynamic languages. 

But, can't you expose the dynamic as a plain class, and the optional/named parameters as attributes, rather than extending C# language syntax? It is there mostly for interop scenarios, and this will discourage people from using unless they have good reasons. 

[after watching the full video]

Ah, Erlang is mentioned near the end. Would still like to know which constraints are same or different as compared to erlang....

One more thing. Will I get into trouble if I call into legacy code that uses traditional threading constructs like mutexes and critical sections?

Sounds like a cool addition for C++. 

Sounds similar to the Erlang actor based programming model. Although I think the Erlang model is more restrictive.

Do I understand correctly that Actors are not reentrant (so no other messages are handled during a blocking receive)?

Hi,

I love _HAS_ITERATOR_DEBUGGING. I am relieved to hear that it complains about theoretical validation too, it should. That is what debug builds are for. My experience is that for 99% the slowdown due to the STL checking is irrelevant.

Having said that, I have a few files where we would welcome the opportunity to disable it. That is because our software has some image processing, that only one or two people are interested in debugging anyway, and usually only when they're working on bugs in that portion of the code. Now, I am expecting that undefining _HAS_ITERATOR_DEBUGGING for one file will lead to ODR violations, for sure if it shares containers with other classes in the dll. I can use plain pointers, but is there no other way?

So Stephan,

[question you already anwerered]

Now that shared_ptr<> is thread-aware, does the same thing go for other parts of the language? the C++ standard does not mention the word "thread" just once, quite deliberatly, I suspect. Is the initialization of function-local statics now thread safe?

Hi, sorry if this sounds naive, but what if you want to read/parse multiple files from disk in parallel using the TPL? Any test done by anyone? My guess would be we need new Async IO features (including Async File Open) that can be combined with this library to make such a scenario perform.

As for the discussion versus fixed-size problems versus variable-size problems (with varying amount of data): As an engineering team, you can score by making your software scaleable by using more cores for more data.  

In my line of work, there are always customers that have 2-4 times more data than the rest, and the same expectations on performance. If you use TPL to do your data in parallel, you can tell him to go buy an extra core... And he will love to hear that, because he now has the ultimate excuse to have his boss buy him extra horsepower.

Hi,

For starters, this is really amazingly cool. The first time I heard of this was in one of Herb Sutters presentations on concurrency. I have always hated locks, because you just can't get them right in non-trivial applications. And don't trust anyone you that says you can.

Can we have it tomorrow?

I do have some lowlevel questions:

Of course it is easy to make a private copy for the current thread of all the objects participating in the transaction. But how is it prevented that you accidently see a pointer to the "public" version of one of the objects in the transaction? Potentially expensive...

Do you aquire locks under the covers?

Are there also people looking at hardware support? With the processors virtual memory support, and copy-on-write features at this level, you could get some of the transactional features fairly cheap. It would complicate the garbage collector implementation a little....