Denis Koroskin пишет: > On Thu, 19 Mar 2009 19:54:10 +0300, Weed <resume...@mail.ru> wrote: > >> naryl пишет: >>> Weed Wrote: >>>> naryl яПНяПНяПНяПНяПН: >>>>> Weed Wrote: >>>>>> BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН: >>>>>>> Yes you can be >>>>>>> very careful in keeping track of pointers (not practical) or use >>>>>>> smart >>>>>>> pointers and such (might end up costing more than GC) >>>>>> I am do not agree: GC overexpenditure CPU or memory. Typically, both. >>>>> I wouldn't be so sure about CPU: >>>>> http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp&box=1 >>>>> >>>> You should not compare benchmarks - they depend on the quality of the >>>> testing code. >>> >>> Then find a way to prove that GC costs more CPU time than explicit >>> memory management and/or reference counting. >> >> I suggest that reference counting for -debug. >> Yes, it slows down a bit. As invariant{}, in{}, out(){}, assert() > > Yeah, ref-count your objects in debug and let the memory leak in release!
Not leak - that may be a reference to non-existent object. The design of "invariant{}" does not reveal all problems with the class in all cases which compiled to the release. So that they abandon invariant{}? Yes, this language is the same danger as the C++.