Re: SGCL - Garbage Collector for C++
On 1 mar, 02:05, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Feb 29, 8:58 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Feb 29, 1:10 pm, Sam <s...@email-scan.com> wrote:
James Kanze writes:
And if you intentionally reject the use of a labor
saving device, and do something by hand which can easily
be automated, you're being professionally irresponsible.
And you'll be even more professionally irresponsible if
you use a so-called "labor saving device" as merely a
crutch to support your own lack of experience and
know-how, rather than taking the time, learning, and
educating yourself on how to do it right in the first
place, instead of relying on mis-designed spaghetti code
to pull you nuts out of the fire.
Doing it right is doing it in the most effective and
maintainable way possible. Not inventing a lot of
make-work just to be able to bill extra time.
Your problems begin when your maintenance task is to port the
code to a platform without GC support.....
Or to a platform without C++ support... Or in my case, to a
platform without directories, or sockets, or files, or threads.
GC support is at least as widely available as threads or
sockets.
True, but there's plenty of embedded platforms with POSIX
support where garbage collection, even if available, would be
acceptable.
I presume you mean "wouldn't be acceptable".
The issue is more complex than that. There are definitly
contexts where garbage collection wouldn't be acceptable; there
are even a lot of contexts where dynamic allocation isn't
acceptable. In such contexts, the "Posix" environment, per se,
typically isn't acceptable either, but...
Even critical systems have non critical parts, where both
classical Posix and garbage collection might be acceptable, and
there are systems which provide a Posix interface, or at least
something fairly similar, or possibly just a subset, but which
also provide additional guarantees which make them usable in
even the most critical contexts.
If a platform didn't have threads or sockets, it would an
unlikely candidate for a port of an application that used
them. Even if it was chosen, being libraries with well
documented interfaces, they could be implemented, simulated or
stubbed by any competent developer. You can't make the same
claim for GC!
Can't you? I'm not sure.
The real issue is what you're targetting with your
"portability". If you want to be portable to absolutely
everything, then of course, you can't count on garbage
collection, or Posix, or even 2's complement integers. That
level of portability is rarely relevent outside low level
libraries, however. At the other extreme, most of the places
I've worked lately have pretty much standardized on Solaris on
Sparc. They express the portability concerns differently: they
refuse to migrate to a new platform unless our existing code
base will work on it. The issue of migrating to Linux has
recently been very relevant, and GC is the least of our worries:
the Boehm collector works well on both platforms, although a lot
of the "Posix" functions have subtly different semantics. (And
of course, even under Solaris, the semantics of pthread_exit and
pthread_cancel are different depending on whether you compiled
with g++ or Sun CC.)
--
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