GLib/GObject+C as the lingua franca?
koos.vriezen at gmail.com
Sun Jul 27 21:15:22 BST 2008
2008/7/27 nf2 <nf2 at 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.
More information about the kde-core-devel