Зачем нужны GC, Java, .NET?

> Ну да. Единственное отличие - в том, что T& не принято инициализировать нулём.

И неудивительно - T& нельзя изменить без С-стайл cast'ов, так что смысла нет.

А приводить T* к T& часто нужно, если нужен синтаксис ссылки. Например, при возврате *this или в заковыристых шаблонах. Наоборот тоже бывает нужно, но реже.

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

Почему же тогда C является самым переносимым языком? А недокументированные функции и баги можно и в байткоде использовать. Например, для SQL-injection в веб-приложении.

А если программисты такие «мудрые» что от них защищаться надо, лучше их разогнать. Пусть будут обычными дворниками - больше пользы будет.

>А если программисты такие «мудрые» что от них защищаться надо, лучше их разогнать.

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

Скажем так. Если ты посреди леса и у тебя топор слетает с топорища, а ты им работаешь, то ты конечно молодец. Но если под боком есть целый топор, то ты идиот.

Ручное же управление памятью нужно с таких языках как Си. На них пишутся небольшие критичные ко времени исполнению части программы. Все. Кресты тут не нужны.

>Почему же тогда C является самым переносимым языком?

orly?

> С++ники при написании программ усердно борятся с граблями, которые им подсовывает их же инструмент и не только считают это нормой, но и тем самым причисляют себя некой элите.

Лично я никогда не относил себя к «элите». Какой в этом смысл? Если заранее вешать на всех ярлык идиота, будешь окружен идиотами. Сам лучше от этого не станешь.

«Борьбу с граблями» никто нормой не считает. Но иногда нет другого выхода. Как раз поэтому я не терплю искусственных ограничений managed-сред - когда там встречаешь грабли, их НЕВОЗМОЖНО обойти.

А «чистых» C++ программистов почти нет. Разве только совсем начинающие. Почти все пишут скрипты для сборки и автоматицации рутины, делают прототипы, веб-интерфейсы, внедряют скриптовые языки в свои приложения (а некоторые даже пишут новые). Многим приходится спускаться на уровень ассемблера. А кто имеет дело с железом, тот и осциллографом и паяльником не побрезгует.

Если С++ не подходит для задачи, я возьму другой инструмент. Выбор у меня есть. А у любителей managed-сред его нет. Их спасает только убогость задач, которые им дают. На нетривиальных задачах они собирают грабли месяцами или вовсе сливаются. Поэтому C# и Java остаются уделом enterprise - там всем похуй на качество софта. Он может вообще не работать - бабло распилено, все довольны.

Ручное же управление памятью нужно с таких языках как Си. На них пишутся небольшие критичные ко времени исполнению части программы. Все. Кресты тут не нужны.

В C++ есть разные модели управления памятью, в том числе и GC. Только он мало кому нужен.

> > Почему же тогда C является самым переносимым языком?

orly?

Да, представь себе. За примером далеко ходить не надо - у меня под рукой пять платформ: x86-linux ноутбук, x86-darwin Mac Mini, arm-linux сетевой диск, роутер на mips, и arm-darwin (да-да, йамобилко). На С я могу писать программы для любого из этих устройств. При этом изменения если и будут, то минимальные.

А у Java и C# платформа только одна - JVM и .NET соответственно. В лучшем случае есть реализации ее для 2-3 разных ОС. В худшем - программа привязана к вендо-x86.

Ты лучше расскажи, сколько времени уходит на тонкий тюнинг GC, чтобы приложением можно было пользоваться. Например, подбор опций командной строки типа -Xmx и -Xms,

Сколько памяти может съесть джава? Это не тонкий тюнинг, это определяется исходя из объёмов данных. Чуть более сложные опции мне приходилось подбирать 1 раз, заняло это полдня из которых часа два я читал хелп, если не изменяет память.

ручное дергание GC в нужные моменты (определяются методом проб и ошибок)

Никогда не было нужно.

написание костылей для перезапуска упавшего от segfault'а в GC приложения

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

Утечек быть не должно. Для меня это аксиома. Может быть это не страшно, это и вправду, наверное, самая мягкая ошибка, если утечки небольшие, эксплуататоры просто забьют, если большие - будут перезапускать программу периодически. На функционале это не скажется. Это больше правило хорошего тона, как и не юзание write-only хаков, например. Утечка - неосвобождённая память, которая программе не понадобится до конца работы, если хочется определений. Чаще всего к этой памяти программа не имеет указателей, иногда указатели имеются но реально никогда не используются (тогда утечки будут и в языках с GC).

Да, представь себе. За примером далеко ходить не надо - у меня под рукой пять платформ: x86-linux ноутбук, x86-darwin Mac Mini, arm-linux сетевой диск, роутер на mips, и arm-darwin (да-да, йамобилко). На С я могу писать программы для любого из этих устройств. При этом изменения если и будут, то минимальные.

На какие из этих платформ не портирована Java?

Понимаешь в чем дело. Жабисты при написании программ усердно борятся с граблями, которые им подсовывает их же мусоросборочный инструмент и не только считают это нормой, но и тем самым причисляют себя некой GC-элите. Хотя обход мусоросборочных граблей - это не более чем упорный, нудный, но примитивный труд.

Скажем так. Если ты посреди леса и у тебя топор слетает с топорища, а ты им работаешь, то ты конечно молодец. Но если под боком есть целый топор, то ты идиот.

>На нетривиальных задачах они собирают грабли месяцами или вовсе сливаются.

На нетривиальных задачах(со сложной логикой программы) чтото хуже, чем писать на с++ трудно себе придумать.

В C++ есть разные модели управления памятью, в том числе и GC. Только он мало кому нужен.

Да. В С++ все есть. Все кое как работает с подводными камнями и граблями. Да и так. Скорее для галочки. В том числе и GC. И ФП тоже вроде как есть. Но по понятным причинам им не пользуются. Ибо больше чем на посмотреть оно не тянет аж никак.

Как раз поэтому я не терплю искусственных ограничений managed-сред - когда там встречаешь грабли, их НЕВОЗМОЖНО обойти.

Это тебе так кажется. В С++ просто не получиться построить сколько-то сложную, но не текущую абстрацию.

На С я могу писать программы для любого из этих устройств. При этом изменения если и будут, то минимальные.

Писать ты можешь для любой из платформ. А вот кроссплатформенный код сделать не просто. Посмотри на морцы многих кроссплатформенных прог. Они там так и пестрят ifdef'ами

>Например, для SQL-injection в веб-приложении.

Какое огромное количество всего в веб было взломано. И то, что всё это было написано на языках с GC (PHP Java Ruby и т.п.), не помогло защититься от взлома.

>Понимаешь в чем дело. Жабисты при написании программ усердно борятся с граблями, которые им подсовывает их же мусоросборочный инструме....Но если под боком есть целый топор, то ты идиот.

Пошла уже петросянщина. Какие грабли тебе в принципе может подсунуть GC?

ЭВМ - интструмент. И прежде всего предназначен для того, что-бы переложить побольше работы с человека. И писать код, который не является архикритичным к времени выполнения на низкоуровневых языках (и уж тем более на таком, как с++) - просто глупо.

>На нетривиальных задачах(со сложной логикой программы) чтото хуже, чем писать на с++ трудно себе придумать.

Несчастный Джон Кармак не знает вашего авторитетного мнения и пишет без GC на С и С++. Вы бы ему подсказали что ли, как надо делать большие проекты.

>И писать код, который не является архикритичным к времени выполнения на низкоуровневых языках (и уж тем более на таком, как с++) - просто глупо.

А кто-то заставляет всё писать на С++? Я пишу на С++ там, где нужна производительность, но это не мешает мне писать тупые интерфейсы пользователя на Делфи. На C/С++ я их писать не буду, нах это надо, когда досточно накидать «компонеты» на «форму» и получить готовую программу.

Единственное отличие - в том, что T& не принято инициализировать нулём.

а ещё не принято менять указуемый объект. а ещё не принято выполнять арифметику

у тебя спецефическая альтернатива слову «нельзя», и специфическое понимание слова «единственное»

Несчастный Джон Кармак не знает вашего авторитетного мнения и пишет без GC на С и С++

ты его исходники видел? от C и C++ там мало чего осталось

это не мешает мне писать тупые интерфейсы пользователя на Делфи

а зря. лучше бы Tcl/Tk выучил, в самом деле

А где взять его исходники? Он только квак 3 арена открыл.

Quake 3 Arena только С/С++. Где вы взяли старшие версии? Очень интересно немного поработать с ними.

А где взять его исходники?

http://www.idsoftware.com/business/techdownloads/

можно начинать с первой кваки :)

Там старше квака 3 нет ничего

Там старше квака 3 нет ничего

щито?

ftp://ftp.idsoftware.com/idstuff/source/q1source.zip

В каком кваке вы нашли мало следов С/С++? Квак 3 только С/С++.

Старше имею в виду более позднюю версию типа Quake 4

Как вы определили, что в Quake малдо осталось С/С++? Если он не откруывал ещё 4 версию

ты его исходники видел? от C и C++ там мало чего осталось

Отсюда вывод, что вы видели его исходники Quake 4 и Unreal Tournament, так как квак 3 арена весь на С/С++. Где вы их взяли или просто наврали про малое кол-во С/С++ у него?

> более позднюю версию типа Quake 4

Ты говоришь это так, будто Карамак участвовал в её разработке...

Старше имею в виду более позднюю версию типа Quake 4

в этом треде определённо собрались норкоманы, придающие словам новый смысл

В каком кваке вы нашли мало следов С/С++? Квак 3 только С/С++.

от того, что ты ещё пять раз задашь этот вопрос, ничего не изменится. тебе лень посмотреть исходники?

Если сказано, что там осталось мало С/С++ (quake 4 enemy territory), то значит заявивший или видел это сам или наврал. Если видел, пусть даст ссылочку на исходники.

Я исходники квака 3 видел ещё в 2005 году. Там только С/С++.

удваиваю про норкоманов. прозреваю метамфетамин, или хотя бы бензедрин

Тебе сказано про исходиники Кармака. Кармак - это ку{1,2} + Даикатана. Его связь с ку3 мне не известна.

Слив тебе защитан. Заявил про мало С++, а сам-то и не видел исходников.

>Тебе сказано про исходиники Кармака. Кармак - это ку{1,2} + Даикатана. Его связь с ку3 мне не известна.

Какие зачётные сливы начались.

Педивикию читай. http://en.wikipedia.org/wiki/John_D._Carmack

Doom 4, Rage : Engine programming
Enemy territory: programming
Quake 4: technical director

Quake 3 arena: programming

Двачую норкомана.

December 2, 1999 Quake III Arena id Software Activision programming
December 9, 1997 Quake II id Software Activision programming
June 22, 1996 Quake id Software id Software programming

October 18, 2005 Quake 4 Raven Software Activision technical director

Разницу между «programming» и «technical director» сам нагуглишь, когда отпустит?

чучело, может ты попробуешь читать то, что тебе пишут, а? :) или там, думать иногда, что ли. для разнообразия

хотя, в принципе, с таким подходом можно считать что и Java-программисты пишут на C++ - HotSpot-то на нём написан. делов-то

> На какие из этих платформ не портирована Java?

Полноценные реализации JVM доступны только для x86, и те надо устанавливать отдельно. Википедия утверждает, что есть JVM чуть ли не для AVR контроллеров, но на практике ими никто не пользуется.

Кроме x86, Java есть на старых мобильниках в обрезанном варианте. Годится только на игрушки не сложнее тетриса.

> > На нетривиальных задачах они собирают грабли месяцами или вовсе сливаются.

На нетривиальных задачах(со сложной логикой программы) чтото хуже, чем писать на с++ трудно себе придумать.

Нетривиальная задача - не обязательно сложная логика. Это практически что угодно, выходящее за рамки «веб-морда к SQL базе». Например, патчинг стороннего компонента в runtime или работа с «подглюкивающим» железом.

А для сложной логики язык вообще дело десятое. Я прорабатывал логику на простых прототипах, сделанных на perl, и потом переносил на C++. Когда логика программы понятна, перенести ее на С++ легко.

Полноценные реализации JVM доступны только для x86

Да ну. А я пишу на x86_64 на джаве, запускаю джаву на IBM-овских PowerPC, а они оказывается не полноценно.

и те надо устанавливать отдельно. Википедия утверждает, что есть JVM чуть ли не для AVR контроллеров, но на практике ими никто не пользуется.

Ссылку на утверждение в википедии о том, что ими никто не пользуется, можете привести?

Кроме x86, Java есть на старых мобильниках в обрезанном варианте. Годится только на игрушки не сложнее тетриса.

А на новых мобильниках она в полноценном варианте.

> > Единственное отличие - в том, что T& не принято инициализировать нулём.

а ещё не принято менять указуемый объект. а ещё не принято выполнять арифметику

Менять указуемый объект еще как можно - вызывая не-const функции. Присваивать ссылке новое значение не принято только потому, что синтаксис = для них уже занят, а cast'ы будут громоздкими. Проще завести новую ссылку.

Арифметика по ссылкам выполняется еще как. Например, при вызове функций-членов класса. А явная арифметика для указателей тоже не принята. Единственное исключение - это указатели как частный случай итераторов. Синтаксис T* тут не при чем - это может быть любой random access итератор. Например, в STLport в release итераторы - это указатели, а в debug - классы с перегруженными операторами. А код работы с ними тот же.

> Это больше правило хорошего тона, как и не юзание write-only хаков, например.

Такие правила хороши только в теории. Определение write-only для каждого свое. У dreamweaver-«дизигнеров» и html будет write-only. Для меня, например, синтаксис J - совершенный write-only, но другие как-то читают.

Да и write-only иногда имеет смысл. Когда точно знаешь, что выкинешь код через неделю-другую.

Утечка - неосвобождённая память, которая программе не понадобится до конца работы

В таком варианте определения GC среды текут всегда, пока хватает памяти.

> Да ну. А я пишу на x86_64 на джаве, запускаю джаву на IBM-овских PowerPC, а они оказывается не полноценно.

x86_64 - это такой x86. Только с _64.

Ссылку на утверждение в википедии о том, что ими никто не пользуется, можете привести?

Ага, сейчас. Только подредактирую статью ^__"

Это всего лишь мой личный опыт. Программистов Java на x86 я видел немало, а на AVR и всяческих arm - ни одного. А С/C++ - полно и тех и других. Может android и изменит ситуацию. Хотя там уже есть возможность писать на других языках. Кто станет писать на java если есть хотя бы python?

А что, есть не android современные мобильники с полноценной java? В iphone ее точно нет. В Symbian - только обрезанная.

> > написание костылей для перезапуска упавшего от segfault'а в GC приложения

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

Тот скрипт, что я видел, был намного сложней. Кроме простой проверки на «живость», он проверял, отвечает ли она на запросы, не висит ли в deadlock (были известные баги, но искать их было лень). Плюс регулярный перезапуск раз в день (то ли сама JVM подтекала, то ли программисты нашли-таки способ «утекать» память).

Со стороны мне казалось, что Java-программисты копаются в стэктрейсах и какой-то там отладочной console больше, чем я в С++. И проблемы с синхроницацией у них, и память течет, и в JVM баги.

Да-да, я знаю что у меня неправильные java программисты и они делают неправильные java программы.

x86_64 - это такой x86. Только с _64.

Ну всё-таки общего между ними только режим совместимости, архитектуры разные.

Программистов Java на x86 я видел немало, а на AVR и всяческих arm - ни одного.

Чистый Java код не зависит от архитектуры вообще никак. Поэтому выражение «программист java на x86» почти бессмысленно. В отличие от С, естественно.

Кто станет писать на java если есть хотя бы python?

Ну если скорость нужна, можно и на джаве. Джава отстаёт от С в 1-5 раз, питон, думаю, в 100-500 раз :)

А что, есть не android современные мобильники с полноценной java? В iphone ее точно нет. В Symbian - только обрезанная.

В айфоне её нет из за жёсткой политики эппл. В интернете есть инструкции, как её туда можно водрузить (с взломом, как я понял, сильно не вдавался). В любой открытой платформе (т.е. где пользователь решает что ему использовать, а не производитель) она будет. Какие устройства будут преобладать на рынке, не знаю, думаю что всё же вторые.

В таком варианте определения GC среды текут всегда, пока хватает памяти.

Почему? Освобождение - по сути переиспользование. GC будет переиспользовать память, которая больше не нужна. Т.е. можно считать, что память освобождается тут же, как только теряется последняя ссылка на неё.

Дедлоки, они и в африке дедлоки. Ещё можно вечный цикл сделать, и оно тоже зависнет. JVM вряд ли подтекает. Подтекать будет, если в памяти висят ссылки на объекты, которые реально не нужны. Тут тоже чудес не бывает, угадывать, что программисту больше этот объект не нужен, компьютер не умеет. К платформе, это всё-таки отношения не имеет, это проблемы конкретной программы. Кто у вас неправильный, я не знаю и знать не могу.

>Полноценные реализации JVM доступны только для x86, и те надо устанавливать отдельно. Википедия утверждает, что есть JVM чуть ли не для AVR контроллеров, но на практике ими никто не пользуется.

Это наверное будет для кого-то сюрпризом, но Sun раздает Java SE для ARM, MIPS, PowerPC -> http://java.sun.com/javase/downloads/embedded.jsp

При некорректной работой с JNI тоже можно утечки в памяти получить :) хотя это уже проблема на стороне C.