ВСЕМ: Обсуждение разделения форума

В данный момент в команде обсуждается создание нового форума, посвященного обсуждению тех библиотек C и C++, для которых в текущей системе форумов РСДН подходящего места нет (zlib, libtiff, Crypto++, CGAL, "административные" вопросы сборки и подключения к проекту различных реализаций стандартных библиотек, например STLport и т.п.). Сейчас эти вопросы обсуждаются в форумах "Прочее" и "Средства разработки".

В ходе обсуждения деталей, связанных с созданием нового форума ("C++. Библиотеки и компоненты"), некоторая часть команды предложила пойти далее и перенести из форума "C/C++" в новый форум все обсуждения, связанные с любыми библиотеками. В том числе, в первую очередь, речь идет о стандартной библиотеке, boost, Loki и т.п., которые в настоящее время обсуждаются в "C/C++".

Так как часть команды, предложившая такую модификацию тематики форума "C/C++", настаивает на публичном обсуждении данного вопроса, в этом сообщении я позволю себе изложить свои взгляды на подобные изменения.

Итак...

Думаю, для простоты восприятия этого длинного сообщения, лучше всего будет сразу сформулировать его основные тезисы:

Языки C и C++ неразрывно связаны со своими стандартными библиотеками.

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

В C и C++, кроме стандартных, существует целый ряд библиотек, направленных на решение задач, непосредственно связанных с языком, органично дополняющих его.

Соответственно, на многие "чисто языковые" вопросы находятся "чисто библиотечные" ответы.

Равно как и на многие вопросы по библиотекам, особенно стандартным, находятся "глубоко языковые" ответы.

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

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

Встроенная операция - (бинарный минус), конструкция языка, для двух указателей возвращает результат типа std::ptrdiff_t (ptrdiff_t для языка C), определенного в стандартной библиотеке.

Операция sizeof, конструкция языка, возвращает результат типа std::size_t (size_t для языка C), определенного в стандартной библиотеке.

Такие параметры встроенных типов (char, int, float и т.д.) как максимальное, минимальное значения, разрядность, режим округления и т.п. описаны в классах std::numeric_limits<>, std::float_round_style и т.д. определенных в стандартной библиотеке (соответственно, макросы CHAR_BIT, CHAR_MIN, INT_MAX и т.д. для языка C).

Завершение программы может быть вызвано функцией exit, определенной в стандартной библиотеке. Функция тесно взаимодействует с языком, в частности, вызывая деструкторы статических обеъктов и т.п.

Операция new, конструкция языка, вызывает функции operator new, определенные в стандартной библиотеке.

В случае неудачи выделения памяти неперегруженный new бросает исключение типа std::bad_alloc, определенного в стандартной библиотеке.

Также операцию new можно вызвать, с перегруженным аргументом std::nothrow типа std::nothrow_t, определенного в стандартной библиотеке. Фактически, при некотором угле зрения, это можно даже считать ключевым словом, определенным в библиотеке!

typeid, конструкция языка, возвращает ссылку на объект класса std::type_info, определенного в стандартной библиотеке.

typeid, конструкция языка, в случае невалидного аргумента, бросает исключение типа std::bad_typeid, определенного в стандартной библиотеке.

dynamic_cast, конструкция языка, в случае неудачи преобразования ссылки, бросает исключение типа std::bad_cast, определенного в стандартной библиотеке.

В случае нарушения спецификации исключений, заданной при объявлени функции, "язык" вызовет библиотечную функцию std::unexpected, определенную в стандартной библиотеке.

В процессе раскрутки стека в результате выброса исключения ("языковые" понятия), функция std::uncaught_exception, определенная в стандартной библиотеке, возвращает true.

Работа с аргументами функций с переменным числом параметров ("языковое" понятие) происходит с помощью макросов va_list, va_arg и т.п., определенных в стандартной библиотеке.

И так далее, и тому подобное.
Связь языка со стандартными библиотеками не ограничивается только теми компонентами, которые предназначены для поддержки языковых конструкций. Например, разработчики компилятора могут использовать некоторые свойства стандартных библиотек при генерации кода. Это могут быть как параметры, определенные спецификацией стандартных библиотек, так и нюансы конкретной реализации, поставляемой разработчиками компилятора. В частности, считается, что Visual C++ при генерации кода иногда использует "знание" о "некоторых" контейнерах стандартной библиотеки.
Граница между языком и стандартной библиотекой станет еще более размытой, если начать сравнивать реализацию определенных моментов в C и C++. Последний, за счет наличия классов и перегрузки операций, позволяет реализовать в библиотеке чуть большее количество компонент стандартной библиотеки, которые в C реализованы на уровне языка. К таким, например, можно отнести реализацию комплексных чисел (_Complex в C и std::complex в C++) или массивов переменной длины в C (в обсуждениях легко переходит на сравнение с std::vector в C++). Темы с обсуждениеем подобных моментов будут "болтаться" между двумя форумами в зависимости от того, о каком языке (C или C++) идет речь. Еще хуже, если тема будет включать обсуждение одной "фичи" в обоих языках — в этом случае она будет офф-топиком в обоих форумах.
Стандартные библиотеки языков C и C++ описаны в той же самой спецификации, что и "основная" часть языка, и описание языка тесно связано с описанием библиотек. В частности, описание языка содержит ссылки на описание стандартных библиотек, и наоборот. Соответственно, при обсуждении спецификации библиотек, рано или поздно будут встречаться ссылки на описание языка, и наоборот. Это неизбежно приведет к тому, что в некоторой части обсуждений, посвященных стандартным библиотекам, будет обсуждаться непосредственно языки C или C++, и наоборот. Такая ситуация очень сильно затруднит определение того, куда помещать часть вопросов, создавая проблемы как для модераторов, так и для аудитории. Ниже я приведу конкретные примеры таких обсуждений.
Можно перечислять существующие связи языка со стандартными библиотеками и далее, но, полагаю, интересным будет и немного другой угол зрения на этот вопрос. Возвращаясь к тезису, сформулированному ранее:

Вообще, развитие языков C и C++, да и, собственно, его существование в теперешнем виде, обусловлены постоянным поиском той грани, где кончается возможность реализовать желаемое в библиотеке, и начинается необходимость изменять "ядро" языка.

В частности, если посмотреть на историю языков C и C++, то можно увидеть, что в ходе эволюции часть "фич" переходила из языка в стандартные библиотеки и обратно. Естественно, для ответов на некоторые вопросы по дизайну языка или стандартной библиотеки, запросто могут потребоваться экскурсы в историю, затрагивающие и такие пограничные моменты.
Еще более заметным это становится, если обратить внимание на обсуждения предполагаемых направлений развития языка. В ходе обсуждений одна и та же "фича" неоднократно переходит из разряда "библиотечных" в "языковые" и обратно (яркий пример — move semantics). Или, например, обсуждение вопросов возможной поддержки многопоточности в языке неизбежно будет качаться от добавления функциональности и уточнения спецификации самого языка в сторону добавления каких-то новых (возможно, стандартных) библиотек и обратно. Соответственно, множество дискуссий по вопросам предполагаемых дополнений в следующий стандарт будут "размазаны" между "языковым" и "библиотечным" форумом, делая невозможным определение "правильного" местоназначения как для аудитории, так и для модераторов.
Продолжая тему развития стандартных библиотек и языка нельзя не упомянуть boost и аналогичные, дополняющие язык, библиотеки. При всем моем неоднозначном отношении к безусловному использованию boost в коммерческих проектах (по крайней мере, некоторых из его частей), умолчать о нем сложно. Фактически, это экспериментальная площадка, инициированная авторами спецификации C++ для того, чтобы иметь возможность вести "полевые" испытания библиотек, которые метятся для помещения в следующем стандарте.
В частности, в Technical Report 1, описывающий набор расширений стандартных библиотек, который с наибольшей вероятностью войдет в следующую спецификацию C++, по большей части включены прямые заимствования из boost: boost::function, boost::bind и т.д., т.п.
Кроме полигона для интерфейсов предполагаемых стандартных библиотек, "универсальные" библиотеки являются своего рода испытательным стендом для определения границы: что из прелагаемых дополнений к языку может быть реализовано в виде очередной библиотеки, а что можно реализовать только в виде непосредственной части "ядра" языка. Это например, те же move semantics, мультиметоды, лямбда, шаблоны с переменным числом аргументов, boost::static_assert, boost::preprocessor, boost::noncopyable и т.д., и т.п.
Учитывая высокую концентрацию в boost людей, работающих над спецификацией C++, большое количество новых идей по использованию языка и предложений к изменению его спецификации, исходящих из boost, можно с уверенностью сказать, что вокруг boost сейчас происходят большая, если не наибольшая, часть исследований относительно использования и дальнейшего развития С++.
Однако следует отметить, что boost не является единственным набором таких исследовательских или тесно связанных с языком библиотек. Легко можно вспомнить и другие. До сих пор политикой модерирования форума "C++" являлось поощрение обсуждения всех таких "языковых" библиотек и проектов (boost, Loki, sigslot, библиотеки мультиметодов и т.п.). Просто boost, пожалуй, является из них самым часто упоминаемым.
На мой взгляд, кардинальное отличие подобных "универсальных" библиотек C++ в том, что они не являются библиотеками, решающими задачи некоторой предметной области, как это обстоит, скажем, с zlib, libtiff, MFC и т.п. В моем понимании эти библиотеки зачастую решают задачи того же уровня, что и языковые конструкции.

Во многих других языках многое из того, что делается в тех же boost, Loki или библиотеке поддержки мультиметодов входит непосредственно в язык. Например, попробуйте отделить делегаты из C#! В "языковой" части C++ такой функциональности нет, вместо этого она реализуется в библиотеках (sigslot, boost::function). Или возьмите тот же for each... Или лямбду...

В общем, проблема с отделением этих библиотек, на мой взгляд, в первую голову в том, что любое их мало-мальски глубокое обсуждение очень легко может перейти в область обсуждения деталей самого языка. И наоборот, при обсуждении некоторых аспектов языка, разговор естественным образом поворачивается в сторону таких библиотек.
Есть еще и такая проблема: когда новички задают "языковые" с их точки зрения вопросы, они часто понятия не имеет, что на самом деле, ответ лежит в плоскости "универсальных" библиотек, подобных boost, Loki, части стандартных библиотек и т.п. В той же степени верна и обратная ситуация. Соответственно они часто будет помещать сообщения "не в тот" форум, если, конечно, вообще, получится определить "правильный" форум.
Наконец, обращаясь к prior art, мне не известно ни одного сколько-нибудь популярного форума или группы новостей UseNet по C или C++, которые бы принудительно отделяли обсуждения непосредственно языков от обсуждений их стандартных библиотек, или бы считал офф-топиком обсуждение таких проектов как boost. И, на мой взгляд, это очень легко объяснимо в свете перечисленных обстоятельств.
Соответственно, учитывая исторически сложившуюся и существующую связь языков C и C++ с их стандартными библиотеками, а также с другими "универсальными" библиотеками типа boost, Loki и т.п., я прошу аудиторию форума "C/C++" подойти очень ответственно к обсуждению вопроса отделения "универсальных" библиотек от непосредственно языков C и C++.

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

Есть также очень интересный момент, связанный с тем, что спецификации C и C++ описывают как бы интерфейсы языков и соответствующих стандартных библиотек, по большей части оставляя нюансы конкретных реализаций за кадром. Соответственно, я нахожу более чем естественным обсуждение в "Библиотеках" таких по большей части "административных" вопросов использования конкретных реализаций, как их сборка и подключение. Замечу, что в настоящее время эти вопросы обсуждаются в "Средствах разработки".

Т.е. вопросы по дизайну и использованию стандартных библиотек, boost и т.п. "на уровне языка", в своем коде, я определенно отношу к "C++". А, скажем, вопросы о том, как собрать такую-то версию STLport из исходников или как ее подключить к своему проекту — в "Библиотеки".

Немного свежих примеров дискуссий, находящихся на грани языка и стандартных библиотек. А иногда и boost

stl must die — будучи обсуждением стандартной библиотеки, дискуссия органично приходит к обсуждению отсутствия в языке так называемой семантики перемещения (move semantics). Имхо, разделять эту тему на две — лишать обсуждение одного из существенных аспектов. Этот вопрос находит свое продолжение в обсуждении одной из возможных библиотечных техник реализации move. Сложно не заметить, возникший в дискуссии вопрос по одному из нюансов определения языка.

std::auto_ptr и new[] — насколько это допустимо? :) — вопрос как бы по стандартной библиотеке. Однако по существу это снова-таки вопрос по языку, а именно по комбинации new [] и delete.

Двухмерный массив — вопрос сформулирован по языку. Однако, не будь в ответе варианта с использованием std::vector, ответ был бы значительно менее полон.

Свертка. Как ускорить? — основной вопрос по модификации фрагмента кода, однако одновременно с этим содержит вторую часть, касающуюся использования стандартной библиотеки.

shared_ptr(std::auto_ptr<Y> & r) — внешне вопрос по дизайну boost::shared_ptr (или tr1::shared_ptr — смотря из какого источника взята цитата), однако по сути является вопросом по одному из аспектов программирования, устойчивого к исключениям — одной из основных техник современного C++. Легко можно представить себе обсуждение этой техники без упоминания shared_ptr и auto_ptr, но, как это часто бывает в форуме "C++", стандартная библиотека или boost служат хорошим общеизвестным примером для обсуждения тех или иных аспектов языка.

Макрос + шаблон = не компилится — вопрос по языку, и, естественно, "библиотечный" ответ не заставил себя ждать.

Еще аналогичный вопрос с аналогичным же ответом.

Почему sizeof(long double) = 8? — вопрос совершенно не упоминающий никаких библиотек, закономерно получающий развитие в сфере стандартной библиотеки языка С.

Итератор, иерархическая структура, как сделать? — вопрос, изначально объединяющий общую часть в виде вопроса по дизайну, и затрагивающий стандартную библиотеку, предполагающий возможность наличия библиотечного решения.

Указатели на функции — очередной вопрос "по языку" с очередным неизбежным библиотечным решением.

И так далее, и тому подобное — эти вопросы даже не приходится специально искать: это все за последние несколько дней.

	От:	Павел Кузнецов
	Дата:	13.10.04 00:20
	Оценка:	5 (5) +12 -1