Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

С++11 (& Co)

359  
  moose старожил12.02.18 21:05
12.02.18 21:05 

кто-нибудь соприкасается ежедневно вплотную? поделитесь впечатлениями. что нравится и удобно, что неудобно и т.д.

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

#1 
anly коренной житель12.02.18 22:41
anly
NEW 12.02.18 22:41 
в ответ moose 12.02.18 21:05

некоторыми удобными штучками из с11 я пользуюсь:

- ауто переменной, где видеть реальный тип смысла нет

- фореач и фор, который тоже как фореач: for( auto var : array ){...}

- лямды (они покруче и удобнее чем в си шарпе).

- final, override

Проклят нарушающий межи ближнего своего (Втор.27:17)
#2 
  moose старожил12.02.18 22:55
NEW 12.02.18 22:55 
в ответ anly 12.02.18 22:41

спасибо за ответ.

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


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

#3 
dymanoid знакомое лицо12.02.18 23:33
dymanoid
NEW 12.02.18 23:33 
в ответ moose 12.02.18 21:05

Какой С++11? Уже С++17 на дворе, и ему уже С++20 в затылок дышит.

[sarcasm_mode_off]

После многолетней любви с boost, я был рад увидеть очень многое оттуда в std. Особенно std::memory. Долой new & delete! А кто не знает или не любит boost, тот и не С++ вовсе.

#4 
  moose старожил13.02.18 10:42
NEW 13.02.18 10:42 
в ответ dymanoid 12.02.18 23:33

а по теме что-нибудь можете?

#5 
anly коренной житель13.02.18 11:14
anly
NEW 13.02.18 11:14 
в ответ moose 12.02.18 22:55, Последний раз изменено 13.02.18 11:15 (anly)

так перечисленные мелочи и облегчают жизнь. Они короче, елегантнее, приятнее.

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

Проклят нарушающий межи ближнего своего (Втор.27:17)
#6 
  moose старожил13.02.18 12:08
NEW 13.02.18 12:08 
в ответ anly 13.02.18 11:14, Последний раз изменено 13.02.18 12:10 (moose)

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


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


#7 
anly коренной житель13.02.18 14:05
anly
NEW 13.02.18 14:05 
в ответ moose 13.02.18 12:08

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

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

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

Проклят нарушающий межи ближнего своего (Втор.27:17)
#8 
dymanoid знакомое лицо13.02.18 14:19
dymanoid
NEW 13.02.18 14:19 
в ответ moose 13.02.18 10:42

Если для вас новшества из std::memory в С++11 не по теме, то даже не знаю, что ещё сказать. Профессионалов развелось...

#9 
  moose старожил13.02.18 14:49
NEW 13.02.18 14:49 
в ответ anly 13.02.18 14:05

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

#10 
BorisL0 знакомое лицо13.02.18 15:35
NEW 13.02.18 15:35 
в ответ moose 12.02.18 21:05

Умные указатели,

Threads.

#11 
  moose старожил13.02.18 23:09
NEW 13.02.18 23:09 
в ответ moose 12.02.18 21:05

интересная статья


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.

...

читать дальше, естественно, требует времени.

#12 
anly коренной житель14.02.18 19:14
anly
NEW 14.02.18 19:14 
в ответ moose 13.02.18 23:09

я лично не понимаю восторга от этих смартпоинтеров в с11.

Ведь смартпоинтеры - довольно просты.

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

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

Проклят нарушающий межи ближнего своего (Втор.27:17)
#13 
dymanoid знакомое лицо14.02.18 22:15
dymanoid
NEW 14.02.18 22:15 
в ответ anly 14.02.18 19:14, Последний раз изменено 14.02.18 22:16 (dymanoid)

А в своём решении тоже предусмотрены custom allocator'ы или ситуации, когда конструктор объекта швыряет исключение?


ЗЫ. "Своё лучше" = велосипеды и костыли. И я бы ещё на быстродействие "своего" глянул бы.

#14 
LifeRider постоялец14.02.18 23:10
LifeRider
NEW 14.02.18 23:10 
в ответ dymanoid 14.02.18 22:15, Последний раз изменено 14.02.18 23:12 (LifeRider)
"Своё лучше" = велосипеды и костыли. И я бы ещё на быстродействие "своего" глянул бы.

Ну не всегда костыли, и именно из-за быстродействия иногда свою имплементацию STL писать приходится. Конкретная проблема: STL map делает ребалансировку тогда, когда ей вздумается, из-за этого emplace (объект простейший, готовый указатель в map) выбрасывает пики по латентности в сотню микросекунд, тот же аналог garbage collection в RT (C#; java и т.д.). При этом загрузка неравномерная, есть спокойные периоды, когда всем этим можно заниматься... Т.е. контроля за STL недостаточно, как и за garbage collection, кстати, или у меня просто руки из ж. И да, все тайминги неоднократно выверены, в своей имплементации "emplace" практически никогда не выходит за 10 микросекунд. (Все на плюсах, разумеется.)

#15 
anly коренной житель15.02.18 12:50
anly
NEW 15.02.18 12:50 
в ответ dymanoid 14.02.18 22:15

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

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


Ну а насчет быстродействия - это надо постараться написать тормоза при программировании смартпоинтера. :))

Я довольно много оптимизировал старые программы по быстродействию. И ни разу не было проблем с коллекциями, или лучше сказать так: оптимизация внутреннего кода коллекций/деревьев могла принести очень малый выигрыш в быстродействии по сравнению с другими оптимизациями (клопоту густо, в жывоти пусто), потому связываться смысла нет.

Больше всего тормозов давала плохая организация программы:

- лишние обращения к файлам

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

- линейный поиск вместо бинарного поиска

- поиск вместо обращения по хэндлу

Проклят нарушающий межи ближнего своего (Втор.27:17)
#16