Такой подход по сути навсегда привязывает вас к использованию pch. Если в какой-то момент по какой-то причине вы захотите отказаться от pch — это не так то просто будет сделать.
Да, в данный момент изучаю ccache, и в целом результаты воодушевляющие. Однако, я бы не сказал, что ccache — это замена precompiled headers. Например, pch может ускорить даже полностью чистую (без кэша) пересборку проекта, поскольку после компиляции pch-файла сборка остальных юнитов будет происходить быстрее. Это может быть полезно, например, для релизных сборок, где хочется быть уверенным в полной повторяемости сборок.
Насколько я понял, с выходом CMake 3.16 Cotire потерял свою актуальность и больше не будет обновляться.
The functionality provided by cotire has been superseded by features added to CMake 3.16. Support for pre-compiling and unity builds is now built into CMake. Thus, there will not be any further updates or support for this project.
Но когда вводят карантин, изначально предполагают, что это на время. Поэтому все же, на мой взгляд, аналогия не совсем корректная. Я бы тут скорее сравнил с запретом полетов новых боингов на время расследований причин их крушений, или запретом на полностью беспилотные автомобили на дорогах общего пользования, пока технология не будет обкатана.
Мне кажется, мысль, что средний человек всегда может заниматься только интересными делами — это красивый миф. Всегда найдутся не очень интересные дела, которые делать _надо_. Кроме того, есть дела, от которых интерес получаешь не сразу (например, надо войти в поток или пройти сложный начальный этап).
А зачем вообще делать работу, в которой вы не видите никакого смысла? Это какой-то мазохизм, сизифов труд. Дисциплина, привычки, вот это все — это для того случая, когда смысл в работе есть, но она не особо интересная. Если вы видите смысл в том, чтоб, например, за хорошую зарплату делать не учень увлекательные вещи — тогда надо прикладывать дисциплину и использовать другие приемы. Например, потому, что полученные деньги позволят вам заняться другими интересными вещами. Если же вы не видите в этом смысла — тогда надо увольняться.
Похожий приём используется в системе достижения результатов GTD Дэвида Аллена. Каждый проект должен иметь чётко определенное следующее действие (next action) и необходимый для этого действия контекст (место, время, наличие человека рядом, свежесть ума и т.п.). Тогда в подходящий момент лишь остаётся сделать один следующий шаг, не тратя время и силы на размышления. Как говориться, решая — думай, а решив — делай.
В первую очередь надо следовать принятому в проекте/компании/языке стилю. Выбор, куда поместить открывающую скобку — это по большому счету вкусовщина и дело привычки.
Сам я начинал с С++ и открывающей скобки на новой строке, но потом долгое время пришлось писать на Java, где принято не переносить открывающую скобку на новую строку. Особой разницы на понимание кода при наличии привычки это не оказывает. А преимущества можно найти и там, и там. Например в первом подходе приятненько, когда соответствующие скобочки на одном уровне, зато во втором подходе блок кода зрительно прилеплен к соответствующему условию и отделен от последующих блоков.
Гораздо хуже, когда разные части одного и тоже проекта написаны в разном стиле.
Честно говоря, глядя на оба листинга, я принципиальной разницы между ними не вижу. Но вижу ошибку, из-за которой, видимо, в С некоторые используют goto и метки. У вас в случае неинициализации B не хватает деинициализации A перед выходом. И вот для исключения подобных ошибок часто используют отдельный блок деинициализации в конце функции с меткой, в который переходят при помощи goto в случае ошибки:
пример
void* someFunc() {
// function body ...
exitFunc:
if (b != NULL) {
deinit_b(b);
}
if (a != NULL) {
deinit_a(a);
}
return ret;
}
При таком подходе вынос в начало определения всех переменных, которые нужно в конце деинициализировать, как раз имеет смысл. Но, все равно, это скорее как исключение. По умолчанию я бы определял переменные как можно ближе к месту использования даже в С. Но я давно не пишу на С, вполне могу что-то упускать.
Попробуйте расширение TypeScript Hero для vscode. Он избавит вас от необходимости вручную писать импорты в большинстве случаев. Или TypeScript Importer, но у него меньше функционал.
Но несмотря на подобную поддержку со стороны IDE у меня тоже есть претензия к языку, правда в моем случае именно к Type Script. Поскольку тип у него идет после имени переменной (что, видимо, типично для языков с необязательной типизацией), то часто по сути приходится одно и то же слово набирать два раза. Первый раз с маленькой буквы для имени переменной, и второй раз с большой — для имени типа. Например, myFunc(control: Control) {}. Для vscode не нашел расширений, решающих эту проблему.
Так vscode вполне умеет с установленным Microsoft C/C++ Extension.
А можете развернуть логическую цепочку между профайлингом и ограничением возможности индивидуума?
Но когда вводят карантин, изначально предполагают, что это на время. Поэтому все же, на мой взгляд, аналогия не совсем корректная. Я бы тут скорее сравнил с запретом полетов новых боингов на время расследований причин их крушений, или запретом на полностью беспилотные автомобили на дорогах общего пользования, пока технология не будет обкатана.
Мне кажется в переводе вместо слова «смертность» правильнее было применять слово «летальность».
Похожий приём используется в системе достижения результатов GTD Дэвида Аллена. Каждый проект должен иметь чётко определенное следующее действие (next action) и необходимый для этого действия контекст (место, время, наличие человека рядом, свежесть ума и т.п.). Тогда в подходящий момент лишь остаётся сделать один следующий шаг, не тратя время и силы на размышления. Как говориться, решая — думай, а решив — делай.
Сам я начинал с С++ и открывающей скобки на новой строке, но потом долгое время пришлось писать на Java, где принято не переносить открывающую скобку на новую строку. Особой разницы на понимание кода при наличии привычки это не оказывает. А преимущества можно найти и там, и там. Например в первом подходе приятненько, когда соответствующие скобочки на одном уровне, зато во втором подходе блок кода зрительно прилеплен к соответствующему условию и отделен от последующих блоков.
Гораздо хуже, когда разные части одного и тоже проекта написаны в разном стиле.
При таком подходе вынос в начало определения всех переменных, которые нужно в конце деинициализировать, как раз имеет смысл. Но, все равно, это скорее как исключение. По умолчанию я бы определял переменные как можно ближе к месту использования даже в С. Но я давно не пишу на С, вполне могу что-то упускать.
Но несмотря на подобную поддержку со стороны IDE у меня тоже есть претензия к языку, правда в моем случае именно к Type Script. Поскольку тип у него идет после имени переменной (что, видимо, типично для языков с необязательной типизацией), то часто по сути приходится одно и то же слово набирать два раза. Первый раз с маленькой буквы для имени переменной, и второй раз с большой — для имени типа. Например, myFunc(control: Control) {}. Для vscode не нашел расширений, решающих эту проблему.