> Seriously, none of developers I know would ever use GC
> with C++.

The perils of the self selecting survey! Those developers that desperately needed GC have mostly gone elsewhere.

> I suppose it depends on whether you want to be a C++
> programmer or a <OS of choice> C++ programmer or (even
> worse) <OS> <processor> C++ programmer. Or how about just
> a single processor X86 Windows C++ programmer.
> It is much easier to develop for multiple targets if you
> have a common, albeit more restrictive, set of design
> rules.

I am a programmer that solves real problems. I'm not interested in labels.

> > Seriously, none of developers I know would ever use GC
> > with C++.
>
> The perils of the self selecting survey! Those developers
> that desperately needed GC have mostly gone elsewhere.

:)

Note that I say "would never use GC with C++". Many developers use more than one programming language even within a single project. For the pieces where a GC is beneficial, they just use a lanuage that supports GC. C++ simply cannot become a "GC language", or at least not a good GC language at this point.

> > no way to write programs like Firefox, Word, Powerpoint
> > and Visio in languages other than C++, because those
> other
> > languages do not allow the performance of C++.
>
> None of those applications would be in my list as
> requiring C++ for performance reasons. Today, all could be
> implemented in a number of other languages without
> compromising the user experience. The choice at the time
> those projects were started probably was more restricted.

No. With technical documents consisting of 100s of pages filled with text, images and diagrams, C++ is the only choice.

Microsoft Office is written in C++.

Sun started an office suite in Java, but they stopped it for being 'too slow'.

> > But almost all C++ versions in almost all O/Ses provide
> > threads, critical sections, mutexes and semaphores.
> > Therefore I do not see where is the problem for the 99%
> of
> > the cases.
>
> But how do you port such code or write portable
> applications? The current answer seems to be that
> portability is restricted to the set of operating systems
> sufficiently like that on which it was first written.

All that is needed is 100% source-code level compatibility. The underlying code shall be different, as it is today for STL's files.

> > Many C++ programs suffer from manual memory management,
> > and gc is a priority over threads. I have not used a
> > single C++ application that has not crashed in one way
> or
> > another, due to some wild pointer or memory leak.
>
> Using boost::shared_ptr (or some other kinds of smart
> pointers) can eliminate many (in some cases all) memory
> leaks. See boost.org for examples.

Shared pointers are not enough when there are circular references...which practically rules out lots of useful code.

> > And not putting garbage collection in the standard is
> not
> > ignoring the needs of real C++ programmers?
> >
>
> No, it is not :)
>
> Seriously, none of developers I know would ever use GC
> with C++. If you need GC, use a GC enabled language - some
> of them claim to be very performant, ie D, OCaml...
>
> IMHO, for the C++ community threading is much more
> important issue than GC.

I am sorry but any comment that starts with "none of the stuff I know off" can not be taken seriously.

IMHO, for the C++ community, GC is the MOST IMPORTANT ISSUE.

> > > Seriously, none of developers I know would ever use
> GC
> > > with C++.
> >
> > The perils of the self selecting survey! Those
> developers
> > that desperately needed GC have mostly gone elsewhere.
>
> :)
>
> Note that I say "would never use GC with C++". Many
> developers use more than one programming language even
> within a single project. For the pieces where a GC is
> beneficial, they just use a lanuage that supports GC. C++
> simply cannot become a "GC language", or at least not a
> good GC language at this point.

If C++ can not become a good GC language, then how come the Stroustrup, Boehm and others propose the Boehm GC library for serious development?

What is happening is that the C++ standard commitee thinks they know better and they are in love with the manual memory management model.

There is no real technical reason why C++ can not have garbage collection.

> Microsoft Office is written in C++.
Java did not exist at the time work on Office started.

> Sun started an office suite in Java, but they stopped it
> for being 'too slow'.
A long time ago (in Java terms) this would have been true, but not in 2006.

> > Sun started an office suite in Java, but they stopped
> it
> > for being 'too slow'.
> A long time ago (in Java terms) this would have been true,
> but not in 2006.

It is true even today. Just look at Java IDE applications, like NetBeans, Eclipse, JEdit...

Why do you think a new Java Office would be any different?

The fundamental problem with Java is that it consumes "too much" memory, and that inevitably slows down the system.

> I am sorry but any comment that starts with "none of the
> stuff I know off" can not be taken seriously.
>
> IMHO, for the C++ community, GC is the MOST IMPORTANT
> ISSUE.

IMHO, any comment that starts with IMHO cannot be taken seriously :)

Joking aside, the fact is that a majority of developers don't want to use GC with C++. How many real life projects are there where C++ is used with GC?

> It is true even today. Just look at Java IDE applications,
> like NetBeans, Eclipse, JEdit...
>
> Why do you think a new Java Office would be any
> different?
>
> The fundamental problem with Java is that it consumes "too
> much" memory, and that inevitably slows down the system.

Those applications use a lot of memory by choice of the developers, not as a result of the language used. Simply they are keeping a lot of data in memory. If you give them the amount of memory their developers expect you to use, they perform pretty well.
Some of Microsoft's recent applications have exactly the same problem for exactly the same reason.
This is not to say that Java and similar langauges don't tend to use a bit more memory, they do, but in most cases the language itself accounts for only a small portion of the memory used. For an app like NetBeans which gobbles > 100MB on even small projects, less than 20MB of this could be attributed to the use of Java, and this amount is essentially constant (doesn't grow with bigger projects). These days 20MB is of little consequence in a desktop environment.

Over a decade ago, at an MS event, I heard one of their managers explain that you should target the amount of memory that will be typical on NEW machines at the time your product ships. Yes this means it might run like a dog on less well specified machines, BUT they weren't going to pay for your product any way.

You claimed that Java is no longer slow and then you were provided with contemporary examples of slow Java applications which you then dismissed.

So give us some examples of contemporary java apps that perform as well or better than C++ apps.

I suggest adding these definitions in the std namespace:

// Use dummy classes to identify sequences.
class default_template { };

// PT is any primitive type.
void observable_read<
PT, class sequence = default_sequence>(
PT &x);
void observable_write<
PT, class sequence = default_sequence>(
const PT &x);

Sequences in different threads would be distinct
even if they had the same name. A valid program
execution would be one where the resulting order
of observable reads/writes in each sequence would
be both valid (as defined by sequence points) for
the containing thread, as well as being a
"sub-order" (sub-sequence) of the execution's
resulting global order of observable reads/writes.
(Note that this allows a C++ implementation to
ignore the distinction between different
sequences in a particular thread.)

In practice, these "functions" could be used
for communication via memory outside the
program. If now or in the future there
is such a thing as "inter-thread optimization",
it might be necessary to have a distinct
method of outside communication in memory.

I thought it best that a sequence identifier
be something that doesn't bind to any address.
Could have used const int, but then the
programmer has the tedious job of keeping
them distinct over the whole program load.

To avoid a need for multi-access bus locking,
observable reads/writes in different sequences
should (in general) be allowed to be nominally
simultatanous. If an observable write and an
observable read or write of the same variable of
a primitive type occurred simultaneously
in different sequences, the resulting value
in of the variable in the both threads
is undefined.

Each implementation would need to provide a
type named std::atomic. Simultaneous
observable reads/writes of an atomic instance
would have to give correct results for some
arbitary ordering of the reads/writes.
References to std::atomic must convert
implicitly to references of some integral
type (that is to say, atomic is equivalent
to some intergral type except perhaps
with more strict alignment requirements).