ooc-dev team mailing list archive
-
ooc-dev team
-
Mailing list archive
-
Message #00020
Re: interoperability with C libraries
Hi Vincent, we had an IM conversation on that, but let me sum it up for the
rest of the mailing list and for posterity:
- scoped objects are really easy to implement in the compiler, so that
will be done
- for a solution with the GC, look at the 4th item of this FAQ
http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html
Cheers,
Amos
2009/7/2 Vincent R. <forumer@xxxxxxxxxxxxxxx>
> Hi,
>
> If I am interested by ooc is because of 3 main characteristics:
>
> 1) Object orenriented language
> 2) Garbage collected
> 3) esay C interop.
>
> BUT without a destructor I am a bit lost, let's consider a simple C api
> with 5 functions used to read address book.
>
>
> GYNOID_API ErrorCode
> GDAddrBook_Alloc(GDAddrBook** gppAddrbook); // Manage access to address
> book
>
> GYNOID_API ErrorCode
> GDAddrBook_Release(GDAddrBook* gppAddrbook); // Deallocate GDAddrBook
> object
>
>
> GYNOID_API ErrorCode
> GDAddrBook_GetItem(GDAddrBook* gpAddrbook, int iIndex, GDAbItem**
> gppAbItem); // Get a GDAbItem
>
> GYNOID_API ErrorCode
> GDAbItem_Release(GDAbItem* gppAddrbook); // Deallocate a GDAbItem
>
> GYNOID_API void*
> GDAbItem_GetProperty(GDAbItem* gpContact, EAbItemProp eContactProp); // Get
> a prop. from a GDAbItem
>
>
>
> So tu sum up you first allocate a GDAddrBook "object" then you get a
> GDAbItem object to retrieve some properties
> (phone, email and so on) and once you have finished you release abitem then
> addrbook.
>
> in simplifying a lot
>
> GDAddrBook_Alloc // We init addrbook
> GDAddrBook_GetItem // we get a AbItem interface representing a contact item
> GDAbItem_GetProperty // we get a property from the item obtained with the
> previous function
> GDAbItem_Release // we release the current item
> GDAddrBook_Release // we release addrbook
>
>
>
> So my goal would be to design a oo wrapper around this, and using ooc here
> is how I would write it(sorry I don't know yet very well the language :
>
> // this class represent an item from the address book
> class AbItem {
> GDAbItem* gdAbItem;
>
> func new(GDAbItem* abitem) {
> gdAbItem = abitem; // We only transfer pointer
> }
>
> func release()
> {
> GDAbItem_Release(gdAbItem);
> }
>
> // don't even know how to code getProperty because in C I am returning a
> void* and caller cast it to the right type.
> //...
>
> }
>
> // this class gives access to addressbook
> class AddrBook {
>
> GDAddrBook* gdAddrBook;
>
> func new {
> GDAddrBook_Alloc(..., &gdAddrBook);
> }
>
> func getItem(int index, ....) -> AbItem {
>
> GDAbItem* gdAbItem;
> GDAddrBook_GetItem(gdAddrBook, ..., &gdAbItem);
> return AbItem(gdAbItem);
> }
>
> func release()
> {
> GDAddrBook_Release(gdAbItem);
> }
>
> }
>
> so this time in ooc my initial C api would be :
>
> AddrBook addrbook = new AddrBook(); // We allocate a AddrBook object
> AbItem abItem = addrbook.getItem(0); // We get the first contact item and
> we get a AbItem
> abItem.getProperty(eAbMobileTelNumber); // We get mobile phone property
>
> abItem.relase(); // we deallocate item
> addrbook .release(); // we deallocate addrbook
>
> So as you see if I want my C apis to deallocate memory I need to explictely
> call a release method but in this case
> I could also wrapp everything in C++ just smart pointerq and I wouldn"t
> have to manually call release.
>
> In c++ it would give :
>
> AddrBook addrbook;
> AbItem abItem = addrbook.getItem(0);
> abItem.getProperty(eAbMobileTelNumber);
>
> and since in my desctructor I put calls to release, wrapper seems better
> than in ooc.
>
> So is there any solution for my case ?
> Because when wrapping C code from a language with no destructor I have to
> manually call deallocate method.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References