 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dave Harris
Guest
|
 Posted: Fri Aug 01, 2003 8:05 pm Post subject: Re: Comments on TR1 smart pointers [LONG] |
 |
|
[email]gi2nospam (AT) mariani (DOT) ws[/email] (Gianni Mariani) wrote (abridged):
| Quote: | Don't get me wrong, I love intrusive counting, but there seem to be a
lot of cases where it can't be used.
I see what you're saying but I'm lost as to your conclusion.
The class design is somthing the application writer has control over
|
My intended point with the 3rd party classes is that the application
writer /not/ have control over them.
| Quote: | Why not provide a class like :
class RefCountedApplication
: public RefCounted
{
public:
Base m_stuff;
Base & get_Base ()
{
return m_stuff;
}
};
|
I don't see how this supports polymorphic pointers. That is, how a
smart_ptr<Base> can point to an instance of Derived.
What might work is to replace the:
Base m_stuff;
with a pointer:
Base *m_pStuff;
Of course this has problems of its own, and by the time we've fixed them
we are on the way to reimplementing shared_ptr.
| Quote: | The point I'm making is that by the time you create the "Application"
class above you'll find that it's an interesting class 95% of the time
because you'll find there is alot more than one object that shared it's
life-time. It's impossible to show in this example what I mean, we'll
need some real-life examples.
|
By "interesting", you mean such a class will acquire extra member
functions or variables? I think that's unlikely.
If you just mean that RefCountedApplication will be used in several
places, then yes of course. Nowadays I use something like:
class Xxx { ... };
typedef boost::shared_ptr<Xxx> XxxPtr;
because XxxPtr is used in enough places to make it worthwhile. But XxxPtr
is not interesting in the sense of deserving effort. It does not need to
be a class. New functions are added to Xxx, or to shared_ptr, not to
XxxPtr. At least in my experience.
| Quote: | OOOOh - another orthogonal kinda guy. I lay claim to inventing that
term - wait until we get to sporadic classes ... 
|
I think "orthogonal" in the programming sense is pretty old - at least
back to the '60s.
| Quote: | I think shared_ptr does too much already. I think there is room for
a thin system of reference counting smart pointers to do a very small
task very efficiently.
|
Fair enough. Nothing in the standard prevents you writing your own
components, and they can often be more efficient than the standard ones by
being less general. Smart pointers are no exception. The controversial
step is claiming such a partial solution should be standardised.
Shared_ptr is partly about enabling interoperability between components
produced by different vendors. This means it is aimed at interfaces.
Interfaces need to be stable, which means they need to be general, so they
can adapt to future changes. So I think a general smart pointer should be
the first thing to be standardised. A less general one can come later, if
it is still needed.
| Quote: | But I could write the code above by introducing a new simple template
like:
|
I'm not sure what point you are making here. There are lots of ways to
denote move semantics, some simple.
| Quote: | They did register and I'm all for more general solutions. The one
issue I have is that there are different kinds of "move" semantics and
at the end of the day, describing the semantics in a class may be all
that is needed. In other words : What may be missing in the language
wrt move semantics that can't be described already with a few choice
classes ?
|
There are indeed proposals for move semantics which don't need language
changes. I don't have any references to hand, sorry.
The perceived challenge is to make the syntax transparent to the user at
the point of call. The && proposal tries to avoid the need for the user to
describe semantics explicitly by exploiting the compiler's knowledge about
temporaries.
-- Dave Harris, Nottingham, 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 ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
