Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » C++ FQA
Re: C++ FQA [message #12618 is a reply to message #12613] Sat, 10 November 2007 23:57 Go to previous messageGo to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sat, 10 November 2007 17:54

cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...




As with GC, refcount can be made thread safe, IMHO.
And, as GC, it can be made more or less efficient code.
Even pick_ can be not thread safe, if it's bad coded, and must have some sort of synchronizing code to be thread safe. Of course, the 'blocking' code in pick_ should be a bit less than in refcount, and (I guess) much less than in GC.
Even copying a whole array can be a big problem in multithreading stuff, and can become slow.
At least, refcount (and GC) can be made thread safe by design, without requiring additional sync code by user program; new(), delete() and malloc() and manual memory management requires thread safe stuffs in user code. Of course they CAN be faster, but more error-prone too.
I *don't* like GC, but only because I want to know when memory is being freed; I *do* like refcount because gives you some coding comfort without too much performance penalty; pick_ gives you less code comfort with best performance, and has great advantage over more manual stuff that gives you an error if you access picked objects.

That said, GC is nothing modern, lisp has it since before 1980, and also appleII pc with its basic had it, awfully slow, too, for string management. If I remember well, some GC have a mix of refcount AND other stuffs to solve circular references, but I'm not sure. It could be made working with refcounts, some linked list stuff and the GC traversing them to solve circular refs, at a cost of performance.

I would not accept a language based mostly on GC, but I've got nothing against an optional gc among other management stuffs.

BTW, I can't see how refcount can be slower than GC... maybe I'm wrong, but I'd like to have it explained !

ciao

Max

[Updated on: Sun, 11 November 2007 00:00]

Report message to a moderator

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Tools or methodologies you use when developing software
Next Topic: About vista....
Goto Forum:
  


Current Time: Tue May 07 18:02:23 CEST 2024

Total time taken to generate the page: 0.02864 seconds