dheld@codelogicconsulting.com ("David B. Held") wrote in message news:<uu7j85quneps48@corp.supernews.com>...
> "John Nagle" <nagle@animats.com> wrote in message
> news:3DE3BEA7.1040907@animats.com...
> > [...]
> >      The fact that all attempts at auto_ptr to date don't
> > work right indicates a real problem with C++.
>
> I disagree.
>
> > Many bright people have beaten their heads against that wall.
> > You just can't do "smart pointers" right in C++ without a little more
> > support in the language.
>
> You just can't have a universal smart pointer.

You've missed the original point JK made.  The problem is that the
following will not work for *any* smart pointer that implements
ownership (not auto_ptr, not boost, not arglib, ...).

typdef any_smart_ptr<int> smart_ptr;

void f(smart_ptr foo, smart_ptr bar);

int main() {
    f(smart_ptr(new int()), smart_ptr(new int())); // Possible leak
}

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

"Alan Griffiths" <alan@octopull.demon.co.uk> wrote in message
news:4c498b63.0212050139.5e3d1d7@posting.google.com...
> > [...]
> > > Many bright people have beaten their heads against that wall.
> > > You just can't do "smart pointers" right in C++ without a little
> > > more support in the language.
> >
> > You just can't have a universal smart pointer.
>
> You've missed the original point JK made.  The problem is that the
> following will not work for *any* smart pointer that implements
> ownership (not auto_ptr, not boost, not arglib, ...).
>
> typdef any_smart_ptr<int> smart_ptr;
>
> void f(smart_ptr foo, smart_ptr bar);
>
> int main() {
>     f(smart_ptr(new int()), smart_ptr(new int())); // Possible leak
> }

The question is whether it *ought* to work.  Granted, it makes smart
pointers fundamentally different from raw pointers, but isn't the issue
really sequence points?  And isn't it true that sequence points (or the
lack thereof) can cause problems in all kinds of situations?  So we
just have to be careful about relying on the order of execution.  I
don't see that as a failure to properly handle smart pointers.  It just
means that C++ does things in a way where we have to be careful.
I guess I don't see it as a problem any more than not being able
to write:

foo(i++, ++i);

C++ is not a functional language, so we can't always compose
functions in what may seem are obvious ways.

Dave


---
[ 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                       ]

alan@octopull.demon.co.uk (Alan Griffiths) wrote in message
news:<4c498b63.0212050139.5e3d1d7@posting.google.com>...
> dheld@codelogicconsulting.com ("David B. Held") wrote in message
> news:<uu7j85quneps48@corp.supernews.com>...
> > "John Nagle" <nagle@animats.com> wrote in message
> > news:3DE3BEA7.1040907@animats.com...
> > > [...]
> > >      The fact that all attempts at auto_ptr to date don't
> > > work right indicates a real problem with C++.

> > I disagree.

> > > Many bright people have beaten their heads against that wall.  You
> > > just can't do "smart pointers" right in C++ without a little more
> > > support in the language.

> > You just can't have a universal smart pointer.

> You've missed the original point JK made.  The problem is that the
> following will not work for *any* smart pointer that implements
> ownership (not auto_ptr, not boost, not arglib, ...).

> typdef any_smart_ptr<int> smart_ptr;

> void f(smart_ptr foo, smart_ptr bar);

> int main() {
>     f(smart_ptr(new int()), smart_ptr(new int())); // Possible leak
> }

Right.

There are two possible solutions: garbage collection, and introducing a
sequence point between the evaluation of parameters (without imposing an
order on that evalutation).  Personally, I think both would be a good
idea.  Garbage collection simplifies the programmers work, and in many
cases, would make the additional smart pointers superfluous.  Many cases
isn't all cases, however; even with garbage collection, there will be
cases where the smart pointer solution is preferable, and I would like
to see it made to work as well.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

alan@octopull.demon.co.uk (Alan Griffiths) wrote in message news:<4c498b63.0212050139.5e3d1d7@posting.google.com>...
> dheld@codelogicconsulting.com ("David B. Held") wrote in message news:<uu7j85quneps48@corp.supernews.com>...
> > You just can't have a universal smart pointer.
>
> You've missed the original point JK made.  The problem is that the
> following will not work for *any* smart pointer that implements
> ownership (not auto_ptr, not boost, not arglib, ...).
>
> typdef any_smart_ptr<int> smart_ptr;
>
> void f(smart_ptr foo, smart_ptr bar);
>
> int main() {
>     f(smart_ptr(new int()), smart_ptr(new int())); // Possible leak
> }

This is a specific instance of a general problem. Unmanaged resources
of any kind - not just memory - and exceptions (or any nontrivial
control flow, for that matter) do not mix well. Smart pointers are not
to blame.

---
[ 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                       ]

Mirek Fidler wrote:

>>My top three:
>>
>>1. Undefined behaviour.
>>2. Unspecified behaviour.
>>3. Implementation-defined behaviour.
>>
>
>     Exactly. There is way too much undefined behaviour in C++ that is in
> fact consistently well defined on most 32/64 bit platforms. Sometimes you
> have to use it. Sometimes you can get significant performance gain.
> Sometimes you can even get better and safer code.


    Java goes further in that direction, defining the sizes of all
its types, and defining its floating point as IEEE floating point.
This is convenient and consistent, but makes Java support on some
exotic architectures difficult.

    C was standardized back when the 36-bit PDP-10 people were
still influential in academia.  That's the main reason ANSI
C defines integer arithmetic the way it does.  C can be implemented
on ones-complement and signed-magnitude machines of various
unusual word lengths, and it has been.

    But today, very few machines are anything other than
twos-complement byte-oriented.  There are digital signal
processors with 24, 48, and 56 bit word sizes in volume
production, but I don't know of anything in current manufacture
that isn't byte-oriented, with the possible exception of the
Unisys ClearPath servers.

    Yes, Unisys is still selling
machines that will run 36-bit UNIVAC 1100/2200 programs
and 48-bit Burroughs MCP programs.  Those are the
world's oldest living computer architectures.  The 36-bit
ones-complement data formats are nearly compatible back to
the UNIVAC 1103, from 1952, and strictly compatible with
the UNIVAC 1108, circa 1968.

    So that's why C++ still supports 9-bit bytes and odd
sized words.  Whether it should is another question.

     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                       ]

===================================== MODERATOR'S COMMENT:
 C++-standard content dead, please end this subthread.


===================================== END OF MODERATOR'S COMMENT
John Nagle wrote:
>
>     Java goes further in that direction, defining the sizes of all
> its types, and defining its floating point as IEEE floating point.
> This is convenient and consistent, but makes Java support on some
> exotic architectures difficult.
>

And often inefficient on common architectures. The floating point
requirements, in particular, impose a significant slowdown on Intel
processors, which aren't allowed to use their native 80-bit floating
point math internally -- they have to run the math code in a much slower
mode. And then there's the char problem, now that Unicode doesn't fit in
the Java-mandated 16 bit character type. Oh, well, computer cycles are
cheap. May as well waste them.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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                       ]

In article <3DE3BEA7.1040907@animats.com>, John Nagle
<nagle@animats.com> writes
>    The fact that all attempts at auto_ptr to date don't
>work right indicates a real problem with C++.  Many bright
>people have beaten their heads against that wall.
>You just can't do "smart pointers" right in C++ without
>a little more support in the language.


No, what you cannot do is have something that meets the exact design
specifications that got dumped on auto_ptr. I do not want to spend time
rehashing history but there are plenty of ways of meeting the needs but
not via a single smart pointer type (well I do not count Andrei's policy
based smart pointer as a single type)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

===================================== MODERATOR'S COMMENT:
 You can make that point without turning the thread into Java bashing.  :-)


===================================== END OF MODERATOR'S COMMENT
Pete Becker wrote:
>
> John Nagle wrote:
> >
> >     Java goes further in that direction, defining the sizes of all
> > its types, and defining its floating point as IEEE floating point.
> > This is convenient and consistent, but makes Java support on some
> > exotic architectures difficult.
> >
>
> And often inefficient on common architectures. The floating point
> requirements, in particular, impose a significant slowdown on Intel
> processors, which aren't allowed to use their native 80-bit floating
> point math internally -- they have to run the math code in a much slower
> mode. And then there's the char problem, now that Unicode doesn't fit in
> the Java-mandated 16 bit character type. Oh, well, computer cycles are
> cheap. May as well waste them.
>
> ===================================== MODERATOR'S COMMENT:
>  C++-standard content dead, please end this subthread.
>
> ===================================== END OF MODERATOR'S COMMENT

[top post corrected]

Well, reject this if you must <g>, but the C++ content is that there are
risks in rigid requirements. There are good reasons for the flexibility
that C and C++ offer here.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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                       ]

cxl@volny.cz ("Mirek Fidler") wrote in message
news:<arl8ht$2jh0$1@news.vol.cz>...
> > My top three:

> > 1. Undefined behaviour.
> > 2. Unspecified behaviour.
> > 3. Implementation-defined behaviour.

>     Exactly. There is way too much undefined behaviour in C++ that is
> in fact consistently well defined on most 32/64 bit platforms.
> Sometimes you have to use it. Sometimes you can get significant
> performance gain. Sometimes you can even get better and safer code.

Most of the undefined/unspecified behavior that bothers me isn't that
which is effectively defined on most 32/64 bit platforms.  If I am only
porting to those platforms, I know what I can do in addition to what the
standard says, and I do it.

A typical example of where one might get bitten by undefined/unspecified
behavior is the business with creating two auto_ptr in a single
expression that came up lately in clc++m.  It results in an easy mistake
to make, and the resulting code will often work, even under extensive
testing.  Until some future version of the compiler, in which the
optimizer works slightly differently.  More generally, although I find
that code that depends on things like order of evaluation is poorly
written, in reality, we all write poor code from time to time; it is
nice to know that whatever it does in the tests on one machine, it will
do on all of them.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

James Kanze wrote:

> A typical example of where one might get bitten by undefined/unspecified
> behavior is the business with creating two auto_ptr in a single
> expression that came up lately in clc++m.  It results in an easy mistake
> to make, and the resulting code will often work, even under extensive
> testing.  Until some future version of the compiler, in which the
> optimizer works slightly differently.


     The fact that all attempts at auto_ptr to date don't
work right indicates a real problem with C++.  Many bright
people have beaten their heads against that wall.
You just can't do "smart pointers" right in C++ without
a little more support in the language.

     Doing this in a way that's backwards compatible is
really tough, and may be impossible.  I've made two
tries at it so far, and each one had problems.
(Search the archives for the "strict C++" thread.)

     It's clear that some pointers have different
attributes than others.  Some languages make a "strong"
or "weak" pointer distinction.  An "owner" and "user"
distinction is also useful.  It's not clear how to
integrate such attributes into C++, but it's worth
thinking about again.  What we've got isn't working.

    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:3DE3BEA7.1040907@animats.com...
> [...]
>      The fact that all attempts at auto_ptr to date don't
> work right indicates a real problem with C++.

I disagree.

> Many bright people have beaten their heads against that wall.
> You just can't do "smart pointers" right in C++ without a little more
> support in the language.

You just can't have a universal smart pointer.  I think that's the lesson
to be learned.  And if you look at the evolution of smart pointers, I
think that is what history teaches us.  But just because auto_ptr<>
isn't the end-all doesn't mean that it is worthless, or that C++ is
defective.  Just because a hammer can't remove torx nuts doesn't
make it ineffective.

>      Doing this in a way that's backwards compatible is
> really tough, and may be impossible.  I've made two
> tries at it so far, and each one had problems.
> (Search the archives for the "strict C++" thread.)

It's certainly possible that auto_ptr<> will have to make way for
pointers that are invested with more experience.  I would say
already that a lot of people use newer smart pointer types, which
happen to work pretty well for the domains in which they were
intended.

>      It's clear that some pointers have different attributes than others.
> Some languages make a "strong" or "weak" pointer distinction.  An
> "owner" and "user" distinction is also useful.  It's not clear how to
> integrate such attributes into C++, but it's worth thinking about again.
> What we've got isn't working.

I think the Boost smart pointers cover a lot of ground.  Do you think
they are insufficient?

Dave



---
[ 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                       ]

> My top three:
>
> 1. Undefined behaviour.
> 2. Unspecified behaviour.
> 3. Implementation-defined behaviour.

    Exactly. There is way too much undefined behaviour in C++ that is in
fact consistently well defined on most 32/64 bit platforms. Sometimes you
have to use it. Sometimes you can get significant performance gain.
Sometimes you can even get better and safer code.

    Recently I was proposing creating some Common (or Flat) C++
'superstandard' that would define most important 'undefined' and/or
'implementation defined' parts of C++. It would be great help for creating
portable software, and it would also not require too much work on compilers
side - in fact, none other than checking (and eventually to create some
header(s) - depends how far this Common C++ would go...).

    Note that this is not to be meant to replace ISO C++. In fact, Common
C++ compiler would be required to be ISO compliant, PLUS some of
undefined/unspecified/implementation-defined aspects would be defined
(sometimes in form of macros and types - e.g.
PLATFORM_ALLOWS_UNALIGNED_COPY, PLATFORM_LITTLE_ENDIAN, integral ptr_t type
and so on).

Mirek


---
[ 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                       ]