arglib counted_ptr operator= question

[mati-006]

Hi
Why there is no "counted_ptr& operator= (pointee_type* p)" ?
This question has arisen when I was searching why following piece of
code won't compile:

arg::counted_ptr<testc;
c = new test;

And compiler wasn't very helpful with this:

g++ -ansi -pedantic -Wall -W -c test.cpp
arglib/arg_shared.h: In member function `arg::counted_ptr<pointee_type>&
arg::counted_ptr<pointee_type>::operator=(const
arg::typed_reference<pointee_type>&) [with pointee_type = test]':
test.cpp:8: instantiated from here
arglib/arg_shared.h:184: error: `void
arg::typed_reference<pointee_type>::increment_stro ng_references() const
[with pointee_type = test]' is protected
arglib/arg_shared.h:313: error: within this context

BTW Why the g++ hasn't just complain about wrong type?

Finally I've looked on the docs carefully and I see that there are only
following operator= defined:
counted_ptr& operator= (const base_type& rhs)
counted_ptr& operator= (const counted_ptr& rhs)
And only way to initialize the counted_ptr is to call the reset method
void reset (pointee_type* p)
//Delete existing contents (and take ownership of p).

So - is it arglib's author's oversight (I don't think so), am I
misunderstanding something (problably) or everything works as I
understand it and there is an explanation for not implementing
"operator= (pointee_type* p)"?

--
mati

[Salt_Peter]

mati-006 wrote:

Hi
Why there is no "counted_ptr& operator= (pointee_type* p)" ?

Because if there was, you'ld defeat the purpose of smart pointers.

This question has arisen when I was searching why following piece of
code won't compile:

arg::counted_ptr<testc;
c = new test;

You should be gratiously thankfull that failed.
You'ld leak the allocation in the rhv otherwise.
The compiler also describes the missing requirements, which makes sense
since this probably a reference counting smart pointer. Note the error
about the missing increment_strong_references()

arg::counted_ptr<testc;
arg::counted_ptr<testp(new test);
c = p; // this should work
Unlike an auto_ptr, the above allocation will only get deallocated once
both smart pointers are zapped.

By the way, this won't prevent you from passing the smart pointer
around.
instead of
void foo(test* const p) {...} // constant pointer to mutable

You define foo as so:
void foo(const arg::counted_ptr<test>& r_ptr) { /* check r_ptr != 0 */
}

//and call it:
arg::counted_ptr<testp(new test);
foo(p); // the smart pointer is constant, what is *at* p is not !!

Again, note that
const arg::counted_ptr<Tp;
acts like T* const, not const T*
At least, thats how a smart pointer *should* work.

>
And compiler wasn't very helpful with this:

g++ -ansi -pedantic -Wall -W -c test.cpp
arglib/arg_shared.h: In member function `arg::counted_ptr<pointee_type>&
arg::counted_ptr<pointee_type>::operator=(const
arg::typed_reference<pointee_type>&) [with pointee_type = test]':
test.cpp:8: instantiated from here
arglib/arg_shared.h:184: error: `void
arg::typed_reference<pointee_type>::increment_stro ng_references() const
[with pointee_type = test]' is protected
arglib/arg_shared.h:313: error: within this context

BTW Why the g++ hasn't just complain about wrong type?

Finally I've looked on the docs carefully and I see that there are only
following operator= defined:
counted_ptr& operator= (const base_type& rhs)
counted_ptr& operator= (const counted_ptr& rhs)
And only way to initialize the counted_ptr is to call the reset method
void reset (pointee_type* p)
//Delete existing contents (and take ownership of p).

So - is it arglib's author's oversight (I don't think so), am I
misunderstanding something (problably) or everything works as I
understand it and there is an explanation for not implementing
"operator= (pointee_type* p)"?

--
mati

[mati-006]

Salt_Peter wrote:

mati-006 wrote:

>>Hi
Why there is no "counted_ptr& operator= (pointee_type* p)" ?

Because if there was, you'ld defeat the purpose of smart pointers.

So the only way to initialize an existing smart pointer (from arglib)
with a new object is to call its reset member function, or to make a new
counted pointer and then call "=", but which method is better?
Code explaining what I mean:

arg::counted_ptr<testc;
....
c.reset(new test(constructor args));

or
arg::counted_ptr<testc;
....
arg::counted_ptr<testtemp_p(new test(constructor args);
c = temp_p;

>>This question has arisen when I was searching why following piece of
code won't compile:

arg::counted_ptr<testc;
c = new test;

You should be gratiously thankfull that failed.
You'ld leak the allocation in the rhv otherwise.

I do not understand why, afaik the new test returns a pointer to the
newly created "test" object, so what would leak here if the c would take
ownership of the pointee (in other words, if the
operator=(pointee_type*) would be defined in a way that reset member
function is)?

The compiler also describes the missing requirements, which makes sense
since this probably a reference counting smart pointer. Note the error
about the missing increment_strong_references()

arg::counted_ptr<testc;
arg::counted_ptr<testp(new test);
c = p; // this should work
Unlike an auto_ptr, the above allocation will only get deallocated once
both smart pointers are zapped.

By the way, this won't prevent you from passing the smart pointer
around.
instead of
void foo(test* const p) {...} // constant pointer to mutable

You define foo as so:
void foo(const arg::counted_ptr<test>& r_ptr) { /* check r_ptr != 0 */
}

//and call it:
arg::counted_ptr<testp(new test);
foo(p); // the smart pointer is constant, what is *at* p is not !!

Again, note that
const arg::counted_ptr<Tp;
acts like T* const, not const T*
At least, thats how a smart pointer *should* work.

--
mati