Почему все же с++ такой сложный язык?

Покажи другие исключения.

Предлагаемые уже довольно много лет Саттером.

Перечисли отличия этих подходов.

В контексте раста функциональная обработка ошибок к кодам возврата добавляет семантику и проверки на уровне типов.

Маленький и какой-то несчастный язык.

В нём есть абсолютно всё.

В нем действительно ничего нет, кроме тк.

Никакое «тк» здесь не важно - важен сам язык, а не либы и биндинги к нему.

Им практически никто не пользуется.

Я просил критерии «устаревания», а не популярности.

Аду попробуй :) Глядишь, покажется «а С++-то не такой и сложный»

Хаха

Плохому танцору и JS сложный.

Лучше по каким критериям?

По любым.

По скорости разработки не лучше.

Лол, я не говорю, что питон лучше с++ или что-то

Говоришь. Вторая попытка.

но выкидывать мусор нельзя - ибо совместимость.

Это больше к компиляторам относится, чем к самому языку. Читая документацию, часто можно натолкнуться на: (deprecated in C++20) и даже (removed in C++17).

Сходу нашёл: unary_function, binary_function, binder1st, ptr_fun, std::atomic_…< std::shared_ptr>. Я уже не говорю о случаях вроде std::codecvt, где устаревает форма с определёнными типами.

В нём есть абсолютно всё.

Что?

Никакое «тк» здесь не важно - важен сам язык, а не либы и биндинги к нему.

Точно?

Я просил критерии «устаревания», а не популярности.

Ну так может на нем никто ничего не делает (т.е. он не популярен) потому что особо ничего делать комфортно нельзя (потому что устарел и не хватает как раз этих биндингов).

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

Не понял, последние выражение в функции автоматически возвращается как значение функции? Ээээ… а если там несколько выражений подряд и последнее случайно стёр и не заметил? «Счастливой отладки»?

Предлагаемые уже довольно много лет Саттером.

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

В контексте раста функциональная обработка ошибок к кодам возврата добавляет семантику и проверки на уровне типов.

Я не про раст, а в общем плане.

Какое это имеет отношение к темплейтам в стиле С++98?

Ну если ты наконец-то готов обсуждать вопрос по существу, то тот код был сферическим в вакууме примером того, как растёт сложность в крестах и других языках, которые идут тем же путём. Я хз зачем вы тут на пару с тем оратором решили буковки попередвигать… Да и ладно.

Но смысл идеи в том, что в гомоиконном языке это всё нафиг не упало. Ни шаблоны которые превращают язык в подобие brainfuck, ни constexpr который тут работает, а там не работает. Можно делать любой кодоген не сходя с места и это в моём понимании хороший способ борьбы с увеличением сложности языка.

Что?

То.

Точно?

Если ты не отличаешь язык от либ - то нет, не точно.

Ну так может на нем никто ничего не делает

«может» и прочие фантазии не интересуют.

последние выражение в функции автоматически возвращается как значение функции

Да, с оговоркой на то, что оно должно быть без точки с запятой после него. В противном случае возвращается () – аналог void.

«Счастливой отладки»?

Нет. Последние несколько выражений отделены друг от друга точкой с запятой. Соответственно, если последнее нечаянно стирается, то тело функции начинает возвращать () в противоречие с сигнатурой, что выдаст ошибку времени компиляции.

То.

так что? =)

Если ты не отличаешь язык от либ - то нет, не точно

Язык без либ ничто.

«может» и прочие фантазии не интересуют.

Есть статсистика.

Предлагаемые уже довольно много лет Саттером

Мне тоже интересно, можно ссылку?

А если последнее стёрлось с точкой запятой с предыдущей строки?

Но смысл идеи в том, что в гомоиконном языке это всё нафиг не упало.

Проблема в том, что гомоиконичные языки нафиг не упали.

Ни шаблоны которые превращают язык в подобие brainfuck,

Признайтесь, вас в детстве шаблоны там трогали?

ни constexpr который тут работает, а там не работает.

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

должен ли язык быть априори настолько сложным для достижения мощи как в с++

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

А если острым и в глаз?

так что? =)

Я тебе уже сказал - всё. Научись читать.

Язык без либ ничто.

Натурально апи-обезьяна.

Есть статсистика.

Сначала ты говорил про «может», а сейчас у тебя уже «есть статистика». Разъясни это.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2232r0.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf

https://www.youtube.com/watch?v=ARYP83yNAWk

cloun1902

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

:)

этот код заработает

Этот заработает, другой нет.

Проблема в том, что гомоиконичные языки нафиг не упали.

Ну так может и стоить обратить внимание, а не изобретать бесконечно новые кресты, расты и зиги? Это риторический вопрос, если что.

C++ не сложный, C++ большой

Плюсую. Два раза.

Внезапно, на С++ можно писать просто.

Я как-то пробовал написать код на Питоне, а потом переписать его на С++. Большинство кода получилось не намного сложнее. Более того, вещи, которые на Питоне делаюсь сложно, на С++ можно сделать намного проще.

Просто С++ сразу дает тебе в руки 100500 крутилок, и у тебя сразу руки тянутся их крутить.

Заработает, когда имплементация будет полноценно поддерживать 20-й стандарт.

А можно не ждать и просто взять D. Где уже давно все работает ;)

import std;
    
int fib(int n)
{
    return n<=1 ? n : fib(n-1)+fib(n-2);
}

int main()
{
    10                   // Заданное значение
        .iota            // Перебираем от 0 до заданного значения
        .map!(n=>fib(n)) // Для каждого значения n вычисляем число Фибоначчи
        .writeln;        // выводим число Фибоначчи (т.е. именно ленивый вывод)

    return 0;
}

https://godbolt.org/z/PGvxn6

Я тут, конечно, не стал вычислять до 1000 по очевидной причине. Также в стандартный поток вывода выводится не инициализированный массив, а range. Которые тоже давным давно работают в D, откуда Эрик Ниблер, собственно и вдохновился (в числе прочего). Но если нужен именно массив то там добавится только .array:

    10.iota.map!(n=>fib(n)).array.writeln;

Память выделена будет динамически сборщиком мусора. А если нужно вручную памятью управлять, то такой вариант:

    auto inputRange = 10.iota.map!(n=>fib(n));
    auto a = Array!int(inputRange);
    a[].writeln;

З.Ы. no-such-file - кстати, тут однострочник в функциональном стиле, прямо как в Лиспе, ну или похоже очень, как минимум

Этот заработает, другой нет.

Откуда вы взяли «другой»?

Ну так может и стоить обратить внимание

Так они не лично мне не упали, они абсолютному и подавляющему большинству не упали. Если говорить конкретно о разнообразных лиспах, то на них хорошо выглядят высокоуровневые API, когда пресловутые DSL во все поля и все гладко и красиво. Когда приходится писать низкоуровневый код, все становится очень прискорбно.

а не изобретать бесконечно новые кресты, расты и зиги?

Я не агитировал «за» изобретание.

Я начинал знакомство с С++ с книги Джеффа Элджера

Ты именно НАЧИНАЛ?

Этакнига — совсем другое дело. Прежде всего, она предполагает, что вы уже владеете С++. Вероятно, вы программировали на С++ в течение года-двух или более. Став настоящим асом, на вопрос о должности вы перестали скромно отвечать «Программист»; теперь ваш титул складывается из слов «Старший», «Специалист», «Ведущий», «Разработчик», «Проектировщик» (расставьте в нужном порядке). Вы уже знаете, что «перегрузка оператора» не имеет никакого отношения к телефонной компании, а «класс-коллекция» — вовсе не сборище филателистов. На вашей полке стоит книга Страуструпа «Annotated C++ Reference Manual», которую в профессиональных разговорах вы часто сокращенно именуете ARM и даже не считаете нужным расшифровывать. Если вы узнали себя, добро пожаловать — эта книга для вас.

Ты именно НАЧИНАЛ?

Ага. Я только с си был знаком. Ну с крестами на уровне «вот там есть классы, у них можно вызывать методы».

Плюсы настолько сложны язык, что это ппц. Однажды я (не программист и не учил его в институте) видел fizzbuzz на нём без единого ключевого слова объясняющего, что сейчас будет вывод на stdout и при этом он печатал в консоль результат. Зачем так сложно? Без вот этих миллиардов деталей даже прочесть и скомпилировать в голове невозможно.

http://fortranwiki.org/fortran/show/Object-oriented+programming

Это чтоб примерно представлять что мне та реализация напомнила. Тоже не без недостатков. В 2003 чуть улучшили.

У меня такая же ситуация. 1 в 1. Как по мне книга слегка сложновата для начала... Даже не знаю.

Синтаксически язык сложен и большой, да, и с каждым релизом добавляют новые или полируют старые синтаксические конструкции. В 20м добавили новый синтаксис в requires например, который почти как С++, но с нюансами. Это сложно оправдать простой эволюцией, это часто является результатом хуяк-хуяк-и-в-стандарт. Стоит просто понаблюдать, как работает и устроен комитет, как написан сам стандарт. Самый большой квест — это даже не придумать или реализовать в компиляторе, а описать идею в терминах стандарта. Отсюда растут тысячи UB, равно как и синтаксических недоделок. Потому что так проще описать в стандарте и пропихнуть через комитет.

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

Ты не понял задачи. Нужно было производить вычисления в компайл тайме, а ты сделала вообще совершенно не это.

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

Не совсем:

• в явушке ты можешь забывать грохать объекты- она разрулит их сама как только они потеряют связи, тебе не надо помнить высвобождает ли твой промежуточный модуль память по больше не используемым данным, и какие данные у тебя дальше где используются - полный автомат
• в явушке ты не соберёшь проект пока не закроешь явные исключения, либо твой модуль явно требует закрыть исключения либо он сам его должен разрулить - это нельзя забыть сделать.

По сути у тебя в Яве всего несколько вариантов фатально накосячить:

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

Притом первый случай от плохой лексики (ты можешь сразу явно указать что используется нулл) а второй от мозгов зависит (в Яве есть все что нужно для безопасного многопотока но этим надо уметь пользоваться).
В сях у тебя гораздо больше возможностей (накосячить) :-)

Как хорошо что ты задала этот вопрос. В D вычисления в компайл-тайме тривиальная вещь, это еще одно его преимущество:

    enum arrayInCompileTime = 10.iota.map!(n=>fib(n)).array;

Вот и все, что нужно сделать в D, чтобы получить массив в компайл-тайме. Поскольку enum это литерал, то компилятор D автоматически выполняет вычисления в компайл-тайме, без лишних указаний в виде constexpr.

C++ модули в Clion + clang уже завезли? Кто-нить перевёл проект, есть что почитать внятное, как всё это дело настраивать на Xcode?

D - это то, каким с++ должен был быть, особенно это видно в 2021, а, ведь, уже много лет прошло, а в кресты тока завозят фичи

Это не сложный код, если понимаешь как работают шаблоны.

Ну так просто в D нет нужды тащить легаси, вот и воспользовались этим, учитывая опыт С++. Я плюсы лучше стал понимать после D.

Вот что заставляло комитет заставлять static if создавать scope? Ведь насколько проще, когда скоупа нет. Иногда логика комитета заставляет задуматься. Я склоняюсь к тому, что единственный, кто может убить с++ - это только сам с++

Это не сложный код, если понимаешь как работают шаблоны.

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

Так он под грузом токсичности уже растерял рынки - Go, Rust, Swift

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

#язабан

Ответ в строке с тегами:

history

плюсы вообще норм, особенно если говноед

Объектов нет (ну окей в си тоже нет). Try catch нет, вместо него какай-то фигня. И так далее… Синтаксис идиотский ИМХО.

игра фигня мне не понравилось !!!!!!!!!!! остоётся токо ждать лутшего.Это для меня говно плохо зделана тупо.Немогли зделать всё как в Crusis!!! И графику и управление.Не рекоминдую такую игру!!!

• Zhbert

вот у меня есть проект, который меня и коллег не первый год бьёт по пальцам стальной линейкой 60 см.

https://github.com/RC-MODULE/media.hpp/

гляньте любой файл и ответьте честно - с++ - простой язык? :-D

Откуда вы взяли «другой»?

Оттуда же, откуда первый. Как бы работать должен любой код, а не какой-то специфичный.

Так они не лично мне не упали, они абсолютному и подавляющему большинству не упали

Ну так а чего ты тут забыл? Вопрос ТСа был в том, как можно по-другому, какие есть альтернативы имеющимся решениям в виде крестов и подобных.

С std::array должно), там constexpr давно сделали.