If I recall, Stroustrup mentioned that C++0x was going to have some form of garbage collection in it (togglable at the compiler level).
If I recall, Stroustrup mentioned that C++0x was going to have some form of garbage collection in it (togglable at the compiler level).
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
I dunno. I don't think they were going to add it. It is a heated discussion, but I don't think it has been decided to implement yet. Perhaps. But if would definitely be togglable.
Originally Posted by Adak
The current TR1 doesn't mention it and this documented is not going to be changed. It's a draft still because that's part of the procedure for the Committee. Short of an earthquake, I don't see that being added.
In fact, Stroustrup seems to not favor the need for such an addition http://www.research.att.com/~bs/bs_f...age-collection
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Aah. He had mentioned it briefly at a talk he gave at my university over the summer, and I just looked it up and it seems that they've put it off into TRs past C++0x.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Actually I now remember you then mentioning it in these forums. Didn't you?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Yep. I believe I posted a link to the talk a while back.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Standardized garbage collection (an optional feature for compilers) was planned for C++09, but has been taken out due to time constraints. The current working draft contains wording that describes when 3rd-party GCs have to work correctly, and when they're allowed to fail (mostly to do with masking pointers so that the GC collects an object before it's really given up).
By formulating these core requirements, they can later put actual garbage collection into a library TR.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
although, thanks to all of you, that i now have more idea about how to manage my dynamic memory.
still, cant there be two forms of new/delete operators. like a gc_new/gc_delete.
if we want full efficiency and control use new/delete. if we want automatic garbage collection use gc_new/gc_delete.
What would gc_delete do? From what I see of garbage collection in PHP and Java, you only use new and garbage collection handles when to release the memory.still, cant there be two forms of new/delete operators. like a gc_new/gc_delete.
if we want full efficiency and control use new/delete. if we want automatic garbage collection use gc_new/gc_delete.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
oops! ur damn right! i forgot! yeah no need of gc_delete!
PS: but as per the mind set of c++. a gc_delete can still be there to manually force the garbage
collection to take place.
Not really, no. That would be against the spirit of garbage collection and also pose practical problems.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
But as noted, the garbage collection won't guarantee destructors to be run, if I understood correctly, which is not the best thing. Smart pointers do not have this problem.
They will, definitely. Just not necessarily when the object loses scope. This is mainly what differentiates GC from RAII.
While trying to look for that herb sutter article to post here, I come across differentiated opinions on the subject. GC may indeed have its uses. However, they are localized instances and it's my opinion GC shouldn't dominate a program deallocation strategy. Well... not in C++ at least.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
A nice story from Andrew Koenig (the guy the name lookup is named after) about GC
http://www.ddj.com/blog/cppblog/arch...tic_memor.html
God, I wish they wouldn't. This is only going to encourage people to write even crappier code than before, under the assumption that "the GC will take care of it." Not only will this code suck, it will be unusable on compilers that don't implement GC.
What a nightmare.
