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

List:       kde-multimedia
Subject:    Re: More smart wrapping for struct types?
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-29 9:00:14
[Download RAW message or body]

   Hi!

On Sun, May 28, 2000 at 03:14:01PM +0100, Nicolas Brodu wrote:
> Stefan Westerfeld wrote:
> > I am considering to change the mapping for struct like returncodes to a
> > wrapped version similar to SmartWrappers as well. I'll play with it this
> > weekend - looking forward to your comments ;)
> 
> This sounds nice. I've seen that you also have made WeakReferences for the
> SmartWrappers.

Yes, I need them for artsbuilder, because flow graphs can of course contain
cycles and such. With conventional SmartWrappers, you can't possibly write
code that frees this (without conversion to _base*, which is not that safe).

> The sequence is also a good idea, even it there might be problems
> with the iterator (see below).

I thought about defining iterator inside the sequence, so you can do

User_seq s = ...
User_seq::iterator i;
for(i=s->begin();i != s->end(); i++) cout << i->login << endl;

> [...]
> 
> But please commit your first version. I suppose that as for the SmartWrappers,
> about the only way to improve them was to try to use them in practice!

Well, I did just that right now. After having played with the few alternatives
that are there, I decided not to go for User_ptr.

The most important reason is this: if we're talking of object references,
where the SmartWrapper solution works quite nice, we encourage the fact that
two entities may modify the same object. After all, SmartWrappers are
conceptually references.

On the other hand, if we talk of structures, these shouldn't have these co-
referencing functionality. People may end up modifying an internal data
structure, or do similar things, if the source object returns simply a
reference counted pointer to a User, instead of a deep copy.

I found no elegant way to preserve the way you can careless use structures
as values, and on the other hand be safe that no two objects collide, other
than not doing the User_ptr thing.

Instead, I changed the binding to use always "User" now, e.g.:

// IDL
    void addUser(User u);
    User findUser(string login);
    sequence<User> listAllUsers();

// mapped C++ stuff
    void addUser(const User& u);
    User findUser(const std::string& login);
    std::vector<User> *listAllUsers();

Of course, this change costs some performance in some cases, (especially if
you have structs that have huge contents), however, it is

- simple to understand
- very hard to write buggy code with that

and if you really really need to write performace critical code, you'd better
not use auto-generated data structures, but write your own.

I didn't touch the sequence stuff, yet, there are two alternatives:

- a really simple wrapper that just holds the return code - people could be
  free to use or not to use it, depending on whether they'd like to write
  delete themselves, e.g.

    User_seq s = accountManager.listAllUsers()
	/* dosomething */

  would be the same like

    vector<User> *s = accountManager.listAllUsers()
	/* dosomething */
	delete s;

- change to vector<User> - this would be even easier, but comes at the cost
  of one additional copy (why can't compilers be smart enough to optimize
  this away)

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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