Высокоуровневые абстракции, достигаемые ценой головоломных упражнений — такое определение мне представляется справедливым. А это уже фанатизм. Надо просто-напросто использовать язык по назначению, как я, например. А городить огороды из крокозябликов — это профессия геморойщика.
A>Мне на работе тоже один маньяк выговорил за использование ScopeGuard вместо ручного управления ресурсами. Подавай ему "if (FAILED(hr)) goto error; error: LocalFree(...)" и всё тут! Не будем фигурять!
Не надо ёрничать да и ёрнут не будешь. ScopeGuard — это абсолютно естественная для языка конструкция, в отличие от.
A>Tuple включён в TR1, а от туда и в C++0x Standard Library. Пугаться нужно было раньше, где-то с момента появления на свет STL. Если по ночам снятся кошмары, может стоит сменить язык программирования?
Да я не против того, чтобы всем этим пользоваться, а очень даже за. Но я категорически против мегатонны зависимостей для реализации тривиальных вещей.
И я осознаю ограничения языка и пользуюсь только проверенными конструкциями, которые любой компилятор просто обязан переварить. А конструкции буста балансируют на грани фола. Ну и вот результат — развесистая клюква зависимостей и обходных путей. Достаточно поискать слово "workaround" в boost — у меня оно встречается в 535 файлах. И не надо говорить, что это — нужное слово. Оно нехорошее, ругательное.
С другой стороны, все эти C# и Nemerle находятся сейчас в привилигированном положении — у них 1 (один) компилятор. Посмотрим, как они запоют, когда этих компиляторов будет десяток.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[11]: Синтаксический сахар или C++ vs. Nemerle :)
Гы-гы. У меня простые проекты под MSVC 1.0 собирались, успевал покурить и кофейку попить(а шаблонов и исключений в нем еще не было). Я думал что это много, пока не попробовал BC4. И ничего появились новые компы, сейчас нормально все собирается. Только разработчики C++ не спят. Понимают что если компиляция не тормозит, значит это не С++. Придумали boost. Появятся новые компы, будет быстро компилиться, еще что-нибудь придумают.
А если серьезно, то я и не возражал по поводу boost'а. Назвать это развитием, как-то язык не поворачивается. В том виде, в котором он есть, С++ + STL он вполне самодостаточен и справляется с задачами. Я его уважаю за низкоуровневость. С++ с бустом — для меня это уже не С++.
Re[19]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>С другой стороны, все эти C# и Nemerle находятся сейчас в привилигированном положении — у них 1 (один) компилятор. Посмотрим, как они запоют, когда этих компиляторов будет десяток.
Не будет. В отличии от 80-х и 90-х, когда на компиляторах зарабатывали, сейчас в фаворе языки, для которых есть один свободно доступный на большом количестве платформ компилятор/интерпритатор/виртуальная машина. В качестве подтверждения можно глянуть на Java, Python, Perl, Ruby. Java вообще в этом смысле показательна -- из языка стала отдельной платформой, предоставляющей разработчику одинаковые средства и библиотеки на всевозможных ОС (если брать J2SE/J2EE, без J2ME и real-time).
Вообще, в наличии одного компилятора(интерпритатора) и SDK очень много притягательного. Жалко, что C++ в этом смысле не повезло. Сначала было слишком много разных компиляторов C++, поэтому язык потребовалось стандартизировать чтобы его не растащили на несовместимые диалекты (хотя и полностью защитить от этого не смогли, достаточно одни только спецификаторы экспорта/импорта вспомнить). А стандартизация мало того, что затянулась почти на десять лет, так еще и заморозила язык практически на такое же время. И глядя на это безобразие, начинаешь жалеть, что нет единственного C++ компилятора (на базе того же GCC или первых CFront), который бы на всех платформах устанавливался бы из одного дистрибутива (как это происходит с Python, Perl или Ruby). Этот компилятор сам и был бы стандартом C++. И развитие его могло бы идти более динамично.
Так что Nemerle сейчас в гораздо более выгодном положении -- его единственный дистрибутив может быть распространен на разные платформы без необходимости создания форков и независимых реализаций. В отличии от того же C#, развитием компилятора которого на Unix-платформах занимается не MS (в отличии от Sun, которая очень благоразумно распространяет свой компилятор для разных ОС). А если вспомнить, что MS еще и не проявляет заинтересованности в портировании своего .NET под Unix-ы... Кажется, что пользователей C# и Nemerle под разными Mono/dotGNU больше будут волновать не различия в компиляторах C# и Nemerle, а различия в реализации .NET Framework.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, alexeiz, Вы писали:
A>>Высокоуровневые абстракции == головоломные упражнения. Отличное сравнение!
MS>Высокоуровневые абстракции, достигаемые ценой головоломных упражнений — такое определение мне представляется справедливым. А это уже фанатизм. Надо просто-напросто использовать язык по назначению, как я, например. А городить огороды из крокозябликов — это профессия геморойщика.
Когда ты последний раз заглядывал в реализацию printf? Сложность библиотечного кода тебя не должна интересовать. К тожу же tuple элементарен, там просто дублирования много для разного количества параметров.
Твои несколько последних "аргументов" абсолютно необоснованы.
A>>Мне на работе тоже один маньяк выговорил за использование ScopeGuard вместо ручного управления ресурсами. Подавай ему "if (FAILED(hr)) goto error; error: LocalFree(...)" и всё тут! Не будем фигурять!
MS>Не надо ёрничать да и ёрнут не будешь. ScopeGuard — это абсолютно естественная для языка конструкция, в отличие от.
Для кого как. Тому парню, видимо, плохо стало. Возвращаясь к нашим баранам, tuple — абсолютно естественная конструкция, особенно если ты раньше использовал какие-либо из скриптовых или функциональных языков.
A>>Tuple включён в TR1, а от туда и в C++0x Standard Library. Пугаться нужно было раньше, где-то с момента появления на свет STL. Если по ночам снятся кошмары, может стоит сменить язык программирования?
MS>Да я не против того, чтобы всем этим пользоваться, а очень даже за. Но я категорически против мегатонны зависимостей для реализации тривиальных вещей.
Не спеши с обобщениями!
MS>И я осознаю ограничения языка и пользуюсь только проверенными конструкциями, которые любой компилятор просто обязан переварить. А конструкции буста балансируют на грани фола. Ну и вот результат — развесистая клюква зависимостей и обходных путей. Достаточно поискать слово "workaround" в boost — у меня оно встречается в 535 файлах. И не надо говорить, что это — нужное слово. Оно нехорошее, ругательное.
Во первых, то, о чём ты говоришь, это ограничения, накладываемые компиляторами, а не языком. А во вторых, есть спрос есть и предложения. Ты думаешь, кто-то сидит и от нечего делать сочиняет эти workarounds? Люди хотят использовать абстракции, предлогаемые boost'ом. Но не у всех есть возможность сразу пересесть на comeau, вот и приходится изворачиваться. Такой подход очень даже неплохо работает, что от части подтверждается размером boost'а (вон сколько написали, демоны!)
Твоё сравнение с развесистой клюквой абсолютно не оправдано. У любой другой библиотеки похожего назначения, размера и количества поддерживаемых компиляторов и платформ будет сходная ситуация. Да куда там сходная! Я видел примеры из моего опыта, как многие опытные разработчики гораздо раньше упирались в предел расширяемости.
А с подмножеством конструкций, которое компилирует любой компилятор, далеко не уедешь.
Re[14]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, alexeiz, Вы писали:
A>Когда ты последний раз заглядывал в реализацию printf? Сложность библиотечного кода тебя не должна интересовать. К тожу же tuple элементарен, там просто дублирования много для разного количества параметров.
Давай придерживаться фактов вместо нелепых сравнений. Разница в том, что с printf лично у меня никогда не было ни одной проблемы. В то время, как вокруг буста надо поплясать с бубном, чтобы оно хотя бы собралось. Да и не хочу я компилировать столько времени, как на древней PC XT 4.77MHz. И это ради каких-то абстрактных абстракций
A>Для кого как. Тому парню, видимо, плохо стало.
А я бы сказал, что не надо всяких мудаков на букву "ч" приводить в качестве аргумента
A>Во первых, то, о чём ты говоришь, это ограничения, накладываемые компиляторами, а не языком.
Абсолютно не имеет значения, чем они накладываются. Главное, что есть ограниченеия, переступать через которые нехорошо.
A>Такой подход очень даже неплохо работает, что от части подтверждается размером boost'а (вон сколько написали, демоны!)
Гвозди бы делать из этих людей
Всю эту энергию следует в конечном итоге направить на новые концепции в языке (или новые языки). Что в конце концов и произойдет, как я чую.
A>Твоё сравнение с развесистой клюквой абсолютно не оправдано.
Берем любой фйал и смотрим, сколько всего он за собой тащит.
A>А с подмножеством конструкций, которое компилирует любой компилятор, далеко не уедешь.
Я бы попросил не обобщать. Если ты не уедешь, это не значит, что и я не уеду. Ну, скажем, не совсем "любой" компилятор, но хотя бы начиная с MSVC-6. И без условной компиляции.
Это как починить розетку — одному надо шкаф инструментов для этого, а другому — один единственный кухонный нож.
На самом деле, буст — это хороший стресс-тест для компиляторов (и какая-никакая движущая сила для их развития). Но вот пользоваться этим всем на практике — нет уж, увольте.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[15]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>На самом деле, буст — это хороший стресс-тест для компиляторов (и какая-никакая движущая сила для их развития). Но вот пользоваться этим всем на практике — нет уж, увольте.
Оценивать буст как одно целое тоже неправильно, в нем есть много хороших, удобных и легких (по объему кода) вещей: умные указатели, варианты, any, array и т. п. У меня почему-то так сложилось что использую из него только подобные легкие вещи, есть только одно исключение boost::python, просто оказался жутко удобным (даже удобнее чем swig) хотя все недостатки тяжелости в нем есть.
Re[15]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Tom, Вы писали:
VD>>Яд который я пью — грузинский коньяк и грузинское вино у нас сегодня отобрали. Так что до тех пор пока он к нам не вернется прийдется влачить существование трезвиника.
Tom>Могу привезти, у нас тут ентого добра — полно
Давай. За одно его им и помянем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, GlebZ, Вы писали:
VD>>Тут оно как... Ты считашь, что это камень. А я ь(и видимо создатели Шарпа) считаю, что это как раз достоинство. Язык позволят только то, что запланировано. И позволяет это на 5 балов. GZ>Это ты про C#3.0?
Я про C# вообще. Не зависимо от версий он позволяет только то, что изначально заложили его разработчики.
VD>>Метапрограммирования в нем просто нет. Если добавят — будет, но пока нет. И прекрасно, что нет страшных побочных эффектов позволяющих эмулировать отсуствующую функциональность. Иначе когда авторы соберутся ввести ее, то она будет конфликтовать с непродуманной гибкостью. GZ>В С++ такой проблемы не стоит.
GZ> А вот нормальную перегрузку операторов сделать, стоило бы.
Это как в Немерле?
GZ>>>Ага. Зато работает. VD>>Не, не работает. Разумный человек просто плюнет чем связаываться с такими извратами. GZ>Человек разумный пользуется и не такими извратами, лишь бы достичь своей цели.
Значит это был не разумный человек.
VD>>Значит, так. Или надо признать ошибочными (для С++) те лозунги которые были приведены мной в начале статьи, или прийдется признать, что реализация этих лозунгов в С++ весьма посредственна и неполноценна. GZ>Второе.
Тогда какие претензии к статье? Она и это и показала, продемонстрировав как можно сделать все по честному.
VD>>Я и раньше не пог понять почему в С++ нет делегатов. Все доказательства того, что они не нужны в зяке явно выглядили натянуто. Увидив подход Немерловцев я понял, что моя ошибка была в том, что я говорил именно о делегатах. Функции высшего порядка более общая обстракция. Делегаты только один из вариантов ее реализации. Именно их не хватало в С++ (полноценных, а не тех потух в виде С-указателей на функции и весьма странных извращений С++ в вдие указатели на члены). GZ>Во первых, я бы назвал аналогом функторы.
Какие такие фанкторы? В языке ничего такого нет. Если ты про объекты реализующие оператор скобки, то это полнейшее извращение. В прочем действовать через зад очень в духе С++.
GZ> Ну а во вторых, есть идеологическая пропасть между функциональным и императивным программированием.
Как видишь никакой пропости нет. Пропость в мозгах, точнее дыры в знаниях.
GZ> Безусловно, любой функциональный язык должен уметь оптимизировать рекурсию. Процессоры вкупе с OS успешнее работают с последовательными программами. Но для императива такая оптимизация значительно сложней.
Иди еще раз прочти статью. Там рассказано как все прекрасно выходит для вполне императивного себе языка.
GZ> Трудно раскрутить рекурсию, если у тебя изменяются глобальные данные. Функциональные программы — не поощряют изменения глобальных данных(взять тот же mutable в Nemerle).
Это теоретиканство. Немерле на практике догазал ощибочность подобного рода рассуждений. Он без проблем разворачивает все циклы в рекурсию и допускает модификацию данных при вычислениях. Они друг-другу никак не мешают.
GZ> Для императива это одна из основных особенностей. Поэтому, IMHO, полностью универсального, и функционального и императивного, эффективного компилятора не может быть. И функции высшего порядка, в основном, в императивных языках так и останутся по сложности на уровне Fold.
Твое IMHO не более чем набор заблуждений и фобий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>С другой стороны, все эти C# и Nemerle находятся сейчас в привилигированном положении — у них 1 (один) компилятор. Посмотрим, как они запоют, когда этих компиляторов будет десяток.
У C# уже минимум 2. А с натяжкой 4.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, alexeiz, Вы писали:
A>>Когда ты последний раз заглядывал в реализацию printf? Сложность библиотечного кода тебя не должна интересовать. К тожу же tuple элементарен, там просто дублирования много для разного количества параметров.
MS>Давай придерживаться фактов вместо нелепых сравнений. Разница в том, что с printf лично у меня никогда не было ни одной проблемы. В то время, как вокруг буста надо поплясать с бубном, чтобы оно хотя бы собралось.
Плясать приходится если используешь что-либо вроде lambda или spirit. Для многих других вещей мне никогда не приходилось в исходники смотреть.
> Да и не хочу я компилировать столько времени, как на древней PC XT 4.77MHz. И это ради каких-то абстрактных абстракций
Зачем вообще нужны абстракции? Можно и на ассемблере код писать. Но чем более низок уровень абстракции, тем больше допускается багов. Снизить уровень багов путём повышения уровня абстракции вполне возможно. Я думаю, что никто бы не отказался от компилятора, который работает в три раза медленнее, но находит в три раза больше багов на стадии компиляции. Ты знаком с Prefast'ом? Это анализатор, который в принципе является модифицированным компилятором VC++. Он очень популярен в некоторых кругах, несмотря на то, что он эффективно увеличивает время компиляции в два раза. Так вот, если уровень абстраций, которыми оперирует твой код достаточно высок, то Prefast становится безполезен, так как он уже ничего не может найти.
В сущности это простой компромисс. Время компиляции <-> меньше багов при разумном использовании абстракций. А время компиляции можно иногда сократить с помощью precompiled headers, parallel builds и т.п.
A>>Для кого как. Тому парню, видимо, плохо стало.
MS>А я бы сказал, что не надо всяких мудаков на букву "ч" приводить в качестве аргумента
A>>Во первых, то, о чём ты говоришь, это ограничения, накладываемые компиляторами, а не языком.
MS>Абсолютно не имеет значения, чем они накладываются. Главное, что есть ограниченеия, переступать через которые нехорошо.
... A>>Твоё сравнение с развесистой клюквой абсолютно не оправдано. MS>Берем любой фйал и смотрим, сколько всего он за собой тащит.
Хорошо. Берём тот же tuple. Смотрим, что он с собой тащит. Его зависимости такие:
config
utility
ref
static_assert
mpl
type_traits
Что очень даже неплохо, учитывая, что в boost'е на порядок больше библиотек, чем требует tuple.
A>>А с подмножеством конструкций, которое компилирует любой компилятор, далеко не уедешь.
MS>Я бы попросил не обобщать. Если ты не уедешь, это не значит, что и я не уеду. Ну, скажем, не совсем "любой" компилятор, но хотя бы начиная с MSVC-6. И без условной компиляции.
Если тебе приходится возится с VC++6, то я тебе не завидую. Я в глаза не видел VC++6 уже как 5 лет. Очень старый компилятор. Его следует выбросить хотя бы за такие вещи, как for(int i...) и отсутствие whar_t. VC++2003, g++ 3 уже нормально переносят все современные C++ конструкции.
Re[16]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, alexeiz, Вы писали:
A>Хорошо. Берём тот же tuple. Смотрим, что он с собой тащит. Его зависимости такие: A>config A>utility A>ref A>static_assert A>mpl A>type_traits
Дык! Это же зависимости первого уровня. А полное дерево? Со всеми workaround.hpp и прочими?
В STL эти зависимости еще терпимы, в бусте — ужас-ужас Зачем, там, кстати mpl?
A>Если тебе приходится возится с VC++6, то я тебе не завидую.
Наверное мы занимаемся разными вещами. Для меня все эти высокоуровневые абстракции не имеют большого значения — это чисто механические мелочи по сравнению с сочинением алгоритмической части. Поэтому и VC6 могу вполне нормально пользоваться — его ограничения меня почти не напрягают.
Конечно же, при написании больших объемов тривиальной бизнес-логики соотношение усилий совершенно другое. Но C++ и не очень-то подходит для этого.
A>Я в глаза не видел VC++6 уже как 5 лет. Очень старый компилятор. Его следует выбросить хотя бы за такие вещи, как for(int i...) и отсутствие whar_t. VC++2003, g++ 3 уже нормально переносят все современные C++ конструкции.
А по мне так и наплевать на этот "int i". Это не ходовая часть и на скорость не влияет.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[14]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, alexeiz, Вы писали:
A>>Хорошо. Берём тот же tuple. Смотрим, что он с собой тащит. Его зависимости такие: A>>config A>>utility A>>ref A>>static_assert A>>mpl A>>type_traits
MS>Дык! Это же зависимости первого уровня. А полное дерево? Со всеми workaround.hpp и прочими? MS>В STL эти зависимости еще терпимы, в бусте — ужас-ужас Зачем, там, кстати mpl?
Это полное дерево с гранулярностью до библиотеки, т.е. отдельные header'ы внутри каждой библиотеки не показаны.
workaround.hpp и прочее меня не волнуют. В большинстве библиотек boost'а весь код реализации находится в .hpp файлах. Поэтому файлов много подключаться будет, это как пить дать. Но зависимости одной библиотеки boost'а от другой не превышают разумного. И это то, что меня интересует, т.к. это напрямую показывает грамотность проектирования библиотек.
Re[18]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, McSeem2, Вы писали:
MS>>Здравствуйте, alexeiz, Вы писали:
A>>>Хорошо. Берём тот же tuple. Смотрим, что он с собой тащит. Его зависимости такие: A>>>config A>>>utility A>>>ref A>>>static_assert A>>>mpl A>>>type_traits
MS>>Дык! Это же зависимости первого уровня. А полное дерево? Со всеми workaround.hpp и прочими? MS>>В STL эти зависимости еще терпимы, в бусте — ужас-ужас Зачем, там, кстати mpl?
A>Это полное дерево с гранулярностью до библиотеки, т.е. отдельные header'ы внутри каждой библиотеки не показаны.
A>workaround.hpp и прочее меня не волнуют. В большинстве библиотек boost'а весь код реализации находится в .hpp файлах. Поэтому файлов много подключаться будет, это как пить дать. Но зависимости одной библиотеки boost'а от другой не превышают разумного. И это то, что меня интересует, т.к. это напрямую показывает грамотность проектирования библиотек.
В догонку, если бы в boost'е использовались export templates, то многое из реализации (та часть, которая namespace detail) было бы скрыто в .cpp файлах. Ты бы всех внутренностей не видел, и ощущения огромного количества зависимостей не было бы. О чём это говорит? О том, что такое ощущение является ложным.
Что конкретно в плане зависимостей интересует людей, разботающих с boost'ом, и над чем работают бустовские товарищи, так это то, например, что нужно взять из boost'а, чтобы использовать только smart_ptr библиотеку. В идеале должно быть так, что я беру и отдельно копирую себе файл smart_ptr.hpp и директорию smart_ptr и больше ничего. Т.е. сколько там внутри smart_ptr файлов меня не интересует, т.к. они все составляют реализацию одной библиотеки. А вот необходимость копировать другие библиотеки констатирует зависимости.
Re[19]: Синтаксический сахар или C++ vs. Nemerle :)
alexeiz,
A>Что конкретно в плане зависимостей интересует людей, разботающих с boost'ом, и над чем работают бустовские товарищи, так это то, например, что нужно взять из boost'а, чтобы использовать только smart_ptr библиотеку. В идеале должно быть так, что я беру и отдельно копирую себе файл smart_ptr.hpp и директорию smart_ptr и больше ничего. Т.е. сколько там внутри smart_ptr файлов меня не интересует, т.к. они все составляют реализацию одной библиотеки. А вот необходимость копировать другие библиотеки констатирует зависимости.
Сейчас bcp вполне спасает отца русской демократии.
А вот ослабление зависимостей породит другую проблему — дублирование.
Отсюда дизадвантадж номер раз: это увеличит физический размер буста где-нибудь до 100 Мб в архиве, что уже для многих людей неприемлемо. (Хотя можно предоставить возможность скачивать кусочки, но текущий вариант удобнее).
Дизадвантадж номер тва: противоречивость. Поскольку библиотеки разрабатываются разными людми, возникает проблема синхронизации которая ведёт к тому, что разные копии одной и той же зависимости будут противоречить друг другу. (Тоже решаемо, но это усложняет и без того непростой процесс разработки).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Отсюда дизадвантадж номер раз: это увеличит физический размер буста где-нибудь до 100 Мб в архиве, что уже для многих людей неприемлемо. (Хотя можно предоставить возможность скачивать кусочки, но текущий вариант удобнее).
LCR>Дизадвантадж номер тва: противоречивость. Поскольку библиотеки разрабатываются разными людми, возникает проблема синхронизации которая ведёт к тому, что разные копии одной и той же зависимости будут противоречить друг другу. (Тоже решаемо, но это усложняет и без того непростой процесс разработки).
Вот чего Boost-у (а может и вообще C++) не хватает, так это аналога RubyGems.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: Синтаксический сахар или C++ vs. Nemerle :)
eao197,
E>Вот чего Boost-у (а может и вообще C++) не хватает, так это аналога RubyGems.
Напоминает apt/yum, хорошая штука
Но здесь есть одна трудность, которая снесёт крышу почти любому программисту. Давай взглянем на это дело теоретически. Допустим, мы скачиваем некую тулзу из буста (пусть boostgem).
После этого создаём файлик boostgem.config где будут сведения о компиляторе/окружении и т.п. (это сама тулза может создать). Отсюда следует, что для каждого компилятора будет свой конфиг.
Затем
boostgem install shared_ptr
скачивает хедер shared_ptr.hpp со всеми зависимостями и все зависимости кладёт в папочку shared_ptr. Информацию об этом "boostgem"-е сохраняет в своей базе. Пока всё нормально.
И у нас есть 2 программы — одной нужна версия 15, а другой 20. В обоих программах прошито #include "boost/shared_ptr.hpp". Отсюда следует, что должны быть различные каталоги boost, и опции в этих проектах должны быть натравлены на эти различные каталоги. Нет проблем, ручками прописать пути — not a big deal.
Но в первой программе потребовался второй "boostgem", скажем railgun , которому нужна версия 16 shared_ptr. Чего мы будем прописывать в проекте — shared_ptr_15 или shared_ptr_16? Отсюда следует, что "railgun" нужно компилировать с путями к shared_ptr_16, а саму программу потом с путями к shared_ptr_15.
Увеличим количество "boostgem"-ов и предположим, что в каждом "boostgem"-е 10 зависимостей (не бог весть какой мегарулез).
g_0, g_1, g_2, g_3, g_4, g_5, g_6, g_7, g_8, g_9 - базовые гемы, без зависимостей
h_0, h_1, h_2, h_3, h_4, h_5, h_6, h_7, h_8, h_9 - гемы с зависимостями, каждый зависит от всех верхних
i_0, i_1, i_2, i_3, i_4, i_5, i_6, i_7, i_8, i_9 - продвинутые гемы с зависимостями от h_i
Что получим?
А получим, что если мы задействуем в нашей программе 10 продвинутых "boostgem"-ов, то в худшем случае нужно будет прописать в make-файле 10 * 10 * 10 = 1000 разных опциий компилятору!!!
Компилятор глядя на несколько исходников со строкой '#include "boost/shared_ptr.hpp"' не может получить несколько различных хедеров и его каждый раз нужно носом тыкать. А тыкать придётся руками, или делать генератор таких make-файлов, что нехило усложнит задачу и можно будет забыть об IDE.
Вот она фундаментальная проблема: боль по отслеживанию зависимостей не может быть возложена на компилятор, только на хрупкие плечи программиста.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>И у нас есть 2 программы — одной нужна версия 15, а другой 20. В обоих программах прошито #include "boost/shared_ptr.hpp". Отсюда следует, что должны быть различные каталоги boost, и опции в этих проектах должны быть натравлены на эти различные каталоги. Нет проблем, ручками прописать пути — not a big deal.
Вот здесь нужно останавливаться. Мое мнение в том, что обе программы должны договориться об использовании одной версии shared_ptr. Если это не возможно, то программы должны компилироваться в разных условиях, не зная друг от друга.
Если тебе интересно, то я когда-то пытался придумать что-то вроде манифестов проектов и даже изложил свои мысли в виде небольшого документика. Мы даже серьезно его осуждали при выборе системы контроля версий и системы организации проектов. В результате остановились на гораздо более простой схеме, описанной здесь
. Не бог весть что, но работает и обходится дешево, т.к. вся функциональность предоставляется Subversion-ом.
Хотя переодически у меня возникает желание вернуться к идее манифестов для описания зависимостей. Да только не хватает духу браться за еще один безнадежный проект
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
А городить огороды из крокозябликов — это профессия геморойщика.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
