Ambassador

So what did he talk about:

• How it all began?
  
• What is C++ and what it isn't?
  
• The standardization process.
  
• C++0x standard.
  
• Lots of Q&A.
  

There were many questions and I believe if we had time, we'd ask even more! I wanted to blog about "threads" before but I didn't want to/dare to post it, although its title was "This is a constructive comment" (and it really was - nothing negative in that). It was too long (I've cut it into two halves, then cut those halves into halves again...). I basically said something like following (quoting directly)

The concept of "thread" is platform dependent non-portable. There are cross platform libraries, but capabilities, constructs and functionality diverse across platforms and use of thread potentially outside of library (or in combination with other libraries) raise problems. From OS and hardware point of view, there are things that must be taken care of before, during, after (context switching) execution, and termination (graceful?) of thread. In most cases (as in always), we don't know when a thread will be scheduled for execution, how long will it take to complete, how will execution path be followed (without explicit ordering) and how will an arbitrary thread would interact with other threads, can thread receive independent external events (say, intervention) from outside world (e.g. human interaction, network event, etc)... These are difficult to answer. Basically, the environment is somewhat hostile due to absence of determinism, if one expects an ordering just out of the box. We have many resolutions to execution ordering problems. But it must be explicitly expressed, and, guess what, ordering facilities might be fragile (dead locks, live locks, some sort of reentrant mutex, lock free techniques are too complex even for scientists, etc) so one must be careful. Although there are many sides of "thread" concept that I can touch with my limited knowledge, what I mentioned is adequate to see that the concept is still fragile for average developer.

The last sentence is the summary of my thoughts; for an average developer, dealing with a thread is not a good option. Threads are much more complicated and fragile than most think. It's not about taking locks. If you take locks, then why do you use threads? Did you also take care of orders/levels of locks? "Then, what about lock-free things?", usually people say. Yes, what about them? It's too complicated. Well.. it's not too complicated, it's too simple to do complicated things. They usually are used in the building of complicated things.

But C++0x will have "nicer" features, such as async and future (and promises - I couldn't find the paper but it's mentioned in other proposals). These keep people away from the implementation details.

See, the world is not about UI programming, databases, games or web browsers. Each of those have different requirements for parallelism. Databases, for instance, may have a transactional model, while you can't do it in UI; user input and output can't be transactional (or can it?). Games, for instance, instead of waiting for v-sync, engine can prepare next frame or do AI (or something else). All these programs must also run on different platforms, and that requires a porting interface, implemented on each platform, behaving the exact same way. I think, even for big companies, including Opera, maintaining such a complicated and big porting interface is costly (not in terms of money but in time and all maintenance effort). Because, as I mentioned; it's not about locks, threads or lock free stuff. We better not touch those things directly. Most programmers should deal with higher level abstractions such as thread-safe containers, hash tables, etc.

Instead of individuals or some companies doing it in-house, C++ committee took the initiative to make a portable library that does the same thing on different platforms. Therefore, people do not need to fiddle with the threads, locks and managing all resources required by them (you have to give/free your locks and threads at the end, usually). I think the standard is on the right track; it still gives you access to low level concurrent programming primitives (i.e. threads, locks and atomics) but it also abstracts a lot of things so that we do not have to bother porting across platforms.

I think concurrency work is very important and at a fairly usable state in the standard.

When somebody comes up with a new thing, there are unpleased people. One can't please everybody, that would be the epic failure. But I think one must also keep in mind that people have habits and it's stronger than the buildings we live within, so it's difficult to bring them down (or destroy).

I am among the unpleased people... but only for one particular thing; the lambda-closure syntax. Bjarne said he didn't like it either and he said "well, there were no more weird syntax around and we picked up this one". He wrote an example on the whiteboard, and I reminded the "return type" part as well.

For those who don't know what lambda is; it's a small (anonymous) function that you write inline as an argument to algorithms or loops, for instance (see below).

So how does it look? Some of you may already know the new C++ lambda syntax (I am not using new "for range" syntax):

std::vector<int> intVec;
// populate vector
std::for_each(intVec.begin(), intVec.end(), 
          [](int x) {
              std::cout << x << std::endl;
          });

I apologize, but... Jaakko Järvi and his friends came up with one of the weirdest syntax one could invent. I have read other people complaining about the syntax, and it's good to hear I am not alone! As a C++ programmer, [] never ever makes me think about a function, forget about anonymous one! It may be operator[]() overload but [] represents, in all C-derived languages, an index operator (for arrays, collections, etc). Why not use the keyword lambda at least? like:

std::vector<int> intVec;
// populate vector
std::for_each(intVec.begin(), intVec.end(),
          std::lambda<void>(int x) {
             std::cout << x << std::endl;
          });

I am not a compiler designer (but a library author); what's wrong with this? We don't know! You see, this is just the beginning. I was trying out this lambda feature on g++4.5 on FreeBSD and it turned out that in some cases compiler cannot deduce the return type of your expression. In that case, syntax gets uglier (this isn't the real code I tried to compile but it was evaluating a bool at the end)

std::vector<int> intVec;
// populate vector
std::find_if(intVec.begin(), intVec.end(),
           [](int x)->bool {
               return x == 42;
           });

You may refer to another variable within lambda by:

std::vector<int> intVec;
int sum = 0;
// populate vector
std::find_if(intVec.begin(), intVec.end(),
           [&sum](int x)->bool {
               sum += x; return x == 42;
           });

I didn't Google at all but I am 100% sure there are people complaining about the syntax already. This, IMO, is not good. The old way looks much better:

void f(int x)
{
        std::cout << x << std::endl;
}

int main(int argc, char* argv[])
{
        std::vector<int> iVec(4, 42);
        std::for_each(iVec.begin(), iVec.end(), f);
        return 0;
}

At least, I can read it; for each element of iVec, call f. When I see lambda, I think of... for each element of iVec, do .. index.. no, do pointer indirec.. no umm.. oh well, do whatever written within curly braces!

As a geek, I am familiar with some programming languages and pseudo code, that does this return type things the other way around. That is <-. In Pascal, for instance:

i := v;

Usually pseudo code examples express in similar way:

i <- v

The value on the left gets assigned to the value on the right. But in lambdas, I understand something like:
"some thing that looks like a function declaration (int x), for instance, does this -> (whatever that is) a bool then function definition". I mean... even in plain English, I can't express that (well, I am not native speaker but I don't understand C++ lambda syntax enough to explain it to myself either).

I am serious; if that arrow was the other way around and/or the return type would be expressed before the function declaration, then it would make more, if not perfect, sense:

std::vector<int> intVec;
// populate vector
std::find_if(intVec.begin(), intVec.end(),
          []bool(int x) { return x == 42; });

That looks better!

std::vector<int> intVec;
// populate vector
std::find_if(intVec.begin(), intVec.end(),
          []bool<-(int x) { return x == 42; });

Also better (means; whatever this thing is, it's result will be a bool).

My two cents about the lambda syntax...

Thanks for Bjarne for his great talk, and Olve and Tandberg for organizing this event.