[boost] Re: smart_ptr implementation descussion topics

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-06 14:47:15

"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
news:ab6l15$rf4$1_at_main.gmane.org...
> [...]
> Ownership policy interface expect *stored_type* as an argument.

Ok, so maybe I was thinking Ownership needed pointer_type?  I'm not
sure.  I'll take a closer look.

> "David B. Held" <dheld_at_[hidden]> wrote in message
> news:ab5vv9$cf0
> > [...]
> > Maybe we should have both c'tors?  And how do you know that you won't
> > ever want to construct from stored_type?
>
> In most cases they are the same. You can't provide to constructors.

Good point.  I wasn't thinking clearly. ;)

> [...]
> I think you are bitting dead horse here. Look into boost config. Also note
> that 2 compilers that does define NO_MEMBER_TETMPLATE flag really
> support them, but with some bug.

I guess I'd like to see some opinions from other Boost library authors, but
if there is a consensus that lack of member template functions is not
something
that needs to be supported, I sure would be happy to remove all the #ifdefs.

> [...]
> For example on MSVC I was able to make everything (other than templaet
> constructors) to work.

Now that's interesting, because MSVC seems to compile my smart_ptr
test that uses a template conversion c'tor.  Or maybe it just pretends to,
but
doesn't do it correctly?

> [...]
> > Yes, I considered this as well.  Some people don't like a lot of
> > #includes,
>
> We will use combining headers for this.

I understand that.  I just vaguely seem to recall a thread where people
argued about whether it was bad to break up a header into many different
header files.  There was something about directory searching and/or
file open times.  It didn't make a lot of sense to me; but I happened to
remember it, so I thought I would mention it.

> > Umm...I'm sorry, but are you saying we *should* or *should not* be
> > concerned with multithreading?
>
> should NOT of course, sorry.

Well, I don't think I could write a decent multithreading test case for
smart_ptr; but the boost::shared_ptr family already has multithreading
support, so the boost emulation policies can at least take advantage of
that.  Perhaps you could use the code in shared_count as a guide for
adding boost-centric multithreading support.  I didn't want to change
Andrei's ref_counted_mt policy, since it works with a generic threading
model.  And since the shared_ptr emulator uses the multithreading
code of counted_base, I didn't think it was necessary to add a boost-
like threading policy.

> [...]
> What do you mean as overgeneralization? Is it inconvinient or to complex?
> I argue that is is not.

It seems like your checking policy is more power than the average person
needs.  Therefore, it seems like more work for the compiler and more work
for the user to take advantage of it.

Dave