С++ vs Java

[TechInsightJobs]

наличие большого обьема памяти не освобождает от требований по ее освобождению
у нас в процессе верификации продуктов (кроме запусков с чекерами разными) стоял процесс MTBF - процедура состоит в кручении продукта в течении месяца под типичными нагрузками в разных сценариях
при хороших сценариях - вылазят потери очень хорошо

Народ, это же бред!
Какая нахрен память?
Нажмите Ctrl+Del
и посмотрите, сколько у вас свободно.
У меня из 2Гиг обычно используется 1/5.

Вопрос стоит комплексно:
Сколько будет стоить разработка+сопровождение+модификация ПО.
С++ - это новый уровень абстракции - ЗНАЧИТЕЛЬНО
превосходит по этим показателям С для большинства
платфом и большинства задач.

Голый С используется преимущественно на контроллерах и
игровых консолях.

Каждой корове свое стойло.

Чем дешевле железо, тем больше С++ вытесняет С.
И в этом есть сермяжная правда.

[homo ludens]

2 Pal

О примере - memory leak таки да есть. Все таки скоростное написание кода прямо в форум дает о себе знать. Как и общая развращенность valgrind'ом
С другой стороны конструкция z<0 использовалась для симуляции нехватки памяти, так что семантически все правильно. В этом блоке вообще проверки не должно быть.

if(rv)
rv->q=z;
return rv ?: 0;

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

Про общие концепции ООП и наш спор, вырождающийся в holywar.
Дело в том что у каждого программиста есть свой набор ценностей. С моей точки зрения проброс данных между уровнями абстракции является абсолютным злом, которое не может быть оправдано никакими благами. С вашей точки зрения

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

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

В результате диалог сводится к переброске замечаниями - а мне так удобнее, и в пределе неизбежно сводится к холивору. Имхо единственный способ выйти из этого цикла - набрать некоторое количество объективных критериев, с которыми согласны оба и проверить на этих критериях обе концепции.

2 Lexar
хотел написать про MTBF но TechInsightJobs меня опередил. На стресс тестах в разных сценариях такие вещи лезут из всех щелей.

2 TechInsightJobs

при использовании longjumpa нужно смотреть за уже распределенной памятью, распределенными ресурсами
а при определенном размере продукта - это просто ужос

при кидании исключения - и язык, и вспомогательные конструкции значительно упрощают и локализуют эту задачу

Абсолютно с Вами согласен и longjmp - это заплатка, которая помогает жить не чаще, чем мешает.

Но, у каждой абстракции есть дыры. Исключение реально помогает жить, если им не злоупотреблять. И если использовать только автоматические переменные. Либо скрывая динамическую память в автоматических переменных. Опять таки это тоже возможно, но мы уже получили вариант, при котором exception работает тогда и только тогда, если программист выполняет определенные требования по дисциплине программирования. А он их часто выполняет в реальной жизни?
Кроме того есть варианты, когда скобки создать/удалить не работают и требуется именно динамическая переменная. Простейший пример - очередь, в которую пихает созданные им объекты один поток, а вытаскивает и удаляет - другой. И как их очищать через исключение?
Следовательно исключение не решает проблему, а решает ее в большинстве относительно простых и распространенных случаев, а не всегда и только при определенной дисциплине программирования. Т.е. мы вводим новую концепцию для удобства а не для расширения функциональности. С моей точки зрения - это путь приятный, но порочный.
И очевидно единственным обоснованием введения такой фичи должно быть математическое доказательство, что лучше сделать принципиально невозможно. Плюс глубокая внутренняя убежденность в правильности.
Второго в С++ обычно хватает, в отличие от первого.

PS
Дейкстра писал, что создание микропроцессора отбросило программирование на 25 лет назад. Мало кто был согласен с этой мыслью тогда, еще меньше сейчас. Вряд ли это высказывание сегодня актуально, но тем не менее достаточно написать пару рабочих программ на ассемблере PDP или VAX 25-летней давности а потом пересесть на ассемблер современного Intel чтобы понять, что он не был совсем уж не прав. Мне это почему-то напоминает ситуацию с ООП.

[homo ludens]

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

2 All
Похоже пора переносить в новый топик - C vs C++
Переносим?

[TechInsightJobs]

как по мне сравнивать удобство механизма longjump и автоматическое свертывание стека при эксепшинах - слегка извращение

2 Pal
Но, у каждой абстракции есть дыры. Исключение реально помогает жить, если им не злоупотреблять. И если использовать только автоматические переменные. Либо скрывая динамическую память в автоматических переменных. Опять таки это тоже возможно, но мы уже получили вариант, при котором exception работает тогда и только тогда, если программист выполняет определенные требования по дисциплине программирования. А он их часто выполняет в реальной жизни?
Кроме того есть варианты, когда скобки создать/удалить не работают и требуется именно динамическая переменная. Простейший пример - очередь, в которую пихает созданные им объекты один поток, а вытаскивает и удаляет - другой. И как их очищать через исключение?
Следовательно исключение не решает проблему, а решает ее в большинстве относительно простых и распространенных случаев, а не всегда и только при определенной дисциплине программирования. Т.е. мы вводим новую концепцию для удобства а не для расширения функциональности. С моей точки зрения - это путь приятный, но порочный.
И очевидно единственным обоснованием введения такой фичи должно быть математическое доказательство, что лучше сделать принципиально невозможно. Плюс глубокая внутренняя убежденность в правильности.
Второго в С++ обычно хватает, в отличие от первого.

PS
Дейкстра писал, что создание микропроцессора отбросило программирование на 25 лет назад. Мало кто был согласен с этой мыслью тогда, еще меньше сейчас. Вряд ли это высказывание сегодня актуально, но тем не менее достаточно написать пару рабочих программ на ассемблере PDP или VAX 25-летней давности а потом пересесть на ассемблер современного Intel чтобы понять, что он не был совсем уж не прав. Мне это почему-то напоминает ситуацию с ООП.

[THRESHE]

2 All
Похоже пора переносить в новый топик - C vs C++
Переносим?

Так как у явистов нехватило сил спорить с сишниками и они отпали сишники решили устроить спор между собой

[pal]

С другой стороны конструкция z<0 использовалась для симуляции нехватки памяти, так что семантически все правильно. В этом блоке вообще проверки не должно быть.

if(rv)
rv->q=z;
return rv ?: 0;

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

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

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

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

я все никак не пойму, что такого с++ делает не на этапе компиляции

С вашей точки зрения, лапша макросов в коде - вещь намного худшая, ибо она неудобна.

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

мы уже получили вариант, при котором exception работает тогда и только тогда, если программист выполняет определенные требования по дисциплине программирования.

конечно, писать программы за программиста никто не будет. однако, с исключениями требования крайне просты: используйте raii по максимуму, и только в крайних случаях защищайтесь try/catch. крайних случаев крайне мало

Простейший пример - очередь, в которую пихает созданные им объекты один поток, а вытаскивает и удаляет - другой. И как их очищать через исключение?

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

Т.е. мы вводим новую концепцию для удобства а не для расширения функциональности. С моей точки зрения - это путь приятный, но порочный.

правильно ли я понимаю, что функциональность шире, чем у ассемблера, невозможна ?

[pal]

проще переименовать топик в с++ против всех

[homo ludens]

перебираемся в новый топик.
C++ haters handbook.
(по аналогии с известной книжкой).

[napTu3aH]

THRESHE,
а явисты в это время просто работают ...
А вы, таки да, можете спорить дальше ... удачи

[THRESHE]

THRESHE,
а явисты в это время просто работают ...
А вы, таки да, можете спорить дальше ... удачи

А мы Сишники бездельники вот и флудим

[homo ludens]

явисты не работают, они зарабатывают. Чем и объясняется их прагматичность.

[Fireball]

Предлагаю каждому написать свою систему приоритетов, после неё в том же посте - HOWTO по достижению при написании ПО наилучшего приближения к этой системе.
А то что на примерах, что и без примеров не особо информативно получается Точнее интересно, но запутанно.

[balazaur]

Блог на эту тему
Why choose Java

[x[82]]

Блог на эту тему
Why choose Java

Прочитал слева в "Get Informed" строку "About java.net" - вздрогнул