From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-07 12:18:41
At 12:01 AM 08/07/2002, you wrote:
>I've cleaned up the polymorphic ptr<> class:
Thanks. I've been waiting for the other shoe to drop.
I've been looking at your source, and I really don't understand
what it is trying to do, let alone how it does it. Please explain.
What I think you are trying to do is allocate the counter along with
the object and then recover the counter given only a pointer to the
object. This lets sizeof(ptr<T>)==sizeof(T*) which is a very nice
property. To accomplish this you are willing to insist that the T
object be allocated with a placement new syntax, which is fine if it
works. Beyond that I am lost in your has_trivial_destructor and
reinterpret_cast games. As far as I know there is no portable way
to do what you are trying to do, but I'd be glad to be proved wrong.
There are nonportable ways to do it that you can find in the memory
management literature if that is what you are trying to do.
>- The syntax is similar to SGI's for temporary readability issues.
I guess every style is unreadable to someone, but you really should
stay away from names that begin with underscores.
>- Namespace 'fdi' is temporary also.
>- I feel more secure with LGPL. I don't know about you people?
I think we have long since decided that no form of the GPL is
appropriate for Boost. That is not a criticism of the GPL or
those who choose to use it, just that Boost has different goals
than the Free Software Foundation.
>- Lookup tables could be optimized more but are already reasonnable in
What lookup tables? What resources?
>- Template friend classes are not well supported under gcc 2.95.4; some
>internal classes are simply public.
>> >Sorry about it... It was not well explained:
>> >- sizeof(allocated block of new (rc()) T) = sizeof(T) + sizeof(int) * 2;
>> With regard to the "sizeof(int)*2" term, is one int for the reference
>> count and
>> the other for the offset from the start-of-object?
>the second int is used to identify the exact type (some sort of id).
>> On a related matter, do you think the following code:
>> typedef gc_method_subj_btm<gc_method_type,element_type> gen_type;
>> ptr(gen_type * a_gen = 0) : m_gen(a_gen), m_ptr(a_gen->get_subj())
>> would be less error-prone? It would be easy for a user who's careless
>> or in a hurry to just substitute "new T" as an argument instead of the
>> required "new (rc()) T ".
>'new (rc()) T' is error-prone but it can be included in a displaced static
>operator new (size_t) or simply wrapped into a macro (worse case scenario
>here). The problem with gen_type is that it will be constructed using a
>temporary which implies copy constructor dependence of the object pointed
>> argument. The disadvantage is that a specialization is needed for
>> anything other
>> than a default construction of the T; however, the extra safety would be
>> worth it
>> to me and maybe others.
>Specializing every widgets in the QT library would be a problem here but the
>general concept of having two pointers like this is already faster than 2
>separate allocations & deallocations: one for the object, another one for
>Philippe A. Bouchard
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk