gtkmm: что такое Glib :: RefPtr?

Question

Я пишу небольшое приложение GTK3 с библиотекой C ++ и gtkmm.

В документации gtkmm обычно есть несколько конкретных примеров, таких как Gtk :: Application, Gtk :: Builder, Gtk :: StatusIcon и т. Д., Инициализированных с помощьюСтатические методы create (), которые возвращают Glib :: RefPtr.Между тем дочерние виджеты обычно возникают только в стеке.

Это мне не понятно:

• Это из-за использования стека памяти или чего-то еще?В моем коде пока нет RefPtr.Я проверил использование стека с помощью инструмента массива valgrind, пиковое использование было около 100 КБ.Мне кажется, это не слишком мало, но пример сопоставимого размера с RefPtr занимает один и тот же кусок стековой памяти.
• Могу ли я поместить все экземпляры только в стек, как Application myapp, или всегдаиспользовать create (), пока он присутствует?
• Какие преимущества дают указатели в этом случае?

Answer 1

• Это из-за использования стека памяти или чего-то еще?В моем коде пока нет RefPtr.Я проверил использование стека с помощью инструмента массива valgrind, пиковое использование было около 100 КБ.Мне кажется, это не слишком мало, но сопоставимый размер [пример с RefPtr] [1] занимает тот же кусок стековой памяти.

Основная причина в том, что gtkmm является тонкой оболочкой C ++ надБиблиотека Gtk +, написанная на C. Большинство объектов в Gtk + размещаются в куче (например, GtkApplication объект создается с использованием функции gtk_application_new) и подсчитывают ссылки (вручную, используя g_object_ref / g_object_unref функций).Другими словами, эти объекты уже имеют общую семантику указателей, хотя и выраженную в простом C. Из-за этого наиболее целесообразно представлять эти объекты в C ++ как умные указатели - в данном случае Glib :: RefPtr.

• Могу ли я поместить все экземпляры только в стек, как Application myapp, или я всегда должен использовать create (), пока он присутствует?

Нет, потому что Gtk::Application contructorsравны protected, поэтому компилятор не позволяет создавать эти объекты в стеке.

• Какие преимущества дают указатели в этом случае?

Я думаю, что все наоборот.Хранение этих объектов в стеке не даст никаких преимуществ, поскольку объекты Gtk, обернутые объектами gtkmm, по сути являются общими указателями.

Answer 2

Glib::RefPtr - это интеллектуальный указатель с подсчетом ссылок, который предшествует std::shared_ptr и выполняет те же основные функции.Вариант использования для него аналогичен - он позволяет нескольким объектам совместно использовать права собственности на объект, не зная друг о друге напрямую.

В ваших конкретных примерах значок может быть общим, потому что он используется в нескольких местах в пользовательском интерфейсе, и вы не хотите хранить много копий одних и тех же данных изображения, которые могут использовать значительную частьпамяти, если имеется много значков.

Объекты Application и Builder, вероятно, удерживаются несколькими объектами в вашей программе (например, различными объектами окна или диалогового окна), поэтому подсчет ссылок сохраняет каждый из них живымкак один из этих объектов все еще использует его.Это освобождает этих пользователей объекта Application от необходимости знать обо всех других частях программы, которые могут использовать общий объект Application.Когда одно окно завершается с Application, оно уничтожает свой умный указатель на Application.Если это окно было последним владельцем, это также уничтожает объект Application, но в противном случае оно остается в живых для других пользователей - и все это без вашего разрушенного окна, зная об этом, живет ли Application или нет.