Prev: return value optimization vs. returning a boost::shared_ptr of container
Next: Help with Code Please
From: Johannes Schaub (litb) on 16 Jun 2010 22:40
Visda wrote:

> Is a warning/error compiler message expected for the code snippet
> below?
>
> struct Student;
>
> int main() {
> struct Student *ps;
> shared_ptr<Student> sps(ps);
>
> return 0;
> }
>
> I expect front end to complain about Student not being defined and ps
> not being dynamically allocated, but it doesn't.
>

I'm sorry for the added post. But here is how i think you can fix it

struct Student;
void deleteStudent(Student*);
int main() {
struct Student *ps = ...;
shared_ptr<Student> sps(ps, &deleteStudent);
}

This will use the passe deleter instead of the default deleter (which relies
on a complete type). The deleter can then defined in whatever TU that has
access to the complete definition of Student, if needed.

If you know your type Student has a trivial destructor, you may also define
your deleter right there, since deleting it is defined behavior then. But
that is rather ugly, in my opinion :)

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin B. on 17 Jun 2010 03:55
Johannes Schaub (litb) wrote:
> Visda wrote:
>
>> Is a warning/error compiler message expected for the code snippet
>> below?
>>
>> struct Student;
>>
>> int main() {
>> struct Student *ps;
>> shared_ptr<Student> sps(ps);
>>
>> return 0;
>> }
>>
>> I expect front end to complain about Student not being defined and ps
>> not being dynamically allocated, but it doesn't.
>>
>
> This is not expected to work. shared_ptr requires a complete type in its
> *constructor* if it is constructed with a pointer as argument.
>
> However your type is incomplete. Other smart pointers require complete types
> in their *destructor*, which is kinda more awkward because the whole point
> is to don't care about destruction with smart pointers.
>

I really like that explanation/comparison. Kinda makes more sense than
the standardese that is usally applied when explaining when the complete
type is needed. :-)

> (...)
>
> Your code contains undefined behavior for C++0x (probably this is why it
> doesn't give you errors). The version in boost, however, gives you a
> diagnostic message for the code (something like "sizeof applied to
> incomplete type" or like that).
>

Uh. Does this mean that a conforming C++0x compiler is allowed to
compile the following code but then "crash" at runtime?? (Or was your
comment rgd UB about the uninitialized ptr value?)
- - -
struct Incomplete;

int main() {
Incomplete* p = nullptr;
std::shared_ptr<Incomplete> sp( p );
return 0;
}
- - -

cheers,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on 18 Jun 2010 00:24
Johannes Schaub (litb) wrote:
> Visda wrote:
> However your type is incomplete. Other smart pointers require complete types
> in their *destructor*, which is kinda more awkward because the whole point
> is to don't care about destruction with smart pointers.

I don't look at shared pointers that way. The destruction is well
defined (as opposed to garbage collection). While people may _want_
to use smart pointers in cases where they don't care when destruction
happens, my impression is that this _can be_ a wrong thing (sometimes,
not always). And I am glad that this is how things work, because
I personally always prefer the full control of my minions.

Example:

somewhere in code:
std::mutex resource_mutex; // is mutex in std? let's assume it is
std::list<std::shared_ptr<Foo>> wicked_shared_resources;

later:
void release() {
std::mutex::scoped_lock lock(resource_mutex);

wicked_shared_resources.clear();
}

If the destructor can take a really long time, we will hold
resource_mutex for too long. However, because we always have
destruction on our mind, we will instead do a swap while locked
and then clean while unlocked; additionally, queue cleaning
to another cleanup-dedicated thread.

Like I said, this is how I perceive shared pointers.

(And, please, don't ask me why resources are in the form of
shared_ptr<Foo>... :-D)

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: return value optimization vs. returning a boost::shared_ptr of container
Next: Help with Code Please