Я отвернулся от доски и увидел, что в переговорке я один. Через стеклянную стенку переговорки я разглядел интервьюера, который что-то быстро говорил секретарю, показывая пальцем в мою сторону. Он что, вызывает охрану? Похоже, что мне тут больше не рады.
А что если всё более прозаично — например, у автора есть привычка вроде «ругать пятиэтажным матом всё вокруг» или «вести себя странно» в момент сосредоточенного обдумывания задачи, чего он сам может не заметить и что на самом деле было причиной такого поведения интервьюера? Вот представьте картину со стороны интервьюера: даёте вы человеку задачу — он задумался, ушел глубоко в свои размышления и внезапно начал задумчиво корчить рожи, грызть листочек, почесывать ногой нос и вообще лезть на потолок. Может интервьюер после увиденного не охрану звал а экзорциста;) Это конечно всё шутка, но хотелось бы отметить — я на своем примере знаю, что когда я слишком сосредоточен, то не отдаю себе отчёт в совершаемых действиях (примеры: пошел налить кофе — насыпал кофе в сахарницу и выбросил кружку в мусорное ведро. Или в процессе обдумывания разгрыз карандаш в щепки с угрожающим выражением лица, и т.п.)
А потом окажется, это был не тот камаз, переделывай. И грузить надо было только песчинки с 16 углами, остальные — вернуть на место. Или занести каждую песчинку и ее количество углов в эксель, чтобы кто-то мог построить красивые графики. В итоге, на одной из таких итераций даже у такого несгибаемого джуна где-то в мозгу что-то зашевелится и в следующий раз он попытается всё уточнить до того, как снова возьмется за ледоруб (наивно полагая, что в момент погрузки не прилетят новые требования). Осознание бесполезности работы в таких ситуациях убьёт любую оставшуюся мотивацию и приведёт к написанию на хабре статьи «как я выгорел в свои 21».
Забавный момент: внезапно, Ѳ (Фита) была в петровские времена в составе русского алфавита, да и читалась близко к нашей Ф (ферт):
Пётр I, вводя гражданский шрифт, сперва (1707—1708) отменил букву «ферт» (Ф), сделав фиту единственным способом выражения звука [ф]; но вскоре (1710) различие Ф/Ѳ по церковнославянской системе было восстановлено. Орфографические же реформы 1917—1918 гг., наоборот, упразднили фиту с повсеместной заменой её на Ф.
К слову о том, что мне конкретно не понравилось в том туториале — как по мне, для начала стоило бы начать с оперируемых сущностей, чтобы можно было четко сформулировать понимание того, зачем они нужны, с приведением архитектурно-понятных аналогий. Например, начать с этой схемы, обведя в ней своею рамочкой, какие сущности как по смыслу сгруппировать, где что используется. Пробежаться вкратце по всему сразу. Если можно, параллельно привести аналогии из OpenGL. Цель — от общей картины постепенно переходить к деталям, а не как на том сайте — «вот на этом этапе нам надо создать эту хрень, значит создаём. Она нам понадобится в будущем». Подход того туториала похоже на «вот эту деталь несите сюда, ту прикрутите туда, а что именно мы собираем — объясню и покажу в конце». За деревьями леса не видно. Также минус — там пишут код «с заделом на будущее», а потом непонятно какие части его заменяются; приходится открывать ссылку на готовый cpp-файл, что приведен внизу страницы, и самостоятельно соотносить, где что. Опять же, все вышеперечисленное очень субъективно.
Как я понял, вы, по сути, решили перевести вот этотсайт целиком. Как раз по нему изучаю вулкан, но там в туториале, как по мне, много вещей не объясняется, либо объясняется сумбурно, в стиле «но вот тут у нас девайс еще занят обработкой предыдущих кадров, поэтому тут мы передаем VkFence, а вот туда — VkSemaphore», и во многом это выглядит как «доверься мне и пиши так, как я сказал, объясню в следующих главах (но не факт)». Код примера во многом синтетический, не очень хорошо объясняется, как архитектурно разбить получающуюся в туториале портянку кода. Вообще не видел примеров того, как тут сработать с многопоточностью, чего очень бы хотелось. Например, могу ли я создать VkDevice один для всех потоков, или должен создавать по одному на поток? Ну и еще куча попутных вопросов. Кстати, в комментарии под статьями там тоже стоит заглянуть. Помимо этого хотелось бы оставить ссылку на репозиторий V-EZ, там есть хорошая документация и проекты с примерами.
Соглашусь и добавлю: умение правильно составить вопрос так, чтобы гугл тебе выдал ссылку именно на то, что ты хотел найти — в наше время тоже навык. Создается впечатление, что гугл ищет по принципу «перемешать все слова из запроса и составить список самых популярных совпадений». Вот ищешь ты запрос в стиле «как на С++ из А сделать Б», а гугл выдает тебе страницу исключительно с ответами «Как из Б сделать А», при этом выкинув «с++» даже порою взятый в кавычки, как что-то ненужное. Ему же виднее, что ты хотел найти…
Я следую такому правилу: если мне дают задачу на проекте, где уже Windows.h включен, то выход один — смириться. Но в таких проектах также и порядок включений может отличаться от предпочитаемого мной — тут, само собой, я буду писать код в соответствии с их кодстайлом. В своих проектах, где я потенциально расчитываю в будущем портировать это на другие платформы, я соблюдаю гигиену — я могу сдублировать typedef'ы из Windows.h, а порой даже (если нужна именно структура оттуда) — в своем заголовочном файле вместо него ввести сырой массив такого же размера, приправленного static_assert(sizeof() == sizeof()) внутри cpp-файла.
Пример:
// lock.h
// Копирую typedef из Windows.h, но не включаю его
typedef struct _RTL_CRITICAL_SECTION CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
class Sync
{
public:
// В x64 и x86 структура имеет разный размер
template<int = sizeof( size_t )>
struct ArchHelper;
template<>
struct ArchHelper<4>
{
// 32-bits operations
constexpr static size_t CRITICAL_SECTION_SIZE = 24U;
};
template<>
struct ArchHelper<8>
{
// 64-bits operations
constexpr static size_t CRITICAL_SECTION_SIZE = 40U;
};
constexpr static size_t CRITICAL_SECTION_SIZE = ArchHelper<>::CRITICAL_SECTION_SIZE;
//...
CRITICAL_SECTION* GetCriticalSection() const;
private:
// Сырой массив
mutable unsigned char m_criticalSectionBuffer[ CRITICAL_SECTION_SIZE ];
//...
};
Вы хотите сказать, что нижестоящие хедеры ожидают того, что перед ними будет стоять windows.h?
#include <Windows.h> //< переопределяет min/max
#include <vector> //< написан так, чтобы учесть все
// возможные переопределенные макросы?
#include "myHeader.h" //< тоже должен учитывать? Да ну нафиг...
Просто я в своих проектах принципиально не использую precompiled headers, какие у них преимущества?
В Японии есть "налог на телеприемники": покупая, например, телефон, через который возможно принимать телесигнал (через наушники как антенну), вы обязаны заключить контракт с NHK и платить за каждое устройство отдельно, даже если вы этим не пользуетесь
Хм, из вышеперечисленных правил я не согласен со следующими:
Порядок #include: сперва объявляю парный *.h (если это *.cpp), потом прочие зависимости из проекта (все, что в двойных кавычках) и только после этого — стандарные заголовки (все, что в <>). Причины тут две:
Системные заголовки типа Windows.h грешат засильем макросов, тихо подменяя имена внутри включенных заголовков, выбрасывая противные ошибки компиляции/линковки. Пример — макросы min/max.
Как раз ради самодостаточности заголовочного файла. Опять же, #include <vector> будет незаметно включен во все другие заголовочные файлы, объявленные ниже, что не есть хорошо.
Наоборот, использование forward declaration везде, где возможно (исключение — если заголовочный файл гарантированно не может своими включениями создать перекрестный include). Опять же, лечить перекрестные зависимости — тот еще геморрой.
Если в коде заменить #include на предварительное объявление для структур B и D, то test() будет вызывать f(void*).
Надеяться, что компилятор узнает о наследуемости без include и использование void* в таком месте — как мне кажется, ССЗБ. Я понимаю, когда void* используют исключительно с POD-типами — я обычно такое заворачиваю в шаблонный метод с std::enable_if_t<std::is_trivially_copyable_v<T>> или добавляю static_assert (предпочитаю этот вариант, ибо можно выкинуть человекопонятное сообщение об ошибке компиляции). Ведь так можно пойти дальше и случайно вызвать delete на таком void* и совершить прочие Undefined Behavior непотрёбства. Вообще, использование void* в плюсах — это как носить заряженный пистолет в кармане. Если уж носите, то не кладите в этот карман ничего другого (перегрузки функций) или купите ему кобуру (обложите static_assert-ами и прочее).
Структура кода, допускающая предварительное объявление (и, далее, использование указателей в качестве членов класса) может сделать код запутанным и медленным
Как правило, решение использовать указатель/ссылку/непостредственно тип при объявлении поля в первую очередь диктуется архитектурными соображениями, аргумент не засчитан
Предварительное объявление символов из std:: может вызвать неопределённое поведение.
Опять же, основная причина использования forward declaration — избежание перекрестных зависимостей. В случае со стандартной библиотекой этого можно не бояться и смело писать #include<string>.
Насчет inline-функций, как я понял, вообще лучше не использовать без необходимости (необходимостью считаю случаи, когда необходимо написать тело в пределах того же заголовочного файла, но по причине того, что взаимноконвертируемые типы ссылаются друг на друга, тело методов нужно вынести за пределы определение класса ниже объявления зависимого). Вроде как при включенной оптимизации и параметра генерации кода на этапе линковки линковщик сам разберется и заинлайнит все что надо — так я понял из ответов на SO, но все же некоторая неуверенность присутствует… Лично мне не нравится, когда внутренности геттеров торчат в заголовочном файле (в своем пет-проекте я во все функции добавляю макрос с ассертом для проверки текущего потока по маске, геттеры — не исключение). Помимо этого правила, ко всем вышеперечисленным я пришел опытным путем множественного наступания на грабли. Хотелось бы услышать стороннее мнение на этот счет.
Поэтому лично я забил на обычную доту и ушел в режим Абилити Драфт: хоть балансом там и не пахнет, а пик вообще решает всё — режим интересен тем, что больше упор идет на комбинирование скиллов с разных персонажей и полученный эффект синергии, которого нельзя добиться в нормальной игре (из-за существования скиллов, которые работают только в пользу их владельца, то есть их эффект не может быть «одолжен» союзнику). Тут весь тимплей больше сконцентрирован на этапе пика (не допустить взятия важных скиллов командой противника в том числе) и помощи в фарме «везунчику» из своей (кому на этапе пика достались мощные комбинации). Жалко лишь то, что как Вальве, так и большинство игроков не считают достойным внимания любой режим, где нет рейтинга. А ведь из него можно много «фишек» почерпнуть, которые можно применять в «настоящей» доте…
<ностальгия>
Мне это напомнило Космические Рейнджеры 2: это несколько игр-в-игре, причем, если тебе не нравится какой-либо тип этих миниигр — ты можешь отказаться от них (почти всегда, исключение — особые миссии по продвижению в пиратском клане). Но вот насчет «доверить битву ИИ» — значит рисковать целостностью клавиатуры и собственной нервной системы, будь то авто-битвы в космосе (если твой корабль медленнее врага, ИИ выстраивает такой маршрут, что в бою бьют только тебя) или, о боже, ИИ в планетарных битвах, где твои роботы бесконечно «танцуют» вокруг друга, ремонтники стремительно врываются первыми на линию огня, а при выходе из ручного режима робот начинает чувствовать в себе Силу и может начать набигать на вражескую базу в одиночку. Что ж, как говорится, нет минусов без плюсов — учишься микроконтролю в условиях, когда «микроконролируемые» сопротивляются твоим приказам)
</ностальгия>
А что если всё более прозаично — например, у автора есть привычка вроде «ругать пятиэтажным матом всё вокруг» или «вести себя странно» в момент сосредоточенного обдумывания задачи, чего он сам может не заметить и что на самом деле было причиной такого поведения интервьюера? Вот представьте картину со стороны интервьюера: даёте вы человеку задачу — он задумался, ушел глубоко в свои размышления и внезапно начал задумчиво корчить рожи, грызть листочек, почесывать ногой нос и вообще лезть на потолок. Может интервьюер после увиденного не охрану звал а экзорциста;) Это конечно всё шутка, но хотелось бы отметить — я на своем примере знаю, что когда я слишком сосредоточен, то не отдаю себе отчёт в совершаемых действиях (примеры: пошел налить кофе — насыпал кофе в сахарницу и выбросил кружку в мусорное ведро. Или в процессе обдумывания разгрыз карандаш в щепки с угрожающим выражением лица, и т.п.)
y = x * 2 + x
y = x * (2 + 1)
y = x * 3
или это какая-то цитата, с которой я не знаком
Тем, кто не заметил разницы: с андроидовского гуглхрома обе буквы выглядят абсолютно идентично. С десктопного (вин 10) хрома — разница видна
Так что выходит, товарищ shoorick перепутал Ө с Ѳ. А жаль, с фитой комбо получалось…
Таким образом
Можно прочитать как «ФФФ», «СФС» или «ФсФФс» )
Просто я в своих проектах принципиально не использую precompiled headers, какие у них преимущества?
Надеяться, что компилятор узнает о наследуемости без include и использование void* в таком месте — как мне кажется, ССЗБ. Я понимаю, когда void* используют исключительно с POD-типами — я обычно такое заворачиваю в шаблонный метод с std::enable_if_t<std::is_trivially_copyable_v<T>> или добавляю static_assert (предпочитаю этот вариант, ибо можно выкинуть человекопонятное сообщение об ошибке компиляции). Ведь так можно пойти дальше и случайно вызвать delete на таком void* и совершить прочие Undefined Behavior непотрёбства. Вообще, использование void* в плюсах — это как носить заряженный пистолет в кармане. Если уж носите, то не кладите в этот карман ничего другого (перегрузки функций) или купите ему кобуру (обложите static_assert-ами и прочее).
Как правило, решение использовать указатель/ссылку/непостредственно тип при объявлении поля в первую очередь диктуется архитектурными соображениями, аргумент не засчитан
Опять же, основная причина использования forward declaration — избежание перекрестных зависимостей. В случае со стандартной библиотекой этого можно не бояться и смело писать #include<string>.
Насчет inline-функций, как я понял, вообще лучше не использовать без необходимости (необходимостью считаю случаи, когда необходимо написать тело в пределах того же заголовочного файла, но по причине того, что взаимноконвертируемые типы ссылаются друг на друга, тело методов нужно вынести за пределы определение класса ниже объявления зависимого). Вроде как при включенной оптимизации и параметра генерации кода на этапе линковки линковщик сам разберется и заинлайнит все что надо — так я понял из ответов на SO, но все же некоторая неуверенность присутствует… Лично мне не нравится, когда внутренности геттеров торчат в заголовочном файле (в своем пет-проекте я во все функции добавляю макрос с ассертом для проверки текущего потока по маске, геттеры — не исключение). Помимо этого правила, ко всем вышеперечисленным я пришел опытным путем множественного наступания на грабли. Хотелось бы услышать стороннее мнение на этот счет.
Мне это напомнило Космические Рейнджеры 2: это несколько игр-в-игре, причем, если тебе не нравится какой-либо тип этих миниигр — ты можешь отказаться от них (почти всегда, исключение — особые миссии по продвижению в пиратском клане). Но вот насчет «доверить битву ИИ» — значит рисковать целостностью клавиатуры и собственной нервной системы, будь то авто-битвы в космосе (если твой корабль медленнее врага, ИИ выстраивает такой маршрут, что в бою бьют только тебя) или, о боже, ИИ в планетарных битвах, где твои роботы бесконечно «танцуют» вокруг друга, ремонтники стремительно врываются первыми на линию огня, а при выходе из ручного режима робот начинает чувствовать в себе Силу и может начать набигать на вражескую базу в одиночку. Что ж, как говорится, нет минусов без плюсов — учишься микроконтролю в условиях, когда «микроконролируемые» сопротивляются твоим приказам)
</ностальгия>