GObjectへの浮動参照への代替方法

Question

私はlecture on GTK+ memory managementの "オブジェクト降順GInitiallyUnown"の章を読んでいます。浮動参照の概念は、私たちはコード

container = create_container(); 
container_add_child(container, create_child()); 

代わりの

Child *child; 
container = create_container(); 
child = create_child(); 
container_add_child(container, child); 
g_object_unref(child); 

を書くことができます導入された私はすぐに次のように同じことが実現することができることに気づきました。機能はcontainer_add_child_move_ownershipです。 container_add_childは余分です。 container_add_child_move_ownership(container, child)が発信者からcontainerに所有権を移動したとします。したがって、container_add_child_move_ownershipは参照カウントを変更しません。したがって、次の例は正しいです。

void f(Container *container) { 
    container_add_child_move_ownership(container, create_child()); 
} 

0）私の解決策は、私が表示されていない欠陥を持っている、または1）浮動参照の概念は悪いデザインの決定であるのどちらか。それは本当ですか？

Answer 1

StackOverflowは、GObjectとG *プラットフォームのAPIデザイナーとこれについて議論するのは本当に良い方法ではありません。その代わりにgtk-develメーリングリストで尋ねたいと思うでしょう。

はい、浮動参照は所有権移転を行うための単なる方法です。

"所有権の移動" APIアプローチの問題点は、ポインタの所有権についてよく定義された型セマンティクスが存在しないことです。あらかじめ、APIの名前をcontainer_add_with_ownership_transfer()のように扱いにくくしない限り、あらかじめわからないだけです。さらに、一部のAPIが所有権移転で動作することを暗示しますが、タイプ検査では検出できません。これは、オーナーシップ転送ルールを知る必要があるため、、特にが重要です。

最近、GObjectはイントロスペクションの目的で追加のアノテーションを取得しましたが、APIとタイプシステムを変更するには時期尚早です。