Eric - thank for a very well written and useful article.

Robert Ramey

I noticed that Dr. Stroustrup was not in on this discussion.

Any reason why he wasn't included, and there was a Microsoft person.

My concern is that Microsoft intentionally does things different than the standard BSD/UNIX/Linux C/C++ community.

If Microsoft adopted standard C/C++ conventions there would be no need for many of the preprocessor directives.

I would be interested to know the opinions of Dr. Stroustrup on this subject, before the "committee" tinkers with what already is in place.

Kind regards,

leaks and crashes are from poor programming not the language itself...correct the programmer not the language

let's not dumb down C++ because some programmers don't know how to use pointers.

that's what why there are languages like Java and C#, for those who can't use pointers

;)

we already have a common api; it's called POSIX threads

> > You claimed that Java is no longer slow and then you
> were
> > provided with contemporary examples of slow Java
> > applications which you then dismissed.
>
> I have no problems with any of these applications on my
> computer. What kind of computer with what kind of
> graphics card do you run your Java applications with?
>
> > So give us some examples of contemporary java apps that
> > perform as well or better than C++ apps.
>
> It's not just about performant apps. It's about
> programming productivity and application stability. I
> have very performant Java applications that bang away
> 24/7.
>
> The applications that were pointed out, all have something
> in common. They are desktop/GUI apps. The Swing
> implementation, currently, utilizes basic drawing
> primatives to render all components. This means that its
> rendering is more like a 2D/3D game's requirements than a
> "windows desktop app". So, it's no wonder that people
> without powerful graphics cards have poor results with
> Swing based applications. Eclipse/SWT can do better than
> Swing because it uses native drawing. But, in JDK-6,
> support for VISTA and Sun's realization that their
> rendering pipeline was not correct/optimal for windows,
> means that things are going to change, and I believe, for
> the better.
>
> Unfortunately, the masses are still all keyed in on CPU
> performance and don't understand the time they are wasting
> on writing complex code, debugging memory issues, and
> porting their software to a new OS/CPU combination.
>
> The design of Java is what enables it to be portable. The
> JDK1.5 memory model changes are what finally made it
> possible to write dependable multi-thread code. My
> largest applications which run with 100's of threads, will
> run equally well on Windows, Linux and MAC OS-X, without a
> single bit of porting work on the software base.
>
> The work on putting threads into C++ and the lack of GC
> are revealing the deficiencies it really has in its
> overall design. Applications with huge amounts of complex
> data structures are very difficult to get right. C++
> makes it even harder, because you have to deal with memory
> management more explicitly either through finding the
> right library, or creating the memory model you need for
> yourself.
>
> C++ was never designed for a multi-threaded world, and it
> never will be able to really get there, with any
> dependable portability and operation, without a
> memory-model and then the standardized threading support
> that uses that memory-model. That's the effort that's
> underway now, and this report shows the issues that are
> going to have to be dealt with both technically,
> practically and religously.
>
> There are vendors today, providing OS based solutions,
> where they have control/advanced knowledge of the issues
> to deal with, including inparting a memory model in their
> compilers that makes it possible for them to support
> threading in some form.
>
> Thread designs that I saw in this report, based on library
> and templates, are very risky, because they utilize one of
> the more complex parts of the language specification.
>
> I'm anxious to see how things evolve toward a workable
> standard. But, in the end, I'm not at all sure it will
> happen without a "virtual machine" designed into the mix
> that provides the right level of abstraction that vendors
> can plug into.


"C++ was never designed for a multi-threaded world, and it never will be able to really get there, with any dependable portability and operation, without a memory-model and then the standardized threading support that uses that memory-model. That's the effort that's underway now, and this report shows the issues that are going to have to be dealt with both technically, practically and religously."

This is a false assumption -- C++ like C, was built to enable the maximum flexibility and keep it as light-weight as possible. I believe Dr. Stroustrup would tell you, go write your own threading library in C++.

He even recommends the Boost library which has an implementation.

C programs can be multi-threaded using the POSIX library -- the language has nothing to do with the subject.

The question is whether the language should implement the behavior as part of it's standard library.

Correct me if I am wrong here, but cross platform issues such as endian-ness are a function of the hardware.

Garbage Collection??? Are you out of your mind?

C++ is used in realtime applications, and embedded development. We don't want or need that concept.

Again, competent C/C++ programmers don't have issues with dynamic memory allocation, pointer use, etc. And don't wish to have our language dumbed down.

There is a reason why C has survived for so long. If memory wasn't so cheap, there would be greater emphasis on developing coding skill rather than trying to develop the language. There is a difference.

> Again, competent C/C++ programmers don't have issues with
> dynamic memory allocation, pointer use, etc. And don't
> wish to have our language dumbed down.

I think this part of your excursus is absolutely false. First of all, what do you mean by "competent C/C++" and in particular "C/C++"? To me, that often means C programmers who use a few C++ features -- and when I see code created by these people, I often see horrible code full of stuff like "goto ENDFUNC;" instead of doing things a competent C++ programmer would do, like using RAII. C and C++ are two different languages. There is also often a big difference between people who think they are competent and that very small minority who really are.

I don't agree with the macho attitude (using better, more advanced development tools is not "dumbing down" -- by extension C programmers wusses, because they don't type in machine code directly!) that there are mythical "competent" C programmers who never make mistakes with pointers, buffers, arrays, resource leaks, etc. Very experienced and knowledgeable C programmers do and always will make such mistakes, because it is quite easy to do so and because they are all human. Even static analysis and annotations can't solve this problem, though they help a lot.

If you want that statement to be true, then you need to say "... infallible C/C++ programmers don't have issues with dynamic memory allocation, pointer use, etc..."

I do agree with you that C++ doesn't need garbage collection though and not just because of performance. There is definite value to deterministic destruction, for example.

I think if you can use a garbage collected language, you should, otherwise you are just wasting development time. (I think people cling to C because they are affraid of losing their hard-earned status as a low-level guru.) If you are in some domain or platform that requires an unmanaged language, you should use C++, with good C++ idioms. If you must use C (I guess some embedded environments, driver code and low-level OS implementation still require it), use C. Is there ever any good reason to use "C/C++"?

A suggestion regarding C/C++ multi-threading standards:

Instead of having something like:

mutex_lock (mutex);
//do stuff
mutex_release (mutex);

I think it would be much clearer and easier on the programmer if they had a control-structure (since this IS flow-control, anyways) like so:

sync (mutex) {
//do stuff
}

more syntactically standard. easier to read. less typing.


And for read/write, instead of upgradeable mutexes, one could have a "weaker" control structure:

sync_read (mutex) {
//do stuff
}

Which can run concurrently with other sync_reads for the same mutex, but has to wait on syncs. syncs, likewise, have to wait on sync_reads.
Thus, all read and writes are sync.

The concurrency restrictions (per mutex) would be:
1. all sync blocks must wait for any currently running sync block to complete, AND all currently running sync_read blocks to complete before executing.
2. all sync_reads blocks must wait for any currently running sync block to complete before executing.

This guarantees that:
1. only one type of block (sync or sync_read) per mutex is running at a time
2. only one sync block (per mutex) is running at a time
3. any number of sync_read blocks (per mutex) may be running at a time
4. no write operations will be performed on the shared resource while any sync_read block is running


Furthermore, for simplicity, one could have a global mutex per process, that is implied by omission:

sync {
//do stuff
}


Alternatively, these blocks could be called "atomic" because they guarantee atomic operations.



Another suggestion I have for a multi-threading control structure would be a parallel loop block. Often times loops will be written where the
operation of each iteration depends only on the iteration counter. in this case, iterations can be run in parallel by spawning multiple threads and joining them to the current one.

parallel_for( init(i); condition; increment_op(i)) {
//do stuff concurrently
}

the initialization instruction ("int i = 0") is not multi-threaded, of course. the increment operations are done in each thread, atomicly, at the beginning of each loop, and each iteration has its own local copy of i so as not to block other concurrent iterations.

in cases where parts of the code inside the loop have concurrency issues, the above-mentioned sync/atomic blocks can be used to resolve them.

I really can't understand why there are so many issues about C++ and threads. It just takes 200 lines of code to to write a C++ template class that allows easily the creation of threads of class methods.