nagle@animats.com (John Nagle) wrote in message news:<wu4Xc.8068$QJ3.4965@newssvr21.news.prodigy.com>...
> Peter Dimov wrote:
>
> > nagle@animats.com (John Nagle) wrote in message news:<_lAWc.11452$aK5.2292@newssvr29.news.prodigy.com>...
> >
> >>David Abrahams wrote:
> >>
> >>
> >>>nagle@animats.com (John Nagle) writes:
> >>>How does your proposal prevent buffer overflows and memory corruption?
> >>
> >>   See
> >>
> >> http://www.animats.com/papers/languages/
> >
> >
> > Your proposal does not prevent dangling pointers.
> >
> > void f( auto X * p, shared_ptr<Y> & q )
> > {
> >   q.reset();
> >   *p; // may have been invalidated
> > }
> >
> > Besides, shouldn't it be "X * auto p"?
>
>     You have to have safe smart pointer classes.  "reset()"
> doesn't qualify.
>
>     What I'm proposing is the underlying machinery needed
> to allow safe smart pointer classes.  Right now, you
> can't write an unbreakable one.

Of course you can. Just because smart pointers like shared_ptr allow
unsafe functions as part of their API in order to make them more
usable, that doesn't mean it's impossible to make a safer, if less
usable, alternative.

It seems to me that your safe C++ proposal is making the exact same
kind of trade-off -- it's less usable, but safer. For example, it
seems impossible to call ordinary C functions. Another example: you
require range checking on all arrays, even when it's difficult or
prohibitive, even when it's not necessary.

I think that for your proposal to really satisfy the claim of being a
"safe" (as opposed to "safer"; I'm not actually sure if you claim it's
"safe" or "safer") C++, you'd have to somehow disallow the example f()
above; merely saying "don't do that" with safe C++ is just as
effective as saying "don't do that" with unsafe (today's) C++.

Bob

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote in message news:<wu4Xc.8068$QJ3.4965@newssvr21.news.prodigy.com>...
> Peter Dimov wrote:
>
> > nagle@animats.com (John Nagle) wrote in message news:<_lAWc.11452$aK5.2292@newssvr29.news.prodigy.com>...
> >
> >>David Abrahams wrote:
> >>
> >>
> >>>nagle@animats.com (John Nagle) writes:
> >>>How does your proposal prevent buffer overflows and memory corruption?
> >>
> >>   See
> >>
> >> http://www.animats.com/papers/languages/
> >
> >
> > Your proposal does not prevent dangling pointers.
> >
> > void f( auto X * p, shared_ptr<Y> & q )
> > {
> >   q.reset();
> >   *p; // may have been invalidated
> > }
> >
> > Besides, shouldn't it be "X * auto p"?
>
>     You have to have safe smart pointer classes.  "reset()"
> doesn't qualify.

It seems to me that you are missing the point. reset() is safe. "auto
X *" isn't. Another shared_ptr example, without reset:

void f( auto X * p, shared_ptr<Y> & q, shared_ptr<Y> const & r )
{
  q = r;
  *p; // may have been invalidated
}

And another, this time without shared_ptr:

void f( auto X * p, vector<X> & q )
{
  q.push_back( X() );
  *p; // may have been invalidated
}

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote in message news:<_lAWc.11452$aK5.2292@newssvr29.news.prodigy.com>...
> David Abrahams wrote:
>
> > nagle@animats.com (John Nagle) writes:
> > How does your proposal prevent buffer overflows and memory corruption?
>
>    See
>
>  http://www.animats.com/papers/languages/

Your proposal does not prevent dangling pointers.

void f( auto X * p, shared_ptr<Y> & q )
{
  q.reset();
  *p; // may have been invalidated
}

Besides, shouldn't it be "X * auto p"?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Peter Dimov wrote:

> nagle@animats.com (John Nagle) wrote in message news:<_lAWc.11452$aK5.2292@newssvr29.news.prodigy.com>...
>
>>David Abrahams wrote:
>>
>>
>>>nagle@animats.com (John Nagle) writes:
>>>How does your proposal prevent buffer overflows and memory corruption?
>>
>>   See
>>
>> http://www.animats.com/papers/languages/
>
>
> Your proposal does not prevent dangling pointers.
>
> void f( auto X * p, shared_ptr<Y> & q )
> {
>   q.reset();
>   *p; // may have been invalidated
> }
>
> Besides, shouldn't it be "X * auto p"?

    You have to have safe smart pointer classes.  "reset()"
doesn't qualify.

    What I'm proposing is the underlying machinery needed
to allow safe smart pointer classes.  Right now, you
can't write an unbreakable one.

    John Nagle

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle)
> David Abrahams wrote:
> > auto_ptr is a basically flawed design (though I find it pretty good
> > for what it's designed for).  You should never move with copy
> > semantics, except for places where copies could be elided by the
> > compiler anyway.  I don't think that the difficulty of implementing
> > such odd (euphemism) semantic requirements proves anything about the
> > language.
>
>     auto_ptr is the only "smart pointer" class in the standard,
> and after three major revisions, it's still not very good.  That's
> the simplest case.  If that can't be made to work simply,
> cleanly, reliably, and efficiently, then there's very little
> chance of more eomplex smart pointers working reliably.
>
>     Trying to kludge around the problem with wierdo templates
> is not an acceptable solution for production code.

I didn't try to change nor criticize the semantics of auto_ptr but
just to outline the limitations of its implementation restrictions as
specified in the standard.

The main purpose of the alternative implementation was to demonstrate
that it's possible to correctly implement auto_ptr using existing
compilers.

OTOH the main purpose of the DR was to specify that the standard
requirements are too restrictive since the, well-defined, semantics of
auto_ptr are somehow derived from wrong implementation. Semantics are
enough, no implementation needed.

IMHO the user should only care about the usage (via specifications) of
such facilities and don't mind whether the underlying implementation
uses some quirky tricks or complier magic.

Rani

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:

> David Abrahams wrote:
>
>> nagle@animats.com (John Nagle) writes:
>> How does your proposal prevent buffer overflows and memory corruption?
>
>    See
>
>  http://www.animats.com/papers/languages/

Referring me back to the paper that I already read isn't very helpful.

I understand that your proposal can catch certain abuses, but it's far
from bulletproof.

And besides all that:

  [You:]
      If you can get a raw pointer out, it's unsafe.

  [Me:]
      Why, because it can dangle?

  [You:]
        Yes.

  [You:]
        If you can't get a raw pointer out, it's unusable.

        Because you're not going to get every library modified
        to use some specific implementation of encapsulated pointers.

What makes you think you can get every library modified to use some
specific spelling of "safe raw pointers"?  It seems to me that your
restricted semantics "auto" pointers are subject to the same usability
problems as any "restricted semantics" pointer we can put in the
standard library.

I do like the scoping semantics you propose -- you can't do that with
a library -- though I'd like to see generalizations explored.
Something powerful enough to change scoping behavior ought to be
useful for more than just this.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:

> David Abrahams wrote:
>> nagle@animats.com (John Nagle) writes:
>>
>
>>>    If you can get a raw pointer out, it's unsafe.
>> Why, because it can dangle?
>
>      Yes.

OK.  weak_ptr takes care of that, at least.

>>> If you can't get a raw pointer out, it's unusable.
>
> Because you're not going to get every library modified
> to use some specific implementation of encapsulated pointers.

OK.

>>> Rani doesn't address that issue at all.
>
>> Not surprising, if nobody but you understands it.
>
>     Hello?

Until you've explained the issue clearly, it's hard to expect anyone
to address it.

>>>Nor does he address the "collections of auto_ptr" problem.
>> See move_ptr.
>
>     Do collections of move_ptr work?  Is there a distributed
> piece of software that uses them?

Metrowerks' standard library, I'm pretty sure, will support it.
Whether or not it uses collections of move_ptr, I can't say, but it
does have movable std::string for example, and its std::vector takes
advantage of movability.

>>>And his "solution" is hokey.  Two out of three compilers rejected
>>>it, and even when it works, the error messages produced will be very
>>>confusing.
>> There's no accounting for nonconforming compilers and poor QOI.
>
>     It's inherent that the messages will be confusing.  He's
> abusing the overload disambiguation rule to do protection.

A minor variation allows you to direct instantiation into a special
template where you can generate a more intelligible error.

>> auto_ptr is a basically flawed design (though I find it pretty good
>> for what it's designed for).  You should never move with copy
>> semantics, except for places where copies could be elided by the
>> compiler anyway.  I don't think that the difficulty of implementing
>> such odd (euphemism) semantic requirements proves anything about the
>> language.
>
>     auto_ptr is the only "smart pointer" class in the standard,
> and after three major revisions, it's still not very good.  That's
> the simplest case.  If that can't be made to work simply,
> cleanly, reliably, and efficiently, then there's very little
> chance of more eomplex smart pointers working reliably.

auto_ptr probably has the most complicated and subtle semantics I can
think of, so I don't think there's much risk of running into "more
complex smart pointers".

>     Trying to kludge around the problem with wierdo templates
> is not an acceptable solution for production code.

Moralistic judgements about programming techniques don't hold much
weight for me.  Either a technique works or it doesn't.

>> You still haven't explained what "this" is.  What kind of bugs are
>> you preventing?
>
>     The ones that allow buffer overflows and memory corruption.

How does your proposal prevent buffer overflows and memory corruption?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:

> nagle@animats.com (John Nagle) writes:
> How does your proposal prevent buffer overflows and memory corruption?

   See

 http://www.animats.com/papers/languages/

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:

> I see the following problem (using 'scopebound' instead of 'auto'):
>
>    struct S { int scopebound * i; };
>
>    void h(S scopebound * sp, i scopebound * i)
>    {
>       sp->i = i;
>    }

    You wouldn't be allowed to use "scopebound" inside
a struct declaration.  It's a storage class, like
"auto" or "static", and it's not meaningful for different
fields of the same object to have storage classes.
That's why I wanted to use "auto" for that purpose.
You would only use it when declaring a variable.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-08-22 06:36, John Nagle wrote:
> Niklas Matthies wrote:
>
>> I see the following problem (using 'scopebound' instead of 'auto'):
>>
>>    struct S { int scopebound * i; };
>>
>>    void h(S scopebound * sp, i scopebound * i)
>>    {
>>       sp->i = i;
>>    }
>
> You wouldn't be allowed to use "scopebound" inside a struct
> declaration.  It's a storage class, like "auto" or "static", and
> it's not meaningful for different fields of the same object to have
> storage classes. That's why I wanted to use "auto" for that purpose.
> You would only use it when declaring a variable.

Ok, then what about e.g. 'int scopebound * & r' (reference to
scope-bound pointer to int)? Disallowing it makes swap() unusable
for scope-bound pointers, and allowing it causes the same problems
as described above.

-- Niklas Matthies

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:

> David Abrahams wrote:
>> nagle@animats.com (John Nagle) writes:
>>
>>>christopher diggins wrote:
>>>
>>> > In my programming language Heron, I have mark
>>> > pointer ownership semantics
>>> > using an extra symbol. It occured to me that this
>>> > might be something worthy
>>> > of consideration for C++.
>>>
>>>    There's some similarity here to what I wrote on "Strict C++"
>>>several years ago:
>>>
>>> http://www.animats.com/papers/languages
>>>
>>>One of the basic problems of C++ is that the language requires
>>>the user to manage memory carefully yet provides little assistance
>>>in doing so.  This is well known, but no satisfactory solution
>>>has been developed for C++, despite many attempts.
>>>
>>>     Attempts to encapsulate memory management using "smart pointers"
>>>are usually both inefficient and unsafe, due to inadequate language
>>>level support.  The history of auto_ptr (three major revisions and
>>>it still isn't right) makes this clear.
>> Is there anything wrong with it other than what Rani fixes in this
>> thread <http://tinyurl.com/6cqmm>?
>
>     If you can get a raw pointer out, it's unsafe.

Why, because it can dangle?

> If you can't get a raw pointer out, it's unusable.

Why?

> Rani doesn't address that issue at all.

Not surprising, if nobody but you understands it.

> Nor does he address the "collections of auto_ptr" problem.

See move_ptr.

> And his "solution" is hokey.  Two out of three compilers rejected
> it, and even when it works, the error messages produced will be very
> confusing.

There's no accounting for nonconforming compilers and poor QOI.

>     Has the Commitee accepted his approach?

No, it's on the issues list now.

>     auto_ptr is valuable as a way to exhibit basic flaws of C++.
> The fact that auto_ptr is so hard to do demonstrates clearly
> that the language can't support smart pointers well.

auto_ptr is a basically flawed design (though I find it pretty good
for what it's designed for).  You should never move with copy
semantics, except for places where copies could be elided by the
compiler anyway.  I don't think that the difficulty of implementing
such odd (euphemism) semantic requirements proves anything about the
language.

> If it could, there wouldn't be so many bad smart pointer classes.
> There would be a few standard ones.

If Java were suitable for writing any programs at all, there wouldn't
be so many bad Java programs, right?

>>>     Efficient, safe smart pointer schemes for C++ require two
>>>basic mechanisms at the language and compiler level:
>>>
>>>     1.  Some way to avoid unnecessary reference count updates
>>>         and copies of smart pointer objects is required.
>> RVOs are insufficient?
>
>     That's one technique to solve one specific problem.

Not exactly a technique, but OK.

> It doesn't do anything about reference count optimization in loops,
> for example.

Example?

>     When you think you have a good smart pointer implementation,
> try converting some functions from "Numerical Recipes in C/C++"
> to it, and see if the overhead is a problem.

What do you mean by that?  How do you do numerical algorithms on
smart pointers?

>>>     2.  Either the need to ever obtain a raw pointer to an object
>>> must be eliminated, or some means for protecting raw pointers
>>> must be provided.
>> weak_ptr is insufficient?
>
>     weak_ptr does something else entirely, assuming you mean
> Boost's weak_ptr.  You can't even deference Boost's weak_ptr;
> you have to make a shared_ptr from it before you can do
> anything with the object it references.

Yes, I know what it does.

>     I'd proposed something in my "Strict C++" proposal which
> did this right

You still haven't explained what "this" is.  What kind of bugs are
you preventing?

>  - an attribute on raw pointers which limited their
> lifetime.  With this attribute (I'd proposed using "auto"),
> a raw pointer is copyable, but only to a variable of equal or
> lesser scope.  So that's what you pass into a function
> that needs to operate on an object, but can't delete it
> or keep a reference or pointer to it.
>
>     Because you can't talk about "scope" in templates, you
> can't do that via the template mechanism.

Actually you can, but at a whole different level.  It doesn't look
like C++ anymore at that point ;-)

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-08-20 23:05, llewelly wrote:
> nagle@animats.com (John Nagle) writes:
> [snip]
>>     I'd proposed something in my "Strict C++" proposal which
>> did this right - an attribute on raw pointers which limited their
>> lifetime.  With this attribute (I'd proposed using "auto"),
>> a raw pointer is copyable, but only to a variable of equal or
>> lesser scope.  So that's what you pass into a function
>> that needs to operate on an object, but can't delete it
>> or keep a reference or pointer to it.
> [snip]
>
> Ada's access types (which are a rough equivalent of pointers) have
> this limitation by default, IIRC.

I see the following problem (using 'scopebound' instead of 'auto'):

   struct S { int scopebound * i; };

   void h(S scopebound * sp, i scopebound * i)
   {
      sp->i = i;
   }

   void g(S scopebound * sp)
   {
      int i;
      h(sp, &i);
   }

   int f()
   {
      S s;
      g(&s);
      return *s.i;    // bang!
   }

Does Ada prevent this?

I would consider it pretty limiting if scope-bound pointers couldn't
be assigned to one another, but then there's the problem that in the
general case it can't be statically known which pointer points to a
lesser scope than the other.

-- Niklas Matthies

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:
[snip]
>     I'd proposed something in my "Strict C++" proposal which
> did this right - an attribute on raw pointers which limited their
> lifetime.  With this attribute (I'd proposed using "auto"),
> a raw pointer is copyable, but only to a variable of equal or
> lesser scope.  So that's what you pass into a function
> that needs to operate on an object, but can't delete it
> or keep a reference or pointer to it.
[snip]

Ada's access types (which are a rough equivalent of pointers) have
this limitation by default, IIRC.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:

> On 2004-08-22 06:36, John Nagle wrote:
>
>>Niklas Matthies wrote:
>>
>>
>>>I see the following problem (using 'scopebound' instead of 'auto'):
>>>
>>>   struct S { int scopebound * i; };
>>>
>>>   void h(S scopebound * sp, i scopebound * i)
>>>   {
>>>      sp->i = i;
>>>   }
>>
>>You wouldn't be allowed to use "scopebound" inside a struct
>>declaration.  It's a storage class, like "auto" or "static", and
>>it's not meaningful for different fields of the same object to have
>>storage classes. That's why I wanted to use "auto" for that purpose.
>>You would only use it when declaring a variable.
>
>
> Ok, then what about e.g. 'int scopebound * & r' (reference to
> scope-bound pointer to int)? Disallowing it makes swap() unusable
> for scope-bound pointers, and allowing it causes the same problems
> as described above.

     That's right.  There are many things you can't do with scope-bound
pointers and references.  It's not really intended that you
manipulate them much.   The idea is that you use some
smart-pointer class for pointers that need to be manipulated.
When you just want a short-term working reference, with no
extra overhead, you use a scope-bound pointer or reference.

     Think of functions like

   void Multiply(scopebound mat& out,
 scopebound const mat& in1,
 scopebound const mat& in2);

The "scopebound" just means that the function can't delete the object
or keep a pointer to it.  The function can only use the object while
control is in that function.  "scopebound" is most useful for
function declarations, because it tells you whether or not
the function can mess with the object's existence.

   Another way to think of this is that there are three basic
permissions, "read", "write" and "control existence".
"const" addresses write permission.  "scopebound" addresses
"control existence", the power to delete or to prevent deletion.

    Actually, "scopebound" is the most common case for
arguments.  Few functions delete their arguments.
If they do, the caller definitely needs to be aware of it.
As with "const", if this had been thought of early enough,
it would have been the default for arguments.


       John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> nagle@animats.com (John Nagle) writes:
>
>

>>    If you can get a raw pointer out, it's unsafe.
>
> Why, because it can dangle?

     Yes.

>>If you can't get a raw pointer out, it's unusable.

Because you're not going to get every library modified
to use some specific implementation of encapsulated pointers.

>>Rani doesn't address that issue at all.

> Not surprising, if nobody but you understands it.

    Hello?

>>Nor does he address the "collections of auto_ptr" problem.
>
>
> See move_ptr.

    Do collections of move_ptr work?  Is there a distributed
piece of software that uses them?

>>And his "solution" is hokey.  Two out of three compilers rejected
>>it, and even when it works, the error messages produced will be very
>>confusing.
>
>
> There's no accounting for nonconforming compilers and poor QOI.

    It's inherent that the messages will be confusing.  He's
abusing the overload disambiguation rule to do protection.

> auto_ptr is a basically flawed design (though I find it pretty good
> for what it's designed for).  You should never move with copy
> semantics, except for places where copies could be elided by the
> compiler anyway.  I don't think that the difficulty of implementing
> such odd (euphemism) semantic requirements proves anything about the
> language.

    auto_ptr is the only "smart pointer" class in the standard,
and after three major revisions, it's still not very good.  That's
the simplest case.  If that can't be made to work simply,
cleanly, reliably, and efficiently, then there's very little
chance of more eomplex smart pointers working reliably.

    Trying to kludge around the problem with wierdo templates
is not an acceptable solution for production code.

> You still haven't explained what "this" is.  What kind of bugs are
> you preventing?

    The ones that allow buffer overflows and memory corruption.
The ones that cause the most serious problems in software.
The ones that developers of programs that have to work worry
about.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:qWqUc.7113$Ao6.499@newssvr29.news.prodigy.com...
> christopher diggins wrote:
>
>  > In my programming language Heron, I have mark
>  > pointer ownership semantics
>  > using an extra symbol. It occured to me that this
>  > might be something worthy
>  > of consideration for C++.
>
>     There's some similarity here to what I wrote on "Strict C++"
> several years ago:
>
> http://www.animats.com/papers/languages

Thank you for bringing this to my attention, it is an interesting proposal.

> One of the basic problems of C++ is that the language requires
> the user to manage memory carefully yet provides little assistance
> in doing so.  This is well known, but no satisfactory solution
> has been developed for C++, despite many attempts.

Yes I agree with you.

To illustrate how what I am proposing is different from the Strict C++
proposal, I want to allow the syntax of C++ to represent the abstract notion
of ownership without intertwining it with the concern of automated
destruction of dynamically allocated memory. I believe that this is in large
part why auto_ptr is having so much trouble in that it tangles both
concerns.

--
Christopher Diggins
http://www.heron-language.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
news:5b15f8fd.0408170902.1b406d9f@posting.google.com...
> cdiggins@videotron.ca ("christopher diggins") wrote:
> [...]
> > AbstractIterator* SomeCollectionClass::CreateRunTimeIterator() {
> >     return new AppropriateConcreteIterator;
> > }
> [...]
>
> > We could in C++ introduce a special kind of pointer, say MyObject^ which
was
> > distinguishable from MyObject* in that it could only be initialized or
> > assigned from anything but another owner pointer or the results of a new
> > operation. We could then deprecate delete operations performed on raw
> > pointers.
>
> We already have this: it is called smart pointer. For example, the above
> function should be changed to become
>
>   std::auto_ptr<AbstractIterator>
>   SomeCollectionClass::CreateRunTimeIterator() {
>       return std::auto_ptr<AbstractIterator>(new
AppropriateConcreteIterator);
>   }
> --

auto_ptr comes bundled with rules for automated destruction and has for
nullification upon assignment. This comes with many extra problems, not the
least of which being the inability to place auto_ptr's in an STL. auto_ptr
could be seen as a special case of an owner pointer.

What I am proposing is purely a representation of the concept of ownership
without any implication as to when and how the object is destroyed, that is
left up to the programmer.

Using a owner pointer which says nothing about the scope of the object would
free us from the limitations of any particular smart pointer implementation.

--
Christopher Diggins
http://www.heron-language.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> nagle@animats.com (John Nagle) writes:
>
>
>>christopher diggins wrote:
>>
>> > In my programming language Heron, I have mark
>> > pointer ownership semantics
>> > using an extra symbol. It occured to me that this
>> > might be something worthy
>> > of consideration for C++.
>>
>>    There's some similarity here to what I wrote on "Strict C++"
>>several years ago:
>>
>> http://www.animats.com/papers/languages
>>
>>One of the basic problems of C++ is that the language requires
>>the user to manage memory carefully yet provides little assistance
>>in doing so.  This is well known, but no satisfactory solution
>>has been developed for C++, despite many attempts.
>>
>>     Attempts to encapsulate memory management using "smart pointers"
>>are usually both inefficient and unsafe, due to inadequate language
>>level support.  The history of auto_ptr (three major revisions and
>>it still isn't right) makes this clear.
>
>
> Is there anything wrong with it other than what Rani fixes in this
> thread <http://tinyurl.com/6cqmm>?

    If you can get a raw pointer out, it's unsafe.  If you can't
get a raw pointer out, it's unusable.  Rani doesn't address that
issue at all.  Nor does he address the "collections of auto_ptr"
problem.  And his "solution" is hokey.  Two out of three
compilers rejected it, and even when it works, the error messages
produced will be very confusing.

    Has the Commitee accepted his approach?

    auto_ptr is valuable as a way to exhibit basic flaws of C++.
The fact that auto_ptr is so hard to do demonstrates clearly
that the language can't support smart pointers well.  If it
could, there wouldn't be so many bad smart pointer classes.
There would be a few standard ones.

>
>
>>     Efficient, safe smart pointer schemes for C++ require two
>>basic mechanisms at the language and compiler level:
>>
>>     1.  Some way to avoid unnecessary reference count updates
>>         and copies of smart pointer objects is required.
>
> RVOs are insufficient?

    That's one technique to solve one specific problem.   It doesn't
do anything about reference count optimization in loops, for
example.

    When you think you have a good smart pointer implementation,
try converting some functions from "Numerical Recipes in C/C++"
to it, and see if the overhead is a problem.
>
>
>>     2.  Either the need to ever obtain a raw pointer to an object
>> must be eliminated, or some means for protecting raw pointers
>> must be provided.
>
>
> weak_ptr is insufficient?

    weak_ptr does something else entirely, assuming you mean
Boost's weak_ptr.  You can't even deference Boost's weak_ptr;
you have to make a shared_ptr from it before you can do
anything with the object it references.

    I'd proposed something in my "Strict C++" proposal which
did this right - an attribute on raw pointers which limited their
lifetime.  With this attribute (I'd proposed using "auto"),
a raw pointer is copyable, but only to a variable of equal or
lesser scope.  So that's what you pass into a function
that needs to operate on an object, but can't delete it
or keep a reference or pointer to it.

    Because you can't talk about "scope" in templates, you
can't do that via the template mechanism.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<R1uUc.97773$sk2.2062128@wagner.videotron.net>...
> auto_ptr comes bundled with rules for automated destruction and has for
> nullification upon assignment. This comes with many extra problems, not the
> least of which being the inability to place auto_ptr's in an STL. auto_ptr
> could be seen as a special case of an owner pointer.
>
> What I am proposing is purely a representation of the concept of ownership
> without any implication as to when and how the object is destroyed, that is
> left up to the programmer.

What does it mean to own a dynamically allocated pointer if ownership
isn't tied to deallocation? Isn't ownership of a resource about who is
responsible for freeing the resource?

Bob

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<R1uUc.97773$sk2.2062128@wagner.videotron.net>...
> auto_ptr comes bundled with rules for automated destruction and has for
> nullification upon assignment. This comes with many extra problems, not the
> least of which being the inability to place auto_ptr's in an STL. auto_ptr
> could be seen as a special case of an owner pointer.
>
> What I am proposing is purely a representation of the concept of ownership
> without any implication as to when and how the object is destroyed, that is
> left up to the programmer.

What does it mean to own a dynamically allocated pointer if ownership
isn't tied to deallocation? Isn't ownership of a resource about who is
responsible for freeing the resource?

Bob

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In my programming language Heron, I have mark pointer ownership semantics
using an extra symbol. It occured to me that this might be something worthy
of consideration for C++.

The motivation is essentially this, when a function acts as an object
factory we rely on a naming convention or other form of documentation to
indicate to the user of that function that the responsibility for deletion
of the object is being tranfserred to the owner.

Consider the following example:

AbstractIterator* SomeCollectionClass::CreateRunTimeIterator() {
    return new AppropriateConcreteIterator;
}

The names here and the source make the intention apparent, but this method
is hardly robust or consistent across organizations and coding standards.
Something like the following is less clear where the source is unavailable:

MyObject* SomeOtherObject::FuBar();

There are other examples where it is appropriate to transfer ownership. For
instance a design pattern that I frequently use is where I automatically add
new objects to a custom list for deletion.

We could in C++ introduce a special kind of pointer, say MyObject^ which was
distinguishable from MyObject* in that it could only be initialized or
assigned from anything but another owner pointer or the results of a new
operation. We could then deprecate delete operations performed on raw
pointers.

The advantages of such an approach are:

* we would significantly reduce the number of cases where inappropriate
deletion of memory occurs
* programmers would be more aware of object ownership in their own source
code
* code would be more readable and require less documentation

Have any similar proposals already been made and rejected?

--
Christopher Diggins
http://www.heron-centric.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 08/16/2004 05:13 PM, christopher diggins wrote:
[snip]
> There are other examples where it is appropriate to transfer ownership. For
> instance a design pattern that I frequently use is where I automatically add
> new objects to a custom list for deletion.
>
> We could in C++ introduce a special kind of pointer, say MyObject^ which was
> distinguishable from MyObject* in that it could only be initialized or
> assigned from anything but another owner pointer or the results of a new
> operation. We could then deprecate delete operations performed on raw
> pointers.
>
> The advantages of such an approach are:
>
> * we would significantly reduce the number of cases where inappropriate
> deletion of memory occurs
> * programmers would be more aware of object ownership in their own source
> code
> * code would be more readable and require less documentation
>
> Have any similar proposals already been made and rejected?
>

I'm not sure I understand, but this sounds somewhat like the NoPtr in

http://unc.dl.sourceforge.net/sourceforge/noptrlib/NoPtrLib-0.9b2.tar.gz

The following is a quote from file comparePtrOthers.dox within that
tar.gz file:

The essense of NoPtr is strict ownership of dynamically allocated
objects (DAO). I.e., only one object (of class DynObj) in your program,
at any given time, is responsible for the destruction of a given DAO.
Just like for automatic variables (which are also strictly owned),
references are used to pass objects around without copy; this is done
by RRef and DynTmp.

How would this special kind of pointer, indicated with the ^ postfix
operator, differ from the NoPtr smart pointer, other than by saving
typing?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

christopher diggins wrote:

 > In my programming language Heron, I have mark
 > pointer ownership semantics
 > using an extra symbol. It occured to me that this
 > might be something worthy
 > of consideration for C++.

    There's some similarity here to what I wrote on "Strict C++"
several years ago:

 http://www.animats.com/papers/languages

One of the basic problems of C++ is that the language requires
the user to manage memory carefully yet provides little assistance
in doing so.  This is well known, but no satisfactory solution
has been developed for C++, despite many attempts.

     Attempts to encapsulate memory management using "smart pointers"
are usually both inefficient and unsafe, due to inadequate language
level support.  The history of auto_ptr (three major revisions and
it still isn't right) makes this clear.

     Efficient, safe smart pointer schemes for C++ require two
basic mechanisms at the language and compiler level:

     1.  Some way to avoid unnecessary reference count updates
         and copies of smart pointer objects is required.

     2.  Either the need to ever obtain a raw pointer to an object
 must be eliminated, or some means for protecting raw pointers
 must be provided.

     It is unlikely that C++ will ever be provided with
adequate mechanisms to solve either of these problems, and thus,
for the forseeable future, C++ programs will continue to fail
due to memory allocation problems.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote:
[...]
> AbstractIterator* SomeCollectionClass::CreateRunTimeIterator() {
>     return new AppropriateConcreteIterator;
> }
[...]

> We could in C++ introduce a special kind of pointer, say MyObject^ which was
> distinguishable from MyObject* in that it could only be initialized or
> assigned from anything but another owner pointer or the results of a new
> operation. We could then deprecate delete operations performed on raw
> pointers.

We already have this: it is called smart pointer. For example, the above
function should be changed to become

  std::auto_ptr<AbstractIterator>
  SomeCollectionClass::CreateRunTimeIterator() {
      return std::auto_ptr<AbstractIterator>(new AppropriateConcreteIterator);
  }
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:

> christopher diggins wrote:
>
>  > In my programming language Heron, I have mark
>  > pointer ownership semantics
>  > using an extra symbol. It occured to me that this
>  > might be something worthy
>  > of consideration for C++.
>
>     There's some similarity here to what I wrote on "Strict C++"
> several years ago:
>
>  http://www.animats.com/papers/languages
>
> One of the basic problems of C++ is that the language requires
> the user to manage memory carefully yet provides little assistance
> in doing so.  This is well known, but no satisfactory solution
> has been developed for C++, despite many attempts.
>
>      Attempts to encapsulate memory management using "smart pointers"
> are usually both inefficient and unsafe, due to inadequate language
> level support.  The history of auto_ptr (three major revisions and
> it still isn't right) makes this clear.

Is there anything wrong with it other than what Rani fixes in this
thread <http://tinyurl.com/6cqmm>?

>      Efficient, safe smart pointer schemes for C++ require two
> basic mechanisms at the language and compiler level:
>
>      1.  Some way to avoid unnecessary reference count updates
>          and copies of smart pointer objects is required.

RVOs are insufficient?

>      2.  Either the need to ever obtain a raw pointer to an object
>  must be eliminated, or some means for protecting raw pointers
>  must be provided.

weak_ptr is insufficient?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<kZ9Uc.56580$sk2.829133@wagner.videotron.net>...
> In my programming language Heron, I have mark pointer ownership semantics
> using an extra symbol. It occured to me that this might be something worthy
> of consideration for C++.
>
> The motivation is essentially this, when a function acts as an object
> factory we rely on a naming convention or other form of documentation to
> indicate to the user of that function that the responsibility for deletion
> of the object is being tranfserred to the owner.
>
> Consider the following example:
>
> AbstractIterator* SomeCollectionClass::CreateRunTimeIterator() {
>     return new AppropriateConcreteIterator;
> }

This function is flawed, since it returns an unmanaged resource. It
should return auto_ptr, shared_ptr, or another smart pointer or
handle, as appropriate.

[...]

> We could in C++ introduce a special kind of pointer, say MyObject^ which was
> distinguishable from MyObject* in that it could only be initialized or
> assigned from anything but another owner pointer or the results of a new
> operation.

There is a certain appeal to new returning a special kind of pointer.
However if we could change the return type of new X (we can't, really,
it will break too much existing code), what's wrong with auto_ptr<X>?

> http://www.heron-centric.com

You ask some interesting questions in The Joel on Software forum. Too
bad I don't read it. ;-) Without going too off-topic (this is c.s.c++
after all):

http://boost.org/libs/smart_ptr/sp_techniques.html#weak_without_shared

may give you some ideas about weak pointers to stack objects.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]