[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Flat SmartWrappers
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-04-08 16:13:00
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    Hi!
> 
> I've just commited a new version of the smartwrapper code to the CVS. Its
> a lot faster due to the fact that they do not inherit each other any more.

That works fine here as well. I just put back the use of the ?: operator because
it increases the speed by half (150%) on my system, effectively rendering the
SmartWrappers more efficient than the _var code in the first 2 speed test.

> 
> This leads to much simpler code. On the other hand, it seems that inline
> functions don't bloat the binaries, so adding all functions from all base

So long as the compiler accept them as such, it doesn't increase the binaries.
But if they grow too big, then it will probably generate local versions of the
functions in the binary. gcc seems to accept them all.

> classes to each smartwrapper seems to be ok. I've added more tests regarding
> parameter passing and I'm quite happy with the results now.
> 
> Casting is done via operators. So if D inherits from A, it has an
> 
>   inline operator A()
> 
> to do the casts. So it works the same as before, just without inheritance.
> One problem is still that when writing A(d), where "d" is a D class, its
> not clear whether a conversion to D_base* and then to A (from A_base*) or
> to A and then to A via copy constructor is requested. This should go away

I think so, since D isn't a child of A anymore.

> once _base stuff disappears a bit more and the operator is no longer needed.

?? There will still be a need for a A(const D&) constructor, or equivalent.
Perhaps the solution would be a A(const SmartWrapper&) constructor, so that it
could accept any type, including D. Then, the _cast() will check if the
assignment is legal or not. I think it's OK, do you?

> Also the start() function still causes problems - something has to be renamed
> there.

Sure. The SynthModule class is a bit special, since it doesn't have an
implementation but instead a StdSynthModule class that inherits from the _base,
and not the _skel.
The child synth_XXX then inherits from StdSynthModule, and its start() method
isn't the same than the _node()->start().

What I mean is since that is not quite standard, we could:
- Put the SynthModule code in a .h/.cc file, and remove it from the idl.
- Detect in mcopidl if a given module uses streams. If yes, silently add a
parent corresponding to the present SynthModule.

Since we already generate code conditionally to having streams, and include
flowsystem.h the same way, this seems the logical continuation. Moreover, we
would then have a 'real' stream keyword in the idl, independant of what parent
the interface has declared. It will also be easier to add new stream type in the
future (like video...). What do you think?

> So probably, I can start porting some code over to smartwrappers this weekend
> (especially the binding for arguments and Object -> Object_base would be an
> important step). Well, lets see.

Well, SmartWrappers are indeed much more worth their name now than they were in
the beginning. However, solving those last issues in this mail would facilitate
the porting, so we might as well do the corresponding changes before.
There was also the question of underscores. start, stop, isNull and error will
be used often, so should remain without underscore. The current situation seems
fine.


Cheers
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)

[prev in list] [next in list] [prev in thread] [next in thread]