473,851 Members | 2,245 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 5098
Gianni Mariani wrote:
>
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.
Which tricky technique is that?
>
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.
You should put some sort of lexical scoping restrictions on those to limit
their lifespan. Raw pointers with a leash. Not make them assignable or
something. A bit of hackery since C++ doesn't support restricting stuff
to local very well.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Nov 17 '06 #21
Joe Seigh wrote:
Gianni Mariani wrote:
>>
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.

Which tricky technique is that?
Pull down the latest austria c++ "beta" here:
http://netcabletv.org/public_releases/ (warning - it's big - 100meg -
contains some prebuilt binaries).

In the file at_lifetime_mt. h, it contains a traits class
PtrClassRefWrap perMT that provides thread-safe semantics for smart
pointer objects. It's not really "lock free" because it implements a
lock but it works. The smart pointer template disallows anything but
placing a pointer from a "PtrClassRefWra pperMT" into/from a non thread
safe smart pointer so it ensures that the pointer is held by a second
(non thread safe) smart pointer during the process.

This combined with the ThreadSafePtrLo ck in at_thread.h allows you to
"atomically lock" a reference counted lock even while other threads
might be trying to change the pointer contents.

This is used in the MT object coupling using the "twinmt"
system/pattern/whatever. This means two separate objects can talk to
each other while maintaining the ability to disconnect at any time which
relieves design constraints on object lifetimes.

The "at::Timer" test cases exercise this feature
(associating/deassociating/getting events from timers simultaneously) .

I use the word "tricky" because it's a little convoluted not because
it's non-obvious.

The at:: smart pointers can be given traits class that are used to
manage how to increment and decrement the reference counts as well as
access the pointer. The thread safe traits class uses "compare
exchange" and "scheduler yields" in ways that are similar to a spin
lock. The advantages of using the at:: thread safe smart pointer (apart
from syntactic brevity, is that it only uses the storage required for
the pointer itself and it it likely to ever deadlock because the
lock/unlock is done in the same path and the lock is never exposed
(unless someone uses (T*)0x1 as a pointer value!). Also the number of
instructions from lock to unlock is exceedingly small. On classes with
non virtual reference count inc/dec funtions, this can be as little as 3
instructions (but potentially hundreds of cycles because of the atomic ops).

I've only needed to use it for the cases where the at::twin_mt code is
used to attach/detach/destroy simultaneously for the reference counted
lock, but it is not written to be specific to this case, it is truly
general purpose.

>>
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.

You should put some sort of lexical scoping restrictions on those to limit
their lifespan. Raw pointers with a leash. Not make them assignable or
something. A bit of hackery since C++ doesn't support restricting stuff
to local very well.
I'm not sure I know what you mean.

The Austria C++ smart pointer design rules are like this.

1. Use an at::Ptr smart pointer as member variables or places where you
need to "hold a reference" to an object.

2. When passing Austria smart pointers as a parameter if the API can
guarentee that the caller will own the object while the call is in
progress, use an at::PtrView otherwise use an at::PtrDelegate .
PtrDelegate becomes null once the pointer is transferred to a regular
smart pointer.

3. Always use a PtrDelegate when returning a smart pointer and always
place a returned PtrDelegate into an at::Ptr.

4. If you don't care about the overhead of redundant increment/decrement
references, it's safe to pass an at::Ptr everywhere.

Sure, I would like to make it easer, but unless we change the C++
language, I can't see how much easier we can make it. I have not
thought much about the new "move" semantics, but having said that, I
should see if it can eliminate some of the complexity.
Nov 18 '06 #22
Gianni Mariani wrote:
Joe Seigh wrote:
>Gianni Mariani wrote:
>>>
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
simultaneousl y.


Which tricky technique is that?


Pull down the latest austria c++ "beta" here:
http://netcabletv.org/public_releases/ (warning - it's big - 100meg -
contains some prebuilt binaries).

In the file at_lifetime_mt. h, it contains a traits class
PtrClassRefWrap perMT that provides thread-safe semantics for smart
pointer objects. It's not really "lock free" because it implements a
lock but it works. The smart pointer template disallows anything but
placing a pointer from a "PtrClassRefWra pperMT" into/from a non thread
safe smart pointer so it ensures that the pointer is held by a second
(non thread safe) smart pointer during the process.
[...]

Ah, I was thinking there was another lock-free refcount algorithm out
there besides the two I use in atomic_ptr at
http://atomic-ptr-plus.sourceforge.net/
one for double compare and swap and another for load reserved/store conditional
architectures.

It's not documented but if you want to see how it works look at the patent
applications by the Sun Research synchronization group
20060037026 Lightweight reference counting using single-target synchronization
20060218561 Code preparation technique employing lock-free pointer operations
use http://appft1.uspto.gov/netahtml/PTO/srchnum.html
If you have the tiff plugin the illustrations are quite nice.

It's not too bad performance wise but I'm tending toward lighter
weight ptrs like fastsmr (RCU+SMR). A hazard pointer load takes
about 14 nsec on a 866Mhz P3 vs. 4 nsec for a raw load.

I don't use these for memory management but for lock-free solutions
to the reader/writer problem. There are also lock-free based proxy
collectors which effectively give you raw pointer access to collections.
There's also a refcounting scheme which I haven't done yet which
uses PDR (PCOW (partial copy on write) deferred reclaimation) to
ensure the refcount doesn't go away on on any in progress refcount
increments. fastsmr, RCU, proxy refcounting are forms of PDR.

>>>
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.

You should put some sort of lexical scoping restrictions on those to
limit
their lifespan. Raw pointers with a leash. Not make them assignable or
something. A bit of hackery since C++ doesn't support restricting stuff
to local very well.


I'm not sure I know what you mean.

The Austria C++ smart pointer design rules are like this.

1. Use an at::Ptr smart pointer as member variables or places where you
need to "hold a reference" to an object.

2. When passing Austria smart pointers as a parameter if the API can
guarentee that the caller will own the object while the call is in
progress, use an at::PtrView otherwise use an at::PtrDelegate .
PtrDelegate becomes null once the pointer is transferred to a regular
smart pointer.

3. Always use a PtrDelegate when returning a smart pointer and always
place a returned PtrDelegate into an at::Ptr.

4. If you don't care about the overhead of redundant increment/decrement
references, it's safe to pass an at::Ptr everywhere.

Sure, I would like to make it easer, but unless we change the C++
language, I can't see how much easier we can make it. I have not
thought much about the new "move" semantics, but having said that, I
should see if it can eliminate some of the complexity.
They're basically like a raw reference which is safe as long as you
own one of rhe refcount pointers. I haven't tried it but bascially
you don't make them assignable. They can only be declared and
intialized with a ctor. Declare the ptr that holds the refcount
and then declare the "raw" ptr contructed from the refcount one.
Since they're not assignable the "raw" ptr can't have the refcount
one changed out from under it.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Nov 18 '06 #23
Joe Seigh wrote:
Gianni Mariani wrote:
....
>Sure, I would like to make it easer, but unless we change the C++
language, I can't see how much easier we can make it. I have not
thought much about the new "move" semantics, but having said that, I
should see if it can eliminate some of the complexity.

They're basically like a raw reference which is safe as long as you
own one of rhe refcount pointers. I haven't tried it but bascially
you don't make them assignable. They can only be declared and
intialized with a ctor. Declare the ptr that holds the refcount
and then declare the "raw" ptr contructed from the refcount one.
Since they're not assignable the "raw" ptr can't have the refcount
one changed out from under it.
I'm still not exactly sure what you're saying. However, if I'm right,
this technique you describe won't work with extrusive smart pointers.
While the at:: smart pointers are currently useful for intrusive
reference counts, I am toying with adding extrusive reference counting
support as well.
Nov 18 '06 #24
"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:45******** *************** @per-qv1-newsreader-01.iinet.net.au ...
Joe Seigh wrote:
>Gianni Mariani wrote:
...
>>Sure, I would like to make it easer, but unless we change the C++
language, I can't see how much easier we can make it. I have not
thought much about the new "move" semantics, but having said that, I
should see if it can eliminate some of the complexity.

They're basically like a raw reference which is safe as long as you
own one of rhe refcount pointers. I haven't tried it but bascially
you don't make them assignable. They can only be declared and
intialized with a ctor. Declare the ptr that holds the refcount
and then declare the "raw" ptr contructed from the refcount one.
Since they're not assignable the "raw" ptr can't have the refcount
one changed out from under it.

I'm still not exactly sure what you're saying. However, if I'm right,
this technique you describe won't work with extrusive smart pointers.
While the at:: smart pointers are currently useful for intrusive reference
counts, I am toying with adding extrusive reference counting support as
well.
You amortize the reference counting with PDR by tracking collector objects,
and not individual objects. You can attach an object to the collector, which
will use function pointer to inform it that its in a quiescent state.
more info on PDR:
http://groups.google.com/group/comp....0f4163f8e13f1e
(follow all links...)

here some info on high-performance PDR scheme I invented:
http://groups.google.com/group/comp....q=vzoom&qt_g=1

Nov 18 '06 #25
Chris Thomasson wrote:
....
You amortize the reference counting with PDR by tracking collector objects,
and not individual objects. You can attach an object to the collector, which
will use function pointer to inform it that its in a quiescent state.
more info on PDR:
http://groups.google.com/group/comp....0f4163f8e13f1e
(follow all links...)

here some info on high-performance PDR scheme I invented:
http://groups.google.com/group/comp....q=vzoom&qt_g=1

I don't see enough documentation for me to understand specifically the
alogorithm you're talking about.

The austria C++ system is designed for primarily for ease of use and
correctness (making it harder to make silly errors) so I'm not too
concerned with efficiency as this has never been an issue. When it
does, I'll worry about it.

The Austria C++ "thread safe resource" solution is just a simple
reference counted system (as has been around since forever) with an
ability to make a smart pointer copy of the pointer atomically. Not
exactly innovative but effective.

There is also a RAII thread safe lock called ThreadSafePtrTr yLock which
takes a reference counted mutex smart pointer and a reference to a
pointer to a resource and atomically acquires the mutex to the resource.

I have been using these techniques for many years and never ran into
problems. Sure there may be an issue with hot spots on systems with
large numbers of CPUs but I have not yet had that problem.

The question then is, if I can "retrofit" some of these other more
efficient techniques under the same interface? If I can, then everyone
is happy since one day I'll rip out the "ineffinien t" system I have and
replace it with a more efficient system and all will be well. If I
can't, then I'll need to either add a new interface (sucks) or break
alot of code using it (sucks more).

Nov 18 '06 #26

Gianni Mariani wrote:
>
at::Ptr<Derived *x = new Derived;
at::Ptr<Base*y = x;

Do that one without templates.
operator= (T * ptr );

part of a template class but not a template pointer. whatever pointer
is passed in must be or implicitly conver to T*. So if T is Base then
you can pass in x because Derived derives from Base.

In addition if the type is a const X then you can pass in a pointer to
non-const because that can implicitly convert to a pointer to const.
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.
In reality my threads usually get joined at some point and belong to a
threadpool even if there's only one thread in the threadpool.
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 ?
Because you don't always need the overhead as many times the shared_ptr
will only be accessed by one thread at a time. For example, you will
often use shared_ptr in a collection eg vector< shared_ptr< T or
map< string, shared_ptr< T etc.

And the lifetime of those objects is longer than the threads.

Now if one thread is sorting a vector of shared pointers and it is
guaranteed that no other thread is accessing it, either because it's
locked or because the data is local to this thread, then it is wasteful
to have to lock each one.

So sometimes you don't want the overhead, but that doesn't mean there
aren't occasions when you do.
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.
You don't do anything, you call a method call post() or push() or
whatever you want to call it. Now that call locks a mutex, adds the
item to the queue and then unlocks the mutex.

Now if you also get that call to relinquish ownership (and possibly
null the pointer, eg by resetting the shared_ptr) then there is no
problem. The underlying deque is locked throughout all of this so the
other thread gets no access.
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.
On what platform? There is no standard atomic instruction as you know.
On standard POSIX systems there is no such thing as atomic_incremen t().

Of course your particular system may have a more efficient way of doing
it than locking and unlocking a mutex but it is not standard and you
can't guarantee this for all platforms.
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.
Garbage collection can be useful but deterministic destruction is also
useful. I think D addresses both, and if they ever brought GC into C++
then I hope there would still be destructors for other RAII, including
interacting with C libraries where you are required to call a method
when you have finished with something because I'm certain that GC won't
extend to external libraries written in other languages.
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.
Good. If Austria is an open-source library I may have a look at it.

Nov 19 '06 #27
Earl Purple wrote:
Gianni Mariani wrote:
>at::Ptr<Derive d*x = new Derived;
at::Ptr<Base *y = x;

Do that one without templates.

operator= (T * ptr );

part of a template class but not a template pointer. whatever pointer
is passed in must be or implicitly conver to T*. So if T is Base then
you can pass in x because Derived derives from Base.

In addition if the type is a const X then you can pass in a pointer to
non-const because that can implicitly convert to a pointer to const.
Go ahead an try that. I don't remember all the problems but the last
thing you want to do is make it easy to inadvertently convert from a
smart pointer to a regular pointer.
>
>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.

In reality my threads usually get joined at some point and belong to a
threadpool even if there's only one thread in the threadpool.
Really ? Having fixed many bugs due to self destructing threads, I
think there are easier, more robust ways to go.
>
>>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 ?

Because you don't always need the overhead as many times the shared_ptr
will only be accessed by one thread at a time. For example, you will
often use shared_ptr in a collection eg vector< shared_ptr< T or
map< string, shared_ptr< T etc.

And the lifetime of those objects is longer than the threads.

Now if one thread is sorting a vector of shared pointers and it is
guaranteed that no other thread is accessing it, either because it's
locked or because the data is local to this thread, then it is wasteful
to have to lock each one.

So sometimes you don't want the overhead, but that doesn't mean there
aren't occasions when you do.
The overhead associated with atomic increment and decrement is not that
great. However, with Austria C++ reference counted objects, you can
choose to make them thread safe or not.

>
>>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.

You don't do anything, you call a method call post() or push() or
whatever you want to call it. Now that call locks a mutex, adds the
item to the queue and then unlocks the mutex.
simple case:
at::Ptr<Msg *> message = new Message();
....
send_message( message );

//message is a pointer available in both threads now.

so unless you're doing things like removing the message from the smart
pointer in send_message, you have a race condition.

This is a classic.
>
Now if you also get that call to relinquish ownership (and possibly
null the pointer, eg by resetting the shared_ptr) then there is no
problem. The underlying deque is locked throughout all of this so the
other thread gets no access.
>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.

On what platform? There is no standard atomic instruction as you know.
On standard POSIX systems there is no such thing as atomic_incremen t().
True. However all modern platforms having system specific stuff that
does this. The standard C++ thread discussions seem to all agree that
there should be a standard interface to these low level primitives
through a standard interface.
>
Of course your particular system may have a more efficient way of doing
it than locking and unlocking a mutex but it is not standard and you
can't guarantee this for all platforms.
The platforms that don't support it are probably not target platforms
anyway.
>
>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.

Garbage collection can be useful but deterministic destruction is also
useful. I think D addresses both, and if they ever brought GC into C++
then I hope there would still be destructors for other RAII, including
interacting with C libraries where you are required to call a method
when you have finished with something because I'm certain that GC won't
extend to external libraries written in other languages.
>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.

Good. If Austria is an open-source library I may have a look at it.
The latest version (public one that is) is here:

http://netcabletv.org/public_releases/

Note - the download is 100meg - it contains a bunch of prebuilt binaries.

It's more like an alpha release....

Nov 22 '06 #28
"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:45******** **************@ per-qv1-newsreader-01.iinet.net.au ...
The overhead associated with atomic increment and decrement is not that
great.
Oh, yes they are:
http://groups.google.com/group/comp....c665e616176dce
(read all please)
Indeed!

;^)

Any thoughts?
Nov 23 '06 #29
Chris Thomasson wrote:
"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:45******** **************@ per-qv1-newsreader-01.iinet.net.au ...
>The overhead associated with atomic increment and decrement is not that
great.

Oh, yes they are:
http://groups.google.com/group/comp....c665e616176dce
(read all please)
....
Any thoughts?
That thread discusses RW locks. I'm talking about atomic increment. On
IA32 and AMD64 at least these are single instructions that the CPU
synchronizes with other CPU's. It is certainly more expensive that non
atomic instructions but in the scheme of things, it's not that bad.

I'm not saying that having a non-mt safe reference count is a good
option for a reference counted library, I'm just saying that in most
cases you don't need to worry about it.

Austria C++ supports both thread safe and non thread safe reference
counted base classes.
Nov 23 '06 #30

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
18221
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
2084
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
9898
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...
1
10735
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
10356
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
9506
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
7073
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5736
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...
0
5934
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4143
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3180
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.