Re: Re: new round

Alexander Nasonov wrote:
> Daniel Wallin wrote:
> 
> 
>>Yeah, I agree that this is possible. But still, it's probably quite a
>>loss in efficiency for no good reason. Also it doesn't solve the
>>constructor<> case.
> 
> 
> I guess your scheme is mapping from type to conversion function:
> template<class Derived, class Base>
> void* derived_to_base(void*);

Well, the scheme for pointer conversion is to map typeinfo's to vertices
in a cast graph where the edges holds conversion functions. And the
conversion result (pointer offset) is cached. But this isn't what we are
discussing, is it?

> This is also quit inefficient compared to
> void* ptr_Base = ptr_Derived + shift;
> 
> For many compilers shift values can be calculated at init time rather then
> at runtime. In this case our approaches are equivalent in terms of
> execution speed (this is true if unwrapped class is known somehow to the
> framework). I'm not insisting on my idea, though. Best use-case of my
> thoughts is probably a lot of classes hidden behind make function a user
> don't want or don't have time to expose.
> 
> A* make_one_thousand_and_one(std::string id);
> // This function returns pointer to A1, ..., A1001
> // depending on supplied id.
> 
> Although not efficient, my scheme could save user's time and let her expose
> only class A and make_one_thousand_and_one to the system. To restrict a
> number of such conversions we could use a mark to designate A as an open
> class (in opposite to final in Java). One natural restriction already
> exists: the scheme can be applied only to polymorphic classes.

I'm sorry, but I don't understand this. What does this have to do with
the exception conversion thing?

-- 
Daniel Wallin


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click