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

List:       kde-multimedia
Subject:    Re: 'default' updated, idea for the reference problem.
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-03-22 22:02:45
[Download RAW message or body]

   Hi!

On Wed, Mar 22, 2000 at 03:40:11PM +0000, Nicolas Brodu wrote:
> I'll demux the previous message:
> 
> => Default 'keyword':
> Updated the inheritance rules. Now, it is:
> - If a default list is specified in the idl, then use it. Parent ports can be
> put in this list as well.
> - Otherwise, inherit parent defaults.
> - If there is still no default and a single stream in any direction, use it as
> default.

Fine. Can you put these lines (plus a few lines what default ports are, and
why they exist) into the doc/ directory in some .html-file and link it from
index.html (like the other documentation). That would be good.

You should mention what happens when there is more than one parent with
default ports (and you don't specify anything) - however it's not really
relevant what this is (if the result is undefined, well, thats fine as
well, just needs to be documented).


> => Referencing a null object, copy of smartwrappers.
> 
> Thinking about it, the problem comes from the fact we want a pointer semantic
> but have state variables inside the object => when you modify a copy, the
> original isn't affected (contradicts pointer semantics).
> 
> Assigning to 0 does not help, because even in that case when a copy is made
> and then a lazy create done on that copy, the original is still 0.
> 
> I don't want to commit to cvs till it gets more clear, but I'm thinking of
> having a pool common to all the objects that have been assigned together. That
> is, if you have Foo a = b;, than both a and b would have the same pool, itself
> containing (or beeing simply, in its minimal form) a Class_base* pointer.
>

Comments to your implementation:

 - isNull() shouldn't return true if b->_error() is true - that would mean
   that an object could become null without the user changing anything -
   rather these two conditions should be kept seperate

 - you probably don't need to increment the _base reference count every time
   the pool reference count is incremented, that only wastes time - all "pool"
   users can be mapped to one single "_base" reference

> [...]
>
> Well, I like the lazy creation concept, and it seems to me we can come up
> with a good solution. What about the above?

Indeed, this sounds like a good solution. The advantages we have are

- we can have const assignment operators again (as copying the reference to
  the "pool" doesn't need "write access" to the other object)

- we can do very fast assignments (as it is basically copying the "pool"
  pointer)

This looks like smartpointers with mapping idl Foo f(Foo a, Foo b) to
C++ Foo f(Foo a, Foo b) may be possible after all.

I think we should look if we can do an implementation which works like yours
and has the following characteristics:

- SmartWrappers should be fast when doing method calls

  => check that calling a "base->x()" function is not more than factor 2 or so
     faster than calling a "wrapper.x()" function

- SmartWrappers shouldn't bloat the libs too much

  => check that the size of aRts/MCOP with smartwrappers is not more than
     perhaps 10% larger than aRts in the version before smartwrappers
	 (check both: memory consumption of artsd and disk space consumption)

- SmartWrappers should be usable for everything

  => check that all _var and _base* disappears from the code, except for
     usage inside the SmartWrappers (_var should go away completely)

- SmartWrappers should be fast creatable

  => check that simply writing Foo f; or Foo a = b; has no significant
     performance hit

- SmartWrappers should have const assignment and constructor args

  => should be no problem with pool impl

- SmartWrappers should expose the same cast behaviour as "real" base* stuff

  => writing Foo f; Object o = f; should work, other way round of course not

As I see that that stuff is really much nicer to use, I'd really like to
have it completely, if we can (mostly) meet all of the above requirements.

The dot-forwarding will probably be the most critical part of all that, e.g.
writing Foo f; f.xyz(). If the syntax was Foo f; f->xyz(); all that would
be one operator -> overload. However, when you do dot-forwarding, inheritance
is the problem. The pool representation also is tricky and things like that.

Please go on with your pool implementation (its IMHO the way to go, too),
if you like commit the things you are working on. If you like, you can also
look at http://space.twc.de/~stefan/kde/download/smartwrapper-test.tar.gz,
I had also played a bit with the idea of seperating the "internal data" of
the SmartWrapper from the wrapper itself and do implicit sharing. My
implementation (as yours) has also no idea about inheritance yet.

Maybe "flat" dot-forwarding - e.g. implementing every method in every wrapper
again and not to inherit wrappers at all, is also an option, however whether
that hurts the memory requirement too bad needs to be tried.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

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