Да фигня это все. Нормальные люди ограничиваются неким разумным подмножеством языка и на нем пишут. Большой плюс сиплюсплюса в том, что решение о разумном подмножестве принимает сам программист в отличие от провидцев-творцов других языков.
Это верно, но лишь до определённой степени. Вменяемый программист напишет вменяемый код на любом языке. Пижонистый мудак в С++ может наворотить такого... В жабке у него простору всё же поменьше. В шарпе тоже, вроде, даже несмотря на то, что там своих мудацких наворотов достаточно. Плюс отсутствие reflection - действительно серьёзный минус. Иногда бывает такое ощушение, что хочешь что-то сказать - а не можешь :)
А что, лично вам мало, что не получилось вернуть временный объект из функции, обернув его смарт-поинтером? Не впечатлила разве НЕОБХОДИМОСТЬ вводить вспомогательный класс чтобы лишь разрулить использование временного неконстантного объекта - трюк, который, пожалуй, изобрётёт лишь эксперт С++, и далеко не каждый приличный программист С++ поймёт, не лазая по справочникам?
Да нет, это очень слабо. В силу того, что автор уперся в идею показать, что C++ - это плохо, и даже не думает о том, чтобы сказать - а что же, собственно, надо сделать, чтобы было хорошо.
Т.е. много умного сказано - но сильно перемешано с глупостями, и разгребать... ну, с учетом того, что практически все умное, что мне попалось, я и так знаю - нет смысла.
Ну, к примеру, претензия "No run time encapsulation" - это всего лишь непонимание того факта, _почему_ ее нет. То же относится к "No reflection". И то, и другое - не минусы языка, а его особенности, которые надо учитывать. Которые создают некоторые неудобства (про них написано), но дают и преимущества (попробуйте написать какую-либо обработку изображения, обеспечив тот самый encapsulation - вы очень быстро поймете, что это _тормозит_).
Или вот пиздеж про "C++ doesn't have garbage collection, since that, folks, is inefficient". Такую хуйню сморозить - уметь надо. Во первых, garbage collection не обязана быть частью языка, и пользоваться ей в C++ никто не мешает. Во вторых, в изрядной части случаев как раз использование gc ведет к неэффективности.
А вот для сравнения претензия "Very complicated type system" (на примере типов из STL) мне очень близка и понятна. Но как раз это - вкусовщина, кто-то стерпит (хотя я с нетерпением жду введения в стандарт возможностей вроде auto типа переменных).
Короче, надо понимать, что и как устроено в C++. Да, он далек от совершенства, но вполне себе язык.
Кстати, что еще раздражает. Автор пишет, что что-то плохо - но не предлагает лучшего решения. И даже не думает, что будет, если изменить то, что ему не нравится. Неконструктивная критика...
претензия "No run time encapsulation" - это всего лишь непонимание того факта, _почему_ ее нет. То же относится к "No reflection".
да понимает, он, понимает. пишет же что C++ — unmanaged, что позволяет втискивать программы в маленькую память и оптимизировать всякую низкоуровневую хрень. для "general-purpose" языка отсутствие рефлексии непростительно.
обработку изображений и прочий mp3-декодинг недаром в последнее время программируют даже не на C, а на Верилоге. и в силиконовые чипы суют.
garbage collection не обязана быть частью языка, и пользоваться ей в C++ никто не мешает.
спасибо, посмеялся. это примерно как заявить, что exception handling можно игнорировать, никто типа не мешает.
в изрядной части случаев как раз использование gc ведет к неэффективности.
посмеялся ещё раз, причём несколько громче.
но вполне себе язык.
Интеркал — тоже вот вполне себе язык.
Неконструктивная критика
вот это, кстати, интересная фигня. этой фразой обычно начинаются фасцинирующие беседы следущего вида:
- то есть как не предлагают лучшего решения, да вы блин вот сюда посмотрите и вот тут почитайте - но позвольте, это же совсем не C++! - ну да, не C++ - ну и кто будет этим пользоваться? (вариант: никто не будет этим пользоваться, потому что есть C++)
На самом деле давайте упростим спор. На каком языке вы предпочитаете писать? Могу на выбор или раскритиковать его (для случая, когда хотя бы мало-мальски сносно его знаю) или послать туда, где раскритикуют обоснованно.
Хотя на самом деле суть бОльшей части критики будет в том, что подберут условия, для которых он не подходит, и покажут, что не подходит. Сравнив со своим любимым языком, который подходит. Потом вы подберете подходящие условия для своего языка (и неподходящие для чужого), и так далее.
P.S. Меня самого C++ во многом не устраивает. Но с альтернативами для моих задач пока не густо: я вынужден не то что держаться за конкретный язык - держаться за конкретный компилятор/среду и с ощутимым трудом мигрировать с одной версии на другую.
да неочем спорить, собственно. для меня обсуждаемый текст ценен своим форматом и презентацией: это удобное место тыкать людей носом. написано, опять же, живенько.
Написано живенько, но тыкать носом не советую: если попадется человек, который пишет на C++ и тот его пока не достал - будет holy war. А если человек, которого достал - то он в рамках своих задач недостатки и сам знает, ему будет просто неинтересно. Ну а уж человеку, который не пишет на C++, это и знать не надо.
А вообще, конечно, любой подход типа "xxx sux, yyy rulez" ведет к такой аргументации. Пойдите, пообщайтесь с фанатами Haskell - они вам так обругают C++ (и все прочие императивные языки заодно), что закачаетесь. И ведь обоснуют не хуже (а то и лучше), чем автор FQA. Или поищите старые споры "C vs Pascal".
Гы, скажите тем, кто годами спорил =). И если это один и тот же язык - то где, блин, мой любимый оператор with? Почему я вынужден писать гребаные конструкции типа срань* p=моя_великая срань; p->call1(); p->call2();
Классное чтение. Я-то, тёмныё джавщик, как залезу в си, так начинаю спрашивать - а где это, а где это? А нэту. В перле есть, а в си нету. И вот наши интервьюёры тож - когда послушаешь их, какие они вопросы задают про стековые переменные - уши вянут. Это как 20 лет назад всех доставали битами в байтах, типа ну как ну как мы инвертируем биты с помощью арифметики, и т.д. Кого это трахает? Не хватало ещё про задержки на триггерах начать спрашивать.
С половиной можно согласиться, а другая половина - вся "ах, C++ unmanaged, а я так люблю managed!" Ну и люби свой свиной хрящик, и не лезь в наши арбузы. Не приходилось, видать, ему ни разу писать коммерческие программы, у которых не увеличивается вдвое потребность в памяти при переходе с 32-битной на 64-битную платформу, так и пусть молчит в тряпочку.
а насколько я могу судить, этот человек очень долго писал практически исключительно на С++.
> Не приходилось, видать, ему ни разу писать коммерческие программы, у которых не увеличивается вдвое потребность в памяти при переходе с 32-битной на 64-битную платформу
А где такие суровые требования к 64-битной платформе? В embedded? :-)
этот человек очень долго писал практически исключительно на С++.
Верю, но на чем именно он писал - не главное. Главное - что именно он писал.
А где такие суровые требования к 64-битной платформе?
Там, где размеры задач становятся больше 4 Гб, и где переход на 64-битную платформу не должен вызывать ухудшения производительности в связи с возросшей вдвое нагрузкой на кэш.
Не приходилось, видать, ему ни разу писать коммерческие программы, у которых не увеличивается вдвое потребность в памяти при переходе с 32-битной на 64-битную платформу
мне приходилось. клиенты переходили на 64 бита, поскольку их большущим симуляциям на 32 битах элементарно переставало хватать адресного пространства. то что при этом расход памяти увеличивался в 1.5 раза (не в два, int типа всё равно 32 бита), не трогало решительным образом никого. (движок был managed, ага).
конечно, но причём тут C++? это единственный язык, позволяющий не пользоваться пойнтерами (или pointer-sized объектами) без необходимости? или, может быть, managed runtime есть автоматически loss of memory layout control?
оба эти утверждения неверны; видимо, Вы имели в виду что-то иное?
N лет назад это был единственный язык, обладающий набором свойств, пригодных для создания коммерческих программных продуктов с приемлемым для рынка соотношением цена/производительность труда, позволяющий не пользоваться пойнтерами (или pointer-sized объектами) без необходимости. Если не забывать о том, что продолжительность жизни программных продуктов иногда заметно отличается от нуля, то это становится существенно.
managed runtime есть автоматически loss of memory layout control
Наверное, нет. Но и не автоматическое приобретение контроля на желаемом уровне.
N лет назад это был единственный язык, обладающий набором свойств, пригодных для создания коммерческих программных продуктов с приемлемым для рынка соотношением цена/производительность труда, позволяющий не пользоваться пойнтерами (или pointer-sized объектами) без необходимости.
сложно спорить со словами "приемлемым для рынка соотношением цена/производительность труда", да и просить привести примерное значение числа N как-то скучно, так что не вижу смысла в дальнейшем обсуждении. :)
Ну вот и договорились. Надо было заранее договориться, о чем мы спорим: о том, на каком языке начинать писать новый проект, где спору, в сущности, нет - ибо сегодня кидаться с нуля делать это на любом unmanaged языке было бы ярчайшим примером premature optimization; или о том, что делать с существующим корпусом кода на C++ - на этот вопрос автор ответа не дает и не может.
А гадостей про C++ я и сам мог бы порассказать, только неконструктивно это.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2007-10-24 01:36 am (UTC)no subject
Date: 2007-10-24 01:41 am (UTC)Вменяемый программист напишет вменяемый код на любом языке.
Пижонистый мудак в С++ может наворотить такого...
В жабке у него простору всё же поменьше. В шарпе тоже, вроде, даже несмотря на то, что там своих мудацких наворотов достаточно.
Плюс отсутствие reflection - действительно серьёзный минус. Иногда бывает такое ощушение, что хочешь что-то сказать - а не можешь :)
no subject
Date: 2007-10-24 01:37 am (UTC)no subject
Date: 2007-10-24 02:10 am (UTC)no subject
Date: 2007-10-24 05:57 pm (UTC)А что, лично вам мало, что не получилось вернуть временный объект из функции, обернув его смарт-поинтером? Не впечатлила разве НЕОБХОДИМОСТЬ вводить вспомогательный класс чтобы лишь разрулить использование временного неконстантного объекта - трюк, который, пожалуй, изобрётёт лишь эксперт С++, и далеко не каждый приличный программист С++ поймёт, не лазая по справочникам?
Дык, позвольте напомнить: http://dr-tambowsky.livejournal.com/39813.html#t110981
no subject
Date: 2007-10-24 07:19 am (UTC)Т.е. много умного сказано - но сильно перемешано с глупостями, и разгребать... ну, с учетом того, что практически все умное, что мне попалось, я и так знаю - нет смысла.
no subject
Date: 2007-10-24 11:37 am (UTC)можно пример?
(только действительной глупости, а не скучного непопадания в Ваш вкус).
no subject
Date: 2007-10-24 12:09 pm (UTC)Или вот пиздеж про "C++ doesn't have garbage collection, since that, folks, is inefficient". Такую хуйню сморозить - уметь надо. Во первых, garbage collection не обязана быть частью языка, и пользоваться ей в C++ никто не мешает. Во вторых, в изрядной части случаев как раз использование gc ведет к неэффективности.
А вот для сравнения претензия "Very complicated type system" (на примере типов из STL) мне очень близка и понятна. Но как раз это - вкусовщина, кто-то стерпит (хотя я с нетерпением жду введения в стандарт возможностей вроде auto типа переменных).
Короче, надо понимать, что и как устроено в C++. Да, он далек от совершенства, но вполне себе язык.
Кстати, что еще раздражает. Автор пишет, что что-то плохо - но не предлагает лучшего решения. И даже не думает, что будет, если изменить то, что ему не нравится. Неконструктивная критика...
no subject
Date: 2007-10-24 12:24 pm (UTC)да понимает, он, понимает.
пишет же что C++ — unmanaged, что позволяет втискивать программы в маленькую память и оптимизировать всякую низкоуровневую хрень.
для "general-purpose" языка отсутствие рефлексии непростительно.
обработку изображений и прочий mp3-декодинг недаром в последнее время программируют даже не на C, а на Верилоге. и в силиконовые чипы суют.
спасибо, посмеялся. это примерно как заявить, что exception handling можно игнорировать, никто типа не мешает.
посмеялся ещё раз, причём несколько громче.
Интеркал — тоже вот вполне себе язык.
вот это, кстати, интересная фигня. этой фразой обычно начинаются фасцинирующие беседы следущего вида:
- то есть как не предлагают лучшего решения, да вы блин вот сюда посмотрите и вот тут почитайте
- но позвольте, это же совсем не C++!
- ну да, не C++
- ну и кто будет этим пользоваться? (вариант: никто не будет этим пользоваться, потому что есть C++)
no subject
Date: 2007-10-24 12:30 pm (UTC)Хотя на самом деле суть бОльшей части критики будет в том, что подберут условия, для которых он не подходит, и покажут, что не подходит. Сравнив со своим любимым языком, который подходит. Потом вы подберете подходящие условия для своего языка (и неподходящие для чужого), и так далее.
P.S. Меня самого C++ во многом не устраивает. Но с альтернативами для моих задач пока не густо: я вынужден не то что держаться за конкретный язык - держаться за конкретный компилятор/среду и с ощутимым трудом мигрировать с одной версии на другую.
no subject
Date: 2007-10-24 12:44 pm (UTC)для меня обсуждаемый текст ценен своим форматом и презентацией: это удобное место тыкать людей носом.
написано, опять же, живенько.
no subject
Date: 2007-10-24 01:00 pm (UTC)no subject
Date: 2007-10-24 12:16 pm (UTC)И ведь обоснуют не хуже (а то и лучше), чем автор FQA.
Или поищите старые споры "C vs Pascal".
no subject
Date: 2007-10-24 12:25 pm (UTC)C и Pascal — это, в обчем-то, один и тот же язык.
no subject
Date: 2007-10-24 12:32 pm (UTC)И если это один и тот же язык - то где, блин, мой любимый оператор with? Почему я вынужден писать гребаные конструкции типа
срань* p=моя_великая срань;
p->call1();
p->call2();
А? ;-)
no subject
Date: 2007-10-24 03:15 pm (UTC)no subject
Date: 2007-10-24 08:28 pm (UTC)Смотря кого. Кое-кто на этих задержках деньги делает.
no subject
Date: 2007-10-24 08:31 pm (UTC)no subject
Date: 2007-10-24 08:58 pm (UTC)> Не приходилось, видать, ему ни разу писать коммерческие программы, у которых не увеличивается вдвое потребность в памяти при переходе с 32-битной на 64-битную платформу
А где такие суровые требования к 64-битной платформе? В embedded? :-)
no subject
Date: 2007-10-24 09:09 pm (UTC)Верю, но на чем именно он писал - не главное. Главное - что именно он писал.
А где такие суровые требования к 64-битной платформе?
Там, где размеры задач становятся больше 4 Гб, и где переход на 64-битную платформу не должен вызывать ухудшения производительности в связи с возросшей вдвое нагрузкой на кэш.
no subject
Date: 2007-10-24 09:06 pm (UTC)мне приходилось. клиенты переходили на 64 бита, поскольку их большущим симуляциям на 32 битах элементарно переставало хватать адресного пространства. то что при этом расход памяти увеличивался в 1.5 раза (не в два, int типа всё равно 32 бита), не трогало решительным образом никого.
(движок был managed, ага).
no subject
Date: 2007-10-24 09:11 pm (UTC)no subject
Date: 2007-10-24 09:18 pm (UTC)конечно, но причём тут C++?
это единственный язык, позволяющий не пользоваться пойнтерами (или pointer-sized объектами) без необходимости?
или, может быть, managed runtime есть автоматически loss of memory layout control?
оба эти утверждения неверны; видимо, Вы имели в виду что-то иное?
no subject
Date: 2007-10-24 09:40 pm (UTC)managed runtime есть автоматически loss of memory layout control
Наверное, нет. Но и не автоматическое приобретение контроля на желаемом уровне.
no subject
Date: 2007-10-24 09:47 pm (UTC)сложно спорить со словами "приемлемым для рынка соотношением цена/производительность труда", да и просить привести примерное значение числа N как-то скучно, так что не вижу смысла в дальнейшем обсуждении. :)
no subject
Date: 2007-10-24 10:01 pm (UTC)А гадостей про C++ я и сам мог бы порассказать, только неконструктивно это.
(N ~= 10)