Re: Future of C++
on Thu Aug 14 2008, "gast128-AT-hotmail.com" <gast128-AT-hotmail.com> wrote:
It is not about freeing people of 'forgetting' calling delete,
Did I mention forgetting? I don't think so.
Look for the quotes.
Noticed 'em. Usually quotes mean you're quoting someone.
but when applications tend to grow the vast amount of objects becomes
a problem of itself.
Then you should reduce the number of objects.
Yes that would be the easiest solution. Telling our customers that
they should be happy with reduced functionality.
You don't have to reduce functionality to reduce the number of objects.
For years, people have written large, complex programs without any
"objects" (in the OO sense) whatsoever.
If you make large applications, you end up with multi class and high
object count applications. Real life applications aren't of the form
found in many text books.
Thanks, I've spent years writing them.
Objects references to other objects in a higly dynamic configuration,
Those are usually poorly-architected programs. They tend to be
difficult to reason about and inefficient to boot.
I wouldn't use these big words.
I have an inordinate fascination with the employment of high-falutin'
language.
Any non trivial UML model has many class links (aggregation,
association and simple dependency) and there are a number of technical
ways to solve it. But that doesn't reduce the conceptual model in the
first place.
I almost never use UML. I find it drives one towards a highly
object-centric design perspective that results in (surprise!) programs
with too many objects.
it would really help if one could get help here from the environment.
So, what you're giving here is a motivation for being able to
legitimately not call delete. That's fine. My posting was concerned
with the technical goals of introducing GC into C++, whether they would
be addressed, and what problems they would cause.
Yes my case (and others) is that GC might relieve some programming
tasks.
Yes, absolutely.
You now c++ far better than me, so you probably aware of the
difficulties. I only look at it form a client prespective.
Me too, strangely enough. I'm a client of C++ and I want to make sure
there's a usable programming model for any features that get added to
the language.
2) shared_from_this() cannot be called from the dtor
You want ressurection?
Funny.
Not intended to be. That's the technical term for essentially canceling
an object's reclamation by the garbage collector. The problem with
doing that from the dtor is that you likely don't have a fully formed
object anymore.
On the way home I was thinking something similar. Then I
remember the case: the original design was something like a
configuration subsystem observed by another subsystem, and the
lifetime of both subsystems were not bound to each other. The first
design was just with raw pointers, but this gave problems about shared
ownership. So the second attempt was with shared_ptr's which was
actual a correct one, except that than orphaned circular references
are not freed by shared_ptr's. So we had to break this cycle, by
introducing weak_ptr's. In its own destructor, it needed a weak_ptr
for unsubscription...
Okay... I don't see what that has to do with calling shared_from_this
from a dtor.
Btw in c#/.NET it is also not allowed to touch member references.
You mean during finalization? Not surprising.
No, not really. I thought I gave a pretty good explanation of the
problem above, and it's hard to think of anything to add to it that
would help you understand the problem. Maybe an example would help:
<snip example>
When you introduce GC into the language, clients suddenly get the
freedom to intentionally "leak" most objects... but not mutexes, queues,
or simulations.
Ok I think I understood it already the first time.
An answer might be to look at c#/.Net, but I am not an expert in that
area. There seems to be something like a client callable IDisposable,
to free resources asap. I suppose that this interface must be
implented 'upwards' if class contains members having an IDisposable
interface. This would of course be a maintenance nightmare,
Yes, you've just described exactly what I was talking about.
but the rationale is that only a limited number of classes have needs
for implementing an IDisposable interface.
That's true, but it's /completely/ different from orientation of the
existing C++ language, which is essentially that only a limited number
of classes have needs for GC.
The next disdvantage is of course that you have to know such details
about a class, precisely the opposite of information hiding. However
this is not the first case were details are promoted to the highest
level (throwable exceptions by members?).
That doesn't promote details unless you insist on using exception
specifications.
But maybe the c++ committee can think of something better than this. I
wonder by now how Java or other garbage collecting languages solve
this problem...
They don't have dtors (on their GC'd objects).
So this may wrap up the discussion that c++ will or will not
incoperate GC, and the future of c++. In the company were I work, we
look critical at development times. We 've used c++ for about 10 years
(before that c and Pascal) If any other language would significantly
improve the development time, it might be commercially a good idea to
switch for us. It looks like that M$ and c# are tough competitors
though, and they are still warming up...
I think might do a lot to reduce development time by eliminating the
sort of highly-dynamic networks of interacting objects that tend to
drive the use of GC.
See http://lambda-the-ultimate.org/node/563
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]