проблему со строками, это было давно. Все. Как оно сейчас в современном Майкрософте на 100% не могу утверждать. Но... как тогда все, зависимое от WinApi будет работать на винде? Потоки, синхронизация, файловая система и вот это все. В сорцах инклудится windows.h
про файлы не знаю, а потоки и синхронизация переписаны на своих объектах в stl-е Собственно, для меня include windows.h(для windef? winapi?) - это привязка к платформе, а c++ всё ж таки кроссплатформенный язык. Ну и если там есть какие-то условные компиляции, как-то это не очень. Понятно, что в рантайме будут привязки к платформе, но в коде этого не хотелось бы видеть.
Ты работаешь на винде, инклудишь <thread>, используешь std::thread. Под капотом при сборке в проект залетает windows.h со всеми своими потрохами -> время компиляции увеличивается, бинарник тоже = плохо. Вот о чем я. В геймдеве это особо болезненно.
Стандартная библиотека не header only, windows.h не обязан прилетать
где это болезненно? у тебя вариантов нет)) или ты собственные потоки пишешь под каждую платформу?
не залетает там никакой windows.h к вам в инклуды. там будет скорее всего beginthread/begintthreadex.
нет, там будет какой нибудь _StartThreadFromAbiNeutralAPI
В интерфейсе оно может и не торчать, и не будет влиять на время сборки
Обсуждают сегодня