«

Carlo Milanesi <> writes:

> Hello,
> traditionally, in C++, dynamically allocated memory has been
> managed explicitly by calling "delete" in the application code.
>
> Now, in addition to the standard library strings, containers, and
> auto_ptrs, gurus suggest that may be better to use a reference-counted
> smart pointer, or a garbage-collector.
>
> But in which cases it is better to use one technique and in which
> cases another? IOW, which is the design criterion?

Reference counted smart pointers: never. They leak memory as soon as
you have bidirectionnal associations or cycles in your data
structures.

Garbage collectors: always. There are even real-time garbage
collectors, if you have real-time constraints.


> And if, after having completed a working system, a technique would
> result more performing than another, or better for other reasons, is
> it advisable to change the memory management strategy of that working
> system?

Well, usually garbage collectors give better performance.
http://www.jwz.org/doc/gc.html
But of course it depends on the application and datasets. It might be
easier to change the garbage collection strategy, selecting one more
adapted to the application, than to change the application to use
another memory management style. On the other hand, if you write your
code with reference counting, it is easy enough to disable reference
counting and fall back to garbage collection.

--
__Pascal Bourguignon__

Carlo Milanesi wrote:

> Hello,
> traditionally, in C++, dynamically allocated memory has been
> managed explicitly by calling "delete" in the application code.

I think this is a misuderstanding. If by "traditionally" you mean C++ code
written until about 1998 maybe so, but the current C++ standard along with
auto_ptr<> and various third-party shared_ptr/counted_ptr imlementations
exist since at least 10 years now. Not to mention C++0x is just around the
corner and it will change the way we think C++, so we really need to drop
tradition and use best solutions as offered by a modern C++ implementation.

You probably didn't ment that by traditionally, in that case I'm stating the
above for those that do mean it that way

> Now, in addition to the standard library strings, containers, and
> auto_ptrs, gurus suggest that may be better to use a reference-counted
> smart pointer, or a garbage-collector.

I'm no guru but I'll state my oppinion based on my experience.

There are many "problems" with using blind pointers. All IMO derive from the
fact that a pointer is just too semantically rich. Take for example a C
complex program, you will see pointers used as such:
- 90% of cases used as a reference (that is used to pass by reference
arguments and they actually cannot logically be NULL inside the function
receiving it but no explicit syntax states that)
- 9% of times used to signal optionality of value (that is, if the value
exists then it's != 0 or if it doesn't it is 0)
- 1% used for pointer arithmetic and other advanced pointer semantics

Ok, those numbers are obviously exagerated but you get the idea. Using a
pointer is like designing a class type that has all the program logic in it
(a monster with a huge number of memer functins and data with no invariants
to keep). Good design dictates that classes should be made as much
specialized as you can, to do one simple thing and do it well (and maintain
the invariants of that).

Same with pointers, you need to pass by references something around use a
reference (for which you know it can't be NULL since in order to initialize
a reference to something NULL you would have had to dereference NULL which
is UB anyway). You need to signal optional value, use something like
boost:ptional (many even very experienced C++ programmers still prefer
pointers for that). You need a pointer to own some memory and delete the
memory on end scope of the pointer, use an scoped_ptr (maybe an auto_ptr if
you prefer only std code or if you need the auto_ptr move semantics). And
so on.

All this specialization helps your program by moving into the C++ compile
time type system alot of your program logic (the fact that there is no
operator++ on auto_ptr<> means you can't do pointer arithmetic by mistake
on auto_ptr<> values, signaled by a compile time error) thus resulting into
a less error prone program not to mention easier to read by a reader that
knows what all those "alternative pointer types" do (since she won't have
to see how do you use a pointer, she sees an auto_ptr and knows already
some facts about your usage of it).

> But in which cases it is better to use one technique and in which cases
> another? IOW, which is the design criterion?

I think in general you should almost never use pointers. First go through
these alternative solutions and see which best fits your needs: C++
references, boost:ptional (optional is interesting also because you can
use it to build a sort of pointer value that can be either NULL or point
validly if for example you make an boost:ptional<T&>), auto_ptr /
scoped_ptr / shared_ptr / weak_ptr.

About gc I can't say much since I haven't used it in C++ (only in Java as it
was forced in). Since for my kind of development I deal with alot of
resources for which RAII and scoped objects map very well I have no need of
gc.

> And if, after having completed a working system, a technique would
> result more performing than another, or better for other reasons, is it
> advisable to change the memory management strategy of that working system?

I think there are some situations in which a gc should perform better than
probably all those solutions above, maybe someone more experienced with
using gc's can provide an example (because all examples I come with right
now I also find them a solution C++ by doing a custom allocator).

--
Dizzy

Pascal J. Bourguignon wrote:

> Carlo Milanesi <> writes:
>
>> Hello,
>> traditionally, in C++, dynamically allocated memory has been
>> managed explicitly by calling "delete" in the application code.
>>
>> Now, in addition to the standard library strings, containers, and
>> auto_ptrs, gurus suggest that may be better to use a reference-counted
>> smart pointer, or a garbage-collector.
>>
>> But in which cases it is better to use one technique and in which
>> cases another? IOW, which is the design criterion?
>
> Reference counted smart pointers: never. They leak memory as soon as
> you have bidirectionnal associations or cycles in your data
> structures.

By that logic you mean he will always have bidirectional associations or
cycles in his data structures (thus NEVER use shared_ptr). In my years of
C++ I've had that very rare and when I did, I used weak_ptr to break the
cycle. How often do you have bidirectional associations in your data
structures? In thos projects that you have, which percent of the data
structures from the project has cycles?

> Garbage collectors: always. There are even real-time garbage
> collectors, if you have real-time constraints.

gc's are no silver bullet. They may be good in some scenarios but I don't
think they are good in any situation. Plus memory management is just a
small part of resource management in a C++ program (at least in my
programs).

> Well, usually garbage collectors give better performance.
> http://www.jwz.org/doc/gc.html
> But of course it depends on the application and datasets.

Ah so then you contradict your previous "Garbage collectors: always".

--
Dizzy

dizzy <> writes:
> Pascal J. Bourguignon wrote:
>> Carlo Milanesi <> writes:
>>> But in which cases it is better to use one technique and in which
>>> cases another? IOW, which is the design criterion?
>>
>> Reference counted smart pointers: never. They leak memory as soon as
>> you have bidirectionnal associations or cycles in your data
>> structures.
>
> By that logic you mean he will always have bidirectional associations or
> cycles in his data structures (thus NEVER use shared_ptr). In my years of
> C++ I've had that very rare and when I did, I used weak_ptr to break the
> cycle. How often do you have bidirectional associations in your data
> structures? In thos projects that you have, which percent of the data
> structures from the project has cycles?

Often enough. But the main point is of course, if your language
doesn't allow you to express some ideas easily, then you won't try to
express those ideas. If having circular references in C++ is a PITA,
then we will try very hard to avoid them. (And thus, burning a lot of
wetware cycles that would be better allocated to resolving the true
problems, instead of these technicalities).


>> Well, usually garbage collectors give better performance.
>> http://www.jwz.org/doc/gc.html
>> But of course it depends on the application and datasets.
>
> Ah so then you contradict your previous "Garbage collectors: always".

Not really, in the following sentence you cut out, I explained that if
the currrent garbage collection algorithm wasn't good enough for your
application, it would be better to change this garbage collection
algorithm for another one more adapted to your particular
circumstances, rather than going back to manage memory manually.

--
__Pascal Bourguignon__

Fran wrote:

> On Jun 10, 5:37 pm, acehr...@gmail.com wrote:
>
>> The problem is, that complex code hoping to figure out when to
>> 'delete' an object may never be executed. The non-throwing lines of
>> code of today can suddenly start possibly throwing in the future by
>> code changes, and the explicit delete statement may never be executed.
>
> Is there any chance that C++0x will give us mandatory checking of
> throw() clauses in function definitions? That would enable the
> compiler to warn about leaks when exceptions might happen between
> calls to new and delete.

Why is there such a need? Always assume anything may throw and code
accordingly. In the exceptional cases where writing exception safe code is
not possible (making the code expensive or error prone) I'm sure you can
find a solution (like std::stack has for top()/pop()).

--
Dizzy

On 11 kesä, 00:25, acehr...@gmail.com wrote:
> void foo()
> {
> A * a = new A(/* ... */);
> /* code that may throw today or some time in the future possibly
> after some code change */
> delete a;
>
> }

Throw what? A ball?

In article <bcb28001-8bed-4732-8191-b97f61e511b3
@k13g2000hse.googlegroups.com>, says...

[ ... ]

> > The first quote appears to be purely apocryphal -- an
> > unsupported statement from somebody posting under a pseudonym,
> > about software of unknown origin written by people of unknown
> > skills.
>
> The first quote is probably the one which does correspond most
> to practical reality; I seem to recall a similar statement being
> made by Walter Bright (who certainly does qualify as a C++
> guru). But of course, it doesn't have to be that way.

Right -- my point wasn't that the quote was wrong, only that it didn't
really add much. If somebody disagreed with (essentially) the same point
when I said it probably wouldn't find much in this to convince them (of
anything).

> > Joel Spolsky spends a lot of time writing about software, but
> > his credentials seem questionable at best. In particular, I've
> > seen nothing to give a really strong indication that he's much
> > of a programmer (himself) at all.
>
> Another case of "those who can, do; those who can't teach (or
> write articles)".

....except that most of the people I can think of who write specifically
about C++ really _can_ write code, and most of them clearly _do_, and as
a rule do it quite well at that. The only prominent exception would be
Scott Meyers, who's pretty open about the fact that he consults about
C++, teaches C++, but does NOT really write much C++ at all. OTOH, I'm
pretty sure that if he really needed (or wanted to) he could write code
quite nicely as well -- though given his talents as a teacher, I think
it would be rather a waste if he spent his time that way.

Others, however (e.g. David Abrahams, Andrei Alexandrescu, Andrew
Koenig, Herb Sutter) who write about C++, also appear to write a fair
amount of code, and mostly do it quite well at that (and no, I'm not
claiming to be such a guru that I'm in a position to rate the experts,
or anything like that...)

[ ... ]

> > When you get down to it, despite being umpteen pages long, the
> > criticisms in this paper that have at least some degree of
> > validity with respect to current C++ can be summarized as:
>
> > 1) member functions should be virtual by default.
>
> Which is just wrong, at least from a software engineering point
> of view.

Right -- I don't mean to imply that all these are correct, or anything
like that -- I just mean that:

1) they're clearly enough defined to be fairly sure what he's saying.
2) they aren't obviously obsolete.
3) They aren't simply of the form: "Eiffel does it differently."

They're points that can be discussed intelligently, their strengths and
weaknesses can be examined, etc. They're not necessarily right, but at
least you can define (to at least some degree) what it means for them to
be right or wrong.

[ ... ]

> I don't think that there is complete consensus among the gurus
> as to when garbage collection would be appropriate. I would be
> very suspicious, however, of anyone who claimed that it is
> always appropriate, or never appropriate. That it's not
> available in the standard toolkit is a definite flaw in the
> language, but requiring it to be used in every case would
> probably be even worse (but I don't think anyone has ever
> proposted that).

I'm not sure it really needs to be part of the standard library, but I
do think it would be a good thing to tighten up the language
specification to the point that almost any known type of GC could be
included without leading to undefined behavior -- but we've been over
that before...

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin <> writes:
> I'm not sure it really needs to be part of the standard library, but I
> do think it would be a good thing to tighten up the language
> specification to the point that almost any known type of GC could be
> included without leading to undefined behavior

Well said!

> -- but we've been over
> that before...

Ok.

--
__Pascal Bourguignon__

On Jun 11, 6:56 am, Krice <pau...@mbnet.fi> wrote:
> On 11 kesä, 00:25, acehr...@gmail.com wrote:
>
> > void foo()
> > {
> > A * a = new A(/* ... */);
> > /* code that may throw today or some time in the future possibly
> > after some code change */
> > delete a;
>
> > }
>
> Throw what? A ball?

No, an exception; unless you are imagining a type named "ball" of
course.

I can't believe you are serious; you must have forgotten the smiley...
Seriously though, if you really didn't know what I meant with "throw,"
you should learn about exceptions.

Ali

On 11 kesä, 19:43, acehr...@gmail.com wrote:
> Seriously though, if you really didn't know what I meant with "throw,"
> you should learn about exceptions.

Exceptions are not logical. If construction of the object
fails then what? The program fails also, usually. I never
check anything, not since they invented exceptions, so
I'm assuming that there are no exceptions