Кроссплатформенная цепочка инструментов C ++

Question

Я упорный разработчик .NET с ограниченным опытом в C ++. Я действительно знаком с тем, как счастливо интерпретируемые языки (и языки сценариев) работают кроссплатформенно, но как насчет C ++?

Я понимаю, что GCC / GPP и некоторые другие компиляторы работают на разных платформах с правильными флагами компилятора, и я понимаю, что STL нормализован между компиляторами, но что еще мне не хватает? Мне нужно сделать аудио вход / выход, высокоточные таймеры, и мне нужно сделать многопоточность. Я не думаю, что что-то из этого поддерживается в STL, поэтому мне понадобится кроссплатформенная библиотека какого-то типа, верно? Какой из них я должен использовать?

Я стремлюсь поддерживать новейшие платформы Mac и Windows. Это общий каркас / SDK и не будет иметь пользовательского интерфейса. Я планирую написать пользовательский интерфейс на родном языке, таком как Objective-C / Cocoa и .NET / WPF (оба имеют отличную поддержку нативного интерфейса).

Так как должна выглядеть моя цепочка инструментов? Должен ли я использовать GCC / GPP или MinGW? Какие еще «библиотеки» я должен интегрировать, чтобы они работали кроссплатформенно? Я хотел бы настроить свою среду сборки так, чтобы она «просто работала» так, чтобы я мог создавать совместимый с Mac двоичный файл и двоичный файл, совместимый с Windows (32-разрядный и 64-разрядный). Как я могу это сделать?

На этом этапе я буду писать код для каждой платформы, чтобы я мог взаимодействовать с этой моей многоплатформенной средой C ++ sdk / api thingy. Я думаю, что в Windows это будет выглядеть как управляемая DLL, так? Есть мысли о том, как я это сделаю на Mac?

Есть предложения или рекомендации?

Спасибо за предложения, Brett

Answer 1

1) Ваша настоящая цель здесь должна заключаться в написании переносимого C ++ - вы получаете мобильность, поддерживая использование языка в чистоте, а не с помощью определенного компилятора.

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

3) Такие вещи, как многопоточность, могут выполняться независимо от платформы с использованием стандартных библиотек.

Answer 2

Находясь на субъективной территории, но для разработчика, привыкшего работать с большими, универсальными фреймворками, подобными тем, которые мы находим в .NET, QT, вероятно, будет вашей лучшей кроссплатформенной аналогией C ++ (хотя я огромный поклонник этого). Там у вас есть потоки, ввод / вывод XML, локализация, сокеты, высокоточные таймеры, строительные блоки GUI и т. Д.

[...] и мне нужно сделать многопоточность. Я не думаю ничего из этого поддерживаются в STL [...]

Просто мелочь, но STL ограничен описанием совокупных контейнеров и общих алгоритмов Стандартной библиотеки C ++. Это не синоним, но C ++ 11 имеет спецификации в стандартной библиотеке для поддержки параллелизма. Однако популярные компиляторы все еще не спешат полностью его поддерживать. У вас также есть повышение, если вам нужны потоки на данный момент: http://www.boost.org, что является чрезвычайно кроссплатформенной библиотекой.

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

Я рекомендую вам немного попрактиковаться в создании библиотек DLL / разделяемых библиотек на C ++ в качестве способа расширения приложений .NET и Cocoa (например, модуль C ++, используемый в target-C), прежде чем пытаться разрабатывать большую библиотеку.

Answer 3

Для синхронизации у стандартной библиотеки есть <chrono>, которая имеет разрешение наносекунды на Mac.К сожалению, он получил разрешение только в миллисекундах на Windows с бета-версии VS11.Я надеюсь, что они исправят это без особой задержки.