Здравствуйте, Pzz, Вы писали:

Pzz>Никакого противоречия нет. Мы пишем код, чтобы решить задачу, а не чтобы блеснуть своими познаниями тонкостей языка. И потом этот код будет кто-то поддерживать. Чем он проще и яснее, тем проще его поддерживать и разбираться с проблемами, в нем или по соседству.

Скажите, пожалуйста, какой код проще:

Вот этот:

void c::f() {
  std::lock_guard lock{this->mutex};
  this->data.modify();
}

или вот этот:

void c::f() {
  this->mutex.lock();
  this->data.modify();
  this->mutex.unlock();
}

?

Здравствуйте, so5team, Вы писали:

Pzz>>Никакого противоречия нет. Мы пишем код, чтобы решить задачу, а не чтобы блеснуть своими познаниями тонкостей языка. И потом этот код будет кто-то поддерживать. Чем он проще и яснее, тем проще его поддерживать и разбираться с проблемами, в нем или по соседству.

S>Скажите, пожалуйста, какой код проще:

Плюс-минус одинаково.

И нет, мне не нравится и никогда не понравится, что декларация локальной переменной и уход ее из области видимости обладают глобальными побочными эффектами. Но это — C++-ная идеома, ее все понимают, так что и хрен бы с ней.

Здравствуйте, Pzz, Вы писали:

S>>Скажите, пожалуйста, какой код проще:

Pzz>Плюс-минус одинаково.

Ну ахринеть.

Как бы мне еще запомнить, что в области C++ вы дуб дубом и ваше мнение по поводу C++ нужно сливать в /dev/null сразу же.

Здравствуйте, B0FEE664, Вы писали:

BFE>Для меня просто было неожиданностью, что
BFE>auto a = ...
BFE>и
BFE>auto [b] = ...
BFE>так различаются.

BFE>Я бы ожидал такое:
BFE>auto [b] = ... // копия поля
BFE>auto [&b] = ... // ссылка на поле

На этом основывалась дырка в 17 стандарте, не позволявшая делать захват таких полей в лямбду

auto [x, y] = foo();

[x]() {} ();

В 20 разрешили.

Ну и, конечно же, — да, синтаксис непрозрачный.
Фактически, там

auto hidden = foo();
decltype(auto) x = std::get<0>(hidden);
decltype(auto) y = std::get<1>(hidden);

и, при желании, эти геттеры могут возвращать вообще что угодно.

По красоте, надо было бы делать такой синтаксис

[auto x, auto& y] = foo();

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

Здравствуйте, Pzz, Вы писали:

Pzz>Никакого противоречия нет. Мы пишем код, чтобы решить задачу, а не чтобы блеснуть своими познаниями тонкостей языка. И потом этот код будет кто-то поддерживать. Чем он проще и яснее, тем проще его поддерживать и разбираться с проблемами, в нем или по соседству.
Если в C++ придерживаться определённых ограничений, то разбираться с проблемами не придётся. Одно из таких ограничений: никогда не вызывать lock() у мьютекса вне конструктора.
Фактически в приведённой задаче нет никаких тонкостей языка, а просто использование новых возможностей стандарта C++17, которые делают код проще и понятнее.

Например, вот этот код содержит ошибку:

void c::f() {
  this->mutex.lock();
  this->data.modify();
  this->mutex.unlock();
}

— здесь нет ловушки для исключений, а значит mutex останется залоченным, если modify() бросит исключение.

Pzz>>>А что выведет именно эта програмка — ну, можно запустить и посмотреть...
BFE>>Это вам не Паскаль.
Pzz>А что, C++ дошел уже до того, что программы на нем и запустить стало невозможно?
C, как и C++, это такой язык, что отстрелив себе ногу можно годами бегать не замечая отсутствия ноги, а потом на ровном месте внезапно упасть. Ибо UB — оно такое.
Так что если вам программа что-то напечатала, то это не означает, что и в следующий раз она напечатает ровно тоже самое.

Здравствуйте, B0FEE664, Вы писали:

Pzz>>А что, C++ дошел уже до того, что программы на нем и запустить стало невозможно?
BFE>C, как и C++, это такой язык, что отстрелив себе ногу можно годами бегать не замечая отсутствия ноги, а потом на ровном месте внезапно упасть. Ибо UB — оно такое.
BFE>Так что если вам программа что-то напечатала, то это не означает, что и в следующий раз она напечатает ровно тоже самое.

Ну в целом, да. Хотя Си, он, по крайней мере, простой, в голову вмещается.

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

Но я не так давно общался с коллегой, пытаясь объяснить, что не надо тащить в прод сложность без нужды. Его пойнт заключался более-менее в том, что "эту программу было трудно писать. Справедливо будет, если ее будет трудно читать".

Здравствуйте, B0FEE664, Вы писали:

BFE>Это развитие вот такого подхода.

всё-таки оригинал побезопаснее

auto& data = ts.Ref().second;
++data; // oops

Здравствуйте, so5team, Вы писали:

S>Ну ахринеть.

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

Другой вопрос в том, что если из modify() вылетит птичка Т.е. в первую очередь это код с разной семантикой, а не простой и сложный.

Здравствуйте, andyp, Вы писали:

S>>Ну ахринеть.

A>ну так он в чем-то прав имхо. У всей этой raii-шной истории нет шансов блеснуть в коде из трех строчек. Она ж придумана, чтобы со сложностью бороться, а если сложности нет, то и бороться тут не с чем.

A>Другой вопрос в том, что если из modify() вылетит птичка Т.е. в первую очередь это код с разной семантикой, а не простой и сложный.

Да тут вообще разговора не сложилось, т.к. человек не понимает опасностей преждевременного return (причем не важно, будет ли этот return вставлен при сопровождении кода или же modify будет пулять исключениями).

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

std::lock_guard lock{this->mutex};

Там ведь RAII -- это только одна составляющая.

Кроме RAII тут есть еще и шаблоны, ведь std::lock_guard -- это шаблон класса.

А кроме шаблонов тут есть еще и Class template argument deduction (CTAD), т.к. мы указали просто std::lock_guard, а не std::lock_guard<std::mutex>.

И, если в одной простой строчке столько фич C++ сосредоточено, то можно озадачиться следующими вопросами:

— должен ли юниор разбираться в подобных вещах и насколько?

— должны ли мы идти на поводу у юниоров и писать код, в котором не будет ни CTAD, ни шаблонов вообще?

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

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

Здравствуйте, so5team, Вы писали:


S>...И, если в одной простой строчке столько фич C++ сосредоточено, то можно озадачиться следующими вопросами:

S>- должен ли юниор разбираться в подобных вещах и насколько?
S>- должны ли мы идти на поводу у юниоров и писать код, в котором не будет ни CTAD, ни шаблонов вообще?

S>Есть у меня подозрение, что если, во-первых, занижать планку требований к C++ разработчикам и, во-вторых, ориентироваться при написании кода на наименее грамотных и опытных, то затраты на разработку на C++ возрастут многократно. Потому, что добавленные в C++ фичи как раз призваны упростить жизнь программиста, а добровольный от них отказ эту жизнь, напротив, усложнит.

Имхо, судя по лекциям профессиональных учителей С++, CTAD как раз и позиционировался для упрощения жизни новичкам — им вообще можно не париться, что std::lock_guard шаблон. Т.е. понимать фичу, писать своё, её использующее, и пользоваться готовым чужим кодом, использующим фичу — три разные вещи и, по крайней мере, в задумке новичкам должно быть проще использовать уже готовые компоненты, написанные с помощью этой фичи.

S>ЗЫ. Можно провести аналогию: приходит вчерашний школьник с минимальными знаниями в области высшей математики в НИИ, где сложными расчетами физических процессов занимаются. И руководитель подразделения, куда этот школьник попал, заявляет: ну все, вычисления с комплексной переменной не используем, а то наш новый юниор этого не поймет.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>Например, вот этот код содержит ошибку:
...
BFE>- здесь нет ловушки для исключений, а значит mutex останется залоченным, если modify() бросит исключение.

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

Здравствуйте, andyp, Вы писали:

A>Имхо, судя по лекциям профессиональных учителей С++, CTAD как раз и позиционировался для упрощения жизни новичкам — им вообще можно не париться, что std::lock_guard шаблон. Т.е. понимать фичу, писать своё, её использующее, и пользоваться готовым чужим кодом, использующим фичу — три разные вещи и, по крайней мере, в задумке новичкам должно быть проще использовать уже готовые компоненты, написанные с помощью этой фичи.

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

template<typename Obj>
void modify(Obj & obj) {
  std::lock_guard lock{obj.lock_}; // ХЗ что там за тип mutex-а, но нам фиолетово.
  ...
}

вместо

template<typename Obj>
void modify(Obj & obj) {
  std::lock_guard< std::decay_t<decltype(obj.lock_)> > lock{obj.lock_}; // ХЗ что там за тип mutex-а,
                                                                        // но приходится выяснять это
                                                                        // чтобы удовлетворить компилятор.
  ...
}

Или же: было так:

class data_holder {
  std::mutex lock_;
  ...
public:
  void update(int x) {
    std::lock_guard lock{lock_};
    ...
  }
  int get() {
    std::lock_guard lock{lock_};
    return ...;
  }
};

а в один прекрасный момент решили заменить std::mutex на some_spin_lock, и поменяли только одну строку:

class data_holder {
  some_spin_lock lock_;
  ...
  // Все остальное остается без изменений.
};

S>>ЗЫ. Можно провести аналогию: приходит вчерашний школьник с минимальными знаниями в области высшей математики в НИИ, где сложными расчетами физических процессов занимаются. И руководитель подразделения, куда этот школьник попал, заявляет: ну все, вычисления с комплексной переменной не используем, а то наш новый юниор этого не поймет.

A>Ну это стрёмный конечно поход, но очень широко распространенный. Полно внутриконторских гайдлайнов, ограничивающих использование тех или иных фич в языке. Я даже не могу кого-то в этом сильно винить — людям надо выкатывать работающий код с теми программистами, которые у них есть, бюджета и времени на дополнительное обучение у них тоже нет. Им виднее

Мне казалось, что гайдлайны стремятся запрещать потенциально опасные вещи, например:

* исключения, т.к. дорого и непредсказуемо;
* динамическую память после фазы инициализации, т.к. дорого и непредсказуемо;
* рекурсию, т.к. в случае ошибки исчерпаем стек;
* while(true), т.к. в случае ошибки оказываемся в бесконечном цикле

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

Т.е. во вменяемых гайдлайнах во главу угла ставится рациональное зерно и объективные критерии.

А вот "чтобы даже юниор разобрался" так себе критерий, имхо.

Здравствуйте, so5team, Вы писали:

S>Я все-таки очень надеюсь, что CTAD вводили для того, чтобы придать большей гибкости языку. Грубо говоря, чтобы можно было писать так...

Да я в целом согласен, что и опытным разработчикам полезно будет, но останусь при мнении, что задумано это для упрощения жизни новичкам. Уж больно много на эту тему разговоров последнее время было. Про новый чистый простой язык, struggling to get out. Да все не вылазит он никак, каждая "упрощающая" фича идёт с вагоном своих особенностей. Имхо, люди стараются, но как-то получается не очень.

S>Мне казалось, что гайдлайны стремятся запрещать потенциально опасные вещи, например...

Видел как вообще шаблоны запрещали под предлогом code bloat. Ну вот такие представления у некоторых о потенциальной опасности. И ведь не возразишь, из шаблонов действительно код генерится. STL — частая жертва, ибо Степанов всякой фигни намутил (тут идут пара примеров инвалидации итераторов или ещё чего просто ужасного), а вот вам наш кривой велик, на нем езжайте. При чем велик реально кривой. Тут уж на кого нарвешься.

CTAD ввели с с++17
многие при многие компании все еще сидять на с++11
а некоторые почему то все еще на с++14, хотя я бы сказал он был версией фиксов для 11

тут не ожиданно даже в нвидии
https://old.reddit.com/r/cpp/comments/16xr6v6/c_jobs_q4_2023/k35tiby/

Technologies: C++14 (primary) and python (scripting, automation, CI) on Linux (Qnx on-vehicle). Bonus points if you know Bazel.

вообще для себя если я знаю что проект дальше виндовс линукс-64 не будет и не планируется
то еще можно с++20/23 взять и поюзать CTAD для тех же локов
но если я предполагаю что все таки может придеться в каком то будущем и для чего то аля арм собирать
то уже и вручную поставлю те же параметры шаблона в мютексе
бегать обновлят тулчейны и пересобрать всякие контриб библиотеки для проекта оно напрягает знаете больше чем удобновство языка

и вообще по наблюдениям на последние 17/20 версии только всякие hft ко переползают
у них там прям constexpr/consteval головного мозга

остальные если кодобаза старая то могут так же сидеть все еще на 11 версии

так что понятие новички не новички слишком притянуто

Здравствуйте, andyp, Вы писали:

S>>Мне казалось, что гайдлайны стремятся запрещать потенциально опасные вещи, например...

A>Видел как вообще шаблоны запрещали под предлогом code bloat.

Так ведь когда-то давно так и было, на заре появления поддержки шаблонов в компиляторах. Быстро исправили, но "осадочек остался"

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

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