Re: If GC is the solution, then what is the problem?
Gene Bushuyev wrote:
"Walter Bright" <walter@digitalmars-nospamm.com> wrote in message
news:m9GdnQiIO9kwHSrZnZ2dnUVZ_qGdnZ2d@comcast.com...
[...]
The historical string class problem (everyone inventing their
own string class) had its roots in lack of GC. Note that none
of the GC languages have a problem with string classes.
This historical problem is an old history. It was the case
before the standard library was adopted. I haven't seen
anybody writing their own string class for years.
For how many years? As little as five years ago, it was still a
real problem. And in practice, software, and especially
software interfaces, has a very long lifetime. You defined the
interface 15 years ago; it obviously didn't use std::string.
But you're still stuck with it.
I have seen people creating their own string classes for
specific purposes. For example, I have a static_string in my
collection for fast strings located on stack, which also works
seemlessly with std::string and algorithms.
I also don't see how string class is related to GC.
It's not, directly. The problem is one of having a standard
solution to a general problem. Both representing strings and
managing memory are general problems. Both lacked a standard
solution until recently; managing memory still lacks one. So
every library reinvented the wheel, in an incompatible way.
Do you need GC to implement std::string?
It would allow implementations with better performance. But
it's true that std::string's interface (e.g. requiring [] to
return a reference) is somewhat limiting with regards to
possible gains anyway.
No. How can GC possibly be used in something like
static_string?
Actually, it could simplify making static_string compatible with
standard strings, since it would mean you could use exactly the
same memory management code in both.
It can't. On the other hand, if you look at Visual C++, which
has GC, there are at least 3 string classes available. The
best of all of them is still std::string. The "modern" VC++
extensions all look like a saddle on a cow. All those other
modern languages with GC are actually way behind C++ in their
language designs,
For some things. C++ is behind them for others.
and they need a GC crutch to deal with their data model.
Hardly a crutch. Just a tool to make programmers more
efficient. Obviously, you can write working code without it;
you can also write working code without classes, templates or
inheritance. They're all tools which make the programmer's life
easier.
[...]
C++ should have acquired GC about 15 years ago. I think your
comment about too little, too late applies to that as well.
Even if GC were adopted, how many years would it be before it
diffuses through to all the C++ platforms out there? 10
years?
Probably never. And the reason that there is no GC neither in
the C++ Standard nor as a typical extension is the lack of
demand.
That argument is like the argument against classes in C.
There's no demand for classes in C, because all of the people
who want classes have moved on to C++.
But in fact, it' hardly true. I know that all of the new
projects I work on use the Boehm collector, and I'm not alone,
so as an extension, one can hardly speak of lack of demand.
People want garbage collection in C++ because the other
languages, which offer it, have other problems. In the end, one
tries to chose the easier battles, and I find it more likely to
get garbage collection in C++ than to get value semantics and
all the other things that are missing in Java.
(My impression, but it is just a subjective impression, is that
the chances are very good that the next version of C++ will have
garbage collection. There seems to be more or less a concensus
in the standardization committee that it should be studied, and
given that we have existing practice, and know it works, and is
useful, I'd say that the odds are in favor of it.)
Good C++ practices tend to produce the objects with automatic
storage duration.
Certainly the presence of value semantics makes garbage
collection less essential. That doesn't mean that it isn't an
important asset, however.
Resourse management is done in ctor/dtor, which is robust,
flexible and deterministic.
And doesn't always have the desired semantics for the special
resource memory.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]