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

List:       kde-core-devel
Subject:    Re: GLib/GObject+C as the lingua franca?
From:       "koos vriezen" <koos.vriezen () gmail ! com>
Date:       2008-07-27 20:15:22
Message-ID: d4e708d60807271315g5cf25814veb92c01e36b07e80 () mail ! gmail ! com
[Download RAW message or body]

2008/7/27 nf2 <nf2@scheinwelt.at>:
> koos vriezen wrote:

>> But you also need to add a copy constructor then and think about
>> either implicit sharing the GFile object or copying ... GFile doesn't
>> seem to have ref counting only g_file_dup, so for sharing you must do
>> your own ref counting.
>>
>
> GFile inherits from GObject. Therefore it does have ref-counting.

Ah right, thanks! It's a GInterface ... so it's a GLocalFile for local files.


>> But if you can easily track the file objects, why not simply store the
>> pointers in the C++ containers.

> Again - garbage collection.

> The attached example implements the "GO" template class and tests it a
> little - valgrind reports 0 leaks :-)
> A bit like a C++ class with QExplicitlySharedDataPointer.

Looks clean, if you think you need gc this looks pretty nice.
Btw. for const correctness, should 'T *p' be declared mutable? The
copy constructor does change p by adding a ref count. I'm not into
this precise programming, so dunno

Just a quick thought about this ref counting, there is also
g_object_weak_ref, that could be used to set the p pointer to zero (in
which case only one storage object may exist).
Haven't looked in your code, but having closed/deleted files still in
some container because of the ref counting, may require some extra
code to verify the p pointer is still valid.

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