стоит ли запилить тему по с++

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

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

А это почему? Если корпорации захотят кого-то, гм, "трахать" - они смогут это делать, независимо от среды исполнения.

 

Да откуда ты это берёшь? Не было лямбд - добавили лямбды. Как C++03 ни изучай, лямбды там не появятся, а они очень удобные и полезные. Или for по коллекциям вместо итераторов.
Попробуй попиши без C++11, увидишь, какие километровые простыни приходится писать.
Или констэкспры, благодаря которым много рантаймового кода можно перенести в компайл-тайм, что сэкономит тебе киловатты света.
Дебилы, которым включили интернет, никакого влияния на стандарт не оказывают, и всё, что там появляется, взято не с потолка, а потому что профессионалам это нужно.

 

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

 

Пусть экспансируют. Если фреймворк удачный - его стоит продвигать в массы, чтобы более эффективно\быстро\просто делать то, что раньше делалось неэффективно\медленно\сложно. Почему это плохо?

 

Да , похоже, как раз так и происходит - добавляют по большей части всякие хотелки в стиле "а давайте запихнем стандарт и вот это". И усиленно пихают всякие корутины, контракты и прочую дичь. В результате чего язык уверенно движется к состоянию https://ru.wikipedia.org/wiki/ПЛ/1 . Да , есть полезные вещи, вроде auto, lambdas, threading, filesystem, но в общей картине это скорее исключения.
Но добавление фич должно тщательно взвешиваться, а сейчас это носит какой-то метастазирующий характер. Не хочется пользоваться инструментом, который изменяется у тебя прямо в руке.

 

Но почему это дичь? Корутины - хорошее средство для асинхронного программирования, они просто удобны. Кому надо - будет использовать, кому не надо - никто их использовать не заставляет.
А контракты - отличное средство документирования кода (и проверки на соответствие этой документации) в самом коде.
Язык движется к большей безопасности - почему этого не нужно делать?

 

почему разбился Mars Climate Orbiter? потому, что над софтом работало несколько команд разработчиков, одни использовали метрическую систему, другие британскую... а язык программирования не предоставил им средства для того, чтобы конкретизировать, какие единицы измерения использовать в определенный момент... не помню уже, что там был за язык программирования, вроде Фортран или Сишечка, но в то время уже давно была Ада, в которой есть встроенные средства типизации величин... как итог: миссия стоимостью в миллионы провалена потому, что программисты не сдюжили нормально кодить на низкоуровневых языках...

 

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

 

в частности... наличие такой высокоуровневой фичи спасла бы миссию в миллионы...

 

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

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

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

Я понимаю эти вещи. Это моё имхо. По существу есть что сказать?

 

Rel,

> вот вы все такие низко-уровневые программисты... кто из вас где работает и сколько зарабатывает?

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

 

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

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

А чем веб-разработка хуже разработки драйверов? Зачем дискриминировать разработчиков по их роду деятельности?
Это похоже на старческое брюзжание "вот в наши времена...". Веб - крайне востребованная ниша. И научиться писать качественные быстрые и оптимизированные сайты - ничуть не проще, чем писать драйвера.
И то, и другое необходимо. Спрос рождает предложение: был бы массовый спрос на низкоуровневую разработку - будь уверен, люди рвались бы изучать ассемблер.

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

И опять же, так можно сказать про любые корпоративные гайдлайны.
Они не берутся с потолка. Бизнес ничего не делает просто так. Если есть требование использовать контракты (свет клином на них сошёлся!) - на то есть обоснованные причины.

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

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

 

sn0w,

> hasherezade, да, это аверша из malwarebytes

Вот эта https://twitter.com/hasherezade ?

Там походу у них сходка, есчо три бабы выдаёт.. если бы не ответы j00ru и есчо некоторых, то это не иначе как обычная страница с вконтактика, фотки какие то ноль тех инфы
Может линк на её работы или какую то тех инфу, интересно почитать. Если же они работают в ав конторах по подсобным работам, на раздаче хавчика и тп, то не нужно

 

Там ссылки на гитхаб и блог есть:
https://github.com/hasherezade
https://hshrzd.wordpress.com
Еще на malwarebytes своя колонка должна быть.
Давно читаю, хороший специалист, но авер у них кривой, у вин. дефендера куда лучше минфильтры настроены.

 

И то, и другое. Если софт продаётся - он нужен. А значит, закрывает потребности и, как следствие, делает мир лучше.

Я не понял ничего... Какие волатильные области? Какие навязанные принципы? Что будет контролируемо? О чём "об этом" забыть? Что перекрывать?..

 

Новые стандарты делают с плюсов черт знает что. Какой смысл юзать все эти смарт поинтеры и прочие вещи? Хотите безопасный код - берите шарп или джаву.
В итоге, современные плюсы ушли от изначальной (хорошей) идеи Си с классами, и к чему пришли? Черт знает к чему. Ни туда ни сюда.

 

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

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

 

Не, ну вот про smart pointers - очень полезная вещь. Если применять там где надо - делает работу с памятью удобной и безопасной - память не течет.
Это raii обертка для освобождения памяти в деструкторе.
Вот unique_ptr - передается ему указатель на память выделенную при создании его в опр. области видимости (напр., внутри функции) - память автоматически гарантированно освободится при выходе из области видимости, не нужно следить за каждым return, руками делать free - очень удобно.
shared_ptr - то же освобождение при удалении, но тут можно этот объект smaprt ptr'а давать нескольким клиентам, чтобы они могли пользоваться этим объектом. Тут есть подсчет количества того, скольки клиентам дана копия этого "указателя" на выделенную память. При разрушении последней копии память автоматически освобождается. Тоже удобно, руками такую обертку писать утомительно, а тут - из коробки.

"Жираф большой, ему видней" ©

 

njeen, это да, полезная вещь (судя по описанию), но врядли все остальное такое же полезное. Да и теряется сама суть плюсов..ниже напишу.

Rel, я не работал в больших проектах, и как бы сложно судить. Мне неясно только одно - для чего сейчас нужен С++ ? Т.е. этот язык позиционирует себя как язык для чего, какой сферы? Ну как вот РНР - веб, Ассемблер там загрузчик ОС, шеллкоды (я примерно).
Т.е. если нам нужна скорость работы софта, низкий уровень без лишнего мусора, мы используем язык Си (где нет лябмд и смарт поинтеров). Можно кодить на "Си с классами", чтобы упростить абстракцию.
Если же нужно удобство, сборка мусора и прочее - зачем брать С++? Вот в чем преимущество перед шарпом, go или еще чем либо высокоуровневым? Где все эти вещи есть искоробки и не надо думать.

 

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

--- Сообщение объединено, 28 сен 2019 ---

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

--- Сообщение объединено, 28 сен 2019 ---

но да, назовите мне сферу, и я вам скажу хорошую альтернативу плюсам...