программирование независимое от ОС (переносимость программного кода)

[Olej]

На сегодня уже достаточно много много инструментов, позволяющих производить программный код не зависящий от ОС, в которой его будут компилировать и
эксплуатировать.
(речь здесь о статической переносимости, переносимости программного кода)

Достаточно - для того, чтобы разрабатываемым программным проектам было безразлично работать под Linux, Solaris, Windows ... или даже MacOS.

Некоторые соображения для того рассматривались в обсуждении (чтоб не повторяться) независимый от платформы код ... и нескольких соседних там темах.
В итоге получается несколько таких тезисов ... относительно выбора инструментария под проект:
- используйте платформенно-независимые прослойки API, например: ARP для C, Boost для C++...
- код С++ будет более платфрменно-независимым чем C (при прочих равных)...
- а для C++ выбирайте компилятор Clang вместо GCC, ... или компилятора Visual Studio, C++ Builder, всякие CygWin с MinGW ...
- используйте кросс-платформенные GUI фреймвёрки: Qt или wxWidgets ... но не GTK+ или MFC
- используйте IDE (если кому нужно IDE) Eclipse или NetBeans, и не используйте платформенно-зависимые KDesigner, SolarisStudio, Visual Studio, C++ Builder etc. - потом меньше переучиваться придётся.

Какие ещё есть соображения у кого из опыта?
Какие инструменты (проекты) успешно для такого дела применять?

P.S. Здесь рядом есть тема "Программирование Unix Api". Так вот это - в точности до наоборот: программирование, не использующее UNIX API

[drBatty]

речь здесь о статической переносимости, переносимости программного кода

используйте платформенно-независимые прослойки API, например: ARP для C, Boost для C++...

1. что такое ARP??
2. с каких пор код boost будет куда-то переносим?

Какие ещё есть соображения у кого из опыта?

ЯННП

[NickLion]

Olej
1. Я тяготею к Qt, но ради справедливости, GTK+ есть для Windows, Linux, OS X.
2. А Qt Creator и не упомянули :(

drBatty
А чим плоха переносимость boost? Очень многое там просто шаблоны. Зависимые от ОСи, в основном, boost::thread, boost::date_time, и те для основных ОС есть.

[Olej]

используйте платформенно-независимые прослойки API, например: ARP для C, Boost для C++...

1. что такое ARP??

Спешил печатать Apache Portable Runtime (APR)

[eddy]

Не существует такого. А некоторое слабенькое приближение — откровенное говно (кути).

программирование, не использующее UNIX API

Невозможно.

Я, например, вчера подумал: а дай-ка я элементарный клиент (тупо подключается к сокету сервера, забирает JSON-данные и парсит их) скомпиляю под мастдайку при помощи mingw. Заглох на том, что сокеты в мастдайке через задницу + jsonlib пришлось бы пришпиливать статически. А уж про сервер я вообще молчу (т.к. в мастдайке через задницу сделана работа с потоками, а функций вроде waitpid там нет — как с зомби бороться, непонятно).

[Olej]

1. Я тяготею к Qt, но ради справедливости, GTK+ есть для Windows, Linux, OS X.

Спасибо за подсказку. Посмотрю.

2. А Qt Creator и не упомянули

Я под Qt имел в виду всё, что относится к Qt.

А чим плоха переносимость boost? Очень многое там просто шаблоны. Зависимые от ОСи, в основном, boost::thread, boost::date_time, и те для основных ОС есть.

От Boost, всего его обширного состава, толку только в 2-х направлениях:
- обёртки для механизмов специфических API (Win32, POSIX), обеспечивающие им общую модель и переносимость (разделы Boost как Thread, Signals, Timer, Locale, Interprocess и т.д.)
- разделы Boost, реализующие часто используемые прикладные области, такие как мат. статистика, линейная алгебра и т.п. (разделы Math, Math/Special Functions) ... либо мат абстракции, такие как лямбда-функции из функционального программирования (раздел Lambda)...

Подробней о Boost с точки зрения переносимости см. Boost.
Как по мне (IMHO!) любовь нынешних программеров к Boost сильно преувеличена ... и если бы не вопросы межплатформенной переносимости, я не понимал бы вообще аргументов для использования Boost вместо того же POSIX 1003.b (pthread_*, mutex_t, condvar_t и т.д.).

Не существует такого. А некоторое слабенькое приближение — откровенное говно (кути).

Говоно - это: Asterisk, FreeSWITCH, Clang, ... Eclipse (какой технологией это достигается - сейчас это не принципиально) ... ну, что ещё к говну отнесём?

программирование, не использующее UNIX API

Невозможно.

Возможно.

Это вы просто не умеете их готовить.

[FlySnake]

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

[eddy]

Возможно.

А я говорю: невозможно. Не существует универсального кроссплатформенного средства для создания программ любой сложности.
Я вот выше про элементарщину говорил (клиент/сервер на сокетах), а ведь еще бывают всякие архитектурно-зависимые конструкции для оптимизации вычислений, OpenGL'и со всякими CUDA'ми, да чего только нет!
Здесь не то, что универсальных для всех операционок решений, но и даже универсальных для всего железа не существует!!!

Да и вообще, программировать под прошивку игровых приставок — дело неблагородное, грязное.

FlySnake, веб — хорошо лишь для элементарщины (развлечения, игрушки). Для работы не годится.

[Olej]

Возможно.

А я говорю: невозможно.

eddy, я из врождённой скромности промолчал ... но ... не стоит человеку, не разобравшемуся ещё толком с waitpid рассуждать в терминах "возможно-невозможно"

а ведь еще бывают всякие архитектурно-зависимые конструкции для оптимизации вычислений, OpenGL'и со всякими CUDA'ми, да чего только нет!

Так вы и про CUDA слышали?
Спешу вас сообщить, что NVIDIA в новом компиляторе под CUDA перешли на LLVM / Clang, которые принципиально кросс-платформенные. А сам API CUDA (C++) он вообще ни к чему не привязан ... кроме их оборудования (драйвера, точнее).

Да и вообще, программировать под прошивку игровых приставок — дело неблагородное, грязное.

А это кто на что учился.
Ничего не могу сказать по этому поводу...

[eddy]

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

Я подозреваю, что если подобное бы существовало, то было бы полным-полно кроссплатформенного софта. Но такого нет. И портировать что-то на другую ОСь — сложная задача. А если еще и захочется несколько аппаратных архитектур поддерживать, так вообще в общем случае могут проблемы возникнуть (напишет, скажем, Вася крутую считалку, прибитую гвоздями к интеловским процессорам, а Петя захочет эту считалку на MIPS портировать, и будет долго материть Васю).

[NickLion]

От Boost, всего его обширного состава, толку только в 2-х направлениях:
...
Как по мне (IMHO!) любовь нынешних программеров к Boost сильно преувеличена ... и если бы не вопросы межплатформенной переносимости, я не понимал бы вообще аргументов для использования Boost вместо того же POSIX 1003.b (pthread_*, mutex_t, condvar_t и т.д.).

Ну, для ООП стиля использование boost::thread намного проще, нежели pthread. Да и в целом, boost очень полезен. Постоянно использую boost::function, boost::bind, boost::shared_ptr, boost::format, boost::lexical_cast, boost::thread, boost::mutex, всякие полезняшки вроде BOOST_FOREACH, boost::algorithm::split(_regex)...

[Olej]

Я подозреваю, что если подобное бы существовало, то было бы полным-полно кроссплатформенного софта. Но такого нет.

"я не знаю" и "такого нет" - это две очень разные вещи.
Я чуть выше назвал вам 4 очень крупных таких проекта ... один из таких проектов - FreeSWITCH компилируется дольше, чем ядро Linux, и включает (интегрирует) в свой состав ещё множество открытых публичных проектов (Lua, sox, vorbis, ...), каждый из которых является независимым от платформы.
Берите - и рассматривайте...

И портировать что-то на другую ОСь — сложная задача.

Портирование - это совершенно другой процесс.
Речь не о портировании, а о проектах не зависящих от платформы.
Вы, похоже, плохо въезжаете в предмет?

А если еще и захочется несколько аппаратных архитектур поддерживать, так вообще в общем случае могут проблемы возникнуть (напишет, скажем, Вася крутую считалку, прибитую гвоздями к интеловским процессорам, а Петя захочет эту считалку на MIPS портировать, и будет долго материть Васю).

Здесь сказана глупость ... но оставлю это без комментария.
При чём здесь вообще архитектура, если на этой архитектуре уже ОС работает? ... вы в пользовательских приложениях используете супервизорные команды процессора?

[Olej]

В сторону веба всё идёт. Есть предположение что десктоп приложения в скором будущем станут очень нишевыми, а весь мейнстрим будет на вебе вообще не привязанном в какой-то платформе.

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

По поводу "есть предположение" - это где есть? можно ссылки на источник?

[Olej]

и со всякими CUDA'ми,

Про CUDA - это вы очень уместно напомнили...
CUDA технология как раз абсолютно платформенно независимая: всё пишется на С++, и компилятор C++ для их десятков (а то и сотен) графических процессоров (GPU) сделан на движке LLVM (основная движущая сила разработки которого - Apple).
Я с CUDA имел изрядный опыт практической работы, и делал это в Linux ... при том при всём, что подавляющее большинство работающих с CUDA (с кем довелось общаться по переписке) делают это в Windows ... с абсолютно тем же прикладным кодом.
Всё платфоменное различие заложено в ... драйвер NVIDIA, а весь API торчащий внаружу - единый для любой платформы.
(вот это высокий класс реализации)

[eddy]

Речь не о портировании, а о проектах не зависящих от платформы.

Это могут быть лишь десктопные приложения вида "пасьянса".

При чём здесь вообще архитектура, если на этой архитектуре уже ОС работает? ... вы в пользовательских приложениях используете супервизорные команды процессора?

Я — нет, но знаю, что народ использует.

Про CUDA - это вы очень уместно напомнили...

Только куду я всмомнил не как пример зависимости от ОС, а как пример зависимости от железа. Нечто, пытающееся быть похожим на куду — OpenCL — еще слишком сырое и неюзабельное. Кстати, по задумке код OpenCL должен на CPU исполняться, если нет GPU. Но эта задумка не работает, вот и приходится вручную писать код для CPU, код для GPU и в "рантайме" выбирать, что запускать.

[drBatty]

А чим плоха переносимость boost?

тем, что её нет. независящие от OS вещи вы можете "переносимо" и на pure C писать. а для зависящих свои обёртки сделать. или чужие, типа вашего ARP. Это всё фантики.

[Olej]

При чём здесь вообще архитектура, если на этой архитектуре уже ОС работает? ... вы в пользовательских приложениях используете супервизорные команды процессора?

Я — нет, но знаю, что народ использует.

Не надо только "ля-ля" ...
Супервизорные (привилегированные) команды "народ" может использовать только в модулях ядра в Linux, т.е. в составе ядра ... в пользовательских прилжениях никакой "народ" их использовать не может. В принципе.
Здесь же разговор совершенно о другом.

[Olej]

Это всё фантики.

Ну и всё : высказался и будя

Я эту тему сделал не от скуки, и вовсе не для того, чтобы послушать как drBatty будет пальцы растопыривать...
Тема конкретная и узкая: инструменты и технологии для изготовления переносимых проектов - какие в каких известных проектах использованы и какой есть опыт применения.

Небе это не интересно? ... имеешь на то право.
Пойди поговори где-то о ... крутизне дистрибутивов Linux, или ещё где - есть множество интереснейших тем вокруг!

[drBatty]

Супервизорные (привилегированные) команды "народ" может использовать только в модулях ядра в Linux, т.е. в составе ядра ... в пользовательских прилжениях никакой "народ" их использовать не может. В принципе.

танки на брюхе не ездят. Они на гусеницах. Лыжники - тоже, они на лыжах. Однако гусеницы не заменить на лыжи, ибо брюхо лыжника и танка принципиально отличается.

А вы предлагаете универсальные лыжи для танка и для людей. Извините, но как пишут на ЛОРе - не нужно.

[Olej]

А вы предлагаете универсальные лыжи для танка и для людей. Извините, но как пишут на ЛОРе - не нужно.

drBatty, я вам - ничего не предлагаю.
Вам - на ЛОР, там вас заждались

[drBatty]

Я эту тему сделал не от скуки, и вовсе не для того, чтобы послушать как drBatty будет пальцы растопыривать

та я как раз наоборот - понять не могу, чего вы хотите. Я и так вас не понял, а когда вы начали какую-то чушь про IDE нести, дык вообще… Ну ладно, boost ясно при чём (хотя не ясно, чем вам STL не люб. Он что, в Win или MacOS теперь не работает?), но IDE-то как на код влияет, а тем более на его переносимость???

Тема конкретная и узкая: инструменты и технологии для изготовления переносимых проектов

Эх… Вам разве не известно, что _любой_ ЯП может и должен быть переносимым? Если он и должен в чём-то зависеть от OS, то как можно меньше, в идеале - вообще никак (пример Pure C, в котором даже ввода/вывода нет, ибо непереносим).

Другая крайность (вроде bash & PowerShell) - это внутренние инструменты самой OS, они самостоятельными ЯП и не являются. Да и не должны.

Что вы хотите сказать-то? Выбрать самый лучший ЯП для ваших целей? Для каких? Пока я никаких целей не вижу. Кроссплатформенность - это средство, а не цель. Одно из дополнительных условий.

Вам - на ЛОР, там вас заждались

Ваше мнение очень важно для нас.

[Olej]

Эх… Вам разве не известно, что _любой_ ЯП может и должен быть переносимым? Если он и должен в чём-то зависеть от OS, то как можно меньше, в идеале - вообще никак (пример Pure C, в котором даже ввода/вывода нет, ибо непереносим).

... и бла-бла-бла ...

Всё. Понятно ... мнений здесь не будет.
Всем спасибо - всё было очень вкусно .

[drBatty]

Olej
а что вы желали услышать? «Вау, круто, побежали делать!!!»?

[NickLion]

А чим плоха переносимость boost?

тем, что её нет. независящие от OS вещи вы можете "переносимо" и на pure C писать. а для зависящих свои обёртки сделать. или чужие, типа вашего ARP. Это всё фантики.

Ещё раз. При использовании boost, без необходимости изменения кода с Вашей стороны, код компилируется под разные ОС. Это и называется переносимостью. Писать свои обёртки — это замечательно, но зачем, если есть готовая отлаженная обёртка?

[NickLion]

Ну ладно, boost ясно при чём (хотя не ясно, чем вам STL не люб. Он что, в Win или MacOS теперь не работает?)

1. В STL (до C++11) нет работы с потоками, мьютексами и др. полезных плюшек.
2. boost не противоречит STL, более того, постоянно использует его.
3. Вся многопоточность и т.п. в STL C++11 пришла из boost'а.

[drBatty]

Ещё раз. При использовании boost, без необходимости изменения кода с Вашей стороны, код компилируется под разные ОС. Это и называется переносимостью.

спасибо что рассказали. Скажите пожалуйста, а если я пишу на C или C++ (с STL), то почему мой код тоже компилируется и работает на разных платформах? И чем ваш boost более кросплатформенный, чем чистый C?

Писать свои обёртки — это замечательно, но зачем, если есть готовая отлаженная обёртка?

т.е. по вашему - boost::фантики - самые готовые и отлаженные?

[NickLion]

Скажите пожалуйста, а если я пишу на C или C++ (с STL), то почему мой код тоже компилируется и работает на разных платформах? И чем ваш boost более кросплатформенный, чем чистый C?

Ничем. Просто в чистом Си нет многих плюшек. Как и в чистом C++. Только в C11 и C++11 появлется многое из необходимого. Да только не всегда есть возможность использовать новые версии.

т.е. по вашему - boost::фантики - самые готовые и отлаженные?

Раз комитет стандарта языка C++ включил их новый стандарт, то да, думаю с отлаженностью всё в порядке.

[drBatty]

Ничем. Просто в чистом Си нет многих плюшек. Как и в чистом C++. Только в C11 и C++11 появлется многое из необходимого. Да только не всегда есть возможность использовать новые версии.

при чём тут "кроссплатформенность"? Как эти плюшки на неё влияют? По моему они вообще ортогональны.

Или вы хотите сказать, что программа с C++11 лямбдами будет более совместимой? Чем программа с указателями на функцию к примеру.

Раз комитет стандарта языка C++ включил их новый стандарт, то да, думаю с отлаженностью всё в порядке.

у вас неверное понимание стандартов. Стандарт вообще ничего не гарантирует, кроме того, что там написано. Если трубу на ¾ дюйма стандартиризировали, это не говорит о том, что она менее ржавая/кривая/дырявая, нежели нестандартная труба на ⅗. Про "отлаженность" вообще в стандарте не пишут.

[eddy]

Вам - на ЛОР, там вас заждались

А вам, батенька, похоже, БХ больше подходит.

Всё. Понятно ... мнений здесь не будет.

Мнения здесь высказаны, просто вы, дорогой, не хотите их видеть.

Просто в чистом Си нет многих плюшек. Как и в чистом C++. Только в C11 и C++11 появлется многое из необходимого. Да только не всегда есть возможность использовать новые версии.

Если я не ошибаюсь, то в этих ваших C11 и C++11 полезные плюшки все равно ничем не помогут: как приходилось писать обертки под каждую ОСь, так и будет приходиться.

[eddy]

[offtop]
Читаю про новинки c11.
Блин, ну "офигительно совместимые вещи"!
Например, aligned_alloc введен явно не от хорошей жизни (т.е. от желаемой ТСом кроссплатформенности мы все дальше и дальше).
_Generic — жалкая пародия на классы в плюсах. С моей точки зрения — совершенно ненужная вещь (т.к. ухудшает читаемость программы).
Типы char16_t и char32_t введены явно китайцами. Людям с нормальной письменностью это не нужно.
Функцию gets, на мой взгляд, стоило бы вообще упразднить (равно как и многие другие опасные функции). Скажем, вместо strcpy оставить только strncpy.
Многое я совершенно не понял (т.к. я не программист).

А вообще, единственное, чего сильно не хватает в сях — нормальный препроцессор. Например, без скотского буста в gcc приходится писать жуткие конструкции для элементарщины! А все оттого, что препроцессор не понимает сложной логики!
Нет, еще хотелось бы нормальной работы с памятью: как минимум, чтобы идиотский malloc был заменен calloc'ом, а free устанавливало очищенный указатель в null.
[offtop]