История изменений

У msvcrt отличается интерпретация строки формата в wprintf (я сейчас конкретно про %s - на одном большом проекте, на котором я работал, незнание об этом разработчиков плагинов было очень частой причиной сегфолтов).

Кроме того, стандартная библиотека C, а как следствие и стандартная библиотека C++ в реализации от Microsoft умеют понимать юникодные имена файлов только если использовать widechar-версии функций (которых нет в стандартах и чаще всего нет на системах, которые не винда).

В GNU C/C++ и Clang по дефолту все символы экспортируются (и за такой дефолт хорошо бы кому-то руки оторвать), в Visual C++ символы нужно экспортировать явным образом. Синтаксис для этого у GNU C/C++ и Visual C++ отличается.

В GNU C/C++ и Clang препроцессор работает по стандарту (сначала токенизация, потом препроцессинг), а на Visual C++ - нет (по сути, препроцессор там просто заменяет строки, т.е, сначала препроцессинг, а потом токенизация).

Много базовых задач не решаются стандартной библиотекой C или C++. Только в C++11 появились потоки. API для работы с файловой системой как не было, так и нет. То же самое про сеть, динамическую линковку, запуск других приложений. А это довольно базовые вещи. Даже для того, чтобы узнать путь к бинарнику данного приложения, нужно использовать платформозависимые API, причём на разных никсах это делается по-разному.

Логика решения, какую перегруженную версию функции вызывать, разная на Visual C++ и GNU C++/Clang. Обычно различие уровня «на одном компилируется, на другом - нет», но иногда оно действительно вызывает разные версии функции.

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

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

В списке только то, на что я натолкнулся гораздо больше одного раза за 2 года работы на большом коммерческом проекте под Win и Mac.

У msvcrt отличается интерпретация строки формата в wprintf (я сейчас конкретно про %s - на одном большом проекте, на котором я работал, незнание об этом разработчиков плагинов было очень частой причиной сегфолтов).

Кроме того, стандартная библиотека C, а как следствие и стандартная библиотека C++ в реализации от Microsoft умеют понимать юникодные имена файлов только если использовать widechar-версии функций (которых нет в стандартах и чаще всего нет на системах, которые не винда).

В GNU C/C++ и Clang по дефолту все символы экспортируются (и за такой дефолт хорошо бы кому-то руки оторвать), в Visual C++ символы нужно экспортировать явным образом. Синтаксис для этого у GNU C/C++ и Visual C++ отличается.

В GNU C/C++ и Clang препроцессор работает по стандарту (сначала токенизация, потом препроцессинг), а на Visual C++ - нет (по сути, препроцессор там просто заменяет строки, т.е, сначала препроцессинг, а потом токенизация).

Много базовых задач не решаются стандартной библиотекой C или C++. Только в C++11 появились потоки. API для работы с файловой системой как не было, так и нет. То же самое про сеть, динамическую линковку, запуск других приложений. А это довольно базовые вещи. Даже для того, чтобы узнать путь к бинарнику данного приложения, нужно использовать платформозависимые API, причём на разных никсах это делается по-разному.

Логика решения, какую перегруженную версию функции вызывать, разная на Visual C++ и GNU C++/Clang. Обычно различие уровня «на одном компилируется, на другом - нет», но иногда оно действительно вызывает разные версии функции.

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

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

В списке только то, на что я натолкнулся гораздо больше одного раза за 2 года работы на большом коммерческом проекте под Win и Mac.