Re: problem a function
On Mar 6, 1:08 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
There are clearly cases where Fallible or garbage collection
is not the right (or at least not the best) answer. There
are just as clearly cases where they are, however, and I
have very little tolerance for people who refuse to use it
in such cases
I'm not sure they're ever the best tools to choose in a green
field C++ project, but people have obviously found them both
useful.
There the most appropriate tools when they're the most
appropriate tools. In the case of Fallible, green field is
irrelevant, and in the case of garbage collection, it's almost
impossible to retro-fit into an existing implementation, so
green field projects are the only ones which can effectively use
it.
and even less for those who would try to limit others' use
of it (and to be really effective as a tool, garbage
collection must be part of the language).
I'm against imposing the overhead of supporting GC, in terms
of development, integration, testing, and documentation, on
all compliant implementations. IMO, it's just not a very
useful feature.
And that's really an ideological statement, not backed up by
hard facts. It's almost essential for certain types of
applications (not mine, but I do know of some). And it reduces
the amount of work necessary to implement most applications
(albeit not always by an enormous amount).
And the overhead for a compiler implementor isn't that great;
certainly a lot less than e.g. concepts.
I don't dispute for one moment your right to use it, but I see
this as a QoI issue, not something that should be required by
the standard. This isn't ideological for me at all, btw; if I
saw a real gain to be had by using language-level GC in C++,
the first thing I'd do is try to figure out which compiler had
the best support for it, and the second thing I'd do is try
that compiler.
The problem is that it affects the language---it's not just a
library that you can add in. Current implementations make a
number of assumptions about how compilers work, and how people
write code. At the very least, those assumptions must be
integrated into the language definition.
--
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