473,847 Members | 1,714 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

A smart pointer and type forwarding

Hello.

I have written a simple reference-counting smart pointer class template
called RefCountPtr<T>. It works in conjunction with another class,
ReferenceCounta ble, which is responsible for the actual counting. Here
is the latter's definition:

// --- Begin ReferenceCounta ble.h ----------

class ReferenceCounta ble
{
public:
virtual ~ReferenceCount able() {}
void incrementRefere nceCount() { count++; }
void decrementRefere nceCount() { count--; }
unsigned int referenceCount( ) const { return count; }
protected:
ReferenceCounta ble() : count(0) {}
private:
unsigned int count;
};

// --- End ReferenceCounta ble.h ----------

Classes whose objects are to be reference-counted must derive from
ReferenceCounta ble. E.g.:

// --- Begin Foo.h ----------

#include "ReferenceCount able.h"

class Foo : public ReferenceCounta ble
{
public:
void f() {}
};

// --- End Foo.h ----------

From now on, one can create instances of the smart pointer class and
use them as regular pointers. E.g.:

RefCountPtr<Foo pfoo = new Foo;
pfoo->f();

The idea of making the smart pointer behave like regular pointers is key
and is also the reason for this post. There is a situation where I have
found myself unable to make my smart pointers behave like regular ones.
It occurs when a given class holds RefCountPtr<Tas member variables.
For a regular pointer, one could do:

class Foo;

class Test
{
Foo* mFoo;
};

Therefore, I would like to be able to have:

#include "RefCountPtr.hp p"

class Foo;

class Test
{
RefCountPtr<Foo mFoo;
};

But, unfortunately, the compiler does not find it sufficient to know
that Foo is a class. Here is a relevant snippet of the /RefCountPtr<T>/
class template, showing its constructors, destructor and only member
variable:

// --- Begin snippet of RefCountPtr.hpp ----------

#include "ReferenceCount able.h"

template <class T>
class RefCountPtr
{
public:
RefCountPtr()
: object(0)
{
}

RefCountPtr(T* pointer)
: object(pointer)
{
if (object)
object->incrementRefer enceCount();
}

RefCountPtr(con st RefCountPtr& original)
: object(original .object)
{
if (object)
object->incrementRefer enceCount();
}

~RefCountPtr()
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
}
Nov 7 '06
33 5096
Earl Purple wrote:
You should declare a destructor in Test and put its implementation into
the compilation unit, even if it is empty (which is probably will be).
Then your compiler won't attempt to call the destructor of your
RefCountPtr class.
That makes sense. Because the definition of the /Foo/ class is included
in the compilation unit for the /Test/ class, Foo's structure will be
already known inside the definition of /~Test()/. The strange thing is
that one of the compilers I tried (Borland's BCC32 5.6) kept on
producing the error messages, even after I explicitly provided the
destructor for /Test/.

Regards,

--
Ney André de Mello Zunino
Nov 8 '06 #11
Ney André de Mello Zunino wrote:
Earl Purple wrote:
You should declare a destructor in Test and put its implementation into
the compilation unit, even if it is empty (which is probably will be).
Then your compiler won't attempt to call the destructor of your
RefCountPtr class.

That makes sense. Because the definition of the /Foo/ class is included
in the compilation unit for the /Test/ class, Foo's structure will be
already known inside the definition of /~Test()/. The strange thing is
that one of the compilers I tried (Borland's BCC32 5.6) kept on
producing the error messages, even after I explicitly provided the
destructor for /Test/.
Can you post a minimal but complete sample that we can cut-n-paste
unchanged to produce the error messages you're seeing?

Cheers! --M

Nov 8 '06 #12

Frederick Gotham wrote:
Earl Purple:
operator= should be implemented in terms of copy-construct and swap!

operator=( T* ) is not recommended either. Better to use a method such
as reset( T* )

swap is nice and simple and will never throw.


Nicely inefficient, yes.
How is it swap inefficient? You are swapping pointers, not what they
point to.

operator= implemented purely in terms of copy-construct and swap can be
inefficient in some cases when there is no need to do any allocations
or de-allocations. For example, if implementing std::string and the new
string fits comfortably into the already allocated buffer.
For such an implementation you should check first and only if a
reallocation is required, then use copy-construct and swap. For that
reason it is difficult to know whether operator= should take
std::string or const std::string & as its parameter. A good workaround
to that is to also have one overload that takes const char * directly
so you never get the implicit conversion.

None of this applies for smart pointers.

Nov 9 '06 #13
>
Pointer assignment should be a template. You want to allow assignment
from types derived from T.
Absolutely not necessary. The one that should preferably be a template
is assignment to another smart pointer where you do want to be able to
assign to smart pointers to types derived from T, or have SmartPtr<
const T take an assignment to SmartPtr< T >
Also, what you're designing here is an "intrusive" smart pointer. There
is also an "extrusive" smart pointer idea which is what seems to be
targeted for approval for the next version of the standard. You can
find it in the boost shared_ptr implementation.
Is it called "extrusive" or "non-intrusive"? I've never heard of the
word "extrusive" . Intrusive reference-counting has its uses too, and
code can use more than one type of smart pointer. You also mention a
multi-threaded environment, but that's only an issue on rare occasions
and the majority of the times when it isn't, you don't want to be
locking and unlocking every time you modify a reference count. For
those times when it is an issue, you can use a special
reference-counter. None of this will be in tr1::shared_ptr because the
new standard doesn't yet recognise threads.

In addition, shared_ptr in tr1 will have a standard behaviour, not a
standard implementation. There is no such thing as a standard
implementation and this will remain the case in the next standard, so
although it is likely that tr1::shared_ptr will be implemented on code
similar to that of boost, it isn't guaranteed to be exactly the same
code, nor will it be guaranteed that two different versions of
shared_ptr are compatible with each other, so a library built with one
version that returns shared_ptrs to objects might break if the client
library is using a differerent implementation of the standard library.

To counter that, it is better off if your library does not return
shared_ptrs (or any other class in the standard library, even a
std::string). This is something I would like to see addressed because I
think it's a major flaw in C++ at the moment.

For education purposes, programmers should be taught how to write basic
constructs, even those that are already in the standard library or
boost or any other open-source library, even if they will never use
them in production code. Without this knowledge, who will be the PJ
Plaugers and Peter Dimovs of the next generation? Who will write the
next set of standard libraries that has concurrency issues built in?

Nov 9 '06 #14
mlimber wrote:
Can you post a minimal but complete sample that we can cut-n-paste
unchanged to produce the error messages you're seeing?
Sure! Here it goes. (Note: It would have been much easier for you and
for me if I could post the header and source files as attachments;
however, it seems attachments are not allowed [1], even if they are of
plain-text nature. Can anybody confirm that?)

// ---------- ReferenceCounta ble.h ---------- //

#ifndef REFERENCE_COUNT ABLE_H
#define REFERENCE_COUNT ABLE_H

class ReferenceCounta ble
{
public:
virtual ~ReferenceCount able() {}
void incrementRefere nceCount() { count++; }
void decrementRefere nceCount() { count--; }
unsigned int referenceCount( ) const { return count; }
protected:
ReferenceCounta ble() : count(0) {}
private:
unsigned int count;
};

#endif

// ---------- RefCountPtr.hpp ---------- //

#ifndef REF_COUNT_PTR_H PP
#define REF_COUNT_PTR_H PP

#include "ReferenceCount able.h"

template <class T>
class RefCountPtr
{
public:
RefCountPtr()
: object(0)
{
}

RefCountPtr(T* pointer)
: object(pointer)
{
if (object)
object->incrementRefer enceCount();
}

RefCountPtr(con st RefCountPtr& original)
: object(original .object)
{
if (object)
object->incrementRefer enceCount();
}

~RefCountPtr()
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
}

RefCountPtr& operator=(const RefCountPtr& original)
{
return operator=(origi nal.object);
}

RefCountPtr& operator=(T* pointer)
{
// Handle self-assignment and assignment from
// "equivalent " smart pointer
if (this->object != pointer)
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
object = pointer;
if (pointer)
pointer->incrementRefer enceCount();
}
return *this;
}

T* operator->()
{
return object;
}

const T* operator->() const
{
return object;
}

T& operator*()
{
return *object;
}

const T& operator*() const
{
return *object;
}

T* pointer()
{
return object;
}

const T* pointer() const
{
return object;
}

operator void*() const
{
return object;
}
private:
T* object;
};

#endif

// ---------- Foo.h ---------- //

#ifndef FOO_H
#define FOO_H

#include "ReferenceCount able.h"

class Foo : public ReferenceCounta ble
{
};

#endif

// ---------- Test.h ---------- //

#ifndef TEST_H
#define TEST_H

#include "RefCountPtr.hp p"

class Foo;

class Test
{
public:
Test();
~Test();
private:
RefCountPtr<Foo mFoo;
};

#endif

// ---------- Test.cpp ---------- //

#include "Test.h"
#include "Foo.h"

Test::Test()
{
}

Test::~Test()
{
}

// ---------- Main.cpp ---------- //

#include "Test.h"

int main()
{
Test test;
}

And here is the command session with Borland's compiler. g++ compiles
successfully and produces no output.

D:\Temp\RefCoun tPtrTest>bcc32 -eMain.exe Test.cpp Main.cpp
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
Test.cpp:
Main.cpp:
Error E2315 RefCountPtr.hpp 35: 'decrementRefer enceCount' is not a
member of 'Foo', because the type is not yet defined in function
RefCountPtr<Foo >::~RefCountPtr ()
Error E2315 RefCountPtr.hpp 36: 'referenceCount ' is not a member of
'Foo', because the type is not yet defined in function
RefCountPtr<Foo >::~RefCountPtr ()
*** 2 errors in Compile ***

Please, note that the code still contains most of the problems indicated
in this thread. At the moment, the goal is to understand why BCC32 is
behaving the way it is.

[1] http://www.parashift.com/c++-faq-lit...t.html#faq-5.4

Thank you,

--
Ney André de Mello Zunino
Nov 9 '06 #15
* Ney André de Mello Zunino:
>
(Note: It would have been much easier for you and
for me if I could post the header and source files as attachments;
however, it seems attachments are not allowed [1], even if they are of
plain-text nature. Can anybody confirm that?)
Plain-text attachments, such as I hope is the result below (or wherever
your newsreader places it) are practically speaking OK. The problem is,
when such are "allowed", soon we'd have a flood of base64-encoded
attachments etc., from people using e.g. Outlook Express, attached code
with tabs instead of spaces, etc. And that would be UnGood.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
#include <iostream // std::cout
#include <ostream // operator<<, std::endl
#include <string // std::endl

class List
{
private:
std::string myString;

// Internal conversion from and to std::string.
List( std::string s ): myString( s ) {}
std::string asString() const { return myString; }

public:
typedef char Item;

List() {}
List( Item aHead, List aTail ): myString( aHead + aTail.asString( ) ) {}

Item head() const { return myString.at( 0 ); }
List tail() const { return List( myString.substr ( 1 ) ); }
bool isEmpty() const { return myString.empty( ); }
};
// An example of an operation built from the above operations.
void display( List s )
{
while( !s.isEmpty() )
{
std::cout << s.head() << ' ';
s = s.tail();
}
std::cout << std::endl;
}

List operator>>=( List::Item h, List t )
{
return List( h, t );
}

List aShortList()
{
return 'r' >>= 'e' >>= 'p' >>= 'a' >>= 'i' >>= 'd' >>= List();
}

void testDisplay() { display( aShortList() ); }

// Another example of an operation built from the above operations.
List asList( List::Item x )
{
return List( x, List() ); // Item followed by List produces List.
}

void testAsList() { display( asList( 'A' ) ); }

// A third example of an operation built from the above operations.
List joined( List a, List b )
{
return (a.isEmpty()? b : List( a.head(), joined( a.tail(), b ) ));
}

void testJoined() { display( joined( aShortList(), aShortList() ) ); }

// A fourth example of an operation built from the above operations.
List appended( List s, List::Item x )
{
return joined( s, asList( x ) );
}

void testAppended() { display( appended( aShortList(), '!' ) ); }

// A fifth example of an operation built from the above operations.
List reversed( List s )
{
return (s.isEmpty()? s : appended( reversed( s.tail() ), s.head() ));
}

void testReversed() { display( reversed( aShortList() ) ); }

int main()
{
testDisplay();
testAsList();
testJoined();
testAppended();
testReversed();
}
Nov 9 '06 #16
Earl Purple wrote:
>Pointer assignment should be a template. You want to allow assignment
from types derived from T.

Absolutely not necessary.
necessary to who ? I use them all the time.

at::Ptr<Base*x = new Derived;

.. The one that should preferably be a template
is assignment to another smart pointer where you do want to be able to
assign to smart pointers to types derived from T, or have SmartPtr<
const T take an assignment to SmartPtr< T >
Yep - that too.
>
>Also, what you're designing here is an "intrusive" smart pointer. There
is also an "extrusive" smart pointer idea which is what seems to be
targeted for approval for the next version of the standard. You can
find it in the boost shared_ptr implementation.

Is it called "extrusive" or "non-intrusive"?
intrusive is where the reference count is part of the object being
reference counted. Win32 COM objects are a great example of
"intrusive" . "extrusive" or "non-intrusive" reference counts is where
the smart pointer creates a reference count on the fly for you.
... I've never heard of the
word "extrusive" . Intrusive reference-counting has its uses too, and
code can use more than one type of smart pointer. You also mention a
multi-threaded environment, but that's only an issue on rare occasions
and the majority of the times when it isn't, you don't want to be
locking and unlocking every time you modify a reference count.
Sure, but you want the flexibility to have thread safe ones. Something
as basic as lifetime management gets into a threaded environment very
quickly. This is one of the reasons I prefer intrusive reference
counts. The type of reference count is part of the object not the
pointer, although the distinction is irrelevant in practice.
... For
those times when it is an issue, you can use a special
reference-counter. None of this will be in tr1::shared_ptr because the
new standard doesn't yet recognise threads.
There are a number of thread proposals being discussed at the moment.
Reference counts in smart pointers need to be thread safe so you can bet
that they're going to come out with a thread safe option to begin with.
boost's shared_ptr is thread safe last I looked (at least it has
compile mode for thread safety).

Also in the Austria C++ library's smart pointers, (which are intrusive
btw), these have ways of supporting non thread safe and thread safe
reference counts as well as supporting the COM style reference counts
(new objects start with a refcount of 1). The latest and trickiest is
an "atomic" version of the Austria smart pointer which allows multiple
threads to read and write the pointer simultaneously.

While I'm at it, there are also different modes of austria smart pointer
(one I call the "medusa" pointer) where you have different (intrusive)
reference counts for different smart pointer type allowing you to track
when all pointers of a particular type have released the object.

Then on top of all this, there are there flavours of Austria smart
pointer, (Ptr, PtrDelegate, PtrView) which can be used to minimize the
number of redundant increment/decrements when passing around lots of
smart pointers hence reducing the performance hit but it does require a
little "education" on the part of the programmer.
>
In addition, shared_ptr in tr1 will have a standard behaviour, not a
standard implementation. There is no such thing as a standard
implementation and this will remain the case in the next standard, so
although it is likely that tr1::shared_ptr will be implemented on code
similar to that of boost, it isn't guaranteed to be exactly the same
code, nor will it be guaranteed that two different versions of
shared_ptr are compatible with each other, so a library built with one
version that returns shared_ptrs to objects might break if the client
library is using a differerent implementation of the standard library.
Yep. There are going to be teething problems. Oh well.
>
To counter that, it is better off if your library does not return
shared_ptrs (or any other class in the standard library, even a
std::string). This is something I would like to see addressed because I
think it's a major flaw in C++ at the moment.
Really ? Why should we not return std::string ? Anyhow, in Austria
C++ land, return an at::PtrDelegate which basiclly "moves" the pointer
eliminating an increment/decrement...
>
For education purposes, programmers should be taught how to write basic
constructs, even those that are already in the standard library or
boost or any other open-source library, even if they will never use
them in production code. Without this knowledge, who will be the PJ
Plaugers and Peter Dimovs of the next generation? Who will write the
next set of standard libraries that has concurrency issues built in?
shared_ptr has lots of pros/cons and it will work just fine in a
threaded environment. As for concurrency, even though C++ does not
"support" threads, many implementations do. Austria C++ supports
win32/linux (64 & 32 bit) and a little behind on OSX testing and those
platforms have been supporting threads for quite a while.

As for gcc, there have been alot of "fixes" for threading and gcc
threading has been solid for probably 5 years now. Since 4.0, the
compiler even guarantees thread safety on constructs like:

T & f()
{
static T t = expression;

return t;
}
Anyhow, I think it's safe to say that "smart pointers" are a rich topic
for discussion but there are at least 4 implementations that are fairly
complete that have different "pros" and cons and they will probably work
mixed in the same body of code (not that I reccomend that but it will
probably work nonetheless).
Nov 13 '06 #17

Gianni Mariani wrote:
Earl Purple wrote:
Pointer assignment should be a template. You want to allow assignment
from types derived from T.
Absolutely not necessary.

necessary to who ? I use them all the time.

at::Ptr<Base*x = new Derived;
yes but just because you set it to a derived class doesn't mean that
the function should be a template (which would allow you to pass in ANY
type). I'm not sure you understand what templates are for.
Also, what you're designing here is an "intrusive" smart pointer. There
is also an "extrusive" smart pointer idea which is what seems to be
targeted for approval for the next version of the standard. You can
find it in the boost shared_ptr implementation.
Is it called "extrusive" or "non-intrusive"?

intrusive is where the reference count is part of the object being
reference counted. Win32 COM objects are a great example of
"intrusive" . "extrusive" or "non-intrusive" reference counts is where
the smart pointer creates a reference count on the fly for you.
I wasn't asking you what they were, I'm fully aware of what an
intrusive and non-intrusive pointer are. I was asking you whether
extrusive was the correct word or whether the correct word is
non-intrusive.
... I've never heard of the
word "extrusive" . Intrusive reference-counting has its uses too, and
code can use more than one type of smart pointer. You also mention a
multi-threaded environment, but that's only an issue on rare occasions
and the majority of the times when it isn't, you don't want to be
locking and unlocking every time you modify a reference count.

Sure, but you want the flexibility to have thread safe ones. Something
as basic as lifetime management gets into a threaded environment very
quickly. This is one of the reasons I prefer intrusive reference
counts. The type of reference count is part of the object not the
pointer, although the distinction is irrelevant in practice.
To fully define what intrusive reference counting means, it is where
the obejct itself knows it is being reference counted and can get
access to its reference count. It might also possibly be able to
increase it and decrease it. This can be useful if one construction of
an object, it has to put references to itself elsewhere.

You can fake intrusive reference counting with a non-intrusive
implementation by giving an object a shared pointer to itself.

A place where intrusive reference counting can be a good idea is for a
thread class which can contain a reference to itself and reduce its
reference count when it finishes running. If there are other references
to it, then its object state will be maintained but if not it will
destroy all its resources.
There are a number of thread proposals being discussed at the moment.
Reference counts in smart pointers need to be thread safe so you can bet
that they're going to come out with a thread safe option to begin with.
boost's shared_ptr is thread safe last I looked (at least it has
compile mode for thread safety).
I think you can choose to have all your shared pointers lock or all of
them not lock but you can't pick and choose and that should be an
available option.

If I'm posting messages to a deque< shared_ptr< Msg in a
producer-consumer queue then I will probably want thread-safe reference
counting. Even then I can get by without it - I can lock the mutex (to
the deque), post to the queue then immediately reset my own pointer
before releasing the lock to the deque, so I know there is an object
there and my release happens first

If I have a big collection in a vector< shared_ptr< T for some
class T and I have only one thread doing some manipulation with this
vector, eg sorting it, it would most likely be highly inefficient to
keep locking and unlocking each time a reference count is modified.
Also in the Austria C++ library's smart pointers, (which are intrusive
btw), these have ways of supporting non thread safe and thread safe
reference counts as well as supporting the COM style reference counts
(new objects start with a refcount of 1). The latest and trickiest is
an "atomic" version of the Austria smart pointer which allows multiple
threads to read and write the pointer simultaneously.
While I'm at it, there are also different modes of austria smart pointer
(one I call the "medusa" pointer) where you have different (intrusive)
reference counts for different smart pointer type allowing you to track
when all pointers of a particular type have released the object.

Then on top of all this, there are there flavours of Austria smart
pointer, (Ptr, PtrDelegate, PtrView) which can be used to minimize the
number of redundant increment/decrements when passing around lots of
smart pointers hence reducing the performance hit but it does require a
little "education" on the part of the programmer.
I am not aware of Austria, I am aware of Loki. I think the general
feeling is that a one "fits-all" smart-pointer is what a lot of people
want who don't want to have to think smart themselves. After all, even
not picking the best one is probably better than the old code that
didn't use them at all.

A lot of the time, proper garbage collection could replace
reference-counted smart pointers. Garbage collectors do not generally
use reference counting (because of the circular reference problem). I
don't know exactly how they do work.
To counter that, it is better off if your library does not return
shared_ptrs (or any other class in the standard library, even a
std::string). This is something I would like to see addressed because I
think it's a major flaw in C++ at the moment.

Really ? Why should we not return std::string ? Anyhow, in Austria
C++ land, return an at::PtrDelegate which basiclly "moves" the pointer
eliminating an increment/decrement...
Let's suppose you write a library using Dinkumware and you have a
function that returns a std::string. So it will return a Dinkumware
std::string.

But I am perhaps using Roguewave STL and perhaps their std::string has
a different physical layout (why shouldn't it?). So effectively the
code will just break at run-time.
Anyhow, I think it's safe to say that "smart pointers" are a rich topic
for discussion but there are at least 4 implementations that are fairly
complete that have different "pros" and cons and they will probably work
mixed in the same body of code (not that I reccomend that but it will
probably work nonetheless).
You can use as many different smart pointer implementation as you want
as long as they have different names so they act as different classes.

The danger is when you have two different ones that use the same name.
And tr1::shared_ptr might just be that if there is no one standard
implementation.

Nov 13 '06 #18
Earl Purple wrote:
Gianni Mariani wrote:
....
>at::Ptr<Base *x = new Derived;

yes but just because you set it to a derived class doesn't mean that
the function should be a template (which would allow you to pass in ANY
type). I'm not sure you understand what templates are for.
at::Ptr<Derived *x = new Derived;
at::Ptr<Base*y = x;

Do that one without templates.

....
A place where intrusive reference counting can be a good idea is for a
thread class which can contain a reference to itself and reduce its
reference count when it finishes running. If there are other references
to it, then its object state will be maintained but if not it will
destroy all its resources.
Having a thread object destroy itself is really hard to get right and
depends on a number of non-portable assumptions. The whole idea of
detached threads and the constraints under that are needed to make them
reliable is a big question. In short, don't do it.
>
>There are a number of thread proposals being discussed at the moment.
Reference counts in smart pointers need to be thread safe so you can bet
that they're going to come out with a thread safe option to begin with.
boost's shared_ptr is thread safe last I looked (at least it has
compile mode for thread safety).

I think you can choose to have all your shared pointers lock or all of
them not lock but you can't pick and choose and that should be an
available option.
Curious, why ?
>
If I'm posting messages to a deque< shared_ptr< Msg in a
producer-consumer queue then I will probably want thread-safe reference
counting. Even then I can get by without it - I can lock the mutex (to
the deque), post to the queue then immediately reset my own pointer
before releasing the lock to the deque, so I know there is an object
there and my release happens first
Ah, false assumption. Unless you're really really careful to release
(decrement the reference count) before unlocking the deque mutex, you're
in for surprises unless it's a thread safe reference count. If you do
that, you're deque interface would look rather ugly.
>
If I have a big collection in a vector< shared_ptr< T for some
class T and I have only one thread doing some manipulation with this
vector, eg sorting it, it would most likely be highly inefficient to
keep locking and unlocking each time a reference count is modified.
Thread safe reference counting is done using atomic ("intrisic")
instructions. They do have an overhead but it is certainly not as
significant as a mutex/lock/unlock cycle. However, having said that,
for many use cases, it would probably not make a discernible difference.
>
>Also in the Austria C++ library's smart pointers, (which are intrusive
btw), these have ways of supporting non thread safe and thread safe
reference counts as well as supporting the COM style reference counts
(new objects start with a refcount of 1). The latest and trickiest is
an "atomic" version of the Austria smart pointer which allows multiple
threads to read and write the pointer simultaneously.
>While I'm at it, there are also different modes of austria smart pointer
(one I call the "medusa" pointer) where you have different (intrusive)
reference counts for different smart pointer type allowing you to track
when all pointers of a particular type have released the object.

Then on top of all this, there are there flavours of Austria smart
pointer, (Ptr, PtrDelegate, PtrView) which can be used to minimize the
number of redundant increment/decrements when passing around lots of
smart pointers hence reducing the performance hit but it does require a
little "education" on the part of the programmer.

I am not aware of Austria, I am aware of Loki. I think the general
feeling is that a one "fits-all" smart-pointer is what a lot of people
want who don't want to have to think smart themselves. After all, even
not picking the best one is probably better than the old code that
didn't use them at all.
Sure.
>
A lot of the time, proper garbage collection could replace
reference-counted smart pointers. Garbage collectors do not generally
use reference counting (because of the circular reference problem). I
don't know exactly how they do work.
The "Boehm" collector is a great example of one for C++. The problem
with garbage collectors is unpredictablili ty. If your application does
not require it, then using a collector is probably a good thing.
However, if your application can't deal with an intermittent pause while
the collector does it's thing, then reference counting + smart pointers
is the next best thing.

As you mention, the problem with reference counting is the cyclic issue
and the fix is a "don't do that" design issue. One of the mechanisms I
use is a "coupling" mechanism which reliably allows objects to decouple
one-another at any time. It's in the Austria C++ library called Twin or
TwinMT for MT code.
>
>>To counter that, it is better off if your library does not return
shared_ptrs (or any other class in the standard library, even a
std::string ). This is something I would like to see addressed because I
think it's a major flaw in C++ at the moment.
Really ? Why should we not return std::string ? Anyhow, in Austria
C++ land, return an at::PtrDelegate which basiclly "moves" the pointer
eliminating an increment/decrement...

Let's suppose you write a library using Dinkumware and you have a
function that returns a std::string. So it will return a Dinkumware
std::string.
Ah - nothing like a good standard, let's have lots of them.

This just means you need to "standardiz e" on the implementation. I
stick to the vendor supplied versions.
>
But I am perhaps using Roguewave STL and perhaps their std::string has
a different physical layout (why shouldn't it?). So effectively the
code will just break at run-time.
>Anyhow, I think it's safe to say that "smart pointers" are a rich topic
for discussion but there are at least 4 implementations that are fairly
complete that have different "pros" and cons and they will probably work
mixed in the same body of code (not that I reccomend that but it will
probably work nonetheless).

You can use as many different smart pointer implementation as you want
as long as they have different names so they act as different classes.

The danger is when you have two different ones that use the same name.
And tr1::shared_ptr might just be that if there is no one standard
implementation.
Nov 15 '06 #19
Earl Purple wrote:
If I have a big collection in a vector< shared_ptr< T for some
class T and I have only one thread doing some manipulation with this
vector, eg sorting it, it would most likely be highly inefficient to
keep locking and unlocking each time a reference count is modified.
You would want to just move the shared_ptr's in that case. There's no
need to adjust the reference counts.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Nov 17 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
2692
by: David B. Held | last post by:
I wanted to post this proposal on c.l.c++.m, but my news server apparently does not support that group any more. I propose a new class of exception safety known as the "smart guarantee". Essentially, the smart guarantee promises to clean up resources whose ownership is passed into the function, for whatever defintion of "clean up" is most appropriate for the resource passed. Note that this is different from both the basic and the...
8
5158
by: Axter | last post by:
I normally use a program call Doxygen to document my source code.(http://www.stack.nl/~dimitri/doxygen) This method works great for small and medium size projects, and you can get good documentation like the following: http://axter.com/smartptr Now I'm on a client site, and I'm trying to create the same type of documentation on a very large project. I ran the Doxygen program, and it ran for over 16 hours, before I had
6
2312
by: zl2k | last post by:
hi, When I considered about preventing memory leaking, the method came up to my mind is using boost smart pointer if possible (use stl::vector instead of type, use smart pointer whenever declare an instance of class). With the container of STL, this may often result in a vector of smart pointers, or a smart pointer of STL container. Am I making things too complicated or this is an usual implementation? Thanks in advance. zl2k
14
18219
by: Ian | last post by:
I am looking at porting code from a C++ application to C#. This requires implementing data sharing functionality similar to what is provided by a smart pointer in C++. I have only recently begun to work in C# and am asking for suggestions/comments of how to implement a similar data sharing technique in C#. A C++ smart pointer can be used to share common information. For example, assume information managed by objects I1, I2, I3,...
13
2083
by: Phil Bouchard | last post by:
I am currently writting a smart pointer which is reasonnably stable and I decided supporting allocators for completion because of its increase in efficiency when the same pool used by containers is shared. I was told the new standards are being finalized and I am hoping minor but important changes could be applied before anything else. To give a quick overview on the current status of this topic, you will find below the latest text...
50
4532
by: Juha Nieminen | last post by:
I asked a long time ago in this group how to make a smart pointer which works with incomplete types. I got this answer (only relevant parts included): //------------------------------------------------------------------ template<typename Data_t> class SmartPointer { Data_t* data; void(*deleterFunc)(Data_t*);
0
9887
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9730
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10983
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
10707
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10341
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9485
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5719
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4529
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4119
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.