Разделить стандартную библиотеку на уровни

Александр Коновалов
Александр Коновалов

Идея очень абстрактная, но всё же интересно мнение сообщества на её счёт.

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

Видимо при создании Java его разработчики столкнулись с аналогичной проблемой, решением которой стало разделение платформы на 4 уровня: Java Card, Java ME, Java SE, Java EE. Более старшая платформа включает функции более младшей.

Моё предложение состоит в том, чтобы применить такую схему и для стандартной библиотеки. Что бы это могло дать? Во-первых, runtime библиотеку можно было бы разделить в соответствие с этими уровнями. Таким образом, на платформах с ограниченными ресурсами не пришлось бы тащить весь runtime. Во-вторых, это дало бы возможность появлению компиляторов с "урезанной" реализацией, которые декларировали бы поддержку только конкретных уровней.

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

1
рейтинг
4 комментария
Marat Abrarov

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

Аргумент "против" от Страуструпа - такое разделение на уровни введет никому не нужную фрагментацию в C++, где и так хватает проблем с разными платформами (их всех нужно поддерживать) и компиляторами (каждый добавляет свою специфику, включая опции сборки). Кажется, был Embedded C++ с урезанной стандартной библиотекой (не могу найти правильные ссылки), но идея давно потухла.

В той же Java можно быстро нарастить нехватку чего-то в стандартной библиотеке легким подключением сторонних библиотек (5-6 строк в maven-проекте). В C++ подключить (собрать, а потом подключить) стороннюю бибилиотеку - целое (зачастую печальное) приключение.

Marat Abrarov
Обновлено 
Александр Коновалов

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

Опция сборки считай добавляется только одна: уровень. Кроме того, думаю, что могут начать появляться компиляторы, которые поддерживают функционал только до определенного уровня (с наличием llvm вероятность небольшая, но всё же есть).

Александр Коновалов
Виктор Губин

Не стоит делать то-же что и Java 9. Сломали все что только можно было сломать.

Виктор Губин
Александр Коновалов

Виктор Губин, на сколько помню, это было задолго до Java 9.

Александр Коновалов
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).
Все предложения