Защита от множественного подключения заголовочного файла

У обоих методов есть свои преимущества и недостатки.

#define кроссплатформенный, соответствует стандарту, поддерживается всеми компиляторами, но у него есть очевидный недостаток: если в проекте случайно найдутся два header-файла с одинаковым именем, необъяснимые ошибки гарантированы. Особенно неприятно это в случае больших проектов с 3rdparty-кодом. Можно придумать более продвинутую схему, при которой вероятность коллизии уменьшится (например, включать в guard полный путь к файлу в проекте или UUID), но гарантии вам никто не даст. (И вы не сможете потребовать от разработчиков посторонних библиотек следовать вашему стандарту.)

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

Тем не менее, #pragma once поддерживается большим количеством компиляторов, так что если вы рассчитываете лишь на популярные компиляторы (MSVC, GCC, Clang, Intel compiler) свежих версий, имеет смысл остановиться на этом варианте. Имейте в виду, что многие опытные Unix-разработчики недолюбливают #pragma once, так что вам придётся обосновывать свой выбор.

Если ваш код есть часть какого-либо проекта, всё становится проще: просто спросите руководителя проекта о том, что рекомендуется к использованию. Выбор между include guard и #pragma once — часть coding standards любого проекта.