С++11 (& Co)
кто-нибудь соприкасается ежедневно вплотную? поделитесь впечатлениями. что нравится и удобно, что неудобно и т.д.
кроме того, интересно, в каких проектах используется, как это получилось и как это происходило. т.е. был старый код, и с появлением 11 сразу бросились переписывать все что можно, используя новый стандарт? я порой свое старое боюсь тронуть : (
некоторыми удобными штучками из с11 я пользуюсь:
- ауто переменной, где видеть реальный тип смысла нет
- фореач и фор, который тоже как фореач: for( auto var : array ){...}
- лямды (они покруче и удобнее чем в си шарпе).
- final, override
спасибо за ответ.
а вы можете сказать, что вы наконец-то получили то, что сильно облегчило вашу жизнь? т.е. "ну наконец-то можно вздохнуть свободно! долгожданная ляааамбдааааа!!!"? если бы этот стандарт не появился, вы бы сильно страдали? писали бы менее качественный код?
я пока не вижу ничего такого, чего мне недоставало. вижу единственно серьезное преимущество: стандартизация мультитрединга, синхронизации и пр. будем надеяться, что эти стандарты со временем вытеснят многообразие реализаций.
Какой С++11? Уже С++17 на дворе, и ему уже С++20 в затылок дышит.
[sarcasm_mode_off]
После многолетней любви с boost, я был рад увидеть очень многое оттуда в std. Особенно std::memory. Долой new & delete! А кто не знает или не любит boost, тот и не С++ вовсе.
так перечисленные мелочи и облегчают жизнь. Они короче, елегантнее, приятнее.
А вот мултитрединг, синхронизации сильно не облегчают жизнь, ввиду того что к этой теме надо весьма осторожно подходить и тщательно продумывать (чтоб не захламить проэкт локами, и не наделать дэдлоков) и потому это программируется редко. А что редко - то и облегчает жизнь редко.
я имел ввиду, что существует множество реализаций мультитрэдинга в с++. мне приходилось работать с posix, win32, mfc, qt, возможно еще какие-то, всех не упомнишь. и каждый раз приходится, зная с++, узнавать еще что-то, что не является стандартом языка. а с появлением стандатра, через какое-то время, пару десятилетий, наверное, в какой бы среде/платформе вы не программировали на с++, мультитрэдинг будет (скорее всего) имплементирован одинаково. конечно, если к тому времени с++ все еще не будет вытеснен новыми, более развитыми языками.
мультитрединг программируется редко? у меня другое мнение. скорее редко можно обойтись без. ну а захламить можно и иначе, даже простыми автоматическими переменными. все должно быть на своем месте.
захламить код автоматическими переменными невозможно, ввиду того что они являются более компактной записью тех же переменных (переменные всё равно будут и в том же количестве).
а вот сихнхронизирующими об\ектами можно захламить, если сильно не заботиться о минимизации их количества. На мой взгляд, если об\ектов типа критической секции или мутекса более двух, трёх в проэкте - это уже признак слабого обдумывания многопоточности (конечно от проэкта зависит, но исхожу из своего опыта). Я работал с проэктом в котором критических секций было штук 30, и они периодически висли либо ожидая друг друга, либо ожидая выхода из Win-API SendMessage (где бывает неявная блокировка).
Впрочем главная стратегия тут, по-моему, блокировать только данные и на возможно короткое время (т.е. после блокировки и до разблокирования, не вызывать никаких строронних функций). Но все равно если сихн-об\ектов меньше - то и дышать легче.
Если для вас новшества из std::memory в С++11 не по теме, то даже не знаю, что ещё сказать. Профессионалов развелось...
захламить код, по-моему, можно чем угодно. даже комментариями. но тема не о том, хорошо или нехорошо мультитрэдинг, а о том, чего разработчики "наконец-то дождались" после появления с++11 и дальнейших стандартов, без чего жизнь была значительно сложнее.
интересная статья
http://www.acodersjourney.com/2016/05/top-10-dumb-mistakes...
не люблю постов со ссылками без комментов, поэтому приведу начало
Top 10 dumb mistakes to avoid with C++ 11 smart pointers
I love the new C++ 11 smart pointers. In many ways, they were a godsent for many folks who hate managing their own memory. In my opinion, it made teaching C++ to newcomers much easier.
However, in the two plus years that I've been using them extensively, I've come across multiple cases where improper use of the C++ 11 smart pointers made the program inefficient or simply crash and burn. I've catalogued them below for easy reference.
...
читать дальше, естественно, требует времени.
я лично не понимаю восторга от этих смартпоинтеров в с11.
Ведь смартпоинтеры - довольно просты.
Я уже лет 15 назад сам написал пару таковых: один наподобии ауто-ртр, а второй со счетчиком ссылок, и всегда ими пользуюсь (работаю преимущественно в паре-тройке долгоживущих проэктов). Также написал вектор владеющий об\ектами как исключительно, так и по счетчику ссылок.
На мой взгляд, своё всегда лучше, чем даже из стандартной библиотеки. Т.к. своё ты знаешь как облупленное и никаких фокусов не возникнет к примеру при переходе на новую версию STL.
А в своём решении тоже предусмотрены custom allocator'ы или ситуации, когда конструктор объекта швыряет исключение?
ЗЫ. "Своё лучше" = велосипеды и костыли. И я бы ещё на быстродействие "своего" глянул бы.
"Своё лучше" = велосипеды и костыли. И я бы ещё на быстродействие "своего" глянул бы.
Ну не всегда костыли, и именно из-за быстродействия иногда свою имплементацию STL писать приходится. Конкретная проблема: STL map делает ребалансировку тогда, когда ей вздумается, из-за этого emplace (объект простейший, готовый указатель в map) выбрасывает пики по латентности в сотню микросекунд, тот же аналог garbage collection в RT (C#; java и т.д.). При этом загрузка неравномерная, есть спокойные периоды, когда всем этим можно заниматься... Т.е. контроля за STL недостаточно, как и за garbage collection, кстати, или у меня просто руки из ж. И да, все тайминги неоднократно выверены, в своей имплементации "emplace" практически никогда не выходит за 10 микросекунд. (Все на плюсах, разумеется.)
и что должно быть в смартпоинтере предусмотрено, на случай если конструктор швыряет исключение?
(ясно что смартпоинтер при этом не сохранит указатель об\екта, и в своем деструкторе ничего не сделает - и для этого ничего специального программировать не надо).
Ну а насчет быстродействия - это надо постараться написать тормоза при программировании смартпоинтера. :))
Я довольно много оптимизировал старые программы по быстродействию. И ни разу не было проблем с коллекциями, или лучше сказать так: оптимизация внутреннего кода коллекций/деревьев могла принести очень малый выигрыш в быстродействии по сравнению с другими оптимизациями (клопоту густо, в жывоти пусто), потому связываться смысла нет.
Больше всего тормозов давала плохая организация программы:
- лишние обращения к файлам
- вызовы дорогостоящих функций из цикла, когда можно было один раз перед циклом
- линейный поиск вместо бинарного поиска
- поиск вместо обращения по хэндлу