Re: Garbage collection in C++
On Nov 20, 2:33 pm, SG <s.gesem...@gmail.com> wrote:
On 20 Nov., 10:31, James Kanze <james.ka...@gmail.com> wrote:
Exactly. The current support becomes a lot more awkward if
the cleanup code needs to access local variables.
[...]
the references out in the generated code.) A lambda
function would be nothing more than a functional object
which derived from such a class; a lambda expression would
wrap the expression in a lambda function, then generate the
object. Cleanup, above would be derived from the class as
well, except that the code would define the destructor,
rather than an operator()().
What you want seems to be a "scope guard".
Yeh. Why be simple when you can be complicated. (Of course,
"lambda", "scope guard", and "cleanup" are just arbitrary names.
But if by "scope guard" you mean the complex mixture of
templates and macros that are needed to achieve this end in
current C++---the cure is worse than the disease.)
A Lambda-based scope guard
could be used like this:
template<typename F> requires Callable<F> && MoveConstructible<F>
class scope_guard { /* ... library magic ... */ };
template<typename F> requires Callable<F> && MoveConstructible<F>
scope_guard<F> make_scope_guard(F f);
double* example()
{
double* p = new double[123];
auto && sg = make_scope_guard( [p]{delete[] p;} );
// compute data or throw exception here
sg.cancel(); // makes dtor do nothing
return p;
}
There's no derivation, no virtual functions and no dynamically
allocated function object involved.
But there's library magic required, in order for the scoper
guard to be able to access local variables. If this is possible
as you've written it with the current lambda proposal, fine. If
not, it's basically what I'm asking for, modulo the exact
syntax. Except that I think it's a lot more convenient if I
don't have to invent a name (sg, in your example) for the
variable.
Of course, the example's purpose was ONLY to demonstrate the
how lambdas can be used to make arbitrary scope guards. In
this particular instance managing the dynamically allocated
array should be done differently. At least something like
this:
unique_ptr<double[]> example2()
{
unique_ptr<double[]> p (new double[123]);
// compute data or throw exception here
return p;
}
Actually,
std::vector< double > p( 123 ) ;
does the trick very well. Nothing more is needed. (But of
course, I understood it as just an example. There are times
when no convenient ready-made solution is available.)
It comes with the benefit of the function's declaration being
self- explanatory w.r.t. the life-time management of the
allocated array. It gets even better if you stick with
std::vector which will become movable in C++0x:
std::vector<double> example3();
This works in C++99. I do it all the time.
I've not studied the lambda proposition in detail, so I
don't know how much of the above it might incorporate. A
quick glance, however, does show that it involves a "closure
object", which sounds very much like the instance of my
anonymous class (although described in somewhat different
language). So it shouldn't be too hard to add "cleanup" as
an extension, or in a later version of the standard, if
someone can find time to write up a proposal for it.
It seems that the library solution is as convenient and
flexible as a dedicated language feature would be. So, a
"clean up" core language feature is hardly justified.
I've yet to see a library solution which works. But then, I've
yet to see much actual code which uses the lambda proposal.
Until we know what "library magic" you were referring to, we
can't judge whether this needs to be supported at the core level
or not.
--
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