[Kde-bindings] KDE/kdebindings/csharp

[Arno Rehn]

On Wednesday 30 July 2008 15:17:49 Richard Dale wrote:
> On Wednesday 30 July 2008 14:03:25 Arno Rehn wrote:
> > On Wednesday 30 July 2008 14:31:23 Richard Dale wrote:
> > > On Wednesday 30 July 2008 01:01:28 Arno Rehn wrote:
> > > > On Monday 28 July 2008 20:13:05 Richard Dale wrote:
> > > > > On Saturday 26 July 2008 20:56:44 Arno Rehn wrote:
> > > > > > SVN commit 838125 by arnorehn:
> > > > > >
> > > > > > * Use qobject_cast in the KWrite example.
> > > > > > * If CreateInstance() doesn't find a type, it now replaces the
> > > > > > last '.' with a '+' and tries again to find nested classes.
> > > > >
> > > > > I don't think this is the best way to fix the problem. I think we
> > > > > need a Dictionary from a C++ classname to the C# type. Then another
> > > > > Dictionary that we already have to get from the Type to details
> > > > > about how to construct the instance.
> > > > >
> > > > > I'm not sure we need to have a Dictionary or QHash that goes from
> > > > > the C++ classname to  the C# classname, and then finally get the
> > > > > Type by walking through all the loaded assemblies. I would have
> > > > > thought that was pretty slow apart from problems with '+'s and '.'s
> > > > > in  the classname paths.
> > > >
> > > > Yes, it's definitely not the best solution. I think we should fix the
> > > > problem directly in SmokeBinding::className(). We could dynamically
> > > > replace every '::' with a '.' and then check if the type exists in
> > > > C#. If it doesn't, replace the last '.' with '+' and so on... At the
> > > > end we cache the result. We could then get rid of the static
> > > > classname-hash initialization in every module, too.
> > >
> > > We've always got the C++ class name first in order to have retrieved
> > > the C# one from the SmokeBinding::className() hash. So I think we
> > > should be directly retrieving the C# Type given the C++ name. Maybe it
> > > is useful to have a human readable version of the C# class name that we
> > > can retrieve from the C++ name, and the binding.className() call could
> > > do that. I think we should walk through the classes in a newly loaded
> > > assembly looking for SmokeClass attributes, and build up a Dictionary
> > > of C++ names <--> C# types that way.
> >
> > I thought about that first, too. But walking through all the classes of a
> > assembly via reflection is quite slow and I don't know if the additional
> > overhead is worth it. Actually only around half of the classes in a
> > module, if not less, will really be used in a project, I think.
>
> I think we need to do some actual timing measurements to find out how much
> loads would be slowed down. Maybe we could build a table of C++ names vs.
> C# types at compile time. Anyway, I think the hack we have at the moment is
> ok until we've thought about this a bit more.
I've written a small test app which loads the qt-dotnet, kde-dotnet and plasma 
assemblies and checks for types with the SmokeClass attribute (source 
attached). At the end it prints the milliseconds it took to walk through all 
the types. On my desktop machine it takes around 73 ms to do that, so it's not 
that bad after all (though that's quite recent hardware).

-- 
Arno Rehn
arno at arnorehn.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cs
Type: text/x-csharp
Size: 713 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20080730/7f5e82ac/attachment.bin>