[Mono-devel-list] [off topic] mono/.net pure managed wrapperlibraries

Andreas Nahr ClassDevelopment at A-SoftTech.com
Thu Jul 28 18:01:32 EDT 2005


Don't think about performance on this one, because the loss will be 
absolutely unmeasurable (or at least extremely small) unless you want to 
stream byte by byte.
It is quite possible, that the mono jit will inline that code anyways...
Just create an abstract base class (or interface) and then inherit and 
you're done.

Andreas

----- Original Message ----- 
From: "Dominik Pich" <Dominik at pich.info>
To: <mono-devel-list at lists.ximian.com>
Sent: Thursday, July 28, 2005 7:32 PM
Subject: [Mono-devel-list] [off topic] mono/.net pure managed 
wrapperlibraries


> Ok, I'm aware this is offtopic but hey :) it is _RELATED_ to mono in  so 
> far that I think about using it :P
>
> So... my situation:
> I have managed code written using ms .NET which uses MS managed  wrapper 
> for WMP.
> I'd like to port that code to osx using mono and as I then dont have  WMP 
> but QuickTime, I thought I'd write a wrapper that on WINDOWS uses  WMP and 
> on OSX uses QuickTime.
> So far so good... ;)
>
> Instead of:
> on Windows I got:    MyApp -> managed WMP -> WMP
> on OSX I got:            MyApp -> managed QuickTime -> QuickTime
> I add the add. 'wrapper layer' so I have a common API:
> on Win/osx:               MyApp -> managed Media Player -> managed  WMP 
> (win) -> WMP
>                                                                         -> 
> managed QuickTime (osx) -> Quicktime
>
> Now Im thinking about the performance decrease of such an add.  'wrapper 
> layer' and wonder if I could 'inline' it ... so I dont have  the wrapper 
> in the compiled code:
>
> I write:
> oMediaPlayer->play();
> and it compiles to either
> QTplayer->play()
> WMPplayer->play()
>
> ... or do I worry to much?
> Thanks,
> Dominik
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




More information about the Mono-devel-list mailing list