Здравствуйте, gandjustas, Вы писали:
G>Так вот пока одногруппники писали на первую лабу на Языке Языков я сделал все лабы семестра на C#, да еще и визуализацию прикрутил.
Я когда то такое же провернул на TMT Pascal, который в то время умел в 32 бита protected mode + VESA графику
И чо?
Здравствуйте, Тёмчик, Вы писали:
Тё>Изволь не согласиться. Переопределение операторов, конструкторы с передачей владения, деструкторы в исключениях (которые могут вызвать вложенное исключение UB), выделение и освобождение динамической памяти, которое негарантировано по времени из-за фрагментирования, не детектящаяся автоматически порча памяти, затирание стека вызова при неосторожном копировании строки. Как раз управляемая жава более предсказуема.
Ты какие-то страшилки из прошлого века про C++ помнишь. "Переопределение операторов, конструкторы с передачей владения" — это фичи языка которые никто использовать не заставляет; "деструкторы в исключениях" — вообще не помню когда в последний раз такое видел. Сейчас весь код на С++ очень активно подвергается статическому и динамическому анализу, и даже интерн который пишет на плюсах слома чего-то на уровне языка уже не может. А вот сломать на уровне логики можно вообще в любом языке.
Если говорить про фрагментацию памяти, то это так же давно решается через аллокаторы, если код не критичен, или через отказ от динамического аллоцирования как такового для критичного кода.
"Как раз управляемая жава более предсказуема" — да, и ровно до тех пор пока не решила мусор почистить. Как и Go или C#
Здравствуйте, Pzz, Вы писали:
Pzz>В том же Go все в 100500 раз более предсказуемо, по причине того, что абсолютно все действия, которые осуществляет программа, в этом языке эксплицитны, т.е. описываются явно, и никаких автоматизмов, кроме GC, в нем не предусмотрено.
Ага, кроме GC и как следствие есть куча статей о том, как люди героически боролись с непредсказуемостью этого самого GC, в деталях изучали его конфигурацию и даже писали автотюнилку параметров на лету, что бы дохло. Это ну никак не тянет на предсказуемое поведение. А в плюсах ты его реально имеешь, хотя, не могу не признать, писать на Go на порядок проще и в пару раз быстрее чем на C++.
S>Упс. Тогда остается добавить, что для написания программ Си никогда простым языком и не был. Может чтобы выучить его особых трудозатрат и не нужно, а вот чтобы написать на Си что-то нормально работающее и поддающееся сопровождению -- вот тут уже все умножается на N, где N >> M.
У меня в последнее время неоднозначные впечатления от С++ (на современных плюсах пишу только несколько лет, так что возможно я просто пока не дошел до стадии "принятия"). С одной стороны, очень хорошо, что язык развивается, многое в языке упрощается, добавляются средства написания более эффективного кода. Но с другой стороны, вижу, что при решении каких либо проблем языка, часто возникает ситуация когда "лекарство хуже болезни". Из последнего, что меня особенно сильно впечатлило, это достаточно старый доклад про то, как дядьки из libc++ пытались реализовать на плюсах template функцию вычисляющую среднее арифметическое двух чисел. Просто 60 минут боли. И ведь это не "зеленые пионеры" типа меня, а монстры которые десятилетиями на плюсах библиотеки пишут.
Здравствуйте, Максим, Вы писали:
М>У меня в последнее время неоднозначные впечатления от С++ (на современных плюсах пишу только несколько лет, так что возможно я просто пока не дошел до стадии "принятия").
Современный C++ -- это отдельная история. После долгих лет застоя (до появления C++11) язык стал развиваться настолько быстро и стал вбирать в себя столько разных вещей (временами далеко не однозначных), что это повергает в шок даже старых приверженцев языка. А если добавить сюда еще и то, что сама экосистема C++ очень разнообразна, и C++ применяется в ну очень уж разных проектах, и версии C++ везде разные (кто-то может застрять на C++11, кто-то будет использовать фичи из непринятых еще стандартов как только они становятся доступны хотя бы в одном из компиляторов), то картина становится вообще печальная: по сути нет такой штуки, как "язык C++". В каждом конкретном проекте какое-то свое подмножество C++.
M>И ведь это не "зеленые пионеры" типа меня, а монстры которые десятилетиями на плюсах библиотеки пишут.
Написание универсальной повторно-используемой библиотеки, которая предназначена для широкого использования, -- это в C++ на порядок (если не на два) более сложная задача, чем решение какой-то прикладной задачи.
Здравствуйте, Максим, Вы писали:
М>С одной стороны, очень хорошо, что язык развивается, многое в языке упрощается, добавляются средства написания более эффективного кода.
Ну так и пользуйся тем, что тебе жизнь упрощает.
М> Но с другой стороны, вижу, что при решении каких либо проблем языка, часто возникает ситуация когда "лекарство хуже болезни".
Тем что усложняет — не пользуйся
С++ хорош тем, что ты сам можешь выбирать какими его фичами пользоваться. И совершенно не надо пользоваться всеми сразу. Принцип KISS хоть и древний но соблюдение его весьма упрощает жизнь.
М>Из последнего, что меня особенно сильно впечатлило, это достаточно старый доклад про то, как дядьки из libc++ пытались реализовать на плюсах template функцию вычисляющую среднее арифметическое двух чисел. Просто 60 минут боли.
Дык классика же: когда в руках молоток — все проблемы похожи на гвоздь. Дети с длинными бородами получили в руки новый прикольный молоток и айда им по всему радостно стучать.
М> И ведь это не "зеленые пионеры" типа меня, а монстры которые десятилетиями на плюсах библиотеки пишут.
У тех кто только библиотеки пишет а не занимается production code development and support часто наличествует одна из форм профдеформации — она зарываются в написание configurable всемогуторов на все случаи жизни. В итоге выходит франкенмонстр, в котором только чтоб он начал шевелиться надо сделать кучу конфигурационных телодвижений, зато можно пёрнуть ухом.
Здравствуйте, so5team, Вы писали:
S>Современный C++ -- это отдельная история. После долгих лет застоя (до появления C++11) язык стал развиваться настолько быстро и стал вбирать в себя столько разных вещей (временами далеко не однозначных), что это повергает в шок даже старых приверженцев языка.
Этож совершенно не означает что надо кидаться всё это сразу внедрять направо и налево, особенно в работающем коде.
Появляется что то что сильно упрощает код — можно это аккуратно внедрить.
S>кто-то будет использовать фичи из непринятых еще стандартов как только они становятся доступны хотя бы в одном из компиляторов
Это может быть оправдано только если ну ваще никак без них не вытанцовывалось. Иначе это херовый инженер и надобно его дустом тапком приводить в чувство.
Я лично наблюдал вживую старый синдром "укушенных Александреску", когда вся программа пациентом превращалась в гигантский шаблон, где всё параметризовалось всем.
S>по сути нет такой штуки, как "язык C++". В каждом конкретном проекте какое-то свое подмножество C++.
В целом верно.
S>Написание универсальной повторно-используемой библиотеки, которая предназначена для широкого использования
Это зачастую пустая трата времени как своего так и тех, кто будет пытаться этот результат использовать.
Потому как проблема всех универсальных библиотек в том, что они работают одинаково плохо везде, потому как в гонке за универсальностью страдает всё: от производительности до читабельности и удобства использования.
Здравствуйте, CreatorCray, Вы писали:
S>>Современный C++ -- это отдельная история. После долгих лет застоя (до появления C++11) язык стал развиваться настолько быстро и стал вбирать в себя столько разных вещей (временами далеко не однозначных), что это повергает в шок даже старых приверженцев языка. CC>Этож совершенно не означает что надо кидаться всё это сразу внедрять направо и налево, особенно в работающем коде. CC>Появляется что то что сильно упрощает код — можно это аккуратно внедрить.
Именно так. На 100% согласен.
Но есть нюанс. Нужно сперва научиться использовать ту или иную фичу правильно. Для этого нужно набить шишки, чтобы понять, когда эту фичу использовать не следует, или же следует, но не так.
Личный пример: появление в С++11 noexcept. Нужен опыт, чтобы понимать, куда noexcept пихать, а куда не стоит. И нужен навык, чтобы делать это на автомате (почти такой же, как и с const-ами для методов).
Менее суровый пример, но так же из личного опыта: nodiscard. Нужен навык, чтобы ставить его на автомате там, где требуется.
CC>Потому как проблема всех универсальных библиотек в том, что они работают одинаково плохо везде, потому как в гонке за универсальностью страдает всё: от производительности до читабельности и удобства использования.
Времена требуется, чтобы работало сегодня, пусть даже и так себе, чем завтра, но хорошо. В этих случаях собрать что-то быстро на готовых решениях, чтобы затем выиграть время на доведение до ума.
Хотя кому-то повезло работать на проектах, где есть возможность довести до ума сразу.
Здравствуйте, kaa.python, Вы писали:
KP>Ага, кроме GC и как следствие есть куча статей о том, как люди героически боролись с непредсказуемостью этого самого GC, в деталях изучали его конфигурацию и даже писали автотюнилку параметров на лету, что бы дохло. Это ну никак не тянет на предсказуемое поведение. А в плюсах ты его реально имеешь, хотя, не могу не признать, писать на Go на порядок проще и в пару раз быстрее чем на C++.
Ну а что там непредсказуемо, кроме потребления памяти в динамике и времянки?
Go, конечно, не real-time language. Ну так и популярные ОС тоже не real-time. В линухе это несколько менее заметно; венда может уходить в свои собственные размышления на десятки миллисекунд в самое непредсказуемое время. Если занимаешься медиастримингом (я одно време занимался), это может очень заметно влиять на воспроизведение. Сейчас этот эффект отчасти замаскирован тем, что в компьютеры навставляли кучу процессорных ядер, половина из которых всегда свободна, но когда свободные ядра кончатся, будет заметно ничуть не менее.
ИМХО, самая серьезная проблема/особенность C++ — это очень непростая работа с 3rd party libraries и сборкой. Когда тебе надо что-то затянуть в свой продукт — это становится еще тем приключением на несколько дней. Я говорю сейчас о том, чтобы затащить так, чтобы это собиралось под несколько платформ, чтобы было все легально с точки зрения лицензий, и чтобы это все шипилось как продукт (т.е. закинуть нужные файлы и обеспечить запускабельность на чистой машине).
Вот это, по-крайне мере лично для меня — самая большая боль.
Ведь как в других языках... Например, Go, Python, JavaScript — ты просто в ямле/джсоне/конфиге добавил строку libxyz (опционально указав версию), нажал кнопку в ИДЕ "подхватить"/"выкачать" — и все готово — юзаешь свою xyz либу. Изи пизи лемон сквизи.
А как в плюсах. А тут целый зоопарк: один билдят на мейкфайле, другие на симейке, третьи — мезон, MSVC, плюс еще другие есть. И вот впендюрить к себе в симейковый проект чинить из мезона — да это та еще ебан задача. Это прямо боль.
Или даже взять CMake — да он сам по себе иногда сотник строк содержит, и таких файлов могут быть десятки!!!
Да, есть Конан. Я сам его в боевых проектах не юзал, только немного щупал. Там вроде попроще, но тоже сильно нетривиально и писать надо порядочно. И это только обвязка для билда!
Здравствуйте, so5team, Вы писали:
S>Нужно сперва научиться использовать ту или иную фичу правильно.
Это ж в любом случае необходимо.
Потому как даже в языке с памперсами, которые за обосравшимся девелопером подчистят, всё равно будет выходить плохо если и-так-сойдёт-клепатель-в-продакшен будет продолжать срать в писсуар, не понимая для чего он на самом деле нужен.
Ну а С++ это язык без памперсов, там писсуар отрезает пристроившуюся на него жопу циркуляркой, чем отваживает клепателей, что в общем то хорошо.
CC>>Потому как проблема всех универсальных библиотек в том, что они работают одинаково плохо везде, потому как в гонке за универсальностью страдает всё: от производительности до читабельности и удобства использования. S> Времена требуется, чтобы работало сегодня, пусть даже и так себе, чем завтра, но хорошо.
В таком раскладе часто бывает что как раз проще использовать не либу-всемогутер а просто собрать из более простых кирпичиков.
Здравствуйте, DiPaolo, Вы писали:
DP>Ведь как в других языках... Например, Go, Python, JavaScript — ты просто в ямле/джсоне/конфиге добавил строку libxyz (опционально указав версию), нажал кнопку в ИДЕ "подхватить"/"выкачать" — и все готово — юзаешь свою xyz либу. Изи пизи лемон сквизи.
А потом какой нить Marak Squires или Azer Koculu психует и лёгким движением руки...
DP>А как в плюсах. А тут целый зоопарк: один билдят на мейкфайле, другие на симейке, третьи — мезон, MSVC, плюс еще другие есть. И вот впендюрить к себе в симейковый проект чинить из мезона — да это та еще ебан задача. Это прямо боль.
Есть такой момент, но это проблема не самого языка.
Здравствуйте, DiPaolo, Вы писали:
DP>ИМХО, самая серьезная проблема/особенность C++ — это очень непростая работа с 3rd party libraries и сборкой. Когда тебе надо что-то затянуть в свой продукт — это становится еще тем приключением на несколько дней. Я говорю сейчас о том, чтобы затащить так, чтобы это собиралось под несколько платформ, чтобы было все легально с точки зрения лицензий, и чтобы это все шипилось как продукт (т.е. закинуть нужные файлы и обеспечить запускабельность на чистой машине).
Полностью согласен
Тут тот же Rust очень хорошо обходит плюсы благодаря наличию управлении зависимостями.
У нас умельцы начали новый проект на коленке, так там умудрились добавить зависимости 3-мя (Карл!) разными способами.
git submodule, vcpkg, conan.
И это проекту всего один месяц.
В других проектах на C++ каждая команда использует свои решения и конечно они разные у всех.
Здравствуйте, DiPaolo, Вы писали:
DP>Или даже взять CMake — да он сам по себе иногда сотник строк содержит, и таких файлов могут быть десятки!!!
DP>Да, есть Конан. Я сам его в боевых проектах не юзал, только немного щупал. Там вроде попроще, но тоже сильно нетривиально и писать надо порядочно. И это только обвязка для билда!
Есть мнение что это всё уже прошлый век и теперь Bazel нашефсё. Мы сейчас на нем, и признаю, это просто супер сборочная система, но только при условии что в проекте участвуют реально сильные DevOps-ы, которые это великолепие поддерживают.
Здравствуйте, reversecode, Вы писали:
R>самая большая проблема С++ это то что его критикуют те кто к С++ никакого отношения не имеют
Asm/C/С++ — для элиты, а элиты не может быть много. Не могут все стать элитой. Хватает малого числа, чтобы делать необходимую работу низкого уровня — а менее одаренным Природой — нет смысла, успехи все равно будут посредственными.
Здравствуйте, Shmj, Вы писали:
S>Asm/C/С++ — для элиты, а элиты не может быть много. Не могут все стать элитой. Хватает малого числа, чтобы делать необходимую работу низкого уровня — а менее одаренным Природой — нет смысла, успехи все равно будут посредственными.
Дело не в одаренности, а в практичности. Работы мало, найти ее трудно (особенно у нас). Посмотри вакансии С++, какого рода работу приходится делать: поддержка старых проектов 20-летней давности, или низкооплачиваемый геймдев. Вот тебе и элита.
Здравствуйте, Shmj, Вы писали:
S>Asm/C/С++ — для элиты, а элиты не может быть много. Не могут все стать элитой. Хватает малого числа, чтобы делать необходимую работу низкого уровня — а менее одаренным Природой — нет смысла, успехи все равно будут посредственными.
Как приятно побыть элитой хотя бы чуть-чуть
А еси серьёзно, то Asm/C/С++ это просто инструменты, довольно древние и кривые для большинства современных задач, никакой элитарности в этом нет
Здравствуйте, kaa.python, Вы писали:
S>>Asm/C/С++ — для элиты, а элиты не может быть много. Не могут все стать элитой. Хватает малого числа, чтобы делать необходимую работу низкого уровня — а менее одаренным Природой — нет смысла, успехи все равно будут посредственными.
KP>Как приятно побыть элитой хотя бы чуть-чуть
Но от того, что используешь элитарный язык — сразу элитой не станешь.
Нужно достичь уровня, чтобы тебя пригласили писать ядра ОС, ядра веб-серверов, ядра баз данных и пр. лучшие из лучших, а не местные догонялы, которые пробуют копировать лидеров, но не осознают своей некомпетентности. Если пригласили и дали зарплату уровня 500 k$ в год — значит ты действительно элита. И хрен тебя чем заменишь — вот реально.
