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

При чём тут стандарт? С++ просто самый сложный язык из популярных. Отсюда и все помидоры.

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

Стандарт ECMA-334 (C# Language Specification) — только язык, без библиотеки — 430 страниц (Annex-ы не считал).

C++ разрабатывается комитетом, это автоматически увеличивает размер стандарта

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

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

Ну у юникода 1000 страниц стандарт.

Каким образом? По-моему, наоборот.

Не слушайте наркоманов.

Каждому хочется, чтобы учли его корнер-кейс

Ладно, не буду.

К слову у HTML+CSS наверное раз в 5 больше, но все носятся с ним как со священной коровой.

А это вообще не языки программирования :P

Можно примеры?

Только вебмакакам не говорите.

Возьми любую дублирующуюся функциональность, например перегрузки функций и значения по-умолчанию

for при наличии if и goto это тоже дублирующаяся функциональность?

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

Ни в чем. Это вообще не имеет отношения к сложности Си++.

Ну так на него и ноют.

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

Это.

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

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

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

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

Что именно ты хочешь доказать этой темой?

Великую теорему Ферма.

самый сложный язык

так всегда наговаривают на язык, который хотят уничтожить
кстати, как измерялась «сложность языка»?

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

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

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

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

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

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

например перегрузки функций и значения по-умолчанию

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

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

+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 «это не баги, а фичи»

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

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

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

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

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

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

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

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

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

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

Постоянно слышно жалобы

Это я.

концепты, сеть, рефлексия

Они даже юзабилити не осилили, а вы про высокие материи.

Что такое юзабилити?

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

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

Покажите код, который проверяет наличие элемента в контейнере.

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

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

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

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

ranges же приняли

В каком именно контейнере?

В ISO-контейнере, очевидно. Стандарт C++ это ISO-стандарт.

Они тут при чём?

Любой.

Ну я думал ты недоволен тем, что 2 итератора надо совать.

И это в том числе.

Ну. Так ranges приняли. Теперь не нужно совать итераторы, можно сразу контейнер. http://eel.is/c draft/alg.find

Для любого контейнера и код будет любым. Давайте конкретнее, если мозгов хватит сформулировать свое желание.

Я могу написать vec.contains(item)?

Опять вы за своё...

Нет. А зачем так странно писать?

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