>>> портабельно". >> Ага, и стандартов C++ должно быть минимум три, параллельно действующих >> конечно же (не продолжающих один другой, а именно разных). И SQL, и > > Так так оно и есть. Вот мы сейчас поддерживаем GCC от 4.3.4 до 6.3.0, > clang нескольких версий и MSVC от 2010 onward. Вот тебе и три разных > стандарта, и каждый в своем развитии. Это еще у нас достаточно > ограниченные аппетиты. А upstream по-моему до сих пор MSVC 2003 > поддерживает, плюс еще всякие компиляторы от вендорских юниксов, какие > еще живы. Какой апстрим поддерживает 2003-й мсвс? Его микрософт-то давно уже не поддерживает. Кроме того, не вполне понятно, что это значит. Мне видится, что либо вы живёте на старом стандарте, не используя нового из 11 и выше, либо вы медленно переписываете код на 11 и выше, а старые ветки продукта заморожены и в них делаются только багфиксы.
Насчёт clang - у него совсем немного особенностей, которые требуется поддерживать, и он очень хорошо совместим и со стандартом и с gcc (с ним даже по опциям). К тому же, возможно, что он нужен исключительно для компиляции под MacOS, и для него есть участки кода, которые gcc не компилируются. Это не тоже самое, что полноценная поддержка. И делается это не потому, что "так круто и делает софт надёжнее", а потому, что есть legacy код, который сразу не выкинешь. Вменяемые разработчики, если вы добровольно будете разводить зоопарк компиляторов, от вас сбегут. >> Python, ну и шеллы тоже разные нужно применять для системных скриптов. > > Python постгресом официально поддерживается от 2.4 до 3.5 последних. > И поддержка старых питонов (до 2.7) это еще тот квест. Все современные > удобства питона вплоть до ключика -m в командной строке, оказывается, > свойства 2.7 версии. > Вам нравится решать квесты? Поддержка старого питона осталась из-за того, что третий обратно не совместим со вторым, а на питоне есть куча софта. Со второго постепенно уходят, его поддержку рано или поздно прекратят, потому что наличие двух "стандартов" абсолютно никого не радует. > Разные SQL это, к счастью, не к нам. У нас он один. Это неправильно. Чтобы ваша система стала более надёжной, кроме SQL надо поддержать несколько других стандартов. Я помню, в середине 2000-х ещё писали про всякие альтернативные языки. > Мы его не > поддерживаем, мы его реализуем. Но я еще помню, как разрабатывал > систему, которая была клиентом, а не сервером SQL. И во что там > обходилась одновременная поддержка Oracle и Postgres тоже помню. Так хорошо же. MySQL ещё не забудьте. Надёжнее же это. > И вообще, инженеры которые занимаются миграцией клиентских систем с > Oracle на Postgres от меня в 10 метрах сидят. Можно как-нибудь их > раскрутить на "бойцы вспоминали минувшие дни". > Хех, постгрес давно уже тоже Oracle. :-) Расскажите им, что поддерживать две разных СУБД лучше? Потому что надёжность кода возрастает. > А уж грустная история про башизмы в скриптах при переносе на bsd > или solaris - это вообще. Еще есть грустные истории про сисадминов, > которые прописали в этих системах bash логин-шеллом руту, а потом > траблшутили несмонтировававшийся /usr/local > По-моему, это всё были камни в огород вашего утверждения, вам не кажется? >> А Posix, так вообще твари, навязывают здесь свою идеологию. > > Posix - это как раз почти lowest common denominator. Проблема в том, > что когда современному разработчику нужна какая-то фича, он не лезет в > posix, стандарт C++ или еще какой руководящий документ. Он пробует это > на своей машине, где у него стоит довольно свежая версия компилятора > или интерпретатора с кучей нестандартных расширений, и считает, что > если у него работает, будет работать у всех. > 1. Если у него компилируется. А если скомпилировать надо кому-то другому, есть стандартный компилятор, который в компании официально принят и работает на сборочных серверах. Скомпилировал у себя, не важно чем, работать оно всё-равно будет на всех поддерживаемых платформах (предполагается, что на них результат проходит тесты). 2. Разработчики очень часто заглядывают в стандарт. И я заглядываю. Особенно, если код кроссплатформенный, а если нет, то и компилить студией мне его нафиг не надо, сойдут расширения. > В общем. Добро пожаловать в реальный мир. В котором клиентам позарез > нужна поддержка Windows Server 2003, HP/UX 10 на Itanium и спасибо что > не VMS. > И что? Есть варианты, как это делать. И втаскивать в основную ветку поддержку старья из-за того, что хорошо заплатили, часто не самый лучший выход.