Quick question on smart pointers

Hi,

I'm just reading about smart pointers..
I have some existing C code that I would like to provide wrapper classes
for. Specifically, I would like to provide wrappers for two stucts
defined as ff:

typedef struct {
float *data ;
int count ;
} series ;

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client


I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

Couple of quick questions:

1). Can I do this (I probably should have checked to see if it would
compile first)
2). From my understanding of auto_ptr, variable sPtr gets freed
automagically when class Series goes out of scope (I can't imagine how
this is possible)
3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

Thanks

re: Quick question on smart pointers

Susan Baker wrote:[color=blue]
>
> Hi,
>
> I'm just reading about smart pointers..
> I have some existing C code that I would like to provide wrapper classes
> for. Specifically, I would like to provide wrappers for two stucts
> defined as ff:
>
> typedef struct {
> float *data ;
> int count ;
> } series ;
>
> typedef struct {
> void *clientdata ;
> FUNC_PTR1 cb1 ;
> FUNC_PTR2 cb2 ;
> struct param_ pdata ;
> int size ;
> } client
>
> I am thinking of providing a wrapper for the first one as ff:
>
> class Series {
> std::auto_pointer<series> sPtr ;
> ....
> }[/color]

Well, You could do that. But it would probably be easier to change it to

typedef std::vector< float > Series;

cause the whole structure looks extremely like the C way to code a dynamicaly
resizable array.
[color=blue]
>
> Couple of quick questions:
>
> 1). Can I do this (I probably should have checked to see if it would
> compile first)[/color]

You can do it.
But I recommend to first take a step back and ask a question: "What is the purpose
of that struct?" and "Is there a common C++ method to achieve that purpose?"
[color=blue]
> 2). From my understanding of auto_ptr, variable sPtr gets freed
> automagically when class Series goes out of scope (I can't imagine how
> this is possible)[/color]

It is done easily:
A std::auto_ptr is an object like any other object. When it goes out of scope, its
destructor is called. And now guess what that destructor does.
[color=blue]
> 3). Will the responses for the previous two statements hold true for a
> more complicated structure like client above?[/color]

You are looking for a cook book recipe. I don't think you will find one.
This is what makes programming sometimes frustrating but on the other hand
this is what makes programming interesting: "One size fits all" does seldome
apply in programming.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: Quick question on smart pointers

> I am thinking of providing a wrapper for the first one as ff:[color=blue]
>
> class Series {
> std::auto_pointer<series> sPtr ;
> ....
> }[/color]

This is very error prone. Consider:

Series s1;
Series s2 = s1; //!!!
[color=blue]
> Couple of quick questions:
>
> 1). Can I do this (I probably should have checked to see if it would
> compile first)[/color]

Do you really want/need to use a smart pointer? Just use plain RAII
with private copy constructor and assingment operator.
[color=blue]
> 2). From my understanding of auto_ptr, variable sPtr gets freed
> automagically when class Series goes out of scope (I can't imagine how
> this is possible)[/color]

The magic is called destructor (it's magic only for Java programmers).
[color=blue]
> 3). Will the responses for the previous two statements hold true for a
> more complicated structure like client above?[/color]

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

re: Quick question on smart pointers

Susan Baker <sbaker@no.spam.net> schrieb:
[color=blue]
> typedef struct {
> float *data ;
> int count ;
> } series ;
>
> typedef struct {
> void *clientdata ;
> FUNC_PTR1 cb1 ;
> FUNC_PTR2 cb2 ;
> struct param_ pdata ;
> int size ;
> } client
>
> I am thinking of providing a wrapper for the first one as ff:
>
> class Series {
> std::auto_pointer<series> sPtr ;
> ....
> }[/color]

I don't understand what you are planning. Why not use a real class
instead of the series struct? What should the auto_ptr do here?

I suggest not to use this auto_ptr stuff. This is for people who's
right hand doesn't know what the left hand is doing. You can always
have a simple pointer in your class and delete it yourself. This is
what destructors are made for.

T.M.

re: Quick question on smart pointers

typedef struct {
float *data ;
int count ;



} series ;

I am wondering as, what is the play of this count variable in
struct?...If it is counting number of object instanciated then better
make it static.


Panjandrum wrote:[color=blue][color=green]
> > I am thinking of providing a wrapper for the first one as ff:
> >
> > class Series {
> > std::auto_pointer<series> sPtr ;
> > ....
> > }[/color]
>
> This is very error prone. Consider:
>
> Series s1;
> Series s2 = s1; //!!!
>[color=green]
> > Couple of quick questions:
> >
> > 1). Can I do this (I probably should have checked to see if it would
> > compile first)[/color]
>
> Do you really want/need to use a smart pointer? Just use plain RAII
> with private copy constructor and assingment operator.
>[color=green]
> > 2). From my understanding of auto_ptr, variable sPtr gets freed
> > automagically when class Series goes out of scope (I can't imagine how
> > this is possible)[/color]
>
> The magic is called destructor (it's magic only for Java programmers).
>[color=green]
> > 3). Will the responses for the previous two statements hold true for a
> > more complicated structure like client above?[/color]
>
> If you maintain the 'creator is deleter' rule many 'problems' disappear
> in C++.[/color]

re: Quick question on smart pointers

Torsten Mueller wrote:[color=blue]
> Susan Baker <sbaker@no.spam.net> schrieb:
>[color=green]
> > typedef struct {
> > float *data ;
> > int count ;
> > } series ;
> >
> > typedef struct {
> > void *clientdata ;
> > FUNC_PTR1 cb1 ;
> > FUNC_PTR2 cb2 ;
> > struct param_ pdata ;
> > int size ;
> > } client
> >
> > I am thinking of providing a wrapper for the first one as ff:
> >
> > class Series {
> > std::auto_pointer<series> sPtr ;
> > ....
> > }[/color]
>
> I don't understand what you are planning. Why not use a real class
> instead of the series struct? What should the auto_ptr do here?
>
> I suggest not to use this auto_ptr stuff. This is for people who's
> right hand doesn't know what the left hand is doing. You can always
> have a simple pointer in your class and delete it yourself. This is
> what destructors are made for.
>
> T.M.[/color]

Surely auto_ptr is the last thing to use if you don't know what you're
doing ??

re: Quick question on smart pointers

Panjandrum wrote:
[color=blue][color=green]
>>I am thinking of providing a wrapper for the first one as ff:
>>
>>class Series {
>> std::auto_pointer<series> sPtr ;
>> ....
>>}[/color]
>
>
> This is very error prone. Consider:
>
> Series s1;
> Series s2 = s1; //!!!
>
>[color=green]
>>Couple of quick questions:
>>
>>1). Can I do this (I probably should have checked to see if it would
>>compile first)[/color]
>
>
> Do you really want/need to use a smart pointer? Just use plain RAII
> with private copy constructor and assingment operator.
>
>[color=green]
>>2). From my understanding of auto_ptr, variable sPtr gets freed
>>automagically when class Series goes out of scope (I can't imagine how
>>this is possible)[/color]
>
>
> The magic is called destructor (it's magic only for Java programmers).
>[/color]
The "magic" I was referring to (which everyone seems to have missed -
perhaps I did not make my self clear enough) was this: how can
auto_pointer correctly free memory allocated for a complicated structure
like client - which has several pointer members. It is my feeling that I
am misinterpreting the use(abuse?) of the auto_pointer and I just needed
some clarification on this point. The way I see it, using auto_pointer
in this way will lead to serious memory leaks - unless the container is
made aware of the details of the object (struct in this case), that it
is acting as a container of. This is what I mean when I say I cannot
imagine how the container finds out how to free the appropriate pointers
in the structure. The more I think abot it, the more it seems like I got
the wrong end of the stick. I don't think auto_pointers can be used this
way without memory leaks (although
http://www.parashift.com/c++-faq-lit....html#faq-17.4 appears
to suggest just that). I'll have to take another read to be sure....

[color=blue]
>[color=green]
>>3). Will the responses for the previous two statements hold true for a
>>more complicated structure like client above?[/color]
>
>
> If you maintain the 'creator is deleter' rule many 'problems' disappear
> in C++.
>[/color]

True - but then what is the point of the container?. I *thought* the
container was "managing" mem resources for me - I can just as quickly
roll my own "container" using an array. What "exactly" makes it a "safe
pointer".

re: Quick question on smart pointers

>> I suggest not to use this auto_ptr stuff. This is for people who's[color=blue][color=green]
>> right hand doesn't know what the left hand is doing. You can always
>> have a simple pointer in your class and delete it yourself. This is
>> what destructors are made for.[/color][/color]

That's just not true. If you want your code to be exception safe then
naked pointers are very tricky. It's unfortunate that the majority of
the C++ crowd doesn't think this way but smart pointers (not
necessarily std::auto_ptr) should be used instead of naked pointer
unless there's a good reason not to, NOT the other way around.

re: Quick question on smart pointers

bart.kowalski@gmail.com wrote:
[color=blue][color=green][color=darkred]
>>>I suggest not to use this auto_ptr stuff. This is for people who's
>>>right hand doesn't know what the left hand is doing. You can always
>>>have a simple pointer in your class and delete it yourself. This is
>>>what destructors are made for.[/color][/color]
>
>
> That's just not true. If you want your code to be exception safe then
> naked pointers are very tricky. It's unfortunate that the majority of
> the C++ crowd doesn't think this way but smart pointers (not
> necessarily std::auto_ptr) should be used instead of naked pointer
> unless there's a good reason not to, NOT the other way around.
>[/color]

So briefly, what do they buy me over and above naked pointers?, and how
may I use them in the example stucture I provided previously? (using the
simpler struct "series" as an example - if you please).

Thanks

re: Quick question on smart pointers

Am Wed, 06 Jul 2005 13:32:36 +0200 schrieb Susan Baker
<sbaker@no.spam.net>:
[color=blue]
> Hi,
>
> I'm just reading about smart pointers..
> I have some existing C code that I would like to provide wrapper classes
> for. Specifically, I would like to provide wrappers for two stucts
> defined as ff:
>
> typedef struct {
> float *data ;
> int count ;
> } series ;
>
> typedef struct {
> void *clientdata ;
> FUNC_PTR1 cb1 ;
> FUNC_PTR2 cb2 ;
> struct param_ pdata ;
> int size ;
> } client
>
>
> I am thinking of providing a wrapper for the first one as ff:
>
> class Series {
> std::auto_pointer<series> sPtr ;
> ....
> }
>
> Couple of quick questions:
>
> 1). Can I do this (I probably should have checked to see if it would
> compile first)[/color]

Yes
[color=blue]
> 2). From my understanding of auto_ptr, variable sPtr gets freed
> automagically when class Series goes out of scope (I can't imagine how
> this is possible)[/color]

The auto_ptr-Object is a 'normal' object on the stack. When it get's out
of scope it's destructor gets called. The dtor deletes the owned object
[color=blue]
> 3). Will the responses for the previous two statements hold true for a
> more complicated structure like client above?[/color]

Yes. But be aware the ownership-policy of auto_ptr. The ownership of the
pointer is passed, if the auto_ptr gets copied. The other forgets about
the pointer. Thus, one pointer belongs allways to exactly one auto_ptr. So
auto_ptr is in common not helpful if you want to copy your
wrapper-classes. If so, use boost/shared_ptr (www.boost.org)


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

re: Quick question on smart pointers

"Geo" <gg@remm.org> schrieb:
[color=blue][color=green]
> > I suggest not to use this auto_ptr stuff. This is for people who's
> > right hand doesn't know what the left hand is doing. You can
> > always have a simple pointer in your class and delete it yourself.
> > This is what destructors are made for.[/color]
>
>
> Surely auto_ptr is the last thing to use if you don't know what
> you're doing ??[/color]

No, for a reason I don't know it's the first thing.

T.M.

re: Quick question on smart pointers

bart.kowalski@gmail.com schrieb:
[color=blue]
> If you want your code to be exception safe then naked pointers are
> very tricky.[/color]

It's not. But you simply must know what you do.

Indeed proponents of the auto_ptr template [1] are just too lazy to
think about a concept in their program. They just want to use an
object and don't want to waste any time with its allocation and
deallocation. Oftenly they are students, having not much time, knowing
just the Java world from their university and blaming C++ for bad
memory management. Normally this leads to sources I find complicated
to read because of an additional layer of indirection.
[color=blue]
> It's unfortunate that the majority of the C++ crowd doesn't think
> this way but smart pointers (not necessarily std::auto_ptr) should
> be used instead of naked pointer unless there's a good reason not
> to, NOT the other way around.[/color]

But why? This is like driving a car with a helmet.

In the last 15 years I used exactly one smart pointer, and this one
had reference counting and methods for exchanging the inner object by
another ... I had never the idea of automatic memory management even
in my large applications. And I'm an extremist in asking for
prevention of memory leaks.

T.M.

[1] I don't mean smart pointers with reference counting, I mean just
such primitive smart pointers like auto_ptr.

re: Quick question on smart pointers

Susan Baker wrote:[color=blue]
>
> The "magic" I was referring to (which everyone seems to have missed -
> perhaps I did not make my self clear enough) was this: how can
> auto_pointer correctly free memory allocated for a complicated structure
> like client - which has several pointer members.[/color]

And the answer is: it can't

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client;

You are talking about having an auto_ptr (or some other smart pointer)
to a client object. Well, the only thing the smart pointer does, is
to keep track of when the client object itself should be destroyed.
It is the job of the client object to take care of its inner details.
It does this by eg. making all the pointers in the client struct smart
pointers by themselfs or to simply do the delete in the destructor.
The smart pointer cares about the client object as a whole. The client
object is repsonsible for the inner details of itself.
[color=blue][color=green][color=darkred]
> >>3). Will the responses for the previous two statements hold true for a
> >>more complicated structure like client above?[/color]
> >
> >
> > If you maintain the 'creator is deleter' rule many 'problems' disappear
> > in C++.
> >[/color]
>
> True - but then what is the point of the container?.[/color]

To have one object that is reponsible for all the data in it.
[color=blue]
> I *thought* the
> container was "managing" mem resources for me - I can just as quickly
> roll my own "container" using an array.[/color]

Yes. Then the array *is* your container. No problem with that.
But don't roll your own. Use what is already available.
[color=blue]
> What "exactly" makes it a "safe
> pointer".[/color]

A safe pointer, or what we call a smart pointer, *ensures* that the delete
is executed. Even if you, the programmer have long forgotten that something
was dynamically allocated. It does this delete in all cases by the shear fact
that the smart pointer object is itself destroyed in some way. Be it that the
smart pointer is a member of some structure and an object of that structure
is allocated as a local variable and goes out of scope. Or that this structure
object is dynamically allocated and gets deleted.
There is no magic in it. Everything can be done 'by hand' also. The only problem
is, that humans tend to make mistakes and forget to do things. Then it is handy
to have an object that does the cleanup all by itself without the programmer having
to do anything except just using that smart pointer instead of an ordinary pointer.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: Quick question on smart pointers

Susan Baker wrote:[color=blue][color=green]
> > If you maintain the 'creator is deleter' rule many 'problems' disappear
> > in C++.
> >[/color]
>
> True - but then what is the point of the container?. I *thought* the
> container was "managing" mem resources for me - I can just as quickly
> roll my own "container" using an array. What "exactly" makes it a "safe
> pointer".[/color]

Try this link: http://www.artima.com/intv/modern3.html and search the
internet for RAII.

re: Quick question on smart pointers

Torsten Mueller wrote:[color=blue]
> bart.kowalski@gmail.com schrieb:
>[color=green]
> > If you want your code to be exception safe then naked pointers are
> > very tricky.[/color]
>
> It's not. But you simply must know what you do.
>
> Indeed proponents of the auto_ptr template [1] are just too lazy to
> think about a concept in their program. They just want to use an
> object and don't want to waste any time with its allocation and
> deallocation. Oftenly they are students, having not much time, knowing
> just the Java world from their university and blaming C++ for bad
> memory management.[/color]

That is a VERY presumptious statement. I come from a C background and
have been working in C++ for several years, and I'm the one to tell you
that. For SOME people what you're saying may be true, but if you ask
experienced C++ programmers (such as the people in c.l.c++.moderated)
you'll see a very different picture.
[color=blue]
> Normally this leads to sources I find complicated
> to read because of an additional layer of indirection.[/color]

Consider:

class Foo
{
Bar* a;
Bar* b;
};

void Foo::Init()
{
a = new Bar;
b = new Bar;
}

But what if b's ctor throws an exception? You have a potential memory
leak right there. You have to write:

void Foo::Init()
{
try
{
a = new Bar;
b = new Bar;
}
catch(...)
{
delete a;
delete b;
throw;
}
}

Are you going to write the above code every time you need two or more
dynamic resources? Frankly, I think using some kind of smart pointer is
both shorter and more reliable. Note that I said SOME KIND of smart
pointer. I'm not necessarily advocating std::auto_ptr, only some kind
of management class that wraps just one pointer and provides some form
of access to it.
[color=blue]
> But why? This is like driving a car with a helmet.[/color]

Smart pointers are not about protecting lazy programmers but about
what's more practical. C++ is meant to be a practical language, and I
find smart pointers to be more practical than raw pointers. That's the
bottom line.

re: Quick question on smart pointers

Susan Baker wrote:[color=blue]
>
> So briefly, what do they buy me over and above naked pointers?, and how
> may I use them in the example stucture I provided previously? (using the
> simpler struct "series" as an example - if you please).[/color]

I'm not saying that you should use smart pointers in your example. I'm
just saying that whenever pointers are appropriate for the task at hand
then you should use smart pointers. In your case pointers are not even
appropriate for the task at hand.

Bart.

re: Quick question on smart pointers

bart.kowalski@gmail.com schrieb:
[color=blue]
> C++ is meant to be a practical language,[/color]

Yes, of course!
[color=blue]
> and I find smart pointers to be more practical than raw pointers.[/color]

I do not. That's the difference.

Sorry, perhaps I've just seen too many young programmers becoming
frustrated because of a serious memory problem in their own absolutely
safe smart pointer world, because they (or anybody else!) forgot
somewhere to use a smart pointer where he should use one and then they
soon begin to blame C++ for causing daylong debugging sessions in
their safe programs.

T.M.

re: Quick question on smart pointers

bart.kowalski@gmail.com wrote:[color=blue][color=green]
> > Normally this leads to sources I find complicated
> > to read because of an additional layer of indirection.[/color]
>
> Consider:
>
> class Foo
> {
> Bar* a;
> Bar* b;
> };
>
> void Foo::Init()
> {
> a = new Bar;
> b = new Bar;
> }
>
> But what if b's ctor throws an exception? You have a potential memory
> leak right there. You have to write:
>
> void Foo::Init()
> {
> try
> {
> a = new Bar;
> b = new Bar;
> }
> catch(...)
> {
> delete a;
> delete b;
> throw;
> }
> }
>
> Are you going to write the above code every time you need two or more
> dynamic resources?[/color]

No, alone because your code contains at least 1 bug. BTW, dumb pointers
objects (misleadingly called smart pointers) are not the only and not
the best way to use RAII.

re: Quick question on smart pointers

bart.kowalski@gmail.com wrote:[color=blue]
>[/color]
[snip][color=blue]
> But what if b's ctor throws an exception? You have a potential memory
> leak right there. You have to write:
>
> void Foo::Init()
> {
> try
> {
> a = new Bar;
> b = new Bar;
> }
> catch(...)
> {
> delete a;
> delete b;
> throw;
> }
> }
>[/color]

Note that this is not the end of the story.
The above code still has a problem: What happens, when a's ctor throws
an exception? Then the catch will try to delete b through an uninitialzed pointer.
As you correctly say, at the moment you have more then 1 pointer things
can get tricky.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: Quick question on smart pointers

Karl Heinz Buchegger wrote:[color=blue]
> bart.kowalski@gmail.com wrote:[color=green]
> >[/color]
> [snip][color=green]
> > But what if b's ctor throws an exception? You have a potential memory
> > leak right there. You have to write:
> >
> > void Foo::Init()
> > {
> > try
> > {
> > a = new Bar;
> > b = new Bar;
> > }
> > catch(...)
> > {
> > delete a;
> > delete b;
> > throw;
> > }
> > }
> >[/color]
>
> Note that this is not the end of the story.
> The above code still has a problem: What happens, when a's ctor throws
> an exception? Then the catch will try to delete b through an uninitialzed pointer.[/color]

Ah, yes. I forgot how picky the people in this newsgroup can get
(haven't been here in a long while). Obviously, this example is not
complete. I'm assuming all pointers are null initialized, which is what
I always do in my code.

re: Quick question on smart pointers

In message <uirznjbae.fsf@fastmail.fm>, Torsten Mueller
<dev-null@shared-files.de> writes[color=blue]
>bart.kowalski@gmail.com schrieb:
>[color=green]
>> C++ is meant to be a practical language,[/color]
>
>Yes, of course!
>[color=green]
>> and I find smart pointers to be more practical than raw pointers.[/color]
>
>I do not. That's the difference.
>
>Sorry, perhaps I've just seen too many young programmers becoming
>frustrated because of a serious memory problem in their own absolutely
>safe smart pointer world, because they (or anybody else!) forgot
>somewhere to use a smart pointer where he should use one and then they
>soon begin to blame C++ for causing daylong debugging sessions in
>their safe programs.[/color]

So what you're saying is this:

Some student programmers have problems because they misuse (or
occasionally fail to use?) smart pointers. Therefore we should not use
smart pointers.

Did I get that right?

OTOH I've seen too many young programmers becoming frustrated because of
a serious memory problem in their C-shaped world, because they used raw
pointers without first designing an ownership model.

The cure for "forgetting somewhere to use a smart pointer" is not to
abandon smart pointers but to start with an ownership model, and then
enforce it by using factories etc. and make it impossible to expose raw
pointers at all (a quick search for all instances of "get()", "this",
"new", "delete" etc. should find most of the abuses).

--
Richard Herring

re: Quick question on smart pointers

Richard Herring <junk@[127.0.0.1]> schrieb:
[color=blue]
> So what you're saying is this:
>
> Some student programmers have problems because they misuse (or
> occasionally fail to use?) smart pointers. Therefore we should not
> use smart pointers.
>
> Did I get that right?
>
> OTOH I've seen too many young programmers becoming frustrated because
> of a serious memory problem in their C-shaped world, because they
> used raw pointers without first designing an ownership model.[/color]

The problem of smart pointers is that they cause a feeling of safety,
and this feeling is thin ice. "Our program is safe - we always use
smart pointers. And so we have completely safe code. If something is
wrong it can't be our code - we are safe!" ... I heard this just a few
times too often. I have done endless debugging sessions in code of
other people who were not able to understand their own code but beeing
very sure it's safe ... Even explaining them the problem is a problem
itself. This feeling of false safety does not exist in the classic
style. And in my opinion this is indeed an advantage.

What I want to say is, everyone should use the things he understands
completely. If anyone understands how smart pointers work and if he
can be sure all the others in his team understand this as well, they
may use them. No problem! I have never seen a real reason for using
smart pointers. This is my opinion. But the question came from a
beginner. And I oftenly found, people who do not understand raw
pointers have also serious problems using smart pointers, at least
when calling system or API functions.

T.M.

re: Quick question on smart pointers

In message <uzmss9ogd.fsf@fastmail.fm>, Torsten Mueller
<dev-null@shared-files.de> writes[color=blue]
>Richard Herring <junk@[127.0.0.1]> schrieb:
>[color=green]
>> So what you're saying is this:
>>
>> Some student programmers have problems because they misuse (or
>> occasionally fail to use?) smart pointers. Therefore we should not
>> use smart pointers.
>>
>> Did I get that right?
>>
>> OTOH I've seen too many young programmers becoming frustrated because
>> of a serious memory problem in their C-shaped world, because they
>> used raw pointers without first designing an ownership model.[/color]
>
>The problem of smart pointers is that they cause a feeling of safety,
>and this feeling is thin ice. "Our program is safe - we always use
>smart pointers. And so we have completely safe code. If something is
>wrong it can't be our code - we are safe!"[/color]

Then you have an education problem, not a smart-pointers problem.

Of course smart pointers don't guarantee safety. Smart pointers plus the
supporting concepts of factory patterns etc.) are just a part of a
well-defined ownership model. It's the latter which makes safe programs.
[color=blue]
>... I heard this just a few
>times too often. I have done endless debugging sessions in code of
>other people who were not able to understand their own code but beeing
>very sure it's safe ... Even explaining them the problem is a problem
>itself. This feeling of false safety does not exist in the classic
>style. And in my opinion this is indeed an advantage.[/color]

So we should all deliberately use unsafe raw pointers to write fragile
code, just because it doesn't feel safe? Is that what they call "extreme
programming"? ;-)
[color=blue]
>
>What I want to say is, everyone should use the things he understands
>completely. If anyone understands how smart pointers work and if he
>can be sure all the others in his team understand this as well, they
>may use them. No problem! I have never seen a real reason for using
>smart pointers.[/color]

You've never seen an example of smart pointers removing the need for
putting try-catch blocks around multiple memory allocations? Never seen
an example of RAII? Never even seen a mismatched new and delete?
[color=blue]
> This is my opinion.[/color]

Indeed.
[color=blue]
> But the question came from a
>beginner. And I oftenly found, people who do not understand raw
>pointers have also serious problems using smart pointers, at least
>when calling system or API functions.[/color]

Sure. But "what beginners don't understand" is no basis for deciding
what concepts to use to write reliable programs.

--
Richard Herring

re: Quick question on smart pointers

Richard Herring <junk@[127.0.0.1]> schrieb:
[color=blue][color=green]
> > This feeling of false safety does not exist in the classic style.
> > And in my opinion this is indeed an advantage.[/color]
>
> So we should all deliberately use unsafe raw pointers to write
> fragile code, just because it doesn't feel safe?[/color]

But it's just not true that raw pointers are unsafe. You just should
know what your're doing. And this is how I understand my job.
[color=blue]
> You've never seen an example of smart pointers removing the need for
> putting try-catch blocks around multiple memory allocations?[/color]

No, never. What should the try-catch-block do in this case? What
exception should be caught? bad_alloc? I would rather search for the
reason of the exception and I would find it definitely.
[color=blue]
> Never seen an example of RAII?[/color]

Is this something smart pointers are really necessary for?
[color=blue]
> Never even seen a mismatched new and delete?[/color]

Sure I have. But I can count such situations on just one hand. It's a
question of personal experience handling these things. It's not even
difficult, it's just a bit handwork.

T.M.

re: Quick question on smart pointers

In message <uslyk9hxs.fsf@fastmail.fm>, Torsten Mueller
<dev-null@shared-files.de> writes[color=blue]
>Richard Herring <junk@[127.0.0.1]> schrieb:
>[color=green][color=darkred]
>> > This feeling of false safety does not exist in the classic style.
>> > And in my opinion this is indeed an advantage.[/color]
>>
>> So we should all deliberately use unsafe raw pointers to write
>> fragile code, just because it doesn't feel safe?[/color]
>
>But it's just not true that raw pointers are unsafe.[/color]

It's more true than that smart pointers are.
[color=blue]
>You just should
>know what your're doing. And this is how I understand my job.[/color]

Sure, but even Homer nods. Why make things difficult for yourself?[color=blue]
>[color=green]
>> You've never seen an example of smart pointers removing the need for
>> putting try-catch blocks around multiple memory allocations?[/color]
>
>No, never.[/color]

Then you can't be reading this thread very carefully. Bart Kowalski
posted an example in
<1120722140.919986.276830@z14g2000cwz.googlegroups .com>.[color=blue]
>What should the try-catch-block do in this case?[/color]

I don't know what it "should" do since I'm arguing that it's not
necessary when you use smart pointers properly. What it does in the
usual example is to mop up half-allocated resources and rethrow.
[color=blue]
>What
>exception should be caught?[/color]

Everything that might break an invariant (i.e. leave the object in an
inconsistent state.)
[color=blue]
>bad_alloc?[/color]

Much more. Anything that might happen while the invariant isn't
satisfied.
[color=blue]
>I would rather search for the
>reason of the exception and I would find it definitely.[/color]

You're missing the point. The problem is not in detecting the exception,
but in clearing up after it.
[color=blue]
>[color=green]
>> Never seen an example of RAII?[/color]
>
>Is this something smart pointers are really necessary for?[/color]

Nothing is necessary. You could just write C. But since memory is an
obvious example of a resource, they are an excellent example of it.[color=blue]
>[color=green]
>> Never even seen a mismatched new and delete?[/color]
>
>Sure I have. But I can count such situations on just one hand.[/color]

Even in other people/s code, like those young programmers who spend all
their time becoming frustrated because of a serious memory problem?
[color=blue]
>It's a
>question of personal experience handling these things. It's not even
>difficult, it's just a bit handwork.[/color]

The same is true of smart pointers, but the workload is even less, as
there are no deletes to be matched.

--
Richard Herring

re: Quick question on smart pointers

Torsten Mueller wrote:[color=blue]
> But it's just not true that raw pointers are unsafe. You just should
> know what your're doing. And this is how I understand my job.[/color]

Right! And also it's just not true that 'smart pointers' are smart.
Actually they are a very crude way to handle resources.

re: Quick question on smart pointers

"Panjandrum" <pan6c7yc0j@spambob.com> schrieb:
[color=blue][color=green]
> > But it's just not true that raw pointers are unsafe. You just
> > should know what your're doing. And this is how I understand my
> > job.[/color]
>
> Right! And also it's just not true that 'smart pointers' are smart.
> Actually they are a very crude way to handle resources.[/color]

Nobody talks about resources. Resources are just there.

Smart pointer protagonists tend to use smart pointers always and
everywhere. This means they oftenly avoid to use simple local objects
on the stack. They allocate them on the heap rather because "all
objects need a safe smart pointer around". (This is oftenly
inconsequent - they put always std::string and std::vector objects on
the stack but self-made objects belong surely on the heap ...)

The problem is not only the allocation and deallocation time the heap
management and the OS well need but also that these millions of
temporary heap objects fragment the heap enormously. (This effect
differs from compiler to compiler.) Analyzing this in a given
application with a mysterious high memory usage I found situations
where more than 40% of the memory the heap management had requested
from the OS was not used anymore. This memory was allocated for just
small temporary objects and could not been released because of
fragmentation.

Indeed I use much more local objects directly on the stack. The stack
is is allocated just once and it gets never fragmented. I also try to
use real member variables in classes rather than pointers to heap
objects. That's why I can avoid these situations of partly initialized
objects in most cases. I never throw exceptions from constructors.

T.M.

re: Quick question on smart pointers

In message <ueka3qlna.fsf@fastmail.fm>, Torsten Mueller
<dev-null@shared-files.de> writes[color=blue]
>"Panjandrum" <pan6c7yc0j@spambob.com> schrieb:
>[color=green][color=darkred]
>> > But it's just not true that raw pointers are unsafe. You just
>> > should know what your're doing. And this is how I understand my
>> > job.[/color]
>>
>> Right! And also it's just not true that 'smart pointers' are smart.
>> Actually they are a very crude way to handle resources.[/color]
>
>Nobody talks about resources. Resources are just there.[/color]

RAII is a common topic of conversation in these parts.[color=blue]
>
>Smart pointer protagonists tend to use smart pointers always and
>everywhere. This means they oftenly avoid to use simple local objects
>on the stack. They allocate them on the heap rather because "all
>objects need a safe smart pointer around".[/color]

You must work with some very strange people. *Informed* smart-pointer
protagonists do nothing of the sort. Since they have a well-defined
ownership model they know exactly where to use smart pointers, and that
certainly isn't for objects with local scope.

What they avoid altogether is the unsafe use of raw pointers.
[color=blue]
> (This is oftenly
>inconsequent - they put always std::string and std::vector objects on
>the stack but self-made objects belong surely on the heap ...)
>
>The problem is not only the allocation and deallocation time the heap
>management and the OS well need but also that these millions of
>temporary heap objects fragment the heap enormously. (This effect
>differs from compiler to compiler.) Analyzing this in a given
>application with a mysterious high memory usage I found situations
>where more than 40% of the memory the heap management had requested
>from the OS was not used anymore. This memory was allocated for just
>small temporary objects and could not been released because of
>fragmentation.[/color]

Something wrong with the memory management code? If objects are
released precisely in reverse order of allocation (as will be the
pattern if you use smart pointers with local scope) I'd have thought
fragmentation would be unlikely.[color=blue]
>
>Indeed I use much more local objects directly on the stack. The stack
>is is allocated just once and it gets never fragmented. I also try to
>use real member variables in classes rather than pointers to heap
>objects. That's why I can avoid these situations of partly initialized
>objects in most cases. I never throw exceptions from constructors.[/color]

Can you guarantee that the constructors of your "real member variables"
also never throw?

--
Richard Herring