"TSV" == Varadarajan <tsv@gold.cs.umanitoba.ca>:
"AS" == Alan Stokes <alan@rcp.co.uk>:

AS> If auto_ptr did have a significant overhead, I would agree an alternative
AS> mechanism would be a good thing. But I don't think it does "bloat

TSV> The current definition of auto_ptr includes a boolean variable so that
TSV> it allows copy and assignment operators. So every auto_ptr will have
TSV> its quota of extra memory usage.

True enough, but this overhead is still trivial compared to that involved
with the memory allocation.  If you really care about this, you can roll
your own auto_ptr class which lacks the extra state.  On my own projects I
have used a similar class called Reaper which does not have the extra bool.

Furthermore, if you really care about efficiency, then you can restrict
the use of the class to cleaning up the pointer and avoid the minor
cost of the extra dereference:

   {
      Foo *ptr = new Foo ;
      Reaper<Foo> reap_ptr(ptr) ;

      ptr->blah() ;

      // ...
   }

TSV> Further, I really dont think implementing a finally construct is a
TSV> real big deal.. I did the same thing(along with exception handling)
TSV> for a grad course for a C like language as a course project. Granted
TSV> it does not cover all the intricacies that C++ will have to deal with,
TSV> but I dont feel it is a real big deal compared with such things like
TSV> implementation of standard compliant templates.

If that is really true, then such a construct is much more likely to
eventually make its way into the language.  If you feel very strongly
about this, your best bet is to volunteer to add the construct to the
g++ implementation as a proof of concept and get people to use it.

- Chris
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <qaiv7j6ns2.fsf@gold.cs.umanitoba.ca>, Varadarajan
<tsv@gold.cs.umanitoba.ca> writes:

|> The point is  that, I am *paying for  what I dont  use*, if I am using
|> auto_ptr.

The implementation I wrote for auto_ptr as originally specified had *zero*
cost except during assignment from one auto_ptr to another (aka transfer
of ownership).  I managed this because it contained one single data member,
a pointer to the object, and all functions member were extremely trivial
inline functions.

With the current specification this may no longer be possible without compiler
extensions or assumptions about the implementation, but even now the cost
can be reduced to the addition of a single boolean data member to the class.
There is still no speed cost to actually using the auto_ptr except during
copying and initialization.

[If there is a way under a particular implementation to use some bits of the
pointer as the boolean, one can trade the size cost off for a speed cost].

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:

> `auto_ptr' does decrease efficiency (compared to the proposed
> `try ... finally').  There are two reasons.  Firstly, although
> the original auto_ptr design contained just a single pointer,
> the new design contains both a pointer and a bool to indicate
> ownership.  There are additional time and space costs to manipulate
> this bool.

On most platforms that have word-alignment restrictions for dynamic
allocation, this will be a non-issue: since you're guaranteed that the
lower 2 bits (for a 32-bit machine) of your pointer will be zero, just
encode the bool there.  Granted, there are some time costs to do the
masking, etc.

[Don't interpret this as a defense of auto_ptr as it stands; too much
has been compromised to the requirement of having only "one" class. In
real code, a family of smart pointers a la Barton/Nackman is a
necessity.]

 + Nicolas

---
Nicolas Chapados                         Nortel Technology Ltd.
(formerly BNR)
chapados@nortel.ca                       Montreal, Canada
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Varadarajan <tsv@gold.cs.umanitoba.ca> wrote:
>The current definition of auto_ptr includes a boolean variable so that
>it allows copy and assignment operators.

template <class Type>
class owned_ptr
{
 public:
  owned_ptr(Type *ptr) : myPtr(ptr) {}
  ~owned_ptr() { delete ptr; }
  Type &operator*() { return *myPtr; }
  const Type &operator*() const { return *myPtr; }
  Type *operator->() { return myPtr; }
  const Type *operator->() const { return myPtr; }
 private:
  // copy and assignment hidden -- we don't need em
  owned_ptr(const owned_ptr &ptr);
  operator=(const owned_ptr &ptr);
  Type *myPtr;
};

No overhead, unless the size of a pointer is less than the minimum
size of a struct (rather unlikely), or your compiler is incredibly
inefficient.

>Further, I really dont think
>implementing a finally construct is a real big deal.

That's what everybody says about their favorite feature.  Put 'em all
in, and you'll get a hernia lifting the C++ standard -- even if it's
on CD...

Andrew Bell
abell@mindspring.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

swf@elsegundoca.ncr.com (Stan Friesen) writes:

]The implementation I wrote for auto_ptr as originally specified had *zero*
]cost except during assignment from one auto_ptr to another (aka transfer
]of ownership).  I managed this because it contained one single data member,
]a pointer to the object, and all functions member were extremely trivial
]inline functions.

Did you *measure* the cost, or are you just making theoretical predictions?
My experience with existing C++ compilers is that in practice they do not
live up to expectations such as these.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
> `auto_ptr' does decrease efficiency (compared to the proposed
> `try ... finally').  There are two reasons.  Firstly, although
> the original auto_ptr design contained just a single pointer,
> the new design contains both a pointer and a bool to indicate
> ownership.  There are additional time and space costs to manipulate
> this bool.

But in many cases (where you never copy or assign to the auto_ptr) the
compiler is free to optimise out the bool. Certainly the compiler I use
(a fairly ordinary one in popular use) is capable of this, and will in
fact handle a simple use of auto_ptr with exactly the same code as it
would generate if I did the delete by hand.

In any case, the bool was only added because the original auto_ptr
definition was too clean and simple ;-(. It's easy enough to build a
replacement that doesn't have it.

>  Secondly, most C++ compilers don't do as good a job
> of optimization as they could do.

This isn't a case of auto_ptr decreasing efficiency, it's a case of a
poor optimiser decreasing efficiency. Personally I try not to worry
about this sort of micro-optimisation - I assume the compiler will do a
reasonable job, and if it doesn't the cost is usually low.

--
Alan Stokes (alan@rcp.co.uk)
RCP Consultants Ltd
Didcot, UK
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

nicolas (n.) chapados <chapados@nortel.ca> wrote:
> Fergus Henderson wrote:
>
> > `auto_ptr' does decrease efficiency (compared to the proposed
> > `try ... finally').  There are two reasons.  Firstly, although
> > the original auto_ptr design contained just a single pointer,
> > the new design contains both a pointer and a bool to indicate
> > ownership.  There are additional time and space costs to manipulate
> > this bool.
>
> On most platforms that have word-alignment restrictions for dynamic
> allocation, this will be a non-issue: since you're guaranteed that the
> lower 2 bits (for a 32-bit machine) of your pointer will be zero, just
> encode the bool there.  Granted, there are some time costs to do the
> masking, etc.
>

I couldn't find that guarantee in the draft standard. Alignment is an
implementation issue and in many implementations the alignment can be
changed with compilation options.

Also, if the class has very simple attributes (e.g. all chars) then
class new & delete operators might not (and do not need to) provide a
block of memory with the same alignment properties as the global
operators.

Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

T.S Varadarajan <tsv@cs.umanitoba.ca> writes:

>  I would like to know as to why the draft committee decided not
> to include the finally block as present in JAVA. I was not able to find
> any mention about it in Stroustrup's D&E (Did I overlook something??).
> I was not able to find any message in the archive of this newsgroup
> either.

It has been discussed in comp.std.c++.

The reason it was left out was that the functionality "finally" would
provide can be accomplished better in most cases by letting the destructor
of an automatic object do the cleanup automatically upon exiting the
scope of the procedure. For example:

   Foo *getFoo()
   {
      Mutex lock(mutex) ; // get lock on entry

      auto_ptr<Foo> foo_ptr = new Foo ;

      maybeThrow() ;

      return foo_ptr.release(); // return new Foo

   } // lock released on exit

The auto_ptr object holds onto the newly created Foo
and will delete it upon destruction unless explicitly
released.  If an exception is thrown by maybeThrow() then
destructors for all local objects will be called before
exiting the function scope and consequently the new Foo
object will be deleted.  The mutex object is used to handle
consistency in a multi-threaded environment; the constructor
obtains the lock and the destructor releases it when the function
is exited regardless of whether it was exited normally or due
to an exception.

Here is the same code doing explicit cleanup using the
proposed "finally" block:

   Foo *getFoo()
   {
      Foo *foo_ptr = 0 ;
      get_lock(mutex) ;

      try {
        foo_ptr = new Foo ;
        maybeThrow() ;
        return foo_ptr ;
      }
      catch (...) {
        delete foo_ptr ;
        throw ;
      }
      finally {
        release_lock(mutex) ;
      }
   }

This is *much* harder to read and consequently maintain
than the first example.  It also has a practical disadvantage
in that it won't work with compilers that do not yet support
exceptions.

There might be some cases where "finally" could be useful
but I believe that it was deemed to be not worth the effort.

- Chris
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christopher Barber <cbarber@fd1.boston.deshaw.com> writes:

> The reason it was left out was that the functionality "finally" would
> provide can be accomplished better in most cases by letting the destructor
> of an automatic object do the cleanup automatically upon exiting the
> scope of the procedure. For example:
>

But then there are many cases, where in objects are allocated on the
heap and if an exception occurs, after these objects were constructed,
then they never get destroyed. This kind of forces everybody to use
auto_ptr. When I read thro' Scott Meyer's More Effective C++, he
introduces auto_ptr, as one of the means to plug the absence of the
finally construct. (Yes, I admit there are other uses). So here we are
in a loop(Becos we dont have finally construct, we have auto_ptr, and
becos we have auto_ptr we dont have finally construct, chicken - egg
problem??) But using auto_ptr as a substitute for all occurences of
pointers seems to be an overkill to me.
Regards,
--
------------------------------------------------------------------------
Varadarajan.T.S.                E-Mail : tsv@cs.umanitoba.ca
#725, 77, University Crescent,  HTTP   : http://www.cs.umanitoba.ca/~tsv
Winnipeg,                       Tel No : 1-(204)269-6036(Residence)
Manitoba - MB R3T 3N8                    1-(204)474-8827(Office)
Canada.
------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Varadarajan <tsv@gold.cs.umanitoba.ca> writes:

> Christopher Barber <cbarber@fd1.boston.deshaw.com> writes:
>
> > The reason it was left out was that the functionality "finally" would
> > provide can be accomplished better in most cases by letting the destructor
> > of an automatic object do the cleanup automatically upon exiting the
>
> But then there are many cases, where in objects are allocated on the
> heap and if an exception occurs, after these objects were constructed,
> then they never get destroyed. This kind of forces everybody to use
> auto_ptr.

Yes, but this is a good thing.

> When I read thro' Scott Meyer's More Effective C++, he introduces
> auto_ptr, as one of the means to plug the absence of the finally
> construct. (Yes, I admit there are other uses). So here we are in a
> loop(Becos we dont have finally construct, we have auto_ptr, and becos we
> have auto_ptr we dont have finally construct, chicken - egg problem??)
> But using auto_ptr as a substitute for all occurences of pointers seems
> to be an overkill to me.

There is no loop here.  The auto_ptr class can be implemented with
the existing language, while the finally construct would require an
extension.  Furthermore, as I believe I demonstrate use of auto_ptr
and other such classes to maintain resource allocation can lower the
need for special cleanup code and the extra nesting and complexity
it entails.  Not only do you get exception safe code, and avoidance
of memory leaks, but you also get better code maintainability.  What
more could you ask for?

I think that a finally clause could be more convenient and readable in some
situations, but as there is no actual necessity, I am not sure that is
enough to get it through the standards process.

- Chris
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Christopher Barber <cbarber@fd1.boston.deshaw.com> writes:

> need for special cleanup code and the extra nesting and complexity
> it entails.  Not only do you get exception safe code, and avoidance
> of memory leaks, but you also get better code maintainability.  What
> more could you ask for?

The point is  that, I am *paying for  what I dont  use*, if I am using
auto_ptr. If  an exception  occurs, yes this  code  is useful. In  the
absence of an  exception, auto_ptr happens  to just bloat the code and
decrease the efficiency. No, I do like  auto_ptr (It is conceptually a
great idea,  and  is a demonstrator  of what  a  well defined language
could acoomplish), but then I feel  that to replace every occurence of
pointer by an auto_ptr is an overkill.

Best Regards,

--
------------------------------------------------------------------------
Varadarajan.T.S.                E-Mail : tsv@cs.umanitoba.ca
#725, 77, University Crescent,  HTTP   : http://www.cs.umanitoba.ca/~tsv
Winnipeg,                       Tel No : 1-(204)269-6036(Residence)
Manitoba - MB R3T 3N8                    1-(204)474-8827(Office)
Canada.
------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

This message is a repost. My post did not appear in the newsfeed, and
hence my attempt to repost. My apologies if you get a duplicate copy.
Thanks.

[mod note: it didn't appear at my site either, so I'm (re-) posting it. -sdc]

Christopher Barber <cbarber@fd1.boston.deshaw.com> writes:

> need for special cleanup code and the extra nesting and complexity
> it entails.  Not only do you get exception safe code, and avoidance
> of memory leaks, but you also get better code maintainability.  What
> more could you ask for?

The point is  that, I am *paying for  what I dont  use*, if I am using
auto_ptr. If  an exception  occurs, yes this  code  is useful. In  the
absence of an  exception, auto_ptr happens  to just bloat the code and
decrease the efficiency. No, I do like  auto_ptr (It is conceptually a
great idea,  and  is a demonstrator  of what  a  well defined language
could acoomplish), but then I feel  that to replace every occurence of
pointer by an auto_ptr is an overkill.

Best Regards,
--
------------------------------------------------------------------------
Varadarajan.T.S.                E-Mail : tsv@cs.umanitoba.ca
#725, 77, University Crescent,  HTTP   : http://www.cs.umanitoba.ca/~tsv
Winnipeg,                       Tel No : 1-(204)269-6036(Residence)
Manitoba - MB R3T 3N8                    1-(204)474-8827(Office)
Canada.
------------------------------------------------------------------------


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Varadarajan wrote:
> Christopher Barber <cbarber@fd1.boston.deshaw.com> writes:
>
> > need for special cleanup code and the extra nesting and complexity
> > it entails.  Not only do you get exception safe code, and avoidance
> > of memory leaks, but you also get better code maintainability.  What
> > more could you ask for?
>
> The point is  that, I am *paying for  what I dont  use*, if I am using
> auto_ptr. If  an exception  occurs, yes this  code  is useful. In  the
> absence of an  exception, auto_ptr happens  to just bloat the code and
> decrease the efficiency. No, I do like  auto_ptr (It is conceptually a
> great idea,  and  is a demonstrator  of what  a  well defined language
> could acoomplish), but then I feel  that to replace every occurence of
> pointer by an auto_ptr is an overkill.
>

But in the absence of an exception, a finally statement would be useless
and just bloat the code.

If auto_ptr did have a significant overhead, I would agree an alternative
mechanism would be a good thing. But I don't think it does "bloat the
code and decrease the efficiency". The source code becomes smaller (you
get rid of an otherwise necessary delete statement), and because the
auto_ptr constructor and destructor will almost always be inline there
should be no effect on efficiency.

And of course you don't replace _every_ pointer with auto_ptr - only
where you need the automatic cleanup mechanism.
--
Alan Stokes (alan@rcp.co.uk)
RCP Consultants Ltd
Didcot, UK
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alan Stokes <alan@rcp.co.uk> writes:

]If auto_ptr did have a significant overhead, I would agree an alternative
]mechanism would be a good thing. But I don't think it does "bloat the
]code and decrease the efficiency". The source code becomes smaller (you
]get rid of an otherwise necessary delete statement), and because the
]auto_ptr constructor and destructor will almost always be inline there
]should be no effect on efficiency.

`auto_ptr' does decrease efficiency (compared to the proposed
`try ... finally').  There are two reasons.  Firstly, although
the original auto_ptr design contained just a single pointer,
the new design contains both a pointer and a bool to indicate
ownership.  There are additional time and space costs to manipulate
this bool.  Secondly, most C++ compilers don't do as good a job
of optimization as they could do.  For example, they generally don't
perform optimizations such as storing structs in registers (especially
when the struct is larger than a single word), and some are not be able
to put variables in registers if they have been passed as const
references to inline functions.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alan Stokes <alan@rcp.co.uk> writes:

> If auto_ptr did have a significant overhead, I would agree an alternative
> mechanism would be a good thing. But I don't think it does "bloat

The current definition of auto_ptr includes a boolean variable so that
it allows copy and assignment operators. So every auto_ptr will have
its quota of extra memory usage. Further, I really dont think
implementing a finally construct is a real big deal.. I did the same
thing(along with exception handling) for a grad course for a C like
language as a course project. Granted it does not cover all the
intricacies that C++ will have to deal with, but I dont feel it is a
real big deal compared with such things like implementation of
standard compliant templates.

Best wishes,
--
------------------------------------------------------------------------
Varadarajan.T.S.                E-Mail : tsv@cs.umanitoba.ca
#725, 77, University Crescent,  HTTP   : http://www.cs.umanitoba.ca/~tsv
Winnipeg,                       Tel No : 1-(204)269-6036(Residence)
Manitoba - MB R3T 3N8                    1-(204)474-8827(Office)
Canada.
------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Varadarajan wrote:
> Alan Stokes <alan@rcp.co.uk> writes:
> > If auto_ptr did have a significant overhead, I would agree an alternative
> > mechanism would be a good thing. But I don't think it does "bloat
>
> The current definition of auto_ptr includes a boolean variable so that
> it allows copy and assignment operators. So every auto_ptr will have
> its quota of extra memory usage.

Yes, but you can use the Auto_ptr you want: the one conformant with
the current DWP, the old one, or annother one (I only use mine which
does not have ownership); in particular, you can have an Auto_ptr with
which p.own_its_ptr() == bool (p.its_ptr()).

> Further, I really dont think
> implementing a finally construct is a real big deal.. I did the same
> thing(along with exception handling) for a grad course for a C like
> language as a course project. Granted it does not cover all the
> intricacies that C++ will have to deal with, but I dont feel it is a
> real big deal compared with such things like implementation of
> standard compliant templates.

The behaviour of the following when bar throw is clear: if the fisrt
call throw, NOP, if the second one do, free malloced mem.

int x = foo ();
char* s = 0;

bar ();
s = malloc (100);
bar ();

finally {
    free (s);
}

But what if foo throw in your C like language ?

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]