Здравствуйте, wander, Вы писали:
W>На любом языке. И паскаль, и Си, и всякие W>новомодные Rust`ы могут быть языками, на которых потенциально будут написаны приложения, падающие таким образом.
Да, только в некоторых языках надо сильно постараться, чтобы выстрелить себе в ногу, а в C++ это получается легко, незаметно и непринуждённо. На любом языке можно творить хорошие качественные приложения. Только себестоимость разработки будет разная. А у С++ она заметно выше, чем у некоторых других языков со сравнимыми возможностями. Всё просто: бизнес решает.
Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.
Возможность написать класс "по кусочкам". Т.е. я сначала пишу определение самого класса, без определений его методов. А потом, ниже определяю все его методы. Очень удобно читать код. Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.
То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.
Считаю, что маленькая стандартная библиотека — преимущество. Она может быть реализована на обширнейшем количестве систем. Я бы еще ее подсократил, или расчленил на опциональные компоненты. Например, не везде существуют файлы и потоки ввода/вывода — взять те же микроконтроллеры. В оконных приложениях Windows, потоки cout/cin не имеют смысла. Я бы даже time.h сделал бы опциональным. Если у вас есть обширная стандартная библиотека, она влечет зависимости от наличия фич платформы, которые не везде присутствуют. Хотя опять же, опциональность компонентов библиотеки может спасти ситуацию.
Здравствуйте, jamesq, Вы писали:
J>Мои 5 копеек про достоинства C++ J>Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.
Если не ошибаюсь, J2ME и NetCompact позволяли работать на очень слабых системах. А на совсем слабых возможности c++ точно не нужны (если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит).
J>Возможность написать класс "по кусочкам". Т.е. я сначала пишу определение самого класса, без определений его методов. А потом, ниже определяю все его методы. Очень удобно читать код. Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.
До возможностей современных языков не дотягивает: в C# вы можете нарезать класс на столько partial реализаций, сколько вам будет угодно, при необходимости отдельно реализуя каждый интерфейс в своём partial-классе.
J>То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.
Зато если поменялся .h(pp) файл перекомпилируется пол проекта. В том же C# или Java изменение одного класса влияет исключительно на зависимые от него сборки, и то только в том случае если изменился интерфейс.
J>Считаю, что маленькая стандартная библиотека — преимущество. Она может быть реализована на обширнейшем количестве систем. J>Я бы еще ее подсократил, или расчленил на опциональные компоненты. Например, не везде существуют файлы и потоки ввода/вывода — взять те же микроконтроллеры. В оконных приложениях Windows, потоки cout/cin не имеют смысла. Я бы даже time.h сделал бы опциональным. Если у вас есть обширная стандартная библиотека, она влечет зависимости от наличия фич платформы, которые не везде присутствуют. Хотя опять же, опциональность компонентов библиотеки может спасти ситуацию.
Напоминаю, что CPPшники гордятся тем, что "платишь только за то что используешь" — то есть ширина и глубина стандартной библиотеки не мешает использовать только те функции из неё, которые необходимы. Остальное отрежет линкер.
ЗЫ. Просьба: не используйте список — сайт глючит при цитировании списка (например все мои ответы помечаются как цитаты, даже если сам тег "list" убран), приходится убирать все его теги.
Здравствуйте, Somescout, Вы писали:
S> если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит.
У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года.
Сейчас и в компиляторах и в самом языке есть возможности по устранению оверхеда связанного с генерацией кода по шаблону.
Здравствуйте, Privalov, Вы писали:
P>А первый? Фортран?
Без иронии, Фортран вполне себе был и остается прекрасен кое в чем. Единственной претензией к нему может быть желание писать нечто, выходящее за рамки этого "кое-что". А при том обилии листингов на Фортране в журналах ACM, он останется с нами еще очень надолго.
Здравствуйте, andyp, Вы писали:
A>Без иронии, Фортран вполне себе был и остается прекрасен кое в чем. Единственной претензией к нему может быть желание писать нечто, выходящее за рамки этого "кое-что". А при том обилии листингов на Фортране в журналах ACM, он останется с нами еще очень надолго.
Дак и я без иронии. В свое время я успел черкнуть на нем пару строк. Лучше инструмента, чтобы писать матан, я не знаю.
Здравствуйте, Privalov, Вы писали:
P>Лучше инструмента, чтобы писать матан, я не знаю.
Многие люди, которые эти самые алгоритмы придумывают, тоже считают его вполне достаточным. Да и вычислительные либы живут несколько десятилетий, всё это время в них вылавливают ошибки, так что на существующий момент они на высоком уровне безглючности. Даже с тупым переписыванием на С видимо связываться боятся, хотя наверняка у многих наверняка руки чешутся
Здравствуйте, jamesq, Вы писали:
J>Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.
Туда можно запихать Java Card и Аду. Кстати, запихивание в систему с очень ограниченными ресурсами — это скорее про Си.
J>Возможность написать класс "по кусочкам". ... Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.
Так узнали бы. В яве-то есть интерфейсы, но это ладно, в C# есть вообще partial.
J>То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.
Или не только он. pre-compiled headers не от хорошей жизни появились, макросы до сих пор глобальны, модулей как не было, так и нет.
Здравствуйте, LaptevVV, Вы писали:
LVV>Упаси Господи!
Неожиданная, признаюсь, реакция. А почему?
LVV>Хотя я его сдал досрочно и на отлично.
А я — в срок и на хорошо. Подвел меня вопрос про вычисляемые и назначаемые GOTO. Мы на лабах задачки решали, а не отрабатывали операторы языка. Потому я остался полным теоретиком в этом вопросе. Правда, в реальном коде я эти GOTO видел дважды, может, трижды.
LVV>Первый — это Алгол-68...
Ну и где сейчас тот Алгол? А Фортран — живее всех живых. И переносимость у него такая, что Си не не снилась.
Здравствуйте, andyp, Вы писали:
A>Даже с тупым переписыванием на С видимо связываться боятся, хотя наверняка у многих наверняка руки чешутся
И мы через это прошли. Оказалось гораздо проще и легче сделать переходники от Си к Фортрану и обратно. Единственное, что не заработало — доступ к безымянному COMMON-блоку. Но такого нормальные люди не допускают. Процедура в 5000 строк — сколько угодно, а безымянных COMMON я не видел ни разу.
scf>- бедная стандартная библиотека. Хочется нормальную юникодную строку
std::wstring
scf>с поддержкой кодировок,
std::codecvt&co
scf>регулярок
std::regex&co
scf>и богатого набора операций. http://memesmix.net/media/created/8hjlm0.jpg
scf>Хочется качественные многопоточные коллекции.
Берем обычный качественный set, оборачиваем операции с ним mutex-ом и получаем качественный многопоточный set. Ну и подсказывают выше что в С++17 оно есть, но я еще это не юзал.
scf>Хочется нормальные функции для работы со временем с поддержкой часовых поясов. и т.д. и т.п.
std::chrono::time_zone
scf>- феерическая сложность языка и сложность написания качественного (устойчивого к утечкам памяти и exception-safe) кода
Решается RAII и умными указателями, правда постоянно приходится объяснять шериданам что они не правы.
scf>- значительно меньшая терпимость программы к ошибкам программиста — где managed язык отделается exception-ом, программу на C++ лучше прибить. Это ограничивает применимость в серверных приложениях
В результата java приложения этими ошибками сыпят. Ну а че — ведь можно же не прибиваться.
scf>- типы ошибок, которых нет в managed языках: порча памяти,
Подавляющее ошибок порча памяти в современном С++ коде (см через пункт выше) происходят изза race condition. И тут java ничем не лучше С++.
scf>утечки памяти
Ну да конечно. А потом удивляются.
scf>- менее развитый тулинг для отладки, логгирования и обнаружения проблем
На вкус и цвет.. Я раньше юзал 100500 логгеров, писал свои, с преферансом и поэтессами, теперь все больше довольствуюсь стандартным выводом.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, wander, Вы писали:
W>Здравствуйте, Somescout, Вы писали:
S>> если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит. W>У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года. W>Сейчас и в компиляторах и в самом языке есть возможности по устранению оверхеда связанного с генерацией кода по шаблону.
Читал я обсуждение подобного в этом же форуме: во-первых фича далеко не 98 года, а весьма недавняя, во-вторых работает не всегда и не везде.
K>Совсем кратко: C++ страдает переусложнизмом.
Это не то что переусложнизм, это черезчур-мультипарадигменность.
В результате когда в С++ приходят люди с других ЯП они сразу начинают писать в той парадигме к которой привыкли.
С-шники хреначат на С-с-классами, кладя болт на исключения, джависты хреначат свои любимые try..catch, удивляясь отсутсвию finally и т.п. Беда С++ в том что он этот зоопарк позволяет.
Как говорится 40% С++ знает почти каждый. Проблема в том что это всегда разные 40%.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Somescout, Вы писали:
S>Читал я обсуждение подобного в этом же форуме: во-первых фича далеко не 98 года, а весьма недавняя, во-вторых работает не всегда и не везде.
Я разве говорил, что фича 98 года? Какой вы странный ей-богу.
Что за привычка выкидывать из фразы 10 важных слов, и отвечать только на те, которые удобно?
Еще раз (последний): в 98 году (или около того) действительно было множество проблем с шаблонами,
можно было ненароком сильно раздуть бинарник.
Всякие VC++6, GCC 2.95 и т.п. У нас до сих пор есть legacy проекты, где используются эти компиляторы и видно насколько они отличаются
от современных и по качеству генерации кода в общем и по работе с шаблонами в частности.
А что касается именно фичи, то да, она появилась только в С++11. Но это уже было 8 лет назад, прошу заметить.
Но я писал не только про эту фичу, если внимательно прочитать, а в целом про поддержку шаблонов компиляторами и, что немаловажно, линковщиками.
Поэтому сейчас, если не заниматься чем-то монструозным на шаблонах, вроде Boost.Spirit, т.е. обычному программисту, весьма трудно будет
заставить инструментарий строить раздутый код.
Здравствуйте, wander, Вы писали:
S>>Читал я обсуждение подобного в этом же форуме: во-первых фича далеко не 98 года, а весьма недавняя, во-вторых работает не всегда и не везде.
W>Я разве говорил, что фича 98 года?
Да, ваше сообщение вполне однозначно: "У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года".
W>Какой вы странный ей-богу.
Я действительно жалею что на сайте нет игнор листа.
Здравствуйте, netch80, Вы писали:
N>Всё сказанное выше — результат исторического развития методом "каждый раз шаг, полностью логичный из предыдущего состояния, но в новом направлении".
Все вышесказанное верно, но тут есть интересный момент, про который часто забывают говоря о C++ – санитарайзеры. Я наугад взял два примера из приведенных тобой и собрал следующим образом:
test> ./a.out
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==2982==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0001078c7ef1 bp 0x7ffee83389a0 sp 0x7ffee8338980 T298609)
==2982==The signal is caused by a READ memory access.
==2982==Hint: address points to the zero page.
#0 0x1078c7ef0 in main (a.out:x86_64+0x100000ef0)
==2982==Register values:
rax = 0x0000000000000000 rbx = 0x0000000000000000 rcx = 0x0000000000000000 rdx = 0x00007ffee83389d0
rdi = 0x0000000000000001 rsi = 0x00007ffee83389c0 rbp = 0x00007ffee83389a0 rsp = 0x00007ffee8338980
r8 = 0x0000000000000000 r9 = 0xffffffff00000000 r10 = 0x00007fff9828f0c8 r11 = 0x00007fff9828f0d0
r12 = 0x0000000000000000 r13 = 0x0000000000000000 r14 = 0x0000000000000000 r15 = 0x0000000000000000
UndefinedBehaviorSanitizer can not provide additional info.
==2982==ABORTING
Так что с одной стороны проблемы есть, наследие тяжелое, грабли тщательно прикрыты листьями и т.д. С другой стороны, знать наизусть про то, где и как разложены грабли не надо, надо писать юнит-тесты и гонять их под всеми имеющимися санитайзерами и в общем случае проблемы не будет, ну или она будет сопоставима по сложности с проблемами в управляемых языках.
Здравствуйте, kaa.python, Вы писали:
KP>Все вышесказанное верно, но тут есть интересный момент, про который часто забывают говоря о C++ – санитарайзеры. Я наугад взял два примера из приведенных тобой и собрал следующим образом:
Так это примеры. Они намеренно очевидны, и санитайзеры опознают их ситуации. Я же говорю, что для подавляющего большинства кода нужен не какой-то санитайзер особый, а просто постоянно действующий контроль и более очевидные правила. Например, с тем же переполнением — если санитайзер не заподозрил проблему, то он допустит сложение со скрытым переполнением, а по-нормальному должен проверить и сигнализировать ошибку.
Причём он должен давать не тяжёлый вылет (типичный санитайзер генерирует недопустимую процессорную инструкцию), а нормальное исключение или его выбранный аналог (например, установку переменной — флага ошибки).
И эти санитайзеры пока что есть ой далеко не везде, никакой стандарт их не требует. (Неудивительно.)
KP>Так что с одной стороны проблемы есть, наследие тяжелое, грабли тщательно прикрыты листьями и т.д. С другой стороны, знать наизусть про то, где и как разложены грабли не надо, надо писать юнит-тесты и гонять их под всеми имеющимися санитайзерами и в общем случае проблемы не будет, ну или она будет сопоставима по сложности с проблемами в управляемых языках.
Нет, совсем как в управляемых — ты не добьёшься.
То, что санитайзеры, если доступны, должны входить в базовый набор инструментов — да, согласен.
Но это как те assert'ы, которые в релизном варианте не включаются. В 70-х, может, такой подход был и нормален. Сейчас — нет, нормально это когда 95% таких ассертов всё равно оставлены, а убраны только там, где критично по скорости.
