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

List:       kde-multimedia
Subject:    Re: 'default ' keyword working.
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-03-20 23:53:21
[Download RAW message or body]

   Hi!

On Mon, Mar 20, 2000 at 09:36:18PM +0000, Nicolas Brodu wrote:
> I coded the 'default' port feature today. It works fine. To sum it up, it
> enables connecting objects in a simpler way. It should also enable automatic
> left to left and right to right connection for stereo objects (in fact, the
> mapping is done according to the order found in the idl, as there is no concept
> of 'left' and 'right' in the streams).

That sounds nice. The syntax also looks quite clean.

> The code is generated inside the smartwrappers. If needs be, it can easily be
> moved to the _base object or anywhere else. There are 2 functions
> defaultPortsIn() and defaultPortsOut() that return a vector<std::string>
> containing the default port names for each direction.
> 
> Issue: When inheriting from a parent, the parent defaults are added _after_ the
> object defaults (and in the inheritance list order), so that the object has
> priority. There is still a problem because if a parent has only one stream and
> the child also one, then this will end up with having a default of 2 streams for
> the child (where we might want to have only one default).
> 
> The connection asserts that the number of defaults match for the input/output of
> the connected objects, when the ports aren't specified explicitely. Another
> possibility would be to do as many connections as possible between the source
> and destination objects. This would partially solve the inheritance issue above,
> but then one must be more careful when connecting 2 objects. What do you prefer?

Is there something that speaks against this behaviour:
- if you don't mention the keyword default in your object declaration, the
  default ports are left as they were in the parent object
- if you do, the default ports are set to what you say, so you don't honor
  parents default ports any longer

I think that might be a clear behaviour. Of course, if you inherit from two
objects which both have default streams, then you loose - but hey, we can't
do magic ;)

> On another topic, I didn't have time to investigate but it seems that the
> smartwrapper code have a minor reference counting bug somewhere for remote
> connection. More precisely, artscat ends up after a few seconds when the
> reference clean finds a not so 'unused' object and frees it.

I thought a bit about reference stuff (without reading the code too deeply),
and I see a few issues that smartwrappers maybe don't handle correct yet.

==> 1. Returncodes vs. Parameters:

If you have

Object_base *doSomething(Object_base *foo)
{
    /* some code here */
    return (something);
}

then the returncode and the parameter are handled differently in respect to
reference-counts.

* Parameters are referenced by the caller, so that the object can use them
  as long as "doSomething" is active. Thus, if the object wants to use foo
  longer than that, it needs to do foo->_copy() internally.

* Return codes are referenced by the procedure, and returned "ready-to-use"
  to the caller. Thus, the caller "owns" a readily referenced object after
  calling "doSomething". (Or of course gets a null reference).

==> 2. Null references

I think there are issues with null references. The current smartwrappers
often do

  if(!nullreference) assign(...);

however, I would be amazed if I do:

Synth_PLAY p;
p = remoteObject.doSomething();
if(p.isNull()) cerr << "no object" << endl;

and doSomething *really* returns a null reference. What would happen is that
upon calling p.isNull(), auto-creation kicks in, and you don't get the error
msg, but a fresh locally created object. Thus, you need to do

  if(nullreference) assign(0);
  else assign(reference->_copy());

in all those cases.

==> 3. "Fixed" autocreation?

void calc(Synth_FREQUENCY param)
{
    // 2. a copy is made, but left unassigned
    setFloatValue(&param,440.0);  // 3. the copy gets autocreated here
    // 4. the copy gets destroyed here
}

main()
{
    Synth_FREQUENCY f; // 1. f is unassigned (but ready to autocreate) here
    calc(f);           // 5. f is still unassigned here
    f.start();         // 6. f is now created, however without 440 Hz setting
}

I think this is a new bug in the fixed auto creation. You need to do the
creation upon copy. (As the program should work exactly the same as if f
would get created in 1. already).

==> 4. _vars can also be null references

Well, that should be clear. Foo_var f; f->_copy() is also fatal. Assignment
operators and such should check that and do the same as in 2.

   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]