In article <a4db53$bo3$1@bcarh8ab.ca.nortel.com>, Anthony Williams
<anthwil@nortelnetworks.com> writes
>If a non-virtual function needs access to the internals of your class, make
>it a friend, rather than a member. In fact, you can combine this with Herb's
>advice from Virtuality --- virtual functions should be private/protected,
>with a friend function that forwards to them.

While friendship can certainly be used this way, there are issues such
as friend not being a polymorphic, not being inherited etc.

I think the proposal is another attempt to provide a uniform syntax for
calling functions. I prefer the approach of considering a way of
changing C++ to provide that uniformity rather than via, IMO, hijacking
friend.


--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> In article <fbec00f5.0202110910.604c5608@posting.google.com>, John
> Madsen <johnmadsen_usenet@hotmail.com> writes
>
> Just an instant reaction without much thought: how about making all
> member functions virtual if the class has a virtual dtor?
>
> Second thought, how does the thinking in this thread interact with those
> who want virtual functions to be non-public?


      There are two major issues related to marking a
function as "virtual" - safety and performance.  The main
safety issue is that you can override a non-virtual
function in a derived class.  This is usually an error.
[We will now hear from someone who insists it's essential
that there's a good reason for wanting to do that.]
If overriding a non-virtual function were an error,
the safety issue, and the warnings in elementary C++
programming texts to make everything virtual, would go
away.  I think that would be a step forward,
because it's a common cause of bugs of the type which
cannot be seen by looking at one place in the code.

      (I suggest, as a metric on backwards compatibility,
that an incompatible change is OK if it doesn't cause
serious trouble for any major open-source code or any
major vendor class library delivered with source
headers.)

      The performance issue comes from the fact that
vtables are built at compile time, not link time.
Ideally, the virtual/non virtual implementation decision
should be made at link time, and only functions that
need it should get the extra overhead.  But it's too
late for that.  (Although, since .NET is a late-binding
system, we might see it in that world.)

    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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
> Just an instant reaction without much thought: how about making all
> member functions virtual if the class has a virtual dtor?
>
> Second thought, how does the thinking in this thread interact with those
> who want virtual functions to be non-public?

The proposed change would be a disaster for me.  In my designs virtual
functions (other than the obligatory virtual dtor) are always non-public.

nobody
---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:Z5$zZDCZr6a8EwZS@robinton.ntlworld.com...
> In article <a4db53$bo3$1@bcarh8ab.ca.nortel.com>, Anthony Williams
> <anthwil@nortelnetworks.com> writes
> >If a non-virtual function needs access to the internals of your class,
make
> >it a friend, rather than a member. In fact, you can combine this with
Herb's
> >advice from Virtuality --- virtual functions should be private/protected,
> >with a friend function that forwards to them.
>
> While friendship can certainly be used this way, there are issues such
> as friend not being a polymorphic, not being inherited etc.

class X
{
protected:
    virtual void vf(){}
public:
    void mf()
    {
        vf();
    }
    friend void ff(X& x);
};

void ff(X&x)
{
    x.cf();
}

x.mf() and ff(x) have exactly the same properties wrt polymorphism --- they
are selected at compile-time based on the concrete type of x. If x is a
reference to a derived class Y then they will both still work. If the
derived class Y defines its own version of mf with the same signature, and
its own overload of ff with the same signature, except for Y instead of X,
then they still share the same properties.

The only issue is if the derived class uses a _different_ signature to that
of its parent --- the derived version of mf will hide the original when x is
a reference-to-Y rather than a reference-to-X, whereas both overloads of ff
are still available.

ADL means that we don't have to consider namespace issues either --- if the
friend function takes an X& as its first argument, it will always be found
by ADL if an argument of type X, or any class derived from X, is supplied,
so you can say ff(x) regardless of namespace. However, the name ff can also
be used to refer to entities other than functions in different scopes, in
which case the visibility of such an entity may affect the use of the
unqualified name ff as a function name.

> I think the proposal is another attempt to provide a uniform syntax for
> calling functions. I prefer the approach of considering a way of
> changing C++ to provide that uniformity rather than via, IMO, hijacking
> friend.

My feeling is that it is more an issue of safety. Consider Andrei's example
with a smart pointer that has a Release member function. If it points to a
class that also has a Release member function, then the difference between
sp.Release() and sp->Release() is hard to spot, and may lead to bugs.
However Release(sp) vs Release(*sp) is clearer IMHO (though marginal), as is
Release(sp) vs sp->Release().

Yes, it is also an argument for uniform syntax --- I can still say
Release(sp) if I change sp to be a plain pointer. However, IMHO, uniformity
is a good thing, and makes generic programming simpler. Maybe we should
consider proper proposals for uniform calling syntax in C++ for member and
non-member functions, but until we get there, "hijacking" friend seems a
reasonable way of going about it.

Not that I am necessarily advocating this position, just expanding it as a
point of view to consider in a discussion (such as this one).

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<62MLqbCUOla8EwMS@robinton.ntlworld.com>...
[SNIP]
> Just an instant reaction without much thought: how about making all
> member functions virtual if the class has a virtual dtor?

That has the potential to break existing code, I'm afraid.
But I agree repeating 'virtual' gets tedious. Perhaps a class
definition of "virtual class ClassName { }; " could be used to
make all functions virtual ?

Regards,
--
Michiel Salters
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:<62MLqbCUOla8EwMS@robinton.ntlworld.com>...
> In article <fbec00f5.0202110910.604c5608@posting.google.com>, John
> Madsen <johnmadsen_usenet@hotmail.com> writes
> >I have to admit that this confuses me a little.  Particularly after
> >having read, and finally been convinced by Herb Sutter's
> >"Virtuality" (http://www.gotw.ca/publications/mill18.htm).  Is
> >there dissension in the Guru ranks?  Are you really suggesting
> >going the way of Java on this?  What about the C++ principle of
> >only having to pay for what you use?  Why pay for virtual function
> >calls when you don't always have to?

> >I'd love to hear your arguments for this.  I don't recall you
> >advancing this theory in MC++D.

> Just an instant reaction without much thought: how about making all
> member functions virtual if the class has a virtual dtor?

So how would you declare a member function non virtual in such a
class.  A class with only virtual functions is really a rarity --
perhaps the base class for a Visitor, or something like that, but that
is about all.

> Second thought, how does the thinking in this thread interact with
> those who want virtual functions to be non-public?

That there are two extremist groups at work:-)?

Seriously, of course, in entity classes (which are typically the type
of class which first come to mind when one thinks of virtual
functions), a public virtual function would be really rare.  In my own
experience, in such classes, I find between one and a half and two
non-virtual functions for every virtual function (but the variance is
large enough that I wouldn't want to draw any conclusions from it).
One of my complaints in Java is that I am constantly writing "final"
to inhibit the virtuality:-).

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orientie objet
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany, Til.: +49 (0)69 19 86 27
---
[ 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.research.att.com/~austern/csc/faq.html                ]

> > Andrei Alexandrescu:
> > > operator<() does not make sense most of the time
> > > for smart pointers. They should point to elements
> > > of the same array, and 99.9999999999999% of cases
> > > that's not the case.

Garry Lancaster:
> > Write operator< to use std::less, not the raw <.
> > Then the "same array" requirement is overcome.

Andrei Alexandrescu:
> My point was not how to implement operator<,
> but rather whether or not you
> actually want the comparison to be valid.

And that's the difference: with raw < the comparison
is, as you write, only guaranteed valid for elements
of the same array, whereas with std::less the
comparison is guaranteed to be valid [1] even
for separate non-array objects.

Or, are you saying you don't *want* the result
of the smart pointer's operator< to be valid?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

NOTES:

1. Where "valid" actually means will "yield a total
order" [20.3.3/8]
---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message news:<GrE7F4.1s0x@beaver.cs.washington.edu>...
> "Terje Slettebx" <tslettebo@acm.org> wrote in message

> > Huh? Are you saying that all member functions (in general) should be
> > virtual?

> It's the other way around: all nonvirtuals should be nonmember.

Ok.

> Actually, in
> the best of all worlds, there would be no member functions at all :o).

Then how would you deal with issues such as access control? Which (if
any) functions should have access? If you advocate using "friend" for
this, I don't think you've gained, anything. The result regarding
encapsulation, is the same.


> > Do you have any backing (articles, references, etc.) for your rather
> > extreme statement?
>
> Scott Meyers, "How Non-member Functions Increase Encapsulation".

I've read it, now. He does not advocate to make non-member functions,
if they need to access the non-public interface.

In your statement above, here, you say that _all_ non-virtuals should
be non-member, do you really mean that? That would include those which
need access to the non-public interface of the class, and which
therefore would require a friend declaration. This goes beyond what he
advocates in the article.

It was mostly this that I reacted to, because I couldn't understand
how a function that needed intimate knowledge of a class (access to
its private and protected members), could improve encapsulation by
being defined somewhere else...

Also that you said it so strongly. There are really different opinions
in this matter, and saying that non-virtual member functions lead to
brainwashing, is simply wrong. The point is that they have their
place, too, unless you use copious amounts of friend declarations, and
then you haven't really gained anything, I think.

There's another important issue here: Avoiding namespace pollution.
With global functions, you may end up in name-collisions, which are
avoided if member functions are used. In the article, he suggests
namespaces to cope with this. That means that instead of object.f(),
you'll have to write f(object), and hope that Koenig Lookup will
detect the namespace (something that doesn't work in VC++, for
example, it only works for operators, there).

However, overloading of global functions will probably do so that
name-collisions are avoided.

Also, use of namespace does not work if template parameters are used
to qualify the function name, as he points out (in the sidebar).

There's also the syntax issues, as I pointed out, and he points out in
the article, that access to member and non-member functions are
different, so you don't get a uniform treatment of the two.

He argues that this is used in places such as STL. However, the use of
non-member functions in STL, such as the algorithms, has nothing to do
with encapsulation, when it comes to one class, but rather that they
are supposed to be usable for any kind of class, thus by definition,
they can't be member functions. In the case where there's a better
function, that only applies for one class, it's a member function,
because it only pertains to that class, not classes in general, even
if it isn't virtual.

If it was possible to use object.f() as a shorthand for f(object) (as
you mention regarding Multimethods, in "Modern C++ Design"), then
there would be no syntactic inconsistency. However, C++ isn't designed
that way, and we should consider the language for how it is, rather
than how one may want it to be.

I think the argument in the article, that a class with less member
functions, is more encapsulated than one with more, doesn't hold. It
depends on whether those member functions actually access private
information, or not. His argument for encapsulation is how many must
be changed, if the implementation changes.

Therefore, whether you have a member function that only accesses the
public interface, or you have a non-member non-friend function that is
equal to it, is really the same. Neither of them needs changing, if
the implementation changes.

Therefore, the statement that non-member non-friend functions is
preferable, and increases encapsulation, compared to member functions,
on general grounds, is wrong. Therefore, the argument for it doesn't
hold.

I think you'll see from this that there are more nuyances to this than
your apparent black/white statement.

Given all this, I think your statement about non-virtual member
functions leads to brainwashing, is insulting and uncalled for, and
I'd like you to moderate that. This may insult others, who may have
perfectly good reasons for choosing non-virtual member functions, also
from purely preferential reasons. To assume that others have the same
background and preferences as oneself, would be narrow-minded.

I understand the implications of both member, and non-member
functions.

This is also something that goes well with what you said about
"emperor's clothes", i.e. to think for oneself. For example, macros
are often discouraged, however they are used in for example Loki.
That's because that in those contexts, they appear to be the best
choice.

I argue that the same is the case for non-virtual member functions.
There may be cases where they are the best choice. This is also rather
subjective.

To qoute from the article:

"Of course, a minimal class interface is not necessarily the best
interface. I remarked in Effective C++ that adding functions beyond
those truly necessary may be justifiable if it significantly improves
the performance of the class, makes the class easier to use, or
prevents likely client errors."

This is in rather stark contrast to your uncompromising statement
about non-virtual member functions. Even Scott Meyers doesn't support
this, in the article.


> A wonderful
> "emperor clothes" paper. You don't see them that often.

It's definitely good that people think for themselves, yes. I'm very
non-conformist and anti-authoritative, myself. Or I probably wouldn't
have questioned your statement. :) To me, it doesn't matter who says
it. Even if you're the only person in the world of an opinion, you may
be right.


Regards,

Terje
---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <fbec00f5.0202110910.604c5608@posting.google.com>, John
Madsen <johnmadsen_usenet@hotmail.com> writes
>I have to admit that this confuses me a little.  Particularly after
>having read, and finally been convinced by Herb Sutter's "Virtuality"
>(http://www.gotw.ca/publications/mill18.htm).  Is there dissension in
>the Guru ranks?  Are you really suggesting going the way of Java on
>this?  What about the C++ principle of only having to pay for what you
>use?  Why pay for virtual function calls when you don't always have
>to?
>
>I'd love to hear your arguments for this.  I don't recall you
>advancing this theory in MC++D.

Just an instant reaction without much thought: how about making all
member functions virtual if the class has a virtual dtor?

Second thought, how does the thinking in this thread interact with those
who want virtual functions to be non-public?

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"John Madsen" <johnmadsen_usenet@hotmail.com> wrote in message
news:fbec00f5.0202110910.604c5608@posting.google.com...
> "Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
news:<a3tf4g$1atquh$1@ID-14036.news.dfncis.de>...
> > Basically my belief is that nonvirtual member functions in general are
> > an unnecessary cutesy in C++ that wahses people's brains, leads to bad
> > programs, and will take many years to wear off. For smart pointers in
> > particular, they can do even more harm.
>
> I have to admit that this confuses me a little.  Particularly after
> having read, and finally been convinced by Herb Sutter's "Virtuality"
> (http://www.gotw.ca/publications/mill18.htm).  Is there dissension in
> the Guru ranks?  Are you really suggesting going the way of Java on
> this?  What about the C++ principle of only having to pay for what you
> use?  Why pay for virtual function calls when you don't always have
> to?

I think you've misunderstood Andrei's point (or I have ;-). He is extended
Scott Meyers "Non-member functions improve encapsulation"
(http://www.cuj.com/articles/2000/0002/0002c/0002c.htm) to say that
_everything_ should be a non-member unless it _has_ to be a member (i.e.
it's virtual, a constructor or an operator that _must_ be a member)

If a non-virtual function needs access to the internals of your class, make
it a friend, rather than a member. In fact, you can combine this with Herb's
advice from Virtuality --- virtual functions should be private/protected,
with a friend function that forwards to them.

Recently I have wished that operators such as assignment could be
non-members, though I can see the problems that would cause for the compiler
(should it generate it or not?)

> I'd love to hear your arguments for this.  I don't recall you
> advancing this theory in MC++D.

Andrei's SmartPtr class has no public methods other than constructors,
operators, and the semi-operator Swap --- the public interface consists
mostly of friend functions in the same namespace, so he is following his own
advice (at least mostly --- I don't really see why Swap is a member)

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer
---
[ 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.research.att.com/~austern/csc/faq.html                ]

johnmadsen_usenet@hotmail.com (John Madsen) wrote in message
news:<fbec00f5.0202110910.604c5608@posting.google.com>...
> "Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
> news:<a3tf4g$1atquh$1@ID-14036.news.dfncis.de>...

> [ snip ]

> > Basically my belief is that nonvirtual member functions in general
> > are an unnecessary cutesy in C++ that wahses people's brains,
> > leads to bad programs, and will take many years to wear off. For
> > smart pointers in particular, they can do even more harm.

> I have to admit that this confuses me a little.  Particularly after
> having read, and finally been convinced by Herb Sutter's
> "Virtuality" (http://www.gotw.ca/publications/mill18.htm).  Is there
> dissension in the Guru ranks?

Gurus have been known to disagree.

> Are you really suggesting going the way of Java on this?  What about
> the C++ principle of only having to pay for what you use?  Why pay
> for virtual function calls when you don't always have to?

I don't think that this is what he is arguing.  What he is saying is
that if a function doesn't need to be virtual, it should not be a
member.  In general, I suppose, and I think that the public wrappers
of protected or private virtual functions would definitly be an
exception to the rule.

> I'd love to hear your arguments for this.  I don't recall you
> advancing this theory in MC++D.

I don't know what he says, but I have heard the argument from Scott
Meyers.  The basic idea (at least according to Scott) is
orthogonality: if I add convenience functions, they won't be members,
and using a different syntax to call them leads to a lack of
orthogonality.

I'll admit that I'm not yet convinced.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orientie objet
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany, Til.: +49 (0)69 19 86 27
---
[ 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.research.att.com/~austern/csc/faq.html                ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1013248082 3975 127.0.0.1 (9 Feb 2002 09:48:02
GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 9 Feb 2002 09:48:02 GMT
Content-Length: 1993
ReSent-Date: Sat, 9 Feb 2002 07:58:06 -0800 (PST)
ReSent-From: Steve Clamage <clamage@eng.sun.com>
ReSent-To:  <c++-submit@netlab.cs.rpi.edu>
ReSent-Subject: Re: Proposal: Pointers 2
ReSent-Message-ID: <Pine.SOL.4.33.0202090758060.1549@taumet>

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
news:<a3tf4g$1atquh$1@ID-14036.news.dfncis.de>...

> Basically my belief is that nonvirtual member functions in general are
> an unnecessary cutesy in C++ that wahses people's brains, leads to bad
> programs, and will take many years to wear off. For smart pointers in
> particular, they can do even more harm.

Huh? Are you saying that all member functions (in general) should be
virtual?

If so, why?

If you have a function that's invariant over the class hierachy,
there's no reason it should be virtual (and having it virtual would
preclude inlining and decrease performance).

If you with this mean that non-virtual functions should be global,
then I think that's a matter of preference. I prefer to have functions
dealing with a type, as member functions, as I think that localizes it
better, and you don't need to declare arbitrary functions as "friend",
which would be the result, otherwise.

Do you have any backing (articles, references, etc.) for your rather
extreme statement?

I notice that in much generic programming (such as STL), there are
global functions, to decouple them from types. However, in the case
where a function only pertains to a particular type, having it as a
global function, in my opinion, unnecessarily scatters the interface,
and seems more like a step back to C. Not to mention the need for any
"friend" declaration.

I also like the uniformity of access, which you get when using member
functions. It makes it completely clear which object receives the
message. In other words:

a.f(b,c,d); // Call a.f(), with parameters

f(a,b,c,d); // Which object deals with this one? Which (if any) does
it have special access to (and where does this say)?

The problem is that with non-member functions, requiring special
access, their special state is _not_ reflected in the function, but in
the class (the "friend" declaration). Thus, you no longer have
locality in this matter.


Regards,

Terje



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Atle Slagsvold:
> > At least they should have operator==(), operator!= ()
> > and operator<().

Andrei Alexandrescu:
> operator<() does not make sense most of the time
> for smart pointers. They should point to elements
> of the same array, and 99.9999999999999% of cases
> that's not the case.

Write operator< to use std::less, not the raw <.
Then the "same array" requirement is overcome.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Terje Sletteb   " <tslettebo@acm.org> wrote in message
> Huh? Are you saying that all member functions (in general) should be
> virtual?
>
> If so, why?

It's the other way around: all nonvirtuals should be nonmember. Actually, in
the best of all worlds, there would be no member functions at all :o).

> Do you have any backing (articles, references, etc.) for your rather
> extreme statement?

Scott Meyers, "How Non-member Functions Increase Encapsulation". A wonderful
"emperor clothes" paper. You don't see them that often.


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:iEt98.31698$H37.3797367@news2-win.server.ntlworld.com...
> Andrei Alexandrescu:
> > operator<() does not make sense most of the time
> > for smart pointers. They should point to elements
> > of the same array, and 99.9999999999999% of cases
> > that's not the case.
>
> Write operator< to use std::less, not the raw <.
> Then the "same array" requirement is overcome.

My point was not how to implement operator<, but rather whether or not you
actually want the comparison to be valid.


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/



---
[ 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.research.att.com/~austern/csc/faq.html                ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1013447437 6584 127.0.0.1 (11 Feb 2002 17:10:37 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 11 Feb 2002 17:10:37 GMT
Content-Length: 910
ReSent-Date: Mon, 11 Feb 2002 09:46:51 -0800 (PST)
ReSent-From: Steve Clamage <clamage@eng.sun.com>
ReSent-To:  <c++-submit@netlab.cs.rpi.edu>
ReSent-Subject: Re: Proposal: Pointers 2
ReSent-Message-ID: <Pine.SOL.4.33.0202110946510.4516@taumet>

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message news:<a3tf4g$1atquh$1@ID-14036.news.dfncis.de>...

[ snip ]

> Basically my belief is that nonvirtual member functions in general are
> an unnecessary cutesy in C++ that wahses people's brains, leads to bad
> programs, and will take many years to wear off. For smart pointers in
> particular, they can do even more harm.
>

I have to admit that this confuses me a little.  Particularly after
having read, and finally been convinced by Herb Sutter's "Virtuality"
(http://www.gotw.ca/publications/mill18.htm).  Is there dissension in
the Guru ranks?  Are you really suggesting going the way of Java on
this?  What about the C++ principle of only having to pay for what you
use?  Why pay for virtual function calls when you don't always have
to?

I'd love to hear your arguments for this.  I don't recall you
advancing this theory in MC++D.

John



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

andrewalex@hotmail.com (Andrei Alexandrescu) wrote (abridged):
> Experience has shown that it is best that smart pointers do not have
> any named member functions.

Really? So instead of p.get() you use p.operator int*() or similar?

I have often found code which is more readable if it does not use
operators - not all code, but most code which needs to call the function
explicitly. What do you see as the disadvantage? I have never known it
cause me a problem.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Louis Lavery" <Louis@devilsChimney.co.uk> wrote in message
news:1012992091.20782.0.nnrp-13.9e989763@news.demon.co.uk...
> > Automatic convertibility might be desirable in some applications.
The
> > smart pointer user should decide whether they want conversion or
not.
>
> Equally, should not the user of a reference linked pointer have
> the choice of a single or a double linked list ;-) ?


Of course that's a reasonable option. That's entirely possible if
ownership is separated from the skeleton of the smart pointer. Why the
wink then :o)?


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:bf988.549$jL6.273985@news6-win.server.ntlworld.com...
> Andrei Alexandrescu:
> > Experience has shown that it is best that smart pointers do not
have
> > any named member functions.
>
> I assume your reasoning for this hasn't changed since
> you wrote Modern C++ Design.

That is correct.

> I agree, just, but I do think it's a delicately balanced
> argument and will become more so as time
> marches on and people become more familiar with
> smart pointers.

Basically my belief is that nonvirtual member functions in general are
an unnecessary cutesy in C++ that wahses people's brains, leads to bad
programs, and will take many years to wear off. For smart pointers in
particular, they can do even more harm.

> The member function get() has a point
> in its favour - it fits the pattern adopted by std::auto_ptr
> which, like it or loath it, *is* a part of the standard library
> and is thus familiar to most C++ programmers.

"Nobody knows what most programmers do" -- Bjarne Stroustrup :o).

> > Automatic convertibility might be desirable in some applications.
The
> > smart pointer user should decide whether they want conversion or
not.
>
> This is a trade-off between extensibility and simplicity.
> You favour extensibility, the OP favours simplicity.

If the OP deems the qualities he mentions for an in-house smart
pointer, that's cool. If he proposes that for standardization, that's
another story.

> While the way you offer extensibility in Loki is perhaps
> the best approach I know of, the result is still complex
> and this complexity is not entirely hidden from the
> programmer using it.

I'd love to hear details. Basically the default Loki::SmartPtr<Widget>
does pretty much all what the OP asks for.


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20020206194731.30665E@brangdon.madasafish.com...
> andrewalex@hotmail.com (Andrei Alexandrescu) wrote (abridged):
> > Experience has shown that it is best that smart pointers do not have
> > any named member functions.
>
> Really? So instead of p.get() you use p.operator int*() or similar?

No. You use get_impl(p).

> I have often found code which is more readable if it does not use
> operators - not all code, but most code which needs to call the function
> explicitly.

I agree, but as you see I wasn't referring to that.

> What do you see as the disadvantage? I have never known it
> cause me a problem.

The rationale has been explain in Garry Lancaster's post.


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> skrev i melding
news:a3tf4g$1atquh$1@ID-14036.news.dfncis.de...
>
> If the OP deems the qualities he mentions for an in-house smart
> pointer, that's cool. If he proposes that for standardization, that's
> another story.
I use the rules in an in-house smart pointer, but I would rather use a
standard smart pointer
system. My main point was not the details, but the _system_ of smart
pointers with conversion
between them. Smart pointers should be the prefered way to handle ownership
of dynamically allocated objects.
This means that there should be some way to cast smart pointer, and use them
just as easily as the raw pointers.
This may require compiler support, but thats okay since it is included in
the standard.

>
> I'd love to hear details. Basically the default Loki::SmartPtr<Widget>
> does pretty much all what the OP asks for.
>
Probably. I have my own smart pointer classes that does it too,
but it is not part of the standard.


Atle



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> > Andrei Alexandrescu:
> > > Experience has shown that it is best that smart pointers do not
> > > have any named member functions.

Garry Lancaster:
> > I assume your reasoning for this hasn't changed since
> > you wrote Modern C++ Design.

Andrei Alexandrescu:
> That is correct.
>
> > I agree, just, but I do think it's a delicately balanced
> > argument and will become more so as time
> > marches on and people become more familiar with
> > smart pointers.
>
> Basically my belief is that nonvirtual member functions
> in general are an unnecessary cutesy in C++ that
> wahses people's brains, leads to bad
> programs, and will take many years to wear off.
> For smart pointers in particular, they can do even
> more harm.

Once you generalise it like that it's a much more
extreme argument. I agree with you, because
of encapsulation and name lookup issues,
most/all of which have been thrashed out here
in the past.

Two things about the approach still disturb me:

1. The verbosity of it.
2. Its lack of widespread acceptance.

So, even though I agree, I don't write my code
like that and I don't expect it of others.

> > The member function get() has a point
> > in its favour - it fits the pattern adopted by std::auto_ptr
> > which, like it or loath it, *is* a part of the standard library
> > and is thus familiar to most C++ programmers.
>
> "Nobody knows what most programmers do" -- Bjarne Stroustrup :o).

I suspect Mr. Stroustrup has been quoted out of
context.

Another quote:

"I know what most programmers do. They program" -
Garry Lancaster ;-)

What I don't know is whether most C++ programmers
are familiar with std::auto_ptr. (I don't know anywhere
that offers empirical data of this sort.). I assume so,
but you clearly doubt my assumption. I certainly
believe familiarity with std::auto_ptr is more
widespread than familiarity with Loki::SmartPtr.

> > > Automatic convertibility might be desirable in some
> > > applications. The smart pointer user should decide
> > > whether they want conversion or not.
> >
> > This is a trade-off between extensibility and simplicity.
> > You favour extensibility, the OP favours simplicity.
>
> If the OP deems the qualities he mentions for an in-house smart
> pointer, that's cool. If he proposes that for standardization, that's
> another story.

No library can be all things to all people. You
have to stop generalising somewhere. And
some people might stop before they got to
the level of generalisation that Loki::SmartPtr
supports. Personally, with a few alterations (and
an acceptable test implementation), I would be
pleased to find either smart pointer
system in the standard library.

> > While the way you offer extensibility in Loki is perhaps
> > the best approach I know of, the result is still complex
> > and this complexity is not entirely hidden from the
> > programmer using it.
>
> I'd love to hear details.

Obviously, it's the number, and nature, of the
template arguments used, and the variety of
configuration options they permit.

> Basically the default Loki::SmartPtr<Widget>
> does pretty much all what the OP asks for.

If you mean without overriding any of the defaults
for the other template arguments, no, it doesn't.
It's unrealistic to expect it, since the OP
proposed a number of different smart pointers.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote in message
news:a3ta75$1apcsl$1@ID-14036.news.dfncis.de...
>
> "Louis Lavery" <Louis@devilsChimney.co.uk> wrote in message
> news:1012992091.20782.0.nnrp-13.9e989763@news.demon.co.uk...
> > > Automatic convertibility might be desirable in some applications.
> The
> > > smart pointer user should decide whether they want conversion or
> not.
> >
> > Equally, should not the user of a reference linked pointer have
> > the choice of a single or a double linked list ;-) ?
>
>
> Of course that's a reasonable option. That's entirely possible if
> ownership is separated from the skeleton of the smart pointer. Why the
> wink then :o)?

Oh, I've always read it as a raised eyebrow, a sort of quizzical look,
but now you mention it it is more of a wink. Aynway, what I'm quizzing
about is found on page 167 of MC++D...

The doubly linked list structure fits reference tracking like a glove.
You cannot use a singly linked list because removals from such a list
take linear time.

...where you seem to be dismissing the singly linked list as a option.

I believe all four of the non-intrusive reference tracking methods have
their place, but I'm willing to be proved wrong.

Louis.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> skrev i melding
news:a3nrce$19v1aa$1@ID-14036.news.dfncis.de...
>
> "Atle Slagsvold" <atleslag@online.no> wrote in message
> news:WBw78.10$DQ1.333@news2.ulv.nextra.no...
> > * General rules that "smart pointers" should try to follow when
> possible:
> >
> > get() member returns raw pointer to object pointed to.
>
>
> Experience has shown that it is best that smart pointers do not have
> any named member functions.

This I proposed to use the style used by auto_ptr. If you could
convert auto_ptr to use your style, then the rule should be reversed.

>
> > The "smart pointer" should NOT be convertible to a raw pointer.
>
> Automatic convertibility might be desirable in some applications. The
> smart pointer user should decide whether they want conversion or not.
>
But for pointers USED in the standard library this is a rule that makes
sense.

> > "smart ptr"::value_type is the type of object pointed to.
>
> A traits mechanism is better because it would cover raw pointers as
> well.
This is to use the pattern established by STL. The standard library as it is
today
does things in too many ways. In iterators the type pointed to is
value_type,
in auto_ptr it is element_type. Traits adds a layer to the classes that are
seldom used
and because of this difficult to use for the average programmer. I have
never used any traits,
and I am the most competent of the C++ programmers I work with. I have plans
to buy
"Modern C++ Design" and start to use more advanced techniques.

>
> > A raw pointer should be convertible to the "smart pointer".
> > The exception from this rule is when the pointer requires special
> > allocation.
> >
> > The "smart pointer" should have comparison-operators.
>
> This is tricky. See MC++D and boost's mailing list for an extensive
> discussion on the subject.
>
At least they should have operator==(), operator!= () and operator<().

> > Iterators should have the same style as the rest of the "smart
> pointers".
>
> Why? They serve different purposes.
>
Because iterators are a kind of smartpointer, and if they have the same
style they may be used
in the same situations. If my idea of nonowning-pointer was accepted into
the standard then
you would be able to convert iterators to nonowning-pointers.

>
> > Reference-counted pointer.
>
> That's old news :o).
>
I know, but not included in the standard.

Atle



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Atle Slagsvold" <atleslag@online.no> wrote in message
news:gAO88.2444$HL2.54439@news2.ulv.nextra.no...
> > Automatic convertibility might be desirable in some applications. The
> > smart pointer user should decide whether they want conversion or not.
> >
> But for pointers USED in the standard library this is a rule that makes
> sense.

Ah, what I meant was that the standard library's smart pointer should allow
the user configure this particular feature.

> At least they should have operator==(), operator!= () and operator<().

operator<() does not make sense most of the time for smart pointers. They
should point to elements of the same array, and 99.9999999999999% of cases
that's not the case.


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Atle Slagsvold" <atleslag@online.no> wrote in message
news:WBw78.10$DQ1.333@news2.ulv.nextra.no...
> * General rules that "smart pointers" should try to follow when
possible:
>
> get() member returns raw pointer to object pointed to.


Experience has shown that it is best that smart pointers do not have
any named member functions.

> The "smart pointer" should NOT be convertible to a raw pointer.

Automatic convertibility might be desirable in some applications. The
smart pointer user should decide whether they want conversion or not.

> "smart ptr"::value_type is the type of object pointed to.

A traits mechanism is better because it would cover raw pointers as
well.

> A raw pointer should be convertible to the "smart pointer".
> The exception from this rule is when the pointer requires special
> allocation.
>
> The "smart pointer" should have comparison-operators.

This is tricky. See MC++D and boost's mailing list for an extensive
discussion on the subject.

> Iterators should have the same style as the rest of the "smart
pointers".

Why? They serve different purposes.

> Reference-counted pointer.
> This "smart pointer" uses an reference-count to know how many
pointers point
> on the same object.
> When the count reaches 0 then the object is deallocated.
> boost::shared_ptr could be used as a basis for this.

That's old news :o).


Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Atle Slagsvold:
> > * General rules that "smart pointers" should try to follow when
> possible:
> >
> > get() member returns raw pointer to object pointed to.

Andrei Alexandrescu:
> Experience has shown that it is best that smart pointers do not have
> any named member functions.

I assume your reasoning for this hasn't changed since
you wrote Modern C++ Design.

For those who haven't read it (shame on you!) the
argument is that C++ programmers are better at spotting
subtle differences between invocations of nonmember
functions than similar differences between invocations
of member functions e.g. you believe

Release( *sp ) and Release( sp )

are easier to tell apart than

sp->Release() and sp.Release()

I agree, just, but I do think it's a delicately balanced
argument and will become more so as time
marches on and people become more familiar with
smart pointers. The member function get() has a point
in its favour - it fits the pattern adopted by std::auto_ptr
which, like it or loath it, *is* a part of the standard library
and is thus familiar to most C++ programmers.

> > The "smart pointer" should NOT be convertible to a raw pointer.
>
> Automatic convertibility might be desirable in some applications. The
> smart pointer user should decide whether they want conversion or not.

This is a trade-off between extensibility and simplicity.
You favour extensibility, the OP favours simplicity.

While the way you offer extensibility in Loki is perhaps
the best approach I know of, the result is still complex
and this complexity is not entirely hidden from the
programmer using it.

> > "smart ptr"::value_type is the type of object pointed to.
>
> A traits mechanism is better because it would cover raw pointers as
> well.

Another trade-off between extensibility and simplicity.

I agree with the remainder of your message. Other
than the criticisms you make there I feel that
the system of smart pointers the OP describes
seems reasonable. So is the Loki smart pointer.
>From what I can tell the latter has a certain
advantage, in that it already exists ;-)

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote in message
news:a3nrce$19v1aa$1@ID-14036.news.dfncis.de...
>
> "Atle Slagsvold" <atleslag@online.no> wrote in message
> news:WBw78.10$DQ1.333@news2.ulv.nextra.no...
> > * General rules that "smart pointers" should try to follow when
> possible:
> >

[snip]

>
> > The "smart pointer" should NOT be convertible to a raw pointer.
>
> Automatic convertibility might be desirable in some applications. The
> smart pointer user should decide whether they want conversion or not.

Equally, should not the user of a reference linked pointer have
the choice of a single or a double linked list ;-) ?

Louis.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I wrote a proposal about pointer last week, but got little response so I'll
try to make my points a little clearer.
My native language is not english.
The proposal is about a system of "smart pointers" that should be added to
the next C++ standard.
I use the term "smart pointer" for a class that mimics pointer operations,
and I use the term raw pointer for the classic C pointer.

* General rules that "smart pointers" should try to follow when possible:

get() member returns raw pointer to object pointed to.
The "smart pointer" should NOT be convertible to a raw pointer.

"smart ptr"::value_type is the type of object pointed to.

A raw pointer should be convertible to the "smart pointer".
The exception from this rule is when the pointer requires special
allocation.

The "smart pointer" should have comparison-operators.

* Pointertypes that should be added/changed:

Iterators should have the same style as the rest of the "smart pointers".

auto_ptr should be changed so you may assign a raw pointer to auto_ptr. The
auto_ptr
should then deallocated the object it is pointing to.

Reference-counted pointer.
This "smart pointer" uses an reference-count to know how many pointers point
on the same object.
When the count reaches 0 then the object is deallocated.
boost::shared_ptr could be used as a basis for this.

Garbage-collected pointer.
This "smart pointer" uses garbage-collection techniques to deallocate the
object.
This may require additional runtime support and a special allocation
function.

Non-owning pointer.
With several different pointertypes (including iterators) are used in C++
the functions that takes pointers
should be able to take all pointertypes. I propose one "smart pointer" that
all other pointertypes are convertible to.
Example ( the non-owning pointer is ptr):

#include <needed headers>

using namespace std;

void print(ptr<const string> in)
{
    cout<<"String is "<<*in<<endl;
}

int main()
{
    string *s=new string("raw pointer");
    print(s);
    auto_ptr ap=new string("auto_ptr");
    print(ap);
    vector<string> vs;
    vs.push_back("iterator");
    print(vs.begin());
    return 0;
}

--
Atle Slagsvold - Software Development Engineer
THALES COMMUNICATIONS AS - http://www.thalesgroup.no



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]