Re: SGCL - Garbage Collector for C++
On 1 mar, 11:50, Ioannis Vranos <ivra...@nospam.no.spamfreemail.gr>
wrote:
Ian Collins wrote:
[...]
As all computers (from small embedded devices to large mainframes) are
getting more powerful along with their accompanying facilities, the
abstraction in programming will be increasing. Now we have those CLI
compliant GC frameworks (.NET, Mono etc), and I am pretty sure GC will
be common place sometime in the near future.
Not "sometime in the near future". Today, it's actually rather
rare for a new development to not use GC. Partially, of course,
because most new developments do use either CLI or are in Java.
But many more serious, large scale developments do use C++ and
the Boehm collector. (In practice, Java doesn't really scale to
large scale developments, and CLI doesn't really work except on
Windows platforms, which aren't appropriate for large scale
developments.)
Also we will see more abstraction facilities, and less trade
offs between space and speed. The same applies for storage
medium.
Yes. In a lot of applications, garbage collection is faster,
but typically, it uses more memory. Given the size of current
memories, this usually isn't an issue (but it could be in some
applications, particularly numeric simulations of large scale
physical phenomena, like weather).
For example consider mp3/ogg vs flac. Now we have "mp3
players" with storage >1 GB.
The question for something like a program used to predict the
weather is: do I use this extra memory to simplify memory
managment (which is already very, very simple, since the only
dynamic allocations are in a couple of very, very big arrays),
or do I use it to increase the density of points I'm plotting.
There are applications for which garbage collection isn't
appropriate. There are others---most business applications, for
example---where it represents a definite gain.
This flame in this thread, reminds me other silly flames
between C and C++ advocates, with the C ones insisting that
they can do whatever they need without object oriented
programming, templates etc.
In some cases, how true. That doesn't seem to be Ian's case,
however.
Personally I think the near future will be with more
abstraction (like more templates, GC) and with less low-level
facilities, since space and run-time will have less
importance, because of the more and more powerful systems.
In the near future, either C++ will support threads and garbage
collection, or it will become a niche language. That's really
independent of technical advantages of one or the other.
Currently, I see a lot of applications which are multithreaded,
but which shouldn't be. Realistically, if garbage collection
were part of the language, I expect that there will be a lot of
applications which use it where it's not appropriate. But just
as realistically, there are applications where one or the other
are appropriate, it's important that the language support them,
and the fact that something can be misused has never been an
argument against having it in the language.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34