Codepedia 2: сага о фреймворке
От: Зверёк Харьковский  
Дата: 29.09.05 19:55
Оценка: 45 (5) +1
Краткое содержание предыдущих серий
Началось все это тут
Автор: Зверёк Харьковский
Дата: 25.09.05
. В результате длительного, и изредка даже плодотворного обсуждения, у меня появились существенно новые мысли на заданную тему.
Наиболее сильно повлиявшие на меня сообщения:
* 1a
Автор: eao197
Дата: 26.09.05
,
Автор: buriy
Дата: 26.09.05
— сведения о том, как близкие идеи организованы в действующих проектах.
* 2
Автор: FreshMeat
Дата: 29.09.05
(спасибо за подробный анализ, коллега!) — обоснование утопичности "независимых сниппетов".

Нижеследующий текст — в существенно большей степени философское рассуждение, нежели практическое предложение. Цель его — дать толчок развитию идей и обсуждений. Поехали.

Связь между кусками кода необходима
Codepedia, как набор совершенно независимых друг от друга сниппетов — это очевидная (для меня) теперь ошибка. Очень немногое количество концепций и абстракций могут быть реализованы без опоры на другие концепции и абстракции (FreshMeat убедительно показал это в [2] на примере простейших геометрических абстракций).

Да, все верно: продолжая аналогию с Wikipedia (да и вообще любой энциклопедией) — ценность ее в немалой степени определяется кросс-ссылками на другие "статьи" (в нашем случае — сниппеты). Это позволяет описать одну, чистую идею, привязывая underlying и related концепции ссылками. К вопросам и проблемам реализации "ссылок на другие концепции" в формализованных языках я вернусь ниже.

А сейчас мне хотелось бы поднять один вопрос крайне философского характера.

О библиотеках, которые поддерживают язык
Общим местом уже стала следующая сентенция: помимо языка, очень важны библиотеки. Т.е., по крупному счету, сегодня у программиста на каком бы то ни было языке не должно вставать вопроса, как же реализовать регекспы, математику, работу с сокетами, процессами, потоками и прочими вопросами, решаемыми "раз и навсегда" (размещу в скобках свое имхо: при этом, скажем, определенная свобода выбор все же обязана быть — в форме выбора "стратегий" там, где это уместно). Соответственно, такая вот "библиотека" должна существовать для языка, если он рассчитывает на практическое (промышленное) применение. Отличительной особенностью такой всеобщей "библиотеки" (из-за каковой особенности я и беру ее в кавычки) должна быть ее странная, "сильно-слабая" связность: с одной стороны, монолитность такого объемистого набора кода (когда ее надо целиком устанавливать, прилинковывать, или, скажем, собирать перед использованием) порождает достаточно много неудобств. С другой стороны (и это уже пересекается с нашими сниппетами и их взаимозависимостями) — разумные связи должны быть: например, поддержка регекспов и работа с сокетами должны (бы) использовать один и тот же тип строки, а не вводить каждая свой.

Теперь прикинем, как концепция "глобальной библиотеки" (кстати, есть для нее какой-то однозначный термин?) реализуется для разных языков.
Господа, я могу ошибаться в деталях. Поправки, а тем паче дополнения — welcome.
* Perl — имеется централизованный сборник модулей. Пишет и помещает их туда — кто угодно. Если мне нужна какая-то специфичная функциональность на Perl — я первым делом иду на CPAN и ищу там соответствующий модуль.
* .Net — имеется огромная "встроенная" библиотека (собственно, .Net фреймворк), поставляемый производителем. Теоретически, все что нужно — там есть. (Вопрос к дотнетчикам: а если нету — куда вы идете? тоже на SF?)
* С++ — ситуация, на мой вкус, самая тяжелая (внимание! именно с точки зрения "не задумываться о том, как сделать очевидные вещи") Именно к C++ в большой степени относится описанный в [2] печальный процесс — найти код, понять кто и зачем его делал, проверить его работоспособность, выяснить нюансы... и т.п. Есть, скажем, тот же boost; но как всеобъемлющий фреймворк он не вполне тянет из-за того, что старается оставаться в рамках "чистых концепций".

Итого. О чем это я
Вот к чему я все веду.
Я вам опишу сначала идею, ага? И вы над ней немножко подумаете — именно над идеей в целом. А ниже я чуть-чуть про детали реализации поговорю.

Codepedia, которую я тут "задумал", как "движок" всеобъемлющего фреймворка. Выглядит это примерно так: мне нужно "нечто". К примеру, кривая Безье на C++. Я захожу на cpp.codepedia.org и нахожу ее там (как "нахожу" — вопрос отдельный; вроде бы, теги и поиск рулят, но с другой стороны, хорошо бы что-то еще более очевидное cpp.codepedia.org/Bezier_curve — а почему бы и нет?).

Вижу краткое описание — пример использования, публичный интерфейс, полностью код. Плюс информация "контроля качества" — компилябельность, наличие юнит-тестов и результаты их выполнения и т.п. Буде меня все это устраивает, я "забираю" решение с codepedia. Это значит что я получаю код класса "кривая безье", код всех классов и методов, которые он использует (точка, линия, поверхность, математика.....), код юнит-тестов, некоторую сгенерированную документацию — все. При этом, полученный "пакет" должен интегрироваться в мой код одним движением (примеры: Perl-модуль с CPAN нужно только скопировать в каталог modules; в Руби есть RubyGems, позволяющий одной командой установить или убрать библиотеку и все библиотеки от которых она зависит) — и не только в код. Документация и примеры использования — в справочную систему, тесты — в систему тестов... В идеале, еще и проверка обновлений сниппета должна происходить автоматом.

Сама codepedia — суть движок, позволяющий:
* редактировать код прямо на сайте — увидев в реализации кривой Безье некую неэффективность, я нажимаю "отредактировать", вношу несколько изменений, сохраняю — потрачена пара минут, код улучшился.
* "связывать" один сниппет с другим. Причем, даже не путем каких-нито там include или using, а просто — как только в коде я написал некое имя — оно тут же становится ссылкой на соответствующий сниппет. Причем сниппет этот может быть еще не реализован — например, создаю код этой многострадальной кривой Безье, а класса "точка" в codepedia еще нет.
* некоторым образом "проверять" код — на компилируемость, на юнит-тестах (соотв., должен быть и способ вводить их), возможно, просто проверка некоторых инвариантов, возможно, профилирование — и все это с учетом того, что код может опираться на еще не существующие сниппеты.
* документировать код — ооооооо, какая больная тема
Автор: c-smile
Дата: 25.09.05
. Проблема синхронизации документации с кодом.... Брр...
* и, конечно же, "доставлять" код тому, кто хочет его использовать — собирать "пакет" (код + все зависимости + вся документация... короче, см. выше)

Все это нужно зачем? За "эффектом Википедии" — созданием единого источника информации, надежность и полнота которого обеспечена миллионом леммингов. За эффективным созданием фреймворка пользователями языка, а не производителем. За шкафом, в конце концов!

И напоследок...
...о проблемах реализации. Помимо технических, описанных в Codepedia 1
Автор: Зверёк Харьковский
Дата: 25.09.05
, имеется огромная идеологическая проблема: создание сниппета, который опирается на еще не созданные. Все в том же примере с кривой, пишу я, к примеру: "point a;", класса point еще нет, как должно выглядет его использование? Допустим, я использую его, вызывая point.x, point.y, point+point... Что сразу "фиксирует" интерфейс еще не существующего сниппета (тот, кто будет его создавать, должен следовать этому интерфейсу; да и тот, кто станет использовать еще-не-существующий point в другом сниппете — тоже уже обязан следовать ему). Проблема тут, естественно в том, что "первый пользователь создает интерфейс" — и если этот "первый пользователь" потребовал у точки наличия какого нибудь .isInsideMyCoolPoligon — разумно ли, что будущая точка уже обязана иметь такой метод? Отнюдь.

В общем, dixi.
FAQ — це мiй ай-кью!
Re: Codepedia 2: сага о фреймворке
От: vnp  
Дата: 29.09.05 22:07
Оценка: +2
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>И напоследок...

ЗХ>...о проблемах реализации. Помимо технических, описанных в Codepedia 1
Автор: Зверёк Харьковский
Дата: 25.09.05
, имеется огромная идеологическая проблема: создание сниппета, который опирается на еще не созданные. Все в том же примере с кривой, пишу я, к примеру: "point a;", класса point еще нет, как должно выглядет его использование? Допустим, я использую его, вызывая point.x, point.y, point+point... Что сразу "фиксирует" интерфейс еще не существующего сниппета (тот, кто будет его создавать, должен следовать этому интерфейсу; да и тот, кто станет использовать еще-не-существующий point в другом сниппете — тоже уже обязан следовать ему). Проблема тут, естественно в том, что "первый пользователь создает интерфейс" — и если этот "первый пользователь" потребовал у точки наличия какого нибудь .isInsideMyCoolPoligon — разумно ли, что будущая точка уже обязана иметь такой метод? Отнюдь.


Равным образом,
ЗХ> пишу я, к примеру: "point a;",
а класс point уже есть. Но меня не устраивает. И преследует меня такое чувство, что одним на всех классом point обойтись не удастся в любом случае. Поэтому с самого начала движок должен поддерживать какое-то подобие нэймспейсов.

ЗХ>В общем, dixi.
Re: Codepedia 2: сага о фреймворке
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.05 22:33
Оценка: 103 (9) +4
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>* С++ — ситуация, на мой вкус, самая тяжелая...


Имхо, подобная декомпозиция нужна не только для мелких сниппетов, но и для больших библиотек. Вот я задействовал в своих проектах две большие библиотеки -- Crypto++ (хотя оттуда мне нужны были всего лишь шифрование и подпись на TripleDES) и ACE (оттуда я вообще пока использую ACE_OS и еще чуть-чуть). Да еще из Boost-а в некоторых проектах берется Boost.Test. Но все равно, приходится держать весь Crypto++ и весь ACE. Да еще и (пере)компилировать их время от времени. А вот была бы возможность из Crypto++ выдрать только то, что касается TripleDES или из ACE только ACE_Log_Msg -- вот это бы уже было здорово.

Но это так, к слову. А сказать я хотел, что ситуация с C++ в плане подобной Codepedia настолько тяжелая, что я считаю ее безнадежной. И попробую перечислить несколько факторов, из-за которых мне так кажется.

Во-первых, code convention. Для меня это вообще мелочь, на которую я не обращаю внимания. В том же ACE своя нотация, в Crypto++ своя, в Boost своя, в STL своя, даже у меня своя. Но есть программисты, которые придают этому очень большое значение и с их мнение придется считаться. В Java/C# есть свой, навязанный создателями языка стиль. В Ruby пошли еще дальше -- стиль навязывается самим языком. А вот в C++ полная анархия. И в форумах "C/C++", "C/C++ Прикладные вопросы", насколько мне помнится, проскакивали заявления, "что библиотека X мне не подходит, т.к. мне не нравится ее code convention".

Во-вторых, управление памятью. Поскольку в C++ нет сборки мусора, то практически каждая библиотека выстраивала свою идеалогию работы с памятью. В APR (Apache Portable Runtime) это вообще доведено до предела -- там везде нужно передавать pool-ы, в которых функции создают свои объекты. В Qt принят другой подход -- там объекты выстраиваются в деревья "родитель/подчиненный", и родители должны уничтожать своих потомков. Правда все объекты должны быть унаследованны от QObject. В Boost продвигают идеи умных указателей. А в результате есть вопрос -- если сниппет (библиотечка) написана в идеологии управления памятью Boost-а, то насколько просто ее будет использовать совместно с ACE или Qt? В языках со сборкой мусора такой проблемы нет в принципе. Имхо, поэтому количество библиотек для той же Java столь велико. И все они могут сочетаться в рамках одного проекта.

В-третьих, как продолжение предудущего пункта, разные библиотеки в C++ придерживаются различных взглядов на такие вещи, как информирование об ошибках (коды возврата, булевые возврата и errno/GetLastError, исключения) и RAII. ACE, к примеру, обо всех ошибках сообщает через int-овые коды возврата (с параллельным изменением errno). Для чего ACE-овский код пестрит странными макросами вида ACE_ERROR_RETURN или ACE_RETURN. Зато никаких исключений. Как и никакого RAII . В Boost-е же подход совершенно противоположный. Как результат, попробуйте, ради эксперимента смешать в одном месте работу с ACE_OS и Boost.MultiIndex или Boost.RegEx -- каша получится еще та. С исключениями связана еще одна сложность -- если мы вставляем код, который не был расчитан на исключения, в программу, которая исключения активно использует, то как оценивать безопасность использованного кода по отношению к исключениям? Опять же Java или Ruby, где исключения являются централизованным способом информирования об ошибках, в этом плане гораздо проще для сшивания отдельных фрагментов.

В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а

В-пятых, как следствие из предыдущего, а чем компиляцией/линковкой управлять будем? В Boost есть Boost.Jam, в Qt -- qmake, в ACE -- MPC
Автор: eao197
Дата: 27.06.05
. А еще есть CMake, SCons, A-A-P. Даже у меня есть Mxx_ru. А одних только make-ов сколько? Да еще про autotools не следует забывать. А в Java стандартом де-факто является Ant. В Python и Ruby вообще ничего не нужно компилировать (для сборки RubyGems используется так же стандарт де-факто -- Rake).

В-шестых, как следствие из двух предыдущих пунктов, на C++ очень много написано платформо-зависимого кода. Только представте себе, сколько написано на чистом WinAPI, сколько на MFC, сколько на ATL, сколько на Borland-овской VCL, сколько работает только под Unix-ом? Сколько кода, написанного давным-давно на уже умерших фреймворках? Этот код будет оставаться работоспособным еще сколь угодно долго, но вот его реюзабильность будет на нуле.

В-седьмых, как следствие из предыдущего пункта, огромное пересечение по функциональности у существующих больших C++ библиотек (за счет того, что каждая из них пыталась преодолеть различие платформ по-своему). Например, работа с директориями есть и в ACE, и в Boost, и в Common C++, и в wxBase, и в APR.

А в сухом остатке получается -- C++ был децентрализован по своей природе. Он возник тогда, когда это было, вероятно, единственным способом выживания и процветания. В этом была его сила, а может и есть сейчас. Но, в настоящее время, по сравнению с такими централизованными платформами (в смысле наличия единого центра разработки, развития и координации сил), как Java, .Net, Perl, Python и Ruby C++ выглядит просто диназавром. Как бы не было печально мне это говорить.

Выходом для C++, на мой взгляд, могло бы стать объединение всех сил вокруг одного-двух продуктов. В качестве компилятора -- GCC. В качестве базовых библиотек симбиоз из Boost и ACE, плюс, возможно, wxWidget или Fltk. В любой области (сети, криптография, GUI, математика, системно-зависимая часть, базы данных, XML, ...) нужно отобрать одного-двух лидеров и сосредоточить усилия на них. Фактически, превратить C++ в аналог Perl, Python-а или Ruby -- разрабатываемый силами своего community проект.

Однако, фантастика это все, имхо. Хотя Boost, вроде, по такому пути и развивается. Да только есть здесь два но:
— очень не спешно, имхо, идет этот процесс (как и подготовка нового стандарта C++);
— слишком уж дорогим может оказаться переход от используемых сейчас библиотек к тому, что войдет в Mega-Boost. Существующие проекты переписывать никто не бросится, начинать новые на новой библиотеке -- это единственный возможный путь. Был бы, если бы библиотека такая была бы доступна уже сейчас. А так... Начинается новый проект, на чем делать сетевой уровень? На ACE или подождать, пока Boost.IOStreams (или как их там) сокетами и unix-/win32-пайпами разродятся? А GUI -- что предпочесть: wxWidgets или Fltk, а может лучше FOX? А криптография -- Crypto++ или Botan, или же OpenSSL, или же libcrypt, или же CryptLib? А БД? А XML? А работа с графическими файлами?

Грусно все это. С одной стороны -- язык-то замечательный, с другой -- централизованной поддержки-то у него и нет.

Вот и сейчас, интереснейшую идею Зверек озвучивает. Прикинешь ее на Ruby -- вроде получается. На Java -- то же самое. А на C++...censored.




Возвращаясь к тому, с чего начал, про разделение больших библиотек. Была у меня когда-то мечта, сделать так, чтобы большие проекты, можно было бы использовать в качестве подпроектов по частям. Вот, например, есть у меня проект для сериализации и долговременного хранения C++ данных
Автор: eao197
Дата: 24.01.05
. Не маленький. Если кому-то захотелось взять из него только сериализацию, чтобы это можно было сделать не таская за собой остальные части. Но только дальше некоторых предварительных набросков
Автор: Евгений Охотников
Дата: 23.05.05
дело пока не сдвинулось.




PS.

Мои респекты Зверьку Харьковскому и FreshMeat-у (за Codepedia 2: сага о фреймворке
Автор: Зверёк Харьковский
Дата: 29.09.05
и Re: Codepedia. Взгляд вглубь. (читать придется много :) )
Автор: FreshMeat
Дата: 29.09.05
) -- спасибо за интереснейшие посты.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Codepedia 2: сага о фреймворке
От: Зверёк Харьковский  
Дата: 29.09.05 22:52
Оценка:
Здравствуйте, eao197, Вы писали:

ЗХ>>* С++ — ситуация, на мой вкус, самая тяжелая...


E>Имхо, подобная декомпозиция нужна не только для мелких сниппетов, но и для больших библиотек. Вот я задействовал в своих проектах две большие библиотеки -- Crypto++ (хотя оттуда мне нужны были всего лишь шифрование и подпись на TripleDES) и ACE (оттуда я вообще пока использую ACE_OS и еще чуть-чуть). Да еще из Boost-а в некоторых проектах берется Boost.Test. Но все равно, приходится держать весь Crypto++ и весь ACE. Да еще и (пере)компилировать их время от времени. А вот была бы возможность из Crypto++ выдрать только то, что касается TripleDES или из ACE только ACE_Log_Msg -- вот это бы уже было здорово.


Во-во-во! Это я и держал в голове!

E>Во-первых, code convention...


В Codepedia 1
Автор: Зверёк Харьковский
Дата: 25.09.05
этот вопрос решался:

При этом сайт должен поддерживать простой рефакторинг — единожды задав в своем профайле свои соглашения по кодированию (отступы, переносы, case переменных и прочая), дальше все сниппеты вижу отформатированными по этим соглашениям.


E>Во-вторых, управление памятью...


Факт. По всей видимости, логичное решение тут — навязать свою стратегию (как в википедии есть свои "политики", типа NPOV, так и в кодепедии — свои, типа стратегии управления памятью). Еще вариант — сделать сниппет "управление памятью".
Вообще, конечно, сложнейший вопрос.

E>В-третьих, как продолжение предудущего пункта, разные библиотеки в C++ придерживаются различных взглядов на такие вещи, как информирование об ошибках (коды возврата, булевые возврата и errno/GetLastError, исключения) и RAII.


Факт. Решается опять же, через навязанные "политики".

E>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а


Факт. Теоретически, решение этой проблемы должно быть одной из главных целей.

E>В-пятых, как следствие из предыдущего, а чем компиляцией/линковкой управлять будем?..


Вообще, мое описание было сильно inspired by RubtGems. Т.е. теоретически, должен быть некий (клиентский?) софт, который решает эту проблему. Грубо говоря, скачанный с Codepedia "пакет" должен одним нажатием устанавливаться, и одним же нажатием сниматься (включая все пакеты, от которых он зависит, доки и прочая). Учитывая разнообразие компиляторов и других tools — вопрос, вестимо, нетривиальный.

E>В-шестых, как следствие из двух предыдущих пунктов, на C++ очень много написано платформо-зависимого кода...


Мммм... Не готов ответит.

E>В-седьмых, как следствие из предыдущего пункта, огромное пересечение по функциональности у существующих больших C++ библиотек (за счет того, что каждая из них пыталась преодолеть различие платформ по-своему). Например, работа с директориями есть и в ACE, и в Boost, и в Common C++, и в wxBase, и в APR.


Теоретически, опять же, Codepedia призвана решить этот вопрос. Но! Тут поднят важный момент использования уже существующего кода, при создании snippets.
Я пока склонен к решению, аналогичном википедийному — там статьи из других энциклопедий копируются и дорабатываются напильником (если позволяет лицензия исходной библиотеки).

E>А в сухом остатке получается -- C++ был децентрализован по своей природе. Он возник тогда, когда это было, вероятно, единственным способом выживания и процветания. В этом была его сила, а может и есть сейчас. Но, в настоящее время, по сравнению с такими централизованными платформами (в смысле наличия единого центра разработки, развития и координации сил), как Java, .Net, Perl, Python и Ruby C++ выглядит просто диназавром. Как бы не было печально мне это говорить.


! Факт. Вопрос — можно ли этот факт победить?

[...]

E>Грусно все это. С одной стороны -- язык-то замечательный, с другой -- централизованной поддержки-то у него и нет.


E>Вот и сейчас, интереснейшую идею Зверек озвучивает. Прикинешь ее на Ruby -- вроде получается. На Java -- то же самое. А на C++...censored.


Факт

E>


E>Возвращаясь к тому, с чего начал, про разделение больших библиотек. Была у меня когда-то мечта, сделать так, чтобы большие проекты, можно было бы использовать в качестве подпроектов по частям...


Вот и я пытаюсь в ту же сторону крутить... У кого-то из РСДНовцев есть славный ориджин "Но пока это — всего лишь мечтания". Мда.

E>Мои респекты Зверьку Харьковскому и FreshMeat-у (за Codepedia 2: сага о фреймворке
Автор: Зверёк Харьковский
Дата: 29.09.05
и Re: Codepedia. Взгляд вглубь. (читать придется много :) )
Автор: FreshMeat
Дата: 29.09.05
) -- спасибо за интереснейшие посты.


Спасибо за участие в обсуждении!
FAQ — це мiй ай-кью!
Re: Codepedia 2: сага о фреймворке
От: anonymous Россия http://denis.ibaev.name/
Дата: 30.09.05 05:48
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Codepedia, которую я тут "задумал", как "движок" всеобъемлющего фреймворка. Выглядит это примерно так: мне нужно "нечто". К примеру, кривая Безье на C++. Я захожу на cpp.codepedia.org и нахожу ее там (как "нахожу" — вопрос отдельный; вроде бы, теги и поиск рулят, но с другой стороны, хорошо бы что-то еще более очевидное cpp.codepedia.org/Bezier_curve — а почему бы и нет?).


логичней было бы использовать ссылку codepedia.org/Bezier_curve/cpp, тогда в codepedia.org/Bezier_curve будут описаны общие концепции, а в codepedia.org/Bezier_curve/cpp, codepedia.org/Bezier_curve/perl и т. д. — реализации...

ЗХ>Сама codepedia — суть движок, позволяющий:

ЗХ>* редактировать код прямо на сайте — увидев в реализации кривой Безье некую неэффективность, я нажимаю "отредактировать", вношу несколько изменений, сохраняю — потрачена пара минут, код улучшился.

важно позволить редактировать только часть кода, как редактирование разделов статьи в Википедии... также нужно определить как делить код на подобные части...
Re[2]: Codepedia 2: сага о фреймворке
От: anonymous Россия http://denis.ibaev.name/
Дата: 30.09.05 06:01
Оценка:
Здравствуйте, eao197, Вы писали:

E>Во-первых, code convention. Для меня это вообще мелочь, на которую я не обращаю внимания. В том же ACE своя нотация, в Crypto++ своя, в Boost своя, в STL своя, даже у меня своя. Но есть программисты, которые придают этому очень большое значение и с их мнение придется считаться. В Java/C# есть свой, навязанный создателями языка стиль. В Ruby пошли еще дальше -- стиль навязывается самим языком. А вот в C++ полная анархия. И в форумах "C/C++", "C/C++ Прикладные вопросы", насколько мне помнится, проскакивали заявления, "что библиотека X мне не подходит, т.к. мне не нравится ее code convention".


как на счет автоматического изменения code convention?... пользователь выбирает один из вариантов (возможно описывает свой?) и ему выдается переформатированный код... а Codepedia предоставляет некоторые средства для этого, например (хотя такое решение мне не очень нравится):

sub <word>get</word><word>some</word><word>value</word> {

при выборе кэмел-нотации будет трансформировано в
sub getSomeValue {

паскаль-нотации в
sub GetSomeValue {

и т. п.

E>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а


кстати, интересное предложение, автоматический конвертер с одного языка на другой: если сниппета нет на нужном тебе языке, то можно конвертировать его из другого... понятно, что никакой оптимизации под конкретный язык не будет, но иногда главное чтобы код работал...
Re[3]: Codepedia 2: сага о фреймворке
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.09.05 10:01
Оценка:
Здравствуйте, anonymous, Вы писали:

E>>Во-первых, code convention. Для меня это вообще мелочь, на которую я не обращаю внимания. В том же ACE своя нотация, в Crypto++ своя, в Boost своя, в STL своя, даже у меня своя. Но есть программисты, которые придают этому очень большое значение и с их мнение придется считаться. В Java/C# есть свой, навязанный создателями языка стиль. В Ruby пошли еще дальше -- стиль навязывается самим языком. А вот в C++ полная анархия. И в форумах "C/C++", "C/C++ Прикладные вопросы", насколько мне помнится, проскакивали заявления, "что библиотека X мне не подходит, т.к. мне не нравится ее code convention".


A>как на счет автоматического изменения code convention?... пользователь выбирает один из вариантов (возможно описывает свой?) и ему выдается переформатированный код...


Во-первых, для C++ это будет ой как не просто. Например, как перевести следующий фрагмент (сегодня мной написанный) в нотацию ACE (Типы_Именуются_Так, а методы_вот_так, а атрибуты_класса_вот_так_):
send_pdu(
        impl::make_submit_sm_pdu(
                outgoing,
                sequence_number,
                m_cfg.m_channel.m_submit_sm,
                m_cfg.m_channel.m_smsg2smpp(
                        outgoing.query_sms_body_type() ) ),
        impl::outgoing_pdu_send_trx_info( key ) );


Во-вторых, вот есть у меня этот код. Как мне его в такую Codepedia сконвертировать, чтобы он поддавался автоматическому преобразованию нотации?

E>>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а


A>кстати, интересное предложение, автоматический конвертер с одного языка на другой: если сниппета нет на нужном тебе языке, то можно конвертировать его из другого... понятно, что никакой оптимизации под конкретный язык не будет, но иногда главное чтобы код работал...


Берем C++ шаблоны, которые имеют возможность создавать объекты типов-параметров и приплываем при попытке сконвертировать сниппет в C# или Java (см., например,А generic-и так могут?
Автор: eao197
Дата: 30.05.05
).
Или вот такой код на Ruby, который использует Duck Typing, как его в C++ преобразовать (хотя, если все на шаблонах делается, то можно попробовать, Кто хотел определения наличия функции-члена?
Автор: MaximE
Дата: 13.09.03
)?
def read_file( file_name )
   if file_name.respond_to? :to_str
     File.open( file_name ).read
   elsif file_name.respond_to? :read
     file_name.read
   end
end
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Codepedia 2: сага о фреймворке
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.09.05 10:01
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

E>>Во-первых, code convention...


ЗХ>В Codepedia 1
Автор: Зверёк Харьковский
Дата: 25.09.05
этот вопрос решался...


Мне кажется, что проще вообще забить на единый code convention:

Issues that are really just personal taste and don't affect correctness or readability don't belong in a coding standard. Any professional programmer can easily read and write code that is formatted a little differently than they're used to.

Do use consistent formatting within each source file or even each project, because it's jarring to jump around among several styles in the same piece of code. But don't try to enforce consistent formatting across multiple projects or across a company.

(C++ Coding Standards: 101 Rules, Guidelines, and Best Practices
By Herb Sutter, Andrei Alexandrescu)

E>>Во-вторых, управление памятью...


ЗХ>Вообще, конечно, сложнейший вопрос.


E>>В-третьих, как продолжение предудущего пункта, разные библиотеки в C++ придерживаются различных взглядов на такие вещи, как информирование об ошибках (коды возврата, булевые возврата и errno/GetLastError, исключения) и RAII.


ЗХ>Факт. Решается опять же, через навязанные "политики".


Как раз, имхо, через навязывание-то и не решается. C++ применяется в стольких предметных областях и в стольких стилях/парадигмах, что навязывание вряд ли возможно. Где-то глупо возюкаться с кодами возврата, а где-то лишний try/catch -- это здоровенный просад производительности. Точно так же и с памятью. В apache выгодно создавать pool в начале обработки запроса, собирать в него всю память, которую выделяют при обработке запроса, а затем одним махом все вычищают. В какой-нибудь утилите командной строки вообще можно память по ходу дела не освобождать -- очистится после завершения автоматом. А в каком-нибудь текстовом редакторе вообще может протребоваться иметь свой распределитель памяти.

E>>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а


ЗХ>Факт. Теоретически, решение этой проблемы должно быть одной из главных целей.


Пока производители разных компиляторов делают свои собственные реализации компиляторов эта проблема не решится. А откажутся они от производства компиляторов, только когда перестанут на этом зарабатывать. А зарабатывать перестанут, только доведя C++ до крайней степени забвения.

E>>А в сухом остатке получается -- C++ был децентрализован по своей природе. Он возник тогда, когда это было, вероятно, единственным способом выживания и процветания. В этом была его сила, а может и есть сейчас. Но, в настоящее время, по сравнению с такими централизованными платформами (в смысле наличия единого центра разработки, развития и координации сил), как Java, .Net, Perl, Python и Ruby C++ выглядит просто диназавром. Как бы не было печально мне это говорить.


ЗХ>! Факт. Вопрос — можно ли этот факт победить?


Имхо, я бы и пытаться не стал. Ну не для C++ эта идея.

Может ее попробовать на Java или C# обкатать. А там, глядишь, с C++ что-нибудь прояснится.

E>>


E>>Возвращаясь к тому, с чего начал, про разделение больших библиотек. Была у меня когда-то мечта, сделать так, чтобы большие проекты, можно было бы использовать в качестве подпроектов по частям...


ЗХ>Вот и я пытаюсь в ту же сторону крутить... У кого-то из РСДНовцев есть славный ориджин "Но пока это — всего лишь мечтания". Мда.


Если и ты на ту же тему куришь, то может тебе интересны будут мои измышления полутора годичной давности на эту тему? Тогда у нас еще не была выбрана окончательно системы контроля версий, поэтому я изложил тогда идею, которая могла бы работать со многими VCS (например, с CVS, Subversion или Perforce). Затем мы окончательно выбрали Subversion и надобность в командах populate, upgrade, publish и snapshot отпала, т.к. в Subversion были свойства svn:externals и команды checkout, checkin и update (но об этом я как раз написал в RSDN Mag
Автор: Евгений Охотников
Дата: 23.05.05
). Но вот необходимость в манифестах проектов для диагностирования и разруливания конфликтов у меня по-прежнему существует. Все мечтаю выкроить пару-тройку недель, чтобы ее реализовать (но уже на Ruby в качестве и DSL и основного языка реализации).

"Но пока это — всего лишь мечтания"

... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Codepedia 2: сага о фреймворке
От: FreshMeat Россия http://www.rsdn.org
Дата: 30.09.05 10:22
Оценка: 16 (1)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Факт. По всей видимости, логичное решение тут — навязать свою стратегию (как в википедии есть свои "политики", типа NPOV, так и в кодепедии — свои, типа стратегии управления памятью). Еще вариант — сделать сниппет "управление памятью".

ЗХ>Вообще, конечно, сложнейший вопрос.
+1

Видится три возможных варианта:
1. Жестко фиксировать одну конкретную политику для каждого пункта.
2. Фиксировать несколько политик и оставлять выбор на усмотрение пользователей
3. Анархичный вариант — пользую, что удобно для текущего проекта (именно его и держал в голове, распространяясь здесь
Автор: FreshMeat
Дата: 29.09.05
про документацию)

Делая выбор придется помнить о:
1. Золотом принципе — пользователь не платит за то, что не использует.
2. Существует много потенциальных пользователей, например хардварщики, обиженных эм... ресурсами, компилятором, средствами разработки настолько, что впихнуть их в какие-то рамки окажется просто невозможно.

E>>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а

ЗХ>Факт. Теоретически, решение этой проблемы должно быть одной из главных целей.
В первой строчке проекта написать Win-specific.

E>>В-седьмых, как следствие из предыдущего пункта, огромное пересечение по функциональности у существующих больших C++ библиотек (за счет того, что каждая из них пыталась преодолеть различие платформ по-своему). Например, работа с директориями есть и в ACE, и в Boost, и в Common C++, и в wxBase, и в APR.

ЗХ>Я пока склонен к решению, аналогичном википедийному — там статьи из других энциклопедий копируются и дорабатываются напильником (если позволяет лицензия исходной библиотеки).
+1. Других вариантов не остается.

E>>Мои респекты Зверьку Харьковскому и FreshMeat-у (за Codepedia 2: сага о фреймворке
Автор: Зверёк Харьковский
Дата: 29.09.05
и Re: Codepedia. Взгляд вглубь. (читать придется много :) )
Автор: FreshMeat
Дата: 29.09.05
) -- спасибо за интереснейшие посты.


ЗХ>Спасибо за участие в обсуждении!

+1
Хорошо там, где мы есть! :)
Re[4]: Codepedia 2: сага о фреймворке
От: anonymous Россия http://denis.ibaev.name/
Дата: 30.09.05 10:42
Оценка:
Здравствуйте, eao197, Вы писали:

A>>как на счет автоматического изменения code convention?... пользователь выбирает один из вариантов (возможно описывает свой?) и ему выдается переформатированный код...

E>Во-первых, для C++ это будет ой как не просто. Например, как перевести следующий фрагмент (сегодня мной написанный) в нотацию ACE (Типы_Именуются_Так, а методы_вот_так, а атрибуты_класса_вот_так_):
E>
E>send_pdu(
E>        impl::make_submit_sm_pdu(
E>                outgoing,
E>                sequence_number,
E>                m_cfg.m_channel.m_submit_sm,
E>                m_cfg.m_channel.m_smsg2smpp(
E>                        outgoing.query_sms_body_type() ) ),
E>        impl::outgoing_pdu_send_trx_info( key ) );
E>

E>Во-вторых, вот есть у меня этот код. Как мне его в такую Codepedia сконвертировать, чтобы он поддавался автоматическому преобразованию нотации?

я уже говорил, что нужно будет как то разделять слова в идентификаторах... вариант: стандартный разделитель — подчеркивание, ты пишешь:
bool to_be_or_not_to_be();

потом говоришь конвертеру: "хочу кэмел", а от тебе:
bool toBeOrNotToBe();

примерно так...

E>>>В-четвертых, куча разных платформ, разных специфических API, разных компиляторов (с разной степенью соотвествия стандартам). Не приятно отказываться от библиотеки только потому, что на нужной тебе платформе ее нет, а сам ты не можешь ее туда спортировать. Вот так и сижу, как дурак, до сих пор без Boost-а

A>>кстати, интересное предложение, автоматический конвертер с одного языка на другой: если сниппета нет на нужном тебе языке, то можно конвертировать его из другого... понятно, что никакой оптимизации под конкретный язык не будет, но иногда главное чтобы код работал...
E>Берем C++ шаблоны, которые имеют возможность создавать объекты типов-параметров и приплываем при попытке сконвертировать сниппет в C# или Java (см., например,А generic-и так могут?
Автор: eao197
Дата: 30.05.05
).

E>Или вот такой код на Ruby, который использует Duck Typing, как его в C++ преобразовать (хотя, если все на шаблонах делается, то можно попробовать, Кто хотел определения наличия функции-члена?
Автор: MaximE
Дата: 13.09.03
)?

E>
E>def read_file( file_name )
E>   if file_name.respond_to? :to_str
E>     File.open( file_name ).read
E>   elsif file_name.respond_to? :read
E>     file_name.read
E>   end
E>end
E>


нельзя объять необятное, но есть же простые для конвертации вещи:
С
double sqr(double x) {
    return x * x;
}

"дословно" конвертируем в Perl
sub sqr {
    return @_[0] * @_[0];
}
Что-то подобное реализовано хорошими людьми
От: Зверёк Харьковский  
Дата: 05.11.05 19:24
Оценка: 32 (2)
Вот в таком вот проекте.
FAQ — це мiй ай-кью!
Re[5]: Codepedia 2: сага о фреймворке
От: c-smile Канада http://terrainformatica.com
Дата: 05.11.05 22:42
Оценка:
Здравствуйте, anonymous, Вы писали:

A>нельзя объять необятное, но есть же простые для конвертации вещи:

A>С
A>
A>double sqr(double x) {
A>    return x * x;
A>}
A>

A>"дословно" конвертируем в Perl
A>
A>sub sqr {
A>    return @_[0] * @_[0];
A>}
A>


Perl — вычеркиваем.
Re: Codepedia 2: сага о фреймворке
От: nzeemin Россия http://nzeemin.livejournal.com/
Дата: 06.11.05 08:45
Оценка: 2 (2) +1
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вижу краткое описание — пример использования, публичный интерфейс, полностью код. Плюс информация "контроля качества" — компилябельность, наличие юнит-тестов и результаты их выполнения и т.п. Буде меня все это устраивает, я "забираю" решение с codepedia. Это значит что я получаю код класса "кривая безье", код всех классов и методов, которые он использует (точка, линия, поверхность, математика.....), код юнит-тестов, некоторую сгенерированную документацию — все. При этом, полученный "пакет" должен интегрироваться в мой код одним движением (примеры: Perl-модуль с CPAN нужно только скопировать в каталог modules; в Руби есть RubyGems, позволяющий одной командой установить или убрать библиотеку и все библиотеки от которых она зависит) — и не только в код. Документация и примеры использования — в справочную систему, тесты — в систему тестов... В идеале, еще и проверка обновлений сниппета должна происходить автоматом.


Плюс мои два цента...
Идея с кодепедией сама по себе — довольно интересна. Но, как известно, всякую хорошую идею легко убить кривой реализацией (см. коммунизм).

В основу кодепедии, как я понял, вы кладёте идею сниппета. Что есть, вообще говоря, параметризованный фрагмент кода. Т.е. нашел — и copy-paste в свой код. Но обычно так не бывает. Я не буду тупо копировать код откуда бы то ни было, не будучи 100%-но уверенным в его непогрешимости. Возможно, тупое копирование кода будет интересно новичкам и индийцам, возможно. Да, многие приложения на начальном этапе собираются из своего же наработанного кода — но это только на начальном этапе и только из своего наработанного кода.

Опять же, все зависит от масштаба задачи. Например, для алгоритма сортировки пузырьком или прямой по Бразенхейму — примеры кода уместны и крайне полезны, без них трудно вникнуть в суть. Для алгоритмов получения изображений трассировкой лучей — ценность сниппетов уже сомнительна. Для задач, допустим, балансировки нагрузки на сервера или репликации удалённых баз данных — сниппеты не имеют смысла вообще.

Поэтому, что меня может интересовать в кодепедии — это (1) набор алгоритмов с классификацией, и набор алгоритмов как способов решения определенных задач, (2) текстуально-графическое описание алгоритма, а уже затем (3) реализация на конкретном языке и в конкретном окружении.
Таким образом, первичным (для меня) является классификация и категоризация алгоритмов и их решений, затем — подробное описание (та самая презренная документация, писать которую никто не любит), а затем уже (опционально и в качестве примера) — конкретная реализация.

Так что, задача сборки сниппета с его зависимостями возможно и интересна, но мне лично такой результат не нужен. Гораздо интереснее метаинформация, чем сам получаемый по ней код.
Re[6]: Codepedia 2: сага о фреймворке
От: anonymous Россия http://denis.ibaev.name/
Дата: 12.11.05 09:25
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Perl — вычеркиваем.


зачем?...
Re: Что-то подобное,,,блуждая по rubyforge
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.11.05 09:32
Оценка: 20 (2)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вот в таком вот проекте.


Блуждая по RubyForge увидел загадочный заголовок Code Snippets (прямо на стартовой странице ): http://rubyforge.org/snippet/
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Что-то подобное реализовано хорошими людьми
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.01.06 14:34
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вот в таком вот проекте.


А вот и еще: Code Snippets:

Snippets is a public source code repository. Easily build up your personal collection of code snippets, categorize them with tags / keywords, and share them with the world (or not, you can keep them private!)


И список языков/инструментов/платформ, для которых там есть сниппеты:

REBOL apache array bash canvas cli csharp css database date expressionengine file files find form google html http image java javascript lighttpd linux list mac math mysql osx perl php prototype python rails regex ruby rubyonrails series series60 servers shell sql ssh string text time unix web windows xml xslt



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.