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

R>Да-да, было дело. Помнится, мы вот такую поделку мастырили, чтоб ограничить область видимости:
Экие затейники! Я с таким подходом не встречался.

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

Pzz>Повторюсь: сам дурак.

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

S>>PS. На счет говнокода и Go. Случайный файлик из списка проектов на который вы сослались. Функция на 200 строк из которых изрядный процент как раз if-ы с return err. Красота.

Pzz>Такой код совсем немного сложнее писать, но зато значительно проще читать и отлаживать, поскольку всё эксплицитно.

Код с функциями по 200 строк -- это говнокод. Вот просто говнокод и все.

И, что плохо, сам язык это провоцирует. Вот сейчас на С++ пишу что-то вроде:

auto container = special_container::make(chunk_size);
auto writer = container->mutable_accessor();
writer->add(val1);
writer->add(val2);
...
commit(std::move(writer));

Тогда как на Go аналогичный фрагмент выглядел бы как-то так:

container, err := special_container.Make(chunk_size)
if err != nil {
  return err
}
writer, err := container.mutable_accessor()
if err != nil {
  return err
}
err := writer.add(val1)
if err != nil {
  return err
}
err := writer.add(val2)
if err != nil {
  return err
}
...
err := commit(writer)
if err != nil {
  return err
}

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

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

R>>Да-да, было дело. Помнится, мы вот такую поделку мастырили, чтоб ограничить область видимости:
_>Экие затейники! Я с таким подходом не встречался.

Это Паша Кузнецов придумал. Работали с ним в одной конторе некоторое время.

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

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

В С++ существуют определённые практики, которые нарабатывались годами мировым сообществом программистов С++. Все эти наработки рационально обоснованы и не дураками придуманы. Ты всё это отметаешь на том лишь основании, что тебе это непривычно. А дискутировать о полезности const в 2025 году — это вообще очень странно, как по мне.

P.S. Я на протяжении многих лет рекомендовал и продолжаю рекомендовать всем вот эту книженцию: Стандарты программирования на С++. 101 Правило и рекомендация

Автор(ы): Герб Саттер, Андрей Александреску

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

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

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

S>Тогда как на Go аналогичный фрагмент выглядел бы как-то так:

Я бы во writer-е внутри сделал sticky error, которая устанавливается при первой ошибке и залипает, и гошный код у меня выглядел бы почти как плюсовый. Ошибку возвращал бы writer.commit.

И да. Забыл совсем. Сам дурак.

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

Pzz>Я бы во writer-е внутри сделал sticky error, которая устанавливается при первой ошибке и залипает, и гошный код у меня выглядел бы почти как плюсовый. Ошибку возвращал бы writer.commit.

Правильно ли я понимаю, что если бы в цикле add вызывался миллион раз, а commit был после окончания цикла, то с этим вашим sticky error вы бы выполнили весь миллион операций и только после этого узнали бы про возникновение ошибки?

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

Pzz>И да. Забыл совсем. Сам дурак.

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

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

Pzz>>Я бы во writer-е внутри сделал sticky error, которая устанавливается при первой ошибке и залипает, и гошный код у меня выглядел бы почти как плюсовый. Ошибку возвращал бы writer.commit.

S>Правильно ли я понимаю, что если бы в цикле add вызывался миллион раз, а commit был после окончания цикла, то с этим вашим sticky error вы бы выполнили весь миллион операций и только после этого узнали бы про возникновение ошибки?

А у вас там что, прям миллион вызовов writer.add в столбик написано? Тогда у вас, наверное, проблемы со сборкой, программа в голову компилятора не лезет.

А если там один add в цикле с миллионом проходов, никто не мешает этому add-у тоже ошибку добавлять, для таких случаев.

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

S>Скажите, а вы вообще когда-нибудь занимались проектом, в котором было бы хотя бы 100KLOC написанного вашей командой кода? Т.е. именно проектного кода, без учета зависимостей?

А вы вообще когда-нибудь зимались самостоятельным проектом, в котором вы с нуля и основные решения приняты вами или под вашим руководством?

Pzz>>И да. Забыл совсем. Сам дурак.

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

Вы, вьюноша, чрезмерно категоричны и дурно воспитаны.

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

S>>Правильно ли я понимаю, что если бы в цикле add вызывался миллион раз, а commit был после окончания цикла, то с этим вашим sticky error вы бы выполнили весь миллион операций и только после этого узнали бы про возникновение ошибки?

Pzz>А у вас там что, прям миллион вызовов writer.add в столбик написано?

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

Pzz>А если там один add в цикле с миллионом проходов, никто не мешает этому add-у тоже ошибку добавлять, для таких случаев.

Т.е. ваш sticky error -- это еще и контейнер накопившихся ошибок.
Правильно понял?

S>>Скажите, а вы вообще когда-нибудь занимались проектом, в котором было бы хотя бы 100KLOC написанного вашей командой кода? Т.е. именно проектного кода, без учета зависимостей?

Pzz>А вы вообще когда-нибудь зимались самостоятельным проектом, в котором вы с нуля и основные решения приняты вами или под вашим руководством?

Да, с самого начала своей профессиональной карьеры в 1994-ом году практически только этим и занимаюсь, за редким исключением.

Вы на заданный вам вопрос ответите?

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

Pzz>Вы, вьюноша, чрезмерно категоричны и дурно воспитаны.

Да. Мы, простые деревенские парни из Полеских болот без образования и хороших манер, именно такие.

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

Pzz>>А у вас там что, прям миллион вызовов writer.add в столбик написано?

S>Не думал, что в словах "если бы в цикле add вызывался миллион раз" может быть что-то непонятное.
S>Не в столбик, а именно что в цикле. Например, в цикле читаются данные из источника (файла, например) и добавляются в контейнер. Один add на каждой итерации.

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

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

Pzz>>А если там один add в цикле с миллионом проходов, никто не мешает этому add-у тоже ошибку добавлять, для таких случаев.

S>Т.е. ваш sticky error -- это еще и контейнер накопившихся ошибок.
S>Правильно понял?

Вот вы приписываете мне дурацкие идеи, которые сами и придумали, а потом героически их разоблачаете.

Нет, конечно. Если случилась sticky error, то все, writer сломался. После этоги будет игнорировать все дальнейшие действия, возвращая всё ту же ошибку, пока его не разрушат или не обресетят (если предполагается возможность обресетить и дальше использовать).

S>>>Скажите, а вы вообще когда-нибудь занимались проектом, в котором было бы хотя бы 100KLOC написанного вашей командой кода? Т.е. именно проектного кода, без учета зависимостей?

Pzz>>А вы вообще когда-нибудь зимались самостоятельным проектом, в котором вы с нуля и основные решения приняты вами или под вашим руководством?

S>Да, с самого начала своей профессиональной карьеры в 1994-ом году практически только этим и занимаюсь, за редким исключением.

S>Вы на заданный вам вопрос ответите?

Ваш вопрос хамский. Нет, не отвечу.

Pzz>>Вы, вьюноша, чрезмерно категоричны и дурно воспитаны.

S>Да. Мы, простые деревенские парни из Полеских болот без образования и хороших манер, именно такие.

Не знаю, из каких вы там болот. Я видел живого бизона (или зубра? все время их путаю) с тех самых болот. Он не был категоричен и дурно воспитан, но внушал уважение всем своим видом.

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

Pzz>Если один add на каждой итерации, есть смысл после каждого add-а проверять.

Читаем написанное вами ранее:

Я бы во writer-е внутри сделал sticky error, которая устанавливается при первой ошибке и залипает, и гошный код у меня выглядел бы почти как плюсовый. Ошибку возвращал бы writer.commit.

и видим явное противоречие.

Pzz>>>А если там один add в цикле с миллионом проходов, никто не мешает этому add-у тоже ошибку добавлять, для таких случаев.

S>>Т.е. ваш sticky error -- это еще и контейнер накопившихся ошибок.
S>>Правильно понял?

Pzz>Вот вы приписываете мне дурацкие идеи, которые сами и придумали, а потом героически их разоблачаете.

Как раз чтобы не приписывать я и задаю уточняющие вопросы, т.к. мне было неочевидно, что значит "никто не мешает этому add-у тоже ошибку добавлять".

Pzz>Нет, конечно.

Уже легче.

Pzz>Если случилась sticky error, то все, writer сломался. После этоги будет игнорировать все дальнейшие действия, возвращая всё ту же ошибку, пока его не разрушат или не обресетят (если предполагается возможность обресетить и дальше использовать).

Но 1000000 итераций мы все равно будем вынуждены делать, т.к. снаружи наличие этого sticky error будет видно только в момент коммита.

Прэлесно, просто прэлесно.
Если раньше опытным путем было выяснено, что в /dev/null можно сходу отправлять ваше мнение по поводу C++, то теперь выяснилось, что туда же можно отправлять и ваше мнение по поводу программирования вообще.

Не удивлюсь, если у вас в прошлом отличное образование математика или физика.

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

S>Но 1000000 итераций мы все равно будем вынуждены делать, т.к. снаружи наличие этого sticky error будет видно только в момент коммита.

type writer struct {
    err error // Sticky error
    . . .
}

func (w *writer) add(v value) error {
    if w.err {
        return w.err
    }

    // Do add logic
    w.err = do_add_logic(...)

    return w.err
}

func (w *writer) commit() error {
    if w.err == nil {
        w.err = do_commit_logic(...)
    }

    return w.err
}

func add_million_values(w *writer, src source) error {
    var err error
    for err == nil {
        var v value
        v, err = src.next()
        if err == nil {
            err = w.add(v)
        }
    }

    if err == nil {
        err = w.commit()
    }

    return err
}

func add_grouped_values(w *writer, values vgroup) error {
    w.add(values.v1)
    w.add(values.v2)
    w.add(values.v3)
    return w.commit()
}

S>Не удивлюсь, если у вас в прошлом отличное образование математика или физика.

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

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

SP>

SP>

SP>enum class Type {
SP>    Unknown,
SP>    _1,
SP>    _2,
SP>    _3
SP>};
SP>Type parse(int flag) {
SP>    switch (flag & 3){
SP>        case 0: return Type::_1;
SP>        case 1: return Type::_2;
SP>        case 2: return Type::_3;
SP>    }
SP>}
SP>

Ну значение 3 тут может оказаться, если flag==3
А прикинь такой же пример только не & а %.

А ты тоже думаешь, ну там по любому не бывает ничего кроме 0,1,2, по определению евклидова деления с остатком
А потом опа: parse(-1)

привет американской школе математики, которой пофиг на евклидово деление

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

R>P.S. Я на протяжении многих лет рекомендовал и продолжаю рекомендовать всем вот эту книженцию: Стандарты программирования на С++. 101 Правило и рекомендация

Автор(ы): Герб Саттер, Андрей Александреску

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

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

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

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

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

S>>"Не разрешают", а директивно заставляют говнокодить. Достаточно только на количество if err != null взглянуть.

Pzz>Это — вполне сознательное и аргументированное решение. Многократно публично обсуждавшееся.

Только вот никому оно не нравится, раз люди пытаются заменить его на check, try, ?. Но комитету по Го всё, видимо, нравится с текущим говнокодом положением дел, что они забанили любые попытки улучшать: https://go.dev/blog/error-syntax. И аргументация к "ничего не менять" просто прекрасна:

There are valid arguments in favor of the status quo:

If Go had introduced specific syntactic sugar for error handling early on, few would argue over it today. But we are 15 years down the road, the opportunity has passed, and Go has a perfectly fine way to handle errors, even if it may seem verbose at times.

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

Pzz>Сколько там системных вызовов в венде? Последний раз, когда я интересовался, я слышал число 3500. Сейчас, наверное, уже 5000. Линукс как-то обходится 350-ми, и это прям много, но по историческим причинам разросся, увы.

user <-> kernel коммуникация в винде идёт через https://en.wikipedia.org/wiki/System_Service_Descriptor_Table. Количество сисколов там отличается от версии к версии, но можно самому посмотреть, ну или вот скриншот:



481 сервис (сискол).

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

·>А вот надо придраться! Код пишется для человеков, а не для компилятора. Мне, как человеку, хочется видеть надёжный очевидный код. Я предпочитаю, чтобы было тупо — скомпилировалось, значит работает.

Rust передаёт привет.

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

Pzz>

Pzz>type writer struct {
Pzz>    err error // Sticky error
Pzz>    . . .
Pzz>}

Pzz>func (w *writer) add(v value) error {
Pzz>    if w.err {
Pzz>        return w.err
Pzz>    }

Pzz>    // Do add logic
Pzz>    w.err = do_add_logic(...)

Pzz>    return w.err
Pzz>}

Pzz>func (w *writer) commit() error {
Pzz>    if w.err == nil {
Pzz>        w.err = do_commit_logic(...)
Pzz>    }

Pzz>    return w.err
Pzz>}

Pzz>func add_million_values(w *writer, src source) error {
Pzz>    var err error
Pzz>    for err == nil {
Pzz>        var v value
Pzz>        v, err = src.next()
Pzz>        if err == nil {
Pzz>            err = w.add(v)
Pzz>        }
Pzz>    }

Pzz>    if err == nil {
Pzz>        err = w.commit()
Pzz>    }

Pzz>    return err
Pzz>}

Pzz>func add_grouped_values(w *writer, values vgroup) error {
Pzz>    w.add(values.v1)
Pzz>    w.add(values.v2)
Pzz>    w.add(values.v3)
Pzz>    return w.commit()
Pzz>}
Pzz>

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

То есть, технически-то написанное логично, но из-за Go и их тупости — как бы тут ни написали, получается говнокод.

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

F>Только вот никому оно не нравится, раз люди пытаются заменить его на check, try, ?. Но комитету по Го всё, видимо, нравится с текущим говнокодом положением дел, что они забанили любые попытки улучшать: https://go.dev/blog/error-syntax. И аргументация к "ничего не менять" просто прекрасна:

У Go нет комитета.

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

F>Ну говнокод же получился, не? И я уверен, что не только воинствующие здесь сиплюсплюсники так считают, а и представители других ЯП.

А это точно не вкусовщина?

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

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

F>·>А вот надо придраться! Код пишется для человеков, а не для компилятора. Мне, как человеку, хочется видеть надёжный очевидный код. Я предпочитаю, чтобы было тупо — скомпилировалось, значит работает.
F>Rust передаёт привет.
Так в данном случае это только С/С++ с приветом. В остальных ЯП всё в порядке с return.