Pull to refresh

Comments 82

0x3

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

наверное должно быть что то типа:

int a = index;

++index;

a = a + pockets[index];

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

Вот тоже так показалось.

Как вараинт

int a = index + pockets[index + 1];

поскольку index передается по значению и что с ним делается внутри функции наверх не пробрасывается (т.е. от нас не ждут что index после вызова функции увеличится).

Хотя именно такие вещи несколько бесят - не должна оптимизация ломать логику. Поскольку явного приоритета операций тут нет, выполняться они должны слева направо. Т.е.

  1. Присваиваем a значение index

  2. Увеличиваем index на 1

  3. Прибавляем к a значение pockets[index]

Любое другое поведение есть нарушение порядка операций.

Без понятия sequence point трудно определить правильный порядок операций. Так что не нарушаем его, и не будет никакого UB.

Где-то сказано что получение значения элемента массива имеет приоритет над сложением? Нет. Значит эти операции равноприоритетны. И выполняться должны именно в том порядке, в каком указаны. И

int a = index + pockets[++index];

и

int a = pockets[++index] + index;

должны гарантированно давать разный результат. Вне зависимости от настроек оптимизации.

Иначе начинается угадайка "обмани компилятор".

должны гарантированно давать разный результат

ага, щас https://godbolt.org/z/eccT9hfP8


Эта строка — UB, и компилятор может вычислять её как угодно


https://en.cppreference.com/w/cpp/language/eval_order


2) If a side effect on a memory location is unsequenced relative to a value computation using the value of any object in the same memory location, the behavior is undefined
n = ++i + i;      // undefined behavior

Ну так они и дают разный результат! Каждый раз разный! "Прокатный стан для труб различного диаметра".

Не путайте, пожалуйста, лево-право-ассоциативность и порядок выполнения.

Ассоциативность влияет только на расстановку скобок, и всё.

А порядок выполнения может быть каким угодно.

Например, для fastcall и cdecl - когда более правые аргументы кладутся на стек раньше более левых (чтобы в памяти идти по возрастанию адресов), - естественный порядок будет справа налево. А для stdcall - наоборот.

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

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

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

Это не тестовое задание ни в коем случае. Это понять как человек думает, его способность к алгоритмизации.

Есть люди (вроде меня), которые получив какую-то задачу на первое время впадают в состояние абсолютного тумана в голове. Нет никаких внятных мыслей, в голове роятся разрозненные отрывки из обрывков. Вроде "так, если здесь вот это, то..." и потом обрывается, а вместо этого приходит "а вот если здесь вот так, то..." и потом опять обрывается, чтобы смениться следующим обрывком совсем другой мысли. И так длится какое-то время (в зависимости от задачи от десятка минут до нескольких дней, а то и недель). Чтобы потом внезапно (действительно внезапно, это не фигура речи) туман вдруг отступил и проявились очертания вполне себе четкого решения и вот уже дальше все идет "как по писанному".

Так вот проблема в том, что если в момент "тумана в голове" у меня кто-то будет выпытывать логические построения, то выглядеть я буду, мягко говоря, идиотом. Пык-мык и "не знаю", "не думаю", "не представляю" + рисование ничего не значащих каракулей на бумаге.

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

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

Ну вот это для меня и интересно. Мне не нужен "правильный ответ". Мне нужно понять как человек будет думать. Потому что мне потом с ним работать и хочется примерно представлять ход мыслей "товарища по команде".

Лично для меня собес это не "ответил правильно на семь вопросов из десяти", а понять человека. На что он в принципе способен, насколько с ним можно что-то обсуждать.

И подискутировать "а если тут вот так, то что?" в процессе считаю совершенно нормальным.

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

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

Мне нужно понять как человек будет думать.

Так в том-то и дело, что с некоторыми людьми вы этого не поймете. Лучший способ взаимодействовать с ними -- это дать задачу и позволить скрыться с глаз на какое-то время. Чтобы он потом вернулся к вам с решением. И уже решение можно будет обсудить. Именно решение. Пути его поиска вы не увидите. Потому что в явном виде его нет (пути этого самого): сначала ничего нет, туман и путаница, а потом "Хоп!" и вот же оно же ж.

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

Вопрос в том что мне не нужно решение. Мне нужно понять как человек к нему приходит. Ну мало у нас задач, которые сразу можно решить. А "олимпиадные" задачки оторваны от жизни.

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

Да и задачки не настолько сложные алгоритмически чтобы голову ломать. Скорее на выбор правильного архитектурного подхода. И даже если человек скажет "можно вот так, а можно вот этак, зависит от ..."

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

Ну как пример.

Нужно из БД сделать выборку по определенным условиям. В нее попадет порядка 10 000 000 записей. Каждую нужно определенным образом обработать (обработка одной записи никак не связана с обработкой остальных). Скорость обработки порядка 1 000 записей в секунду. Нужно уложиться в полчаса. Как?

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

Т.е. вот такого плана беседа, а не "сортировка пузырьком" и не "разворот строки или списка".

Вопрос в том что мне не нужно решение.

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

Нужно из БД сделать выборку по определенным условиям. В нее попадет порядка 10 000 000 записей. Каждую нужно определенным образом обработать (обработка одной записи никак не связана с обработкой остальных). Скорость обработки порядка 1 000 записей в секунду. Нужно уложиться в полчаса. Как?

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

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

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

Ну и речь не о том, что ваш подход не правильный (или что он самый правильный). Речь о том, что есть условия, когда вы не получите того, чего желаете. Но это ничего не скажет о пригодности соискателя.

Плюсик поставил. Сочувствую вашим попыткам объяснить, сам такой же. Люди этого не понимают.

Возможно, просто редко сталкиваются.

Мы думаем медленно, но очень хорошо.

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

Значит это человек не того уровня, который мне нужен.

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

Мне не нужно сразу проработку. Это уже предмет дальнейшей дискуссии. Если он не может сразу выбрать правильное направление, ну что ж...

Вы поймите - есть типовые задачи и есть типовые их решения. И есть сроки. Если человек на типовую задачу ждет "озарения" - это не то что тут нужно.

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

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

dcl-ds dsSample qualified;
  fld1   varchar(50);
  fld2   char(50);
end-ds;

...

clear dsSample;
dsply %char(%len(dsSample.fld1));

Более того, вряд ли кто сможет сказать почему результат будет 16448 :-)

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

А что скажет? Умение угадывать как будет оптимизирован тот или иной кусок кода тем или иным компилятором при тех или иных установках? Умение написать сортировку пузырьком или разворот списка? 100500 вызубренных задачек с литкода? Так нам в нашей реальной жизни все это малопригодно.

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

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

Если я буду что-то спрашивать типа того, что привел выше, то буду стараться выбирать ту тему, в которой у человека уже есть какой-то опыт (с его слов).

И что он ответит не будет решающим критерием "берем-не берем". Скорее просто понять общий уровень. А брать-не брать это уже решается голосованием потом, в команде. По общему впечатлению.

Как ни странно, но это работает.

Значит это человек не того уровня, который мне нужен.

Очевидно так.

Очевидно, что вы меня не услышали.

Ну вы тоже не хотите слышать.

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

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

вообще замолчит на полчаса и займется рисованием каракулей на бумаге

ибо если так, то это точно не тот кто нужен.

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

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

Ну вы тоже не хотите слышать.

Это не так.

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

Вообще-то я вам указал на другое, а именно:

Лично мне всегда интересно как человек будет подходить к решению той или иной конкретной задачи.

И, тем более, с конкретным примером:

Нужно из БД сделать выборку по определенным условиям. В нее попадет порядка 10 000 000 записей. Каждую нужно определенным образом обработать (обработка одной записи никак не связана с обработкой остальных). Скорость обработки порядка 1 000 записей в секунду. Нужно уложиться в полчаса. Как?

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

Так вот, я вам о том, что есть люди, для которых "рассуждения в слух" не есть не то, что привычно, но это даже и ненормально.

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

Но когда нужно сделать задачу в заданном объеме и в заданный срок - все... "Озарение не снизошло" вовремя и сроки все сорваны.

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

Приведу пример из школы: есть класс, есть урок родного языка. Есть задача написать за 45 минут сочинение на некую тему. По итогу напишут его все равно все, хуже или лучше, но все. Однако, кто-то начнет писать сразу и у него повествование начнет выходить "прямо из под пера", а кто-то задумается минут на 10 и, возможно, несколько строчек накарябает в черновике, зато потом начнет строчить не останавливаясь, потому что у него уже все продумано.

Оценивать же нужно результирующее сочинение, а не процесс его написания.

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

Я конечно не вот чтобы программист, но откуда в задаче 0xA вообще берётся переменная i, если аргумент функции - l (строчная L)?

Но в целом да, задачки забавные. Реально решил только первые четыре...

Это синтаксический сахар для this->i. Аргумент игнорируется.

То есть, сколько бы Геральт не запросил в аргументе функции, он всё равно получит сто монет?

По замыслу да, но в данном случае не получит, вместо этого вселенная исчезнет из-за прикосновения к Великому Ничто.

в А_что_не_так тоже стоит поправить

Хорошие у вас задания.

Про 0х3... уже писали , предложу уточнение по 0х5...

Правильное решение на мой взгляд у вас страдает избыточным выделением памяти. Что бы нам мешало написать display_string(str_func().c_str()) и временное значение сохраняется до окончания выражения по стандарту.

Это не задания, это темы для поговорить;) задания у нас в джире

0x1

Первый элемент массива пропущен


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

Занятно, что подсветка синтаксиса на Хабре попалила второй sayHello.

первым элементов была сама сказка :)

подсветку отключил, давайте уровняем возможности редакторов хабра и vs. В 90% говорили код не соберется и всего несколько человек попросили ноут

Я правильно понимаю, что вы из игростроя?

Игрострой накладывает какой-то собственный отпечаток на то, какие вопросы задают на собеседовании.

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

С узкими специалистами куча проблем. Со стороны руководства: 1)комплектовать команду узких специалистов сильно сложнее 2)делать равномерную загрузку узких специалистов значительно сложнее 3)при нехватке/перегрузке узких специалистов по какой-то одной вещи может встать много задач, которые в нее упираются 4)задачи, требующие знаний в разных областях, некому решать. Со стороны спеца: 1)сложнее искать работу, потому что в нужный момент спрос на рынке может быть слишком мало подходящих вакансий 2)знания могут устареть, и тогда углубление в технологию будет напрасным 3)может быть банально скучно копать что-то одно все время.

Вы знаете, я плюсанул обе статьи, спасибо. Но когда мне на одном собеседовании начали задавать такие задачки, мол что делать с таким кодом, как его исправить, я в какой-то момент не выдержал и сказал: бить линейкой по рукам того кто так пишет (уточнив что это шутка, но тем не менее). И добавил: если у вас такой код в продакшене, то вы не умеете C++ и нам с вами не по пути. Предложил на этом закончить собес и поблагодарил за вкусный кофе.

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

Был недавно на нескольких собесах. На одном сначала спросили про паттерн стратегия с минимальным примером. А потом начали спрашивать, знаю ли я зачем нужно слово virtual. Мы с компанией друг другу не подошли, тем более что они предложили сильно меньше моих ожиданий для той позиции. На другом собесе (на senior) позицию самым сложным оказалось написать тривиальную функцию уровня самой простой задачи с leetcode. Но на своей практике я знаю что намного важнее уметь проектировать и писать удобный для переиспользования и читаемый код, чем реализовывать определенные алгоритмы (с этим и сильный джун справится).

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

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

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

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

Поэтому на первый план выходят адекватность и "отделопригодность"( называйте как хотите - умение работать в команде, личная приязнь, неконфликтность и тд), если рокстар будет писать код/принимать решения/ставить задачи, от которого страдают все, то будет плохо в итоге всем. И рокстару тоже.

я в какой-то момент не выдержал и сказал: бить линейкой по рукам того кто так пишет

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

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

Использование операций пред- и пост-инкремента в программах не рассчитанных на исполнение на компьютерах серии DEC PDP (либо других системах с автоинкрементом) является одним из смертельных грехов программирования. Наряду с закомментированным кодом, использованием оператора goto и т.п. Ещё как-то можно оправдать код, где эта операция составляет целое выражение. Но, то что предложил автор — это конечно ни в какие ворота. Он сам и указал причину: никто не может заранее предсказать, какой будет результат выполнения этого кода.

видел такое несколько раз в пром коде

Интересно зачем так делать. Экономия строчек в исходнике?

Однако, поскольку поскольку указатель в файле остался на прежнем месте в конце, то попытка прочитать данные из конца файла приведет к UB.

К какому же UB это приведёт, если поведение в данном случае вполне определено?

0х2...

 if (my_legs < 0) {
    return -my_legs;
  }

Что вернёт функция, если my_legs == - 2^31?

Зависит от платформы. int не обязан быть 32-битным.

В 0x4 начиная с C++20 не нужен std::cin.width(), все работает само: https://en.cppreference.com/w/cpp/io/basic_istream/operator_gtgt2

В 0x8, мне кажется, любой нормальный человек использовал бы wait_for, принимающий лямбду с условием, хотя это и не "одно слово".

В 0xC __end - зарезервированное имя, http://eel.is/c++draft/lex#name-3

что есть то есть, из FMOD код не выкинешь

Я не плюсовик, но вообще -my_legs для INT_MIN должен выкинуть исключение. И как оно вообще компилируется, если там не для всех веток return есть? Или в плюсах это норма?

Или в плюсах это норма?

От флажков компилятора зависит.

К сожалению - компилируется. Обратная сторона медали: в языках где return требуется во всех ветках, может не компилироваться валидный код типа `f() { while (true) {return 1;} }`. В таких местах приходится дописывать избыточный return.
Но лично мне более удачным кажется выбор языков, где return требуется везде - больно уж легко его случайно потерять.

Если у вас программа всегда идёт по одному пути, то зачем делать развилку, которая потом и попросит лишний return?

То же приведенный пример можно сократить до return 1;

Murphy's law же: anything that can go wrong will go wrong

Про INT_MIN: Если бы так было, то на каждый вызов наворачивались бы лишние скрытые проверки. В случае если заранее известно что входной my_legs из определённого валидного диапазона это просто резало бы перф... A так да - это UB.

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

Маленькое окошко, в которое помещается только одна голова в регистратуре.

0x8 поле Foo::next не должно быть volatile?

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

Какое же минное поле эти Плюсы, не устаю поражаться... UB там, UB тут, о, и здесь тоже он.

И каждые три года вот вам новый стардарт со свежими UB.

Зато обратная совместимость с Си.

А вы думаете соседнее поле с бемолями менее минное?

Ну, я последние лет 10 писал на Go/Rust и там с этим вроде как всё сильно получше, если не лезть во всякие unsafe

Конечно.
Там запрещено забывать return в каких-то ветках функции.
Там невозможно обратиться к неинициализированной переменной.
Разыменовывание null даёт вполне определённый вид исключения, а не UB.
и т.д...

это что, в новом C++23 добавили специальную функцию которая делает UB по требованию разработчика! std::unexpectedна случай если разработчик не может придумать как сделать UB :)

https://en.cppreference.com/w/cpp/utility/expected/unexpected

все для людей, Комитет не дремлет. @Antoshkaно зачем?

там на cppreference написано же. Чтобы позволить компилятору писать более оптимальный короткий ассемблерный код

например,

int abs_legs(int my_legs) {

if (my_legs < 0) {

return -my_legs;

}

std::unexpected();

}

это подсказка компилятору что abs_legs() никогда не будет вызвана с положительным аргументом; с другой стороны читающий код тоже видит что в std::unexpected() никогда нить выполнения не попадёт (по крайней мере не должна) в std::unexpected(). Но при этом в случае my_legs - отрицательный (как ожидается), то код будет абсолютно валидным

Вроде как для этих целей давно работает более гибкий вариант
assert(false);

Напоминает макросы likely / unlikely в ядре Linux. Да и в крестах вроде что-то такое было вроде, аннотации типа [[likely]]

Хотя нет, они чисто для branch prediction, а тут вообще "второй бранч не будет вызван никогда". Но, по идее, надо просто такой код не писать...

Да, похоже, но есть отличие. Likely используется в случае если нужно указать компилятору более вероятную ветвь для более эффективного когда.

В случае "std::unreachable" вообще никакого кода сгенерировано не будет на этот случай (или будет), на то это UB.

https://youtu.be/ohMyb4jPIAQ?si=yaD5FFuMgqV5F8qG

Это было интересно. Обычно, я что-то такое пишу. А тут довелось самому поиграть в угадайку. Спасибо.

Кстати, пример с int a = index + pockets[++index]; напомнил мне про наш один вопрос - Глубина кроличьей норы или собеседование по C++ в компании PVS-Studio :)

P.S. А кому интересно узнать про глубину глубин с Unicode, приглашаю сюда - Атака Trojan Source для внедрения в код изменений, незаметных для разработчика.

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

тут в 0x2 две проблемы на самом деле

int abs_legs(int my_legs) {

if (my_legs < 0) {

return -my_legs;

}

}

кроме `return my_legs` в случае если часло положительное нужно ещё расмотреть случай когда my_legs == std::numeric_limits<int>::min()

не отрицательные числа могут быть представлены в виде положительных, а именно -2^31 при отрицании будет ОПАНА ПЕРЕПОЛНЕНИЕ. А переполнение не просто переполнение, а именно Undefined Behaviour и это больно

тут в 0xC тоже две проблемы:

for (auto format = begin(formats), __end = end(formats); format != __end; ++format) {

переменные начинающиеся с двух знаков подчёркивания зерезервированы для стандартной библиотеки и внутренного использования. Поэтому __end ПЛОХО!

надеюсь разработчики FMOD в курсе этого

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

Однако, поскольку поскольку указатель в файле остался на прежнем месте в конце, то попытка прочитать данные из конца файла приведет к UB

Неправда:


Errors are signaled by modifying the internal state flags, except for (3), that never sets any flags (but the particular manipulator applied may):
eofbit: The input sequence has no more characters available (end-of-file reached).

Его можно настроить бросать исключения, но это никогда не будет UB.

Столько букв. А про что вообще статья? Какие выводы, результаты... Какая проблема решается?

PS Тема "собеса наоборот" прерывается на самом интересном месте. Поэтому не раскрыта. Знал ли кандидат заранее, что будет такой формат, или нет? От этого тоже многое зависит.Осталось много вопросов. Много рассказано про компанию, про Мишаню, подробно, про детали темы мимоходом. Тройка за подачу материла, начало вообще поток сознания.

Only those users with full accounts are able to leave comments. Log in, please.

Articles