LINUX.ORG.RU

О размере стандарта C++

 , ,


1

2

Часто приходится слышать критику типа «ко-ко-ко, C++ сложный язык, стандарт распух более чем на полторы тыщи страниц, это нивазможна выучить!!!11».

Как известно, стандарт условно делится на Core («сам язык C++») и Library-части (стандартная библиотека). Это не на 100% строгое разделение, «сам язык» знает кое-что о стандартной библиотеке (std::size_t, std::ptrdiff_t, std::initializer_list и т.д.), поэтому я говорю «условно делится».

Стандарт начинается с Core-части, после идёт описание библиотеки. Вот табличка страниц, с которых начинается Library-часть («Library introduction») в разных версиях стандарта:

  • C++98 — стр. 311
  • C++03 — стр. 317
  • С++11 — стр. 424
  • C++14 — стр. 414
  • C++17 — стр. 445

итого, за почти 20 лет «сам» C++ распух чуть более чем на 100 страниц, на треть от C++98.

Всё остальное распухание с 776 до 1618 страниц приходится на стандартную библиотеку.

В чём сложность осилить 100 страниц за 20 лет? Ладно, там не только добавляли, но и меняли уже имеющееся. Страниц на 200-250 новшеств может набралось.

Или кто-то всерьёз под изучением языка понимает зубрёжку списка функций и их аргументов из его стандартной библиотеки?

Или кто-то всерьёз под изучением языка понимает зубрёжку списка функций и их аргументов из его стандартной библиотеки?

Это.

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

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

energetix_user ()

В чём сложность осилить 100 страниц за 20 лет?

«Не количество, а качество». Текст стандарта C++ не написан для людей, а скорее для абстрактного интерпретатора, который создает компиляторы. Благо есть cppreference и stackoverflow. Учить стандарт – не слишком окупаемое занятие.

KennyMinigun ★★★★★ ()

Или кто-то всерьёз под изучением языка понимает зубрёжку списка функций и их аргументов из его стандартной библиотеки?

а разве не существует студентов которые учат путём зубрения?

PexuOne ()
Ответ на: комментарий от utf8nowhere

Ну многие говорят что раз 1600 страниц в стандарте, значит сложный.

ты прав, объём стандарта можно рассматривать как один из критериев сложности

anonymous ()

это какой-то спор о том, у кого стандарт длиннее?

вообще, для изучения языка не нужно читать стандарт. стандарт написан для тех, кто пишет компиляторы. ну и для небольших срачиков на ЛОРе, когда особо упоротые граждане спорят о том, UB или не UB в каком-то хитровывернутом случае, который в природе не встречается. в стандарт можно заглянуть, если ты заподозрил, что компилятор генерит что-то не то. но это уже не уровень начинающего или даже среднего программиста. большинству людей он просто не пригодится ни разу в жизни.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun

«Не количество, а качество»

+1. и в языках, спроектированных коммитетом по принципу «давай, чтобы было всё» получается качество так себе потому что пытаются угодить всем.

Текст стандарта C++ не написан для людей, а скорее для абстрактного интерпретатора, который создает компиляторы.

и тут можно пойти двумя путями:

1. сделать максимально полный, корректный, подробный стандарт с описанием ad hoc случаев и примеров use case когда это может пригодиться, «на всякий случай», см. пункт +1. выше.

2. сделать минимально необходимый и максимально достаточный стандарт с succint описанием операционной семантики, описывающей как такой интерпретатор написать, и устранить все UB случаи. например, см. работы Luca Cardelli по формализации семантики объектно-ориентированного, функционального и т. п. программирования.

ежу понятно, что второе описание более компактно и полезно.

ну то есть, вот Никлаусу Вирту, Абельсону и Сусьману, Гаю Стилу и прочим — понятно. а Бьярну Страуструпу или Кенту Питману — непонятно вот.

вообще говоря, можно пойти и третьим путём. например, если говорится про какую-то C memory model, абстрактную C машину. то можно сменить машину — например задав Rust memory model, абстрактную ржавую машину. которая похожа на сишную, но не совсем — есть определённая паника, модель владения, упрощения для многопоточности и т. п.

четвёртый путь — ну сказать что есть какой-то D refenrence implementation (DMD), например, абстрактный D стандарт и его конкретная реализация в компиляторах (DMD, gcc, ldc и т.п.). и в случае вопросов тыкать носом в reference implementation «это не баги, а фичи»

anonymous ()
Ответ на: комментарий от RazrFalcon

Каким образом количество страниц коррелирует со сложностью?

есть два типа сложности complexity-- complicated громоздкость «потому что не понимаем, как сделать тоже самое просто» и sophisticated «сложные концепции и подходы, потому что позволяют решать сложные задачи (просто, то есть, проще чем без этих концепций и методов».

вторая сложность — имманентная сложность задачи. первая — привнесённая и дурная, избыточная сложность типа «некогда думать, трясти надо».

поэтому коррелирует нелинейно. если 1 compicated — это не то чтобы сложность, просто надмозги переводили, а комитет проектировал. если 2 sophisticated — то это правильная, необходимая сложность.

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

а вообще трудность применения стандарта не в этом. а в том, что например в отличие от других стандартов ISO на процессы и лучшие практики, например — в этих стандартах на описание языка программирования тут отсутствует раздел про валидацию и верификацию методик проверки внедрён ли стандарт в конкретную практику. потому что фломастеры у всех разные.

в итоге сложность освоения стандарта распределяется не только по Library/Core, но и compicated/sophisticated и нужно/ниасилил/нинужна конкретный юзкейз фломастера.

anonymous ()
Ответ на: комментарий от Iron_Bug

ну ещё его надо читать, например, чтобы понимать как применять конкретные юзкейзы. например, невиртуальный деструктор по умолчанию или невиртуальные методы по умолчанию. и грабельки партизанские на виду закопаны. в тех же сисярпе и жабе дефолтная реализация лучше ложиться на типичные примеры использования, а чтобы сделать финт ушами — об этом нужно явно написать, и понимать зачем. в итоге нубам осилить «с++ нового поколения» проще, чем старого — потому что более разумные дефолтные настройки. опять же, или понимать семантику копирования/владения или положить на откуп мусорщику сборку мусора и garbage in/gargage out в голове таких архитектурных проектантов.

anonymous ()
Ответ на: комментарий от anonymous

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

Постоянно слышно жалобы, что в C++ кучу всего «нужного» и «полезного» годами не принимают (концепты, сеть, рефлексия и т.д.), а в этом топике какая-то аномалия. Кому-то кажется, что в стандарт принимают много всего, т.к. «его пишет комитет».

utf8nowhere ★★ ()
Ответ на: комментарий от utf8nowhere

а что мешает эти (концепты, сеть, рефлексию, и блин, даже модули, лол) сделать не реализацией на уровне стандарта а реализацией на уровне языка, библиотеки? самостоятельно?

исключительно compicated описание языка и мешает. в других языках можно и самому сделать, потому что базовые концепции языка более гибкие.

anonymous ()
Ответ на: комментарий от utf8nowhere

Кому-то кажется, что в стандарт принимают много всего, т.к. «его пишет комитет».

проблема не в том, что там много всего или принимают/не принимают, принимают медленно/принимают быстро/не принимают вааще.

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

отзыв рецензента: в работе есть много нового, и много нужного. к сожалению, нужное — не ново, а новое — не нужно

anonymous ()
Ответ на: комментарий от RazrFalcon

Ну я же не виноват, что вы не можете сформулировать мысль хотя бы вот в таком виде: «я хочу видеть в каждом стандартном контейнере метод find(item)».

eao197 ★★★★★ ()