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

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #15 : 19.09.2008 23:24:18 »
1. Не использовать C++, разумеется.
2. Для C++ есть только одна ниша: переносимые на несколько платформ (в т.ч. и Windows) проприетарные приложения с использованием GUI.
3. Разумеется, никто не взялся за то, чтобы облегчить жизнь проприетарщикам.
1. Вот те на!
2. Наверное не сильно ошибусь если скажу, что основная часть СПО, включая ядро Linux и большой спектр библиотек, написаны на НЕ интерпретируемых языках (C/C++).
3. Думаю что у проприетарщиков с этим как раз всё в порядке (если они кодят под единственный MFC, например). Напротив, это подкоп под хвалёный Unix-WAY постулат - "для каждой задачи - своё решение". Вот что вышло из-за недосмотра Бьерна Страуструпа! :-))

Переносимые - да, ключевое слово.
Есть цель - писать программы для KDE/Qt4 на C++. Вроде бы и код самих этих продуктов написан на C++. Да и портирован он уже достаточно прилично, причём под GNU/GPL.

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

Если код прятать не надо, то существует целая куча интерпретируемых языков, которые, в сочетании с C в нужных местах, дают удобные в написании (хехе, не будем про удобство C++) и замечательно переносимые программы.
Тогда каковы альтернативы? Есть задача: писать в т.ч. GUI-приложения под KDE/Qt. Исходя из того, что C/C++/Java знаю в совершенстве, но нет практического опыта работы со сторонними  библиотеками и инструментарием.

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

В C/C++ этим заниматься должен программист.
Возвращаясь в русло топика... Какова практика? Как пишется Qt-шный софт, QT-шные либы?
To moan or to solve -- that is the question!

Оффлайн kas

  • Начинающий
  • *
  • Сообщений: 2
Re: C++ garbage collection
« Ответ #16 : 20.09.2008 00:17:28 »
2. Наверное не сильно ошибусь если скажу, что основная часть СПО, включая ядро Linux и большой спектр библиотек, написаны на НЕ интерпретируемых языках (C/C++).

Не мешайте C и C++ в одну кучу.

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #17 : 20.09.2008 00:21:51 »
2. Наверное не сильно ошибусь если скажу, что основная часть СПО, включая ядро Linux и большой спектр библиотек, написаны на НЕ интерпретируемых языках (C/C++).

Не мешайте C и C++ в одну кучу.
Я этого и не делаю. Они оба действительно  НЕ интерпретируемые :-)))
А то, что большая часть кода (не Qt/KDE) пишется под C, я как бы в курсе. ;)
To moan or to solve -- that is the question!

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #18 : 20.09.2008 00:24:39 »
Я этого и не делаю. Они оба действительно  НЕ интерпретируемые :-)))
А то, что большая часть кода (не Qt/KDE) пишется под C, я как бы в курсе. ;)

Разумеется, слова "с C, вставленным в нужные места", вы проигнорировали. Игнорируйте дальше, мешать не буду.
Debian Lenny

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #19 : 20.09.2008 00:32:07 »
Я этого и не делаю. Они оба действительно  НЕ интерпретируемые :-)))
А то, что большая часть кода (не Qt/KDE) пишется под C, я как бы в курсе. ;)
Разумеется, слова "с C, вставленным в нужные места", вы проигнорировали. Игнорируйте дальше, мешать не буду.
Это был ответ не вам. А вас я спросил выше. Повторюсь:

Тогда каковы альтернативы? Есть задача: писать в т.ч. GUI-приложения под KDE/Qt. Исходя из того, что C/C++/Java знаю в совершенстве, но нет практического опыта работы со сторонними  библиотеками и инструментарием.
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
« Ответ #20 : 20.09.2008 02:05:54 »
Тогда каковы альтернативы? Есть задача: писать в т.ч. GUI-приложения под KDE/Qt. Исходя из того, что C/C++/Java знаю в совершенстве, но нет практического опыта работы со сторонними  библиотеками и инструментарием.

Так вам "писать" или "Garbage Collector"?  Если писать на языке, где встроенного GC нет, то пое...ццо придётся изрядно, вне зависимости от того, используется ли "внешний" GC или нет.

На "высокоуровневом ассемблере" вообще лучше лишний раз не писать без лишней необходимости.  Если есть биндинги к нужной либе, лучше пишите на perl/tcl/ruby/python/whatever, где не дадут так просто выстрелить в ногу.
Я использую Сизиф и я бородат.

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #21 : 20.09.2008 02:29:10 »
К сожалению, ничем из перечисленного (perl/tcl/ruby/python/whatever) не владею и чесно говоря не хочу овладевать. Хорошо пишу на C/C++/Java/PHP. Но круг задач может быть довольно большим, а не только KDE/Qt GUI. Следовательно, хочется иметь единый комплекс наработок в целом для Linux.

Конечно, я могу писать код и без GC-парадигмы. Но "чистый C", вероятно, меня не устроит для построения такого комплекса наработок. Юзать его в связке с Java (JNI) ещё куда ни шло. Но хотелось бы всё-таки юзать один инструмент для всех задач, и скорее всего - это C++.

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

1. Какие существуют альтернативы языку C++ для написания GUI-приложений в KDE (Linux/Mac OS X/Windows)?

2. Есть ли примеры C++ кода под KDE, реально использующие GC? Особенно интересует библиотека на C++, использующая GC.

UPD: Нашёл статью по сабжу - тут убедительно восхваляют связку C++/Qt в сравнении с Java/AWT/Swing.
« Последнее редактирование: 20.09.2008 07:22:35 от klark973 »
To moan or to solve -- that is the question!

Оффлайн nbr

  • alt linux team
  • ***
  • Сообщений: 5
Re: C++ garbage collection
« Ответ #22 : 20.09.2008 11:02:01 »

>Конечно, я могу писать код и без GC-парадигмы. Но "чистый C", вероятно, меня не устроит для построения такого комплекса наработок. Юзать его в связке с Java (JNI) >ещё куда ни шло. Но хотелось бы всё-таки юзать один инструмент для всех задач, и скорее всего - это C++.

Именно так и пишут на С++. Следите за lifetime своих обьектов сами. Сами вызывайте _явно_ деструкторы в нужные моменты...
Плюс этого - в детерминированности времени выполнения. А то в самый ответственный по времени момент выполнения программы либо врубится GC, либо не хватит памяти...
А если хотите помучаться с GC -  вот вам для затравки ссылочка
http://freshmeat.net/search/?q=GC+C%2B%2B&section=projects&Go.x=0&Go.y=0

 to dottedmag: cкорость работы хорошо скомпилированного кода обычно на порядки выше скорости исполнения интерпретируемых программ.

Оффлайн dottedmag

  • /usr/sbin/control
  • *******
  • Сообщений: 235
Re: C++ garbage collection
« Ответ #23 : 20.09.2008 11:14:55 »
to dottedmag: cкорость работы хорошо скомпилированного кода обычно на порядки выше скорости исполнения интерпретируемых программ.

(зевая) не учите меня писать софт. И внимательно читайте то, что я пишу.
Debian Lenny

Оффлайн klark973

  • Завсегдатай
  • *
  • Сообщений: 662
  • Неспящий саппорт
Re: C++ garbage collection
« Ответ #24 : 20.09.2008 18:58:13 »
Именно так и пишут на С++. Следите за lifetime своих обьектов сами. Сами вызывайте _явно_ деструкторы в нужные моменты...
Плюс этого - в детерминированности времени выполнения. А то в самый ответственный по времени момент выполнения программы либо врубится GC, либо не хватит памяти...
Да, именно так я и пишу на C.

А если хотите помучаться с GC -  вот вам для затравки ссылочка
http://freshmeat.net/search/?q=GC+C%2B%2B&section=projects&Go.x=0&Go.y=0
Спасибо! Прочитав большое число книг и перерыв весь тырент, окончательно понял, что GC - это блаж, пустая трата времени и ресурсов. Лучше действительно не сорить! :-))) Всякие автоматические указатели - ещё куда ни шло, но если это публичная либа - они никак не должны быть связаны с реализацией диспетчера памяти, ибо последний определяется лишь на этапе сборки всего проекта.

Цитата: И в выше приведённой статье есть такие слова:
Инструментарий Qt использует более эффективный подход для упрощения задачи управления памятью: при удалении объекта все зависящие от него объекты также автоматически удаляются. Подход Qt не мешает программистам по желанию самостоятельно удалять объекты.
Осталось дело за малым: изучить Qt и тряхнуть стариной!... :D

ВСЕМ СПАСИБО ЗА ПОМОЩЬ! СЧИТАЮ, ЧТО ВОПРОС РЕШЁН!!!
To moan or to solve -- that is the question!