Возможно специалисты прояснят мне мои смутные сомнения.
Тезис заключается в следующем: ANSI C++ ни разу не кроссплатформенен. Фактически, даже простейшие вещи, вроде соглашения о вызове или экспорта/импорта функций и переменных из динамических модулей нет. Без них нельзя, фактически, ничего. Сюда же отнесём пути в заголовочных файлах (include "путь, специфичный для ОС"), выравнивание данных (как описать универсально структуру с точностью до байта).
- Соглашения о вызовах: да, в C++ не прописаны соглашения о вызовах. То есть конкретно вот как параметры передавать - через регистры? стек? в каком порядке? Более того, в кроссплатформенном языке невозможно прописать соглашение о вызовах, просто потому, что некоторые платформы могут тебе просто не позволить соблюсти это соглашение (то есть оно там будет либо не реализуемо вообще (скажем нет регистров общего назначения), либо крайне не эффективно). Собственно даже в том же компонентном паскале соглашения о вызовах не прописаны.
- dll/so: эта штука суть внешняя относительно языка (и вообще говоря, от языка не зависит). Странно было бы пихать описание so'шек в сам язык. dll/so - сущность уровня операционной системы а не языка. Очевидно, что не во всех случаях целесообразно, да и вообще возможно, иметь so'шку.
- Пути в #include: там действительно можно прописывать даже абсолютный путь специфичный для данной OS. Но зачем? По факту #include <blablabla> мало отличается от какого-нибудь IMPORT blablabla. Плюс по инклюду сразу видно - это подключается хедер внутри проекта, или же системный хедер (для системных #include <blablabla>, для проектный хедеров #include "blablabl"). Естественно по хорошему эти инклюды нужно хорошенько причесать, чтобы он стал таки уже не директивой препроцессора, и границы между модулями были в явном виде, но это уже совсем другие проблемы.
А с препроцессором (возможно, внешним) и утилитами для сборки при наличии трансляторов и костылей к ним можно любой язык назвать кроссплатформенным.
Препроцессор это часть языка С++, а не что-то сбоку прикрученное. Это часть стандарта. #include - это именно директива препроцессора. А система сборки нужна любому языку, если на нем предполагается писать что-то круче чем hello world. А если предполагается собирать в разных окружениях, то система сборки еще должна быть и достаточно умной, чтобы оценить возможности данной платформы и правильно собрать.
Нет, можно конечно и без системы сборки. Просто тогда все это придется каждый раз делать руками (с большой вероятностью ошибиться). Ну, то ilovb на самом деле мог не пользоваться системой сборки, а руками компилировать, каждую единицу компиляции, руками запускать компоновщик и так далее. Только вот это будет долго, нудно, и велик шанс ошибиться. Система сборки - это автоматизция рутины, и ничего больше.
По поводу юниковых утилит для сборки. Разве не рудимент, что большинство из них не хочет понимать пути с пробелами/русскими символами? Или это только в окружении Windows такая проблема? У меня отваливаются самые разные программы на С++ при неудобном для них местоположении, даже Notepad++.
Никогда с этим не сталкивался на *nix'ах. Полагаю это рудимент винды :-) В винде же до сих пор есть проблемы с русификацией (скажем берем произвольного буржуя, с его англоязычной виндой и пытаемся ему показать кириллицу - скорее всего будет фейл, а *nix'ах такой проблемы нет, там давно везде utf8, то есть ставим какой-нибудь debian, не ставим там поддержку русского, и, однако с кириллицей все хорошо. Единственное что нужно добавить для "кириллизации" - русскую раскладку клавы, чтобы печатать). В винде же до сих пор местами cp1251 (aka OEM), местами UCS-2, а местами UTF-16 (самое неудобное представление юникода из возможных).
В юниксах отказались от реестра, но в результате имеем реестр в виде переменных окружения, необходимость прописываться в них, альтернативные пути папок с бинарниками и заведомую зависимость одной утилиты от прописанных в таком «реестре» десятка других программ. При переносе на Окна приходится каждую прописать в системный PATH, иначе что-то отваливается.
Стоп. Как можно было отказаться от того, чего нет? :-) 1969 год. В какой OS был реестр, чтобы от него отказываться? :-)
В *nix'ах для конфигов, очевидно, есть файлы конфигурации. Обычно глобальное находится в /etc, а настройки характерные для данного юзера хранятся в /home/username/.programName . Приложения же (исполняемые файлы) обычно складываются в /usr/bin (а если что-то самосборное, то в /usr/local/bin). И никакого бардака, никаких 100500 записей в PATH.
Переменные окружения - это то, что может быть свое для КАЖДОГО запущенного приложения (уже в рамках какого-то конкретного пользователя). Таким образом мы можем настроить нечто общесистемное, нечто специфичное для пользователя и нечто специфичное для данного дерева процессов (в простейшем случае - конкретного приложения). По моему, очень удобно.
А те проблемы которые ты описываешь - это таки скорее проблема винды, которая тащит древние досовые традиции в современный мир. То есть описанная тобой проблема - это проблема доса и досовых утилит (когда еще и винды то не было, проблема уже была). MS когда создавала ДОС особо не вникая скопировала из *nix'ов переменные окружения, но остальное скопировать то ли не осилила, то ли не поняла зачем оно там такое есть. В результате имеем отсутствие четкого разделения что где лежит, имеем приложения ровным слоем разбросаннные по файловой системе как, как левая пятка юзера пожелает, и необходимость регулярно бегать и менять PATH, чтобы это все как-то шевелилось. Также они не додумались скопировать идею централизованного места хранения конфигов. Разграничение доступа.. Да много чего не было сделано.
Затем начали лепить винду, и поверх всего вот этого ужаса, они влепили еще реестр (часть конфигов хранится там, но не все! и без комментов), теперь ставится все по умолчанию в Program Files и Program Files(x86), появилось какое-то подобие /home/user директории, и так далее.
В результате имеем дикую смесь бульдога с носорогом и такие вот вопросы :-)
Можно возразить, что альтернативы нет: либо централизованный общий реестр, либо ручное редактирование переменных окружения. Но реестр понадёжнее будет, на мой взгляд. В реестре если ключу "git" соответствует конкретный путь, то повторная установка его попросту перепишет. С переменными окружения хуже. Дубликаты путей к папкам, пути с различным регистром.
Альтернатива безусловно есть - так как сделано в *nix'ах. И оно действительно хороша и проверена временем :-)
