Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Zhendos, Вы писали:
Z>>Раньше это не могло быть проблемой. Раз код Z>>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)". AG> AG>Что же мешало сделать две перегруженные функции: AG>1) аргумент типа константной ссылки AG>2) аргумент типа rvalue AG>тогда: хочешь сэкономить память — бери функцию с аргументом типа rvalue AG>но если не хочешь — просто передай "v" (всё будет работать без ошибки).
И как все это поможет? Я говорю о чтении кода. То есть читаешь:
V v;
f(v);
и не понимаешь что происходит, есть здесь проблемы с производительностью или нет.
Нужно перейти к определению "f", а здесь какая разница будет ли она overload,
или одна, и так станет все понятно. А если таких вызовов и функций много,
то и в IDE это превращается весьма в неудобное занятие, а уж если это code-review в web.
Z>>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма, AG> AG>Синтаксис C++11/14/17 — вспонишь за секунды, а новый алгоритм или архитектуру — будешь продумывать не один день.
А причем здесь "вспомнить синтаксис"? Запомнить что есть еще и "enum class",
в дополнение к обычному "enum" это действительно секунды и один раз,
а вот проблемы которые породило это разделение приходится расхлебывать для каждого
enum в своей кодовой базе и во всех сторонних библиотеках которые используешь.
И конечно сложно запомнить какой же вид enum для этих сотен тысяч enum.
И все это конечно отвлекает каждый раз когда пишешь алгоритм, правишь его,
пишешь тесты и т.д. и т.п.
Z>>ок, нам пришла переменная типа Color, я знаю что это enum, Z>>и мне нужно проверить красный ли цвет, как мне это написать? Z>>color == RED или color == Color::RED, Z>>ведь теперь знания что тип enum не достаточно, нужно знать Z>>это enum или enum class. AG> AG>Использую (последнюю пятилетку) enum class — нет нигде никаких проблем.
Если бы это все так просто решалось, например в Qt "5.последняя версия"
есть куча "enum" и куча "enum class".
Z>>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>>типа конструктора для создания экземпляра и методов нужно подумать еще Z>>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>>писать руками и т.п. AG> AG>Зачем эти усложнения? AG>Компилятор всё правильно воспримет и без этих лишних телодвижений.
Ну стандарт C++ с вами не согласен, если например объявлен `Foo &operator=(const Foo&)`,
то не будет "Implicitly-declared move assignment operator".
Z>>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>>можно записать двумя способами, это ли не усложнение? AG> AG>Одно и то же действие несколькими способоми — это есть даже в старом добром Си AG>Страшного здесь ничего нет (и быть не может).
Конечно есть, даром что ли пишут "coding style" и в которых речь идет не только об растоновки скобочек,
но и именовании функций, способах обработки ошибок и т.д. и т.п.
Характерно что для C++ есть не только обычный "coding style", но и описание типа
где говориться даже о тех же самых конструкторах, операторах копирования и т.п.
догадываетесь почему это нужно и почему такой совершенно неавторитетный в C++ человек как
Bjarne Stroustrup принял участие в составлении таких рекомендаций? Может
именно потому что 100500 сопсобов это не так уж хорошо и замечательно?
Здравствуйте, Zhendos, Вы писали:
Z>Вот вызвали функцию: Z>
Z>V v;
Z>f(v);
Z>
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК,
Что, правда?
Z>либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо.
А по какой ссылке: константной или нет? Что будет с v после возврата из f()?
А почему вы думаете, что f -- это функция? Может это макрос. А может это вызов конструктора типа f? А даже если f -- это функция, то какая именно и из какого пространства имен (с учетом различных вариантов перегрузок)?
Вы что, правда верите в то, что в C++98 код был простой и читабельный, что стоит только посмотреть на него и все становилось понятно?
Здравствуйте, Zhendos, Вы писали:
Z>>>И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее, Z>>>а как иначе если сохраняется обратная совместимость и новые конструкции только Z>>>прибавляются?
PM>>Да, язык становится сложнее. Я всего лишь пытаюсь донести мысль, что новые средства позволяют писать более читаемый и выразительный код.
Z>Не согласен. Более выразительный противоречит читаемости. Так как намного больше происходит Z>под капотом и следовательно каждую строчку намного труднее понимать. Z>Вот вызвали функцию: Z>
Z>V v;
Z>f(v);
Z>
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
Если f() может принимать аргумент по значению и v может копироваться, не вижу в чем ошибка. Когда вам больше не нужен v, вы указываете это явно. Если вы объявите f(V&&), то также станет явно видно, что функция поглощает свой аргумент, и компилятор вам сообщит об этом. По-моему читаемости и надежности прибавилось, по сравнению со неконстантными ссылками.
Z>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма, Z>улучшения архитектуры и т.д. Вместо этого он думает:
Z>ок, нам пришла переменная типа Color, я знаю что это enum, Z>и мне нужно проверить красный ли цвет, как мне это написать? Z>color == RED или color == Color::RED, Z>ведь теперь знания что тип enum не достаточно, нужно знать Z>это enum или enum class.
Тут вообще не вижу проблемы — компилятор вам сообщит, если ожидается enum class. Я бы вот хотел иметь возможность сделать `using enum class Color` в какой-то области видимости, но пока это предложение не прошло (вроде бы).
Z>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>типа конструктора для создания экземпляра и методов нужно подумать еще Z>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>писать руками и т.п.
Или 0 до 5, в зависимости от данных и предполагаемых сценариев использования. См. "rule of zero" и "Howard Hinnant special members diagram".
Z>И так с каждой возможностью, которую вводят. Все они усложняют язык и затрудняют Z>его использование, если их вводить не ломая и не выкидывая предыдущие возможности.
Или упрощают. Я теперь могу писать range-based loops в шаблонных функциях без шума в виде `typename contanerTemplate<MyTemplateType>::const_iterator`
Z>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>можно записать двумя способами, это ли не усложнение?
PM>>Это разные способы для разных целей. С введением семантики перемещения мы теперь имеем возможность перемещать некопируемые объекты, например дескрипторы файлов. Это не замена обмену. В С++03 трюк с обменом обычно использовался от бедности, для возврата из функции.
Z>Но он много где использовался и в том числе чтобы не вызывать лишний раз аллокацию, Z>и переиспользовать выделенную память. Но я привел конкретный пример, Z>довольно странно парировать его другим примером, а же доказывал общее утверждение, Z>что весь написанный в C++11 стиле код стал хуже.
Ясно. Я не согласен с общим утверждением, что "раньше было лучше, язык стал хуже". Мое мнение — многие вещи стало проще сделать, но из-за обратной совместимости приходится сохранять все предыдущие способы отстрелить себе ногу. Легкого решения здесь нет, языку приходится эволюционировать, накапливая рудименты. Пока С++ с этим как-то справляется, посмотрим лет через 5.
Здравствуйте, σ, Вы писали:
PM>>Вы похоже путаете правительство, которое на другой планете, с людьми из комитета. Вся информация по его работе находится в открытом доступе.
σ>Засекреченные стенограммы заседаний и мейл-листы не очень похожи на "отрытый доступ".
Действительно, теперь вроде результаты заседаний становятся доступны спустя какое-то время. Может быть, это особенности процесса разработки?
Я не очень внимательно слежу на последними новостями в развитии С++, но обычно можно без проблем узнать что нового планируется, уже одобрено, или отклонено — некоторые участники заседаний пишут об этом на reddit/cpp
Здравствуйте, Zhendos, Вы писали:
VT>>Хорошо, напишу чуть по другому: VT>>
VT>>V a{std::move(b)};
VT>>
VT>>Разницу чувствуете?
Z>В чему разницу я должен чуствовать, Z>C++11 дает возможность создать alias a для объекта b. Z>При том как напомнили в другой ветке еще и не бесплатно, Z>так как будет вызван деструктор b, после того как он опустел? Z>Очень ценная возможность, но лучше просто использовать имя "b" в этой функции.
Разницу в том, что для a.swap(b) нужно, чтобы объект а уже существовал, в то время как с помощью V a{std::move(b)} можно передать ресурсы в новый, создаваемый объект.
S>Что происходит?
Происходит классический фейл.
Одна из задач собеседования понять
а)понимает ли соискатель будущее начальство
б)делает ли он задачу которую от него хотят
в данном случае — не делает, занимается какой ***й
Здравствуйте, Dym On, Вы писали:
S>>А вообще, граждане, имеющие настолько мало самоуважения, чтобы после 17 лет опыта писать тестовые задания, должны страдать. DO>Какой на фиг КСВ? DO>
лет 17, это почти две трети моей жизни
DO>Чуваку 25, у него еще юношеский максимализм не прошел.
Т.е. он пишет на плюсах и "читает пропозалы" с 8 лет. Ок.
По опыту, программистам "начинающего" уровня свойственно придавать важное значение
1) количеству "выученных" языков
2) глубокому знанию синтаксиса языка 3) статьям на хабре.
Здравствуйте, zou, Вы писали:
zou>По опыту, программистам "начинающего" уровня свойственно придавать важное значение
Не то что начинающего, а просто нужно признать, что, во-первых, генетически интеллектуальные возможности у всех разные. Во-вторых, не у всех были возможности получить образование — кто-то учился сам как мог, в свободное от работы время.
По этому есть кодеры — не в полной мере программисты. Их задача — закодить, но сделать это с соблюдением всех стандартов и пр. Работа оплачивается ниже, значимость ниже — но пока такие люди нужны.
На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Здравствуйте, Тёмчик, Вы писали:
S>>Статья вышла в топ: https://habr.com/ru/post/497114/ Так же комменты доставляют:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Тогда вы сильно недооцениваете количество находящихся "не в здравом уме".
Здравствуйте, Тёмчик, Вы писали:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Давай скажем честно, у вас почти вся серьезная разработка давно ноги сделала, а та что осталась... тебя туда просто не пускают
Здравствуйте, kaa.python, Вы писали:
Тё>>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
KP>Давай скажем честно, у вас почти вся серьезная разработка давно ноги сделала, а та что осталась... тебя туда просто не пускают
Давай скажем честно, те проекты, где мы с тобой работали, зачинались в 1995г. Уже в 2007г новые проекты зачинались на более других языках.
Здравствуйте, Тёмчик, Вы писали:
S>>Тогда вы сильно недооцениваете количество находящихся "не в здравом уме".
Тё>Наверите "C++" на сайте по поиску работы, и посмотрите предложения. Поддержка кала мамонта и тех раз-два и обчелся.
Из того, что на новые проекты не набирают по объявлениям вовсе не проистекает то, что этих самых новых проектов нет.
Но вот почему вас C++ до сих пор беспокоит? Какие-то фантомные боли? Или когда вы программировали на C++, то были дороже, пользовались большим успехом у противоположного (а может и своего, по нынешним толерантным временам не поймешь) пола и здоровье позволяло этим успехом пользоваться? А сейчас уже остается только вспоминать, как трава была зеленее, вода мокрее, а хрен крепче?
Здравствуйте, Тёмчик, Вы писали:
Тё>Давай скажем честно, те проекты, где мы с тобой работали, зачинались в 1995г. Уже в 2007г новые проекты зачинались на более других языках.
Два сложных свежака начали на C++17 за последнии пару месяцев. И именно C++ в этих проектах самое оно. Но там да, это не опердень, это не JS с формочками
Здравствуйте, kaa.python, Вы писали:
KP>Два сложных свежака начали на C++17 за последнии пару месяцев.
Каких и почему выбрали C++? Крыша протекла от сидения в карантине, или какие-то обьективные причины? Чем node не подошёл?
KP>И именно C++ в этих проектах самое оно. Но там да, это не опердень, это не JS с формочками
Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
Здравствуйте, Тёмчик, Вы писали:
Тё>Каких и почему выбрали C++? Крыша протекла от сидения в карантине, или какие-то обьективные причины? Чем node не подошёл?
А ты как себе представляешь стек автономного автомобиля на Ноде?
Тё>Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
Ну UI же опять и всякие перделки, это побоку на чем делать. Представь себе Redis, ClickHouse, Mongo, Tarantul и т.п. на Ноде и всплакни.
Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде.
Здравствуйте, kaa.python, Вы писали:
KP>А ты как себе представляешь стек автономного автомобиля на Ноде?
Ну т.е. за неимением других инструментов, или за неумением готовить, начали пилить на C++. Хотя, не вижу принципиальных препятствий крутить ноду на arm линуксе.
Тё>>Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
KP>Ну UI же опять и всякие перделки, это побоку на чем делать. Представь себе Redis, ClickHouse, Mongo, Tarantul и т.п. на Ноде и всплакни.
Не пофигу. Redis и Mongo можно на go сделать. Плюсы там, как телеге пятое колесо
KP>Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде.
Это хорошо, только где между титанами нодой и эликсиром место у сипипи?
Здравствуйте, Тёмчик, Вы писали:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Тоже на плюсах проекты начинал недавно. Соседняя команда переписывает проект с C# на C++, часть шарпистов при этом переучиваются. Работает быстрее, кода меньше — профит.
Надо сказать, что в конторе есть специалисты и проекты на многих языках, в одной проекте есть C++, С# и JS. У всех своя ниша, но плюсы тут не уступают, а, скорее, доминируют. И дело не в криворукости или пряморукости, просто быстрый код на плюсах писать легче. И зачастую кроссплатформенный: GUI со сложной визуализацией, выводом видео и других штук проще написать на Qt, местами переходя на OpenGL и что-то на шейдерах. Хоть у нас и не embedded, хотя там тоже Qt безоговорочный лидер в плане GUI. Не говорю уже про логику и вычисления.
