Автор Тема: C++ garbage collection [РЕШЕНО]  (Прочитано 14109 раз)

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
C++ garbage collection [РЕШЕНО]
« : 19.09.2008 19:16:05 »
По автоматической сборке мусора для Linux/C++ проектов такой вопросик: если говорить именно о сборщике мусора, а не о каком-то другом диспетчере памяти, как обстоит дело с написанием библиотек? Именно библиотек, классы которых во всю используют всякие умные и творческие указатели?! :)

Порывшись в источниках, нашёл, что вопрос индивидуально решаем лишь на уровне сборки замкнутого приложения, но никак не на уровне библиотек от разных вендоров. Т.е. мне показалось, что немогу я вот так просто использовать SP<MyType> в коде библиотечного класса, если единый стандарт на это нигде не определён. Также не нашёл, чтобы в скомпилированной мной среде широко использовались готовые решения типа boost, boehm-gc, etc...

И верно ли я сделал выводы из всего вышеперечисленного: GC - блаж. В Linux/C++ в большинстве случаев используются диспетчеры памяти без каких-либо стратегий отложенной сборки мусора? Отдельный вопрос: как обстоит с этим дело при написании Qt-программ?

Почему спрашиваю: хочу заняться разработкой ПО под Linux, в частности под Qt. А здесь к тому же пахнет знающими разработчиками. :-))) Но если ошибся адресом, не пинайте больно!.. ;)
« Последнее редактирование: 25.09.2008 01:52:43 от klark973 »
To moan or to solve -- that is the question!

Оффлайн raorn

  • alt linux team
  • ***
  • Сообщений: 42
  • I'm not fat, I'm big boned!
Re: C++ garbage collection
« Ответ #1 : 19.09.2008 20:10:55 »
Чисто не там, где убирают, а там, где не сорят.  GC это костыль для любителей "пихнуть в этот reference ссылу на другой об'ект".  В более других языках (Java, Ruby, Perl) используются только ссылки, и убить такой "dangling" об'ект средствами языка нельзя.  Там GC реализован "внутре" и он один.  В C/C++ каждый выкручивается как умеет.

$ ruby -e 'foo = "foo"; bar = foo; bar.gsub! /foo/, "bar"; p foo'
"bar"
Я использую Сизиф и я бородат.

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #2 : 19.09.2008 20:38:23 »
В C/C++ каждый выкручивается как умеет.
К сожалению, слышу не впервые... :(
С точки зрения замкнутого приложения - не вижу в этом проблем.
А как же быть с написанием библиотек? :o
Ведь ни одно нормальное приложение без этого не построишь!
Как стыковать разные C++ библиотеки в Linux-е? Только без парадигмы GC? O_o
To moan or to solve -- that is the question!

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #3 : 19.09.2008 20:44:41 »
Не использовать C++, разумеется. Для C++ есть только одна ниша: переносимые на несколько платформ (в т.ч. и Windows) проприетарные приложения с использованием GUI.

Разумеется, никто не взялся за то, чтобы облегчить жизнь проприетарщикам.
Debian Lenny

Оффлайн DarkHobbit

  • Начинающий
  • *
  • Сообщений: 2
Re: C++ garbage collection
« Ответ #4 : 19.09.2008 20:50:01 »
Для C++ есть только одна ниша: переносимые на несколько платформ (в т.ч. и Windows) проприетарные приложения с использованием GUI.
Почему обязательно "проприетарные"? Не только.
Переносимые - да, ключевое слово.

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #5 : 19.09.2008 20:58:15 »
Почему обязательно "проприетарные"? Не только.
Переносимые - да, ключевое слово.

Потому что единственное разумное применение C++ - это написание большой программы, код которой необходимо спрятать.

Если код прятать не надо, то существует целая куча интерпретируемых языков, которые, в сочетании с C в нужных местах, дают удобные в написании (хехе, не будем про удобство C++) и замечательно переносимые программы.
Debian Lenny

Оффлайн Rider

  • /usr/sbin/control
  • *******
  • Сообщений: 1 136
Re: C++ garbage collection
« Ответ #6 : 19.09.2008 21:08:02 »
думаю, что ты не совсем прав.

Иначе бы у нас GNOME, KDE или XFCE были бы написаны на Python.  Однако почему-то они реализованы на C/C++

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #7 : 19.09.2008 21:10:51 »
думаю, что ты не совсем прав.

Иначе бы у нас GNOME, KDE или XFCE были бы написаны на Python.  Однако почему-то они реализованы на C/C++


GNOME и XFCE построены на GObject, т.е. уже совсем не C, а скорее на чём-то ближе к Objective-C.

KDE на C++ из-за тулкита.
Debian Lenny

Оффлайн Rider

  • /usr/sbin/control
  • *******
  • Сообщений: 1 136
Re: C++ garbage collection
« Ответ #8 : 19.09.2008 21:12:40 »
думаю, что ты не совсем прав.

Иначе бы у нас GNOME, KDE или XFCE были бы написаны на Python.  Однако почему-то они реализованы на C/C++


GNOME и XFCE построены на GObject, т.е. уже совсем не C, а скорее на чём-то ближе к Objective-C.

KDE на C++ из-за тулкита.


Суть в том, что по любому это не интерпретируемый язык...

Т.е. - утверждение что компиляторы только для проприетарщины - неверны в корне.

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #9 : 19.09.2008 21:15:11 »
Суть в том, что по любому это не интерпретируемый язык...

Т.е. - утверждение что компиляторы только для проприетарщины - неверны в корне.

Утверждение в том, что компиляторы необходимы только для проприетарщины. И тогда да, вопрос стоит не "что нам выбрать", а "как с наименьшим уроном для здоровья воспользоваться C++".
Debian Lenny

Оффлайн Rider

  • /usr/sbin/control
  • *******
  • Сообщений: 1 136
Re: C++ garbage collection
« Ответ #10 : 19.09.2008 21:16:46 »
Суть в том, что по любому это не интерпретируемый язык...

Т.е. - утверждение что компиляторы только для проприетарщины - неверны в корне.

Утверждение в том, что компиляторы необходимы только для проприетарщины. И тогда да, вопрос стоит не "что нам выбрать", а "как с наименьшим уроном для здоровья воспользоваться C++".


Именно о том и речь - как с наименьшим уроном для здоровья воспользоваться C++.

Лучше бы по теме человеку подсказали ;) А то сейчас пересадите его на Perl...

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #11 : 19.09.2008 21:21:14 »
Именно о том и речь - как с наименьшим уроном для здоровья воспользоваться C++.

Лучше бы по теме человеку подсказали ;) А то сейчас пересадите его на Perl...

Я пытаюсь объяснить, почему урон такой большой: потому что проблемы разработчиков проприетарщины здесь мало кого волнуют и маловероятно, что ситуация исправится.

P.S.: а перл - это да, лучше бы без этого.
Debian Lenny

Оффлайн Rider

  • /usr/sbin/control
  • *******
  • Сообщений: 1 136
Re: C++ garbage collection
« Ответ #12 : 19.09.2008 21:23:00 »
Именно о том и речь - как с наименьшим уроном для здоровья воспользоваться C++.

Лучше бы по теме человеку подсказали ;) А то сейчас пересадите его на Perl...

Я пытаюсь объяснить, почему урон такой большой: потому что проблемы разработчиков проприетарщины здесь мало кого волнуют и маловероятно, что ситуация исправится.

P.S.: а перл - это да, лучше бы без этого.


Согласен - с проприетарщиной добро пожаловать на www.altlinux.ru в раздел контакты. Не забыть перед этим приготовить кошелёк.

Оффлайн raorn

  • alt linux team
  • ***
  • Сообщений: 42
  • I'm not fat, I'm big boned!
Re: C++ garbage collection
« Ответ #13 : 19.09.2008 21:36:36 »
Иначе бы у нас GNOME, KDE или XFCE были бы написаны на Python.

Половина гномоапплетов написана на PyGTK/PyGNOME.
Я использую Сизиф и я бородат.

Оффлайн raorn

  • alt linux team
  • ***
  • Сообщений: 42
  • I'm not fat, I'm big boned!
Re: C++ garbage collection
« Ответ #14 : 19.09.2008 21:45:18 »
Лучше бы по теме человеку подсказали ;) А то сейчас пересадите его на Perl...

Не поможем.  В языках, где GC встроен, компилятор (интерпретатор, VM) сам следит за ссылками на об'екты и зовёт деструкторы.  В C/C++ этим заниматься должен программист.  Даже если предположить, что 3rd-party библиотека сама по себе не "течёт", всё равно придётся или вызывать деструкторы самому, или регистрировать все "указатели" в GC.
Я использую Сизиф и я бородат.