Существует ли язык высокого уровня, который устойчиво быстрее C?

А ты открой его=)

Ну открыл :-) Аргументации твоей там не увидел :-)

Да я не брался даже.

Можешь и браться :-) Лучше посвяти время семье :-) Если, конечно, время у цепепешника на семью имеется :-)

Погугли решения пока, можешь их покритиковать=)

Ну вот, что я говорил :-) Ещё даже не приступив к задаче, адепты цепепе уже кормят ссылками и отправками к гуглам :-) Мне не нужно это дерьмо :-) А тот шлак, который может быть и можно нагуглить, я и палкой трогать побрезгую на расстоянии, а не то, что использовать в реальном коде :-) Любая натужная попытка задействовать Тьюринг-полный (как громко и пафосно!) язык шаблонов цепепе для банальной генерации строчки в компайл-тайме закончится вывихом мозга у героя, либо монстроидальным, нечитаемым, невменяемым дерьмом, годным разве что для демонстрации джидайства в бложике :-)

Ты изначально настроен так, что спорить с тобой бессмысленно=)

Так что может и правда забью. Мне никогда не требовался такой код в реальной жизни.

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

Ключевая ошибка твоих рассуждений, как и у многих неосиляторов, в том, что ты непременно пытаешься охватить весь язык целиком. А язык - всего лишь набор определенных средств. И в философии крестов закладывалась свобода с самого начала. Никто не заставляет тебя использовать ту или иную фичу языка. Знаю проект, где от плюсов только RAII и юзали, по сути. Да мелочи вроде перегрузки функций. Масса проектов отказывается от иключений, например. Некоторые не используют стандартную библиотеку и пишут велосипеды, как ты любишь.

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

Давай, сгенерируй с помощью constexpr или шаблонов данные в формате юникод во время компиляции :-)

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

деструкторе, не уведомив об этом вызывающий код :-)

вы деструкторы явным образом вызываете?

Так что может и правда забью.

Так обычно и поступают неосиляторы :-)

Мне никогда не требовался такой код в реальной жизни.

А мне требовался. Но я признаю себя неосилятором, который не смог сгенерировать на цепепе строчку в компайл-тайме :-) Потом я открыл для себя Лисп, где такая задача решается просто, красиво, эффективно. :-)

Так что переходи и ты=)

Ты удивишься, но я сначала много писал на цепепе, прежде чем понял, что чистый Си лучше :-)

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

Конечно неосилятор :-) Строчку не смог сгенерировать в компайл-тайме :-) А если серьёзно, то многие кукарекают про сложность книжонки «Язык программирования C++» за авторством папаши Си++. По иронии судьбы, это была моя первая книга по программированию :-) Нормальная такая книга для новичков, ничего сложного :-) Существование книг всяких Майерсов и Саттеров и Александресок - это уже свидетельство непомерно сложного языка для скорее для зубрилок и мастеров лавировок, нежели чем для программистов :-) Другое дело - тоненькая книжечка по Си от его создателей :-)

Но он позволит сделать часть вещей проще и реюзабельнее, чем на голом C.

Бла бла бла :-)

вы деструкторы явным образом вызываете?

С чего ты взял, ящер? :-)

ну так а какому коду должен что-либо сообщать деструктор, ежели он явным образом не вызывается?

ну так а какому коду должен что-либо сообщать деструктор, ежели он явным образом не вызывается?

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

Мне никогда не требовался такой код в реальной жизни.

Тогда отмотай вверх по треду и задай вопрос сам себе, к чему было понтоваться этими constexpr или шаблонами, заявляя, что Сишники должны мучать проц там, где цепепешник заюзает вышеупомянутую хрень? :-)

Так что может и правда забью.

Забейте. Это знаменитый аноним со смайликами. Лиспер, но во всех срачах на тему C++/D/Rust, почему-то, агитирует за plain old C. К аргументам не прислушивается, с логикой не дружит от слова совсем. Например, выдвигает задачу сделать что-то в compile-time в C++ противопоставляя шаблонные навороты C++ ручной работе со строками в C в run-time. Т.е. главная цель — набросать как можно больше какашек в C++. Чем более вменяемые собеседники ему попадаются, чем больше какашек он пытается разбросать.

к чему было понтоваться этими constexpr или шаблонами

Это был не я. Но я согласен с тем, что шаблоны и constexpr удобные штуки.

А что ты скажешь об Idris?

Когда я его тыкал, много матерился и ругал по почте автора. Такую замечательную идею ЯП загубил. Во-первых оно с хеловорлдовых сорцов генерило некорректный епик код, который красиво так падал при компиляции с сообщением epic fail. Во-вторых оно само то компилилось, то нет по непонятной причине. В-третьих оно числа складывало в арифметике пеано и потому тупило просто неимоверно. Вопщем желание убить Эдвина а потом воскресить и убить его снова прочно застряло внутри меня.

Так обычно и поступают неосиляторы

Не, с тобой правда спорить бессмысленно, ты упёрся рогом=) Даже если я напишу что-то, тебя это не убедит.

прежде чем понял, что чистый Си лучше

тем, что лишён возможностей, которые ты не осилил?

Но в цепепе исключения не должны покидать деструктор, как учил тот же Саттер, так что облом :-)

Никакого облома. Все логично.

Единственная альтернатива - цепочка исключений (примерно как в java). Не факт, что это лучше.

почему-то, агитирует за plain old C

Ну так C - язык реально безальтернативный, не то что цепепе :-)

с логикой не дружит от слова совсем

Да? Тогда может быть ты рискнёшь наваять форматтер срок времени компиляции на цепепе? :-) Или, может быть, кто-нибудь ещё рискнёт? :-) Или, быть может, кто-нибудь откомпилит ECMASpcript регулярку в машкод на этих це/цепепе? :-) Сдаётся мне, что кроме нарезания понтов, адепты цепепе ничего не могут :-) И дело даже не в их личных способностях, а дело в неадекватном инструменте, который они так рьяно защищают :-) Ну что же, это их/ваш выбор :-)

Это был не я. Но я согласен с тем, что шаблоны и constexpr удобные штуки.

Ну тогда вперёд под лампы дневного света в офис конторки по разработке ПО для заправок :-)

Не, с тобой правда спорить бессмысленно, ты упёрся рогом=) Даже если я напишу что-то, тебя это не убедит.

В общем, слив засчитан :-) Эти сопли в сахаре наглядно доказывают, что цепепе не предоставляет адекватных средств для простой генерации строчек в компайл-тайме :-) Ч.т.д. :-)

Никакого облома. Все логично.

Бугага :-)

Единственная альтернатива - цепочка исключений (примерно как в java). Не факт, что это лучше.

Бугага :-)

Тогда может быть ты рискнёшь наваять форматтер срок времени компиляции на цепепе?

Во-первых, зачем это нужно?

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

Тогда может быть ты рискнёшь наваять форматтер срок времени компиляции на цепепе?

А кому это нужно? С чего ты взял, что это вообще какой-то там критерий?

В общем, слив засчитан :-) Эти сопли в сахаре наглядно доказывают, что цепепе не предоставляет адекватных средств для простой генерации строчек в компайл-тайме :-)

Точно с логикой проблемы=)

У тебя вывод никак не следует из посылки.

Тебе говорят, что C++ лучше С, приводят аргументы(вполне очевидные)

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

Причём сделать её вполне можно, но ты заранее сказал, что не примешь решения из-за его сложности для тебя=)

В результате ты делаешь вывод о том, что C лучше C++.

Ты уверен, что с логикой тут все хорошо?

Ну так C - язык реально безальтернативный, не то что цепепе

А теперь спокойно, ясно и чётко объясни, почему C++ не является альтернативой C?

Во-первых, зачем это нужно?

Странно слышать такой вопрос от адепта цепепе, где его создатель очень много говорил про «технологию компиляции» :-) Это ящик Пандоры, открыв который, можно вообще удивиться тому, зачем вообще цепепе компилируется в машкод? :-)

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

Бугага :-) Так не я закукарекал про constexpr и шаблоны, которые дескать делают цепепе лучше, чем Си :-) Некто пукнул, что якобы много чего теперь в цепепе можно прям в компайл-тайме делать, не то что в Си :-) Так и была поставлена эта простенькая задача, на что в ответ только «пук», «пук», «неосилятор», «вывсёврьёте» и т.п. высер :-)

А кому это нужно?

Мне нужно :-)

С чего ты взял, что это вообще какой-то там критерий?

Это критерий того, что цепепе и его адепты, кукарекающие про комплайл-тайм слились в кусты :-)

C++ излишне сложен. С лучше, т.к. проще. Ассемблер еще проще, но, увы, слишком уж низкоуровневый.

В принципе, для GUI С++ вполне подошел бы. На этом его ниша заканчивается.

А уж всякие пхытоны и прочие перлы вообще непонятно зачем были придуманы. У них вообще сложность зашкаливает, никакого профита!

Тебе говорят, что C++ лучше С, приводят аргументы(вполне очевидные)

Да нихрена он не лучше :-) Какие вполне очевидные аргументы, юноша? :-) Перечисляют наличие дополнительных «обвесов» в виде шаблонов, исключений, RTTI? :-) Если к телеге прикрепить реактивный двигатель и думать, что ездишь на продвинутой тачке, то владелец такого «авто» будет предметом ржача окружающих :-)

Странно слышать такой вопрос от адепта цепепе, где его создатель очень много говорил про «технологию компиляции» :-)

Это не ответ на поставленный вопрос. Посему повторю: зачем нужен форматер строк в compile-time?

Так не я закукарекал про constexpr и шаблоны, которые дескать делают цепепе лучше, чем Си :-) Некто пукнул, что якобы много чего теперь в цепепе можно прям в компайл-тайме делать, не то что в Си :-) Так и была поставлена эта простенькая задача, на что в ответ только «пук», «пук», «неосилятор», «вывсёврьёте» и т.п. высер :-)

Шаблоны и constexpr делают C++ удобнее в ряде проектов, чем C. Какие-то вещи в C++ можно делать прямо в compile-time. Чего C не умеет.

Это то, что вам здесь пытаются сказать.

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

Отсюда и желание увидеть ее решение на C.

Покажете такое решение или изойдете на смайлики?

В результате ты делаешь вывод о том, что C лучше C++.

Конечно лучше, ведь он проще :-)

Ты уверен, что с логикой тут все хорошо?

Конечно уверен :-) Смысл мне использовать непомерно усложнённый инструмент, которым всё-таки нельзя сделать того, что мне нужно, если можно с таким же неуспехом пользоваться гораздо более простым инструментом? :-) Т.е. цепепе ничем не лучше Си :-)

Посему повторю: зачем нужен форматер строк в compile-time?

Для эффективности :-) У меня есть вся информация, которая необходима компилятору для генерации константы :-) Почему же он опять генерирует код для генерации в рантайме того, что он может сгенерировать в компайл-тайме? :-) Да потому что цепепе - ограничен и ущербен как язык :-) Он - не метаязык. Впрочем, как и Си :-) Только Си - много проще. Такие дела :-)

Отсюда и желание увидеть ее решение на C.

Адекватного решения на C, так же как и на цепепе, нет и быть не может :-)

Мне нужно :-)

И как ты это делаешь на Си?

Впрочем, как и Си :-) Только Си - много проще.

В сухом остатке получается, что персонально для вас «лучше» == «проще».

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

Правильно я понимаю?

Адекватного решения на C, так же как и на цепепе, нет и быть не может

Что говорит лишь о том, что для данной конкретной задачи C и C++ одинаково не приспособлены. Не более того.

Что не дает абсолютно никаких оснований для выбора между C и C++.

Это критерий того, что цепепе и его адепты, кукарекающие про комплайл-тайм слились в кусты

С чего вдруг? Объясни логику. Да, в С++ есть определенные возможности работы в compile time, которых нет в С. Это просто факт. Там вполне можно написать форматтер строк или что вы там хотите написать, единственная проблема в том, что в C++ нет встроенных CT-строк. Но это никак не меняет вышеуказанного факта о бОльших возможностях C++ по сравнению с С.

C++ излишне сложен.

Но он предоставляет определенные возможности, которых не предоставляет С. И какая альтернатива C++? Rust и D? Возможно, но на данный момент нет.

С лучше, т.к. проще.

Объясните мне эту логику, пожалуйста. А Logo(черепашка) еще лучше, правильно? А brainfuck?

Но он предоставляет определенные возможности, которых не предоставляет С

Эти возможности только гуеписателям нужны. В остальном бессмысленное усложнение.

В сухом остатке получается, что персонально для вас «лучше» == «проще».

Ну а смысл пользоваться чем-то более сложным, если можно пользоваться чем-то более простым и с тем же результатом? Или даже с лучим результатом? :-)

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

При этом на C пишут гораздо больше людей, чем на C++ :-) На C++ переходят единицы, взвесив «за» и «против» наитщательнейшим образом :-)

Там вполне можно написать форматтер строк или что вы там хотите написать, единственная проблема в том, что в C++ нет встроенных CT-строк.

Всё никак не уймёшься? :-) Ну тогда вперёд, пиши форматтер строк времени компиляции на цепепе :-) Никого не волнует чего там в цепепе нет, а что там есть. Не форматтера - слив засчитан :-)

Эти возможности только гуеписателям нужны. В остальном бессмысленное усложнение.

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

Единственная альтернатива - цепочка исключений (примерно как в java). Не факт, что это лучше.

Интересно, у этого решения есть какие-то «технические» минусы кроме оверхеда?

Ещё есть сомнения, что обрабатывать цепочку удобно и на это не будут забивать. Как там с этим в джаве?

Да нихрена он не лучше

Лучше

Какие вполне очевидные аргументы, юноша?

Если кратко резюмировать, то: наличие возможностей, отсутствующих в Си и при этом не утяжеляющие язык настолько, что он становится неприменим там, где используется Си.

PS. И пока ты будешь тужится, героически доказывая, что на цепепе «вполне себе можно написать генерацию строчек в компайл-тайме», я уже раз 10 напишу простой как пробка макропрепроцессор, который соберёт строчку из кусков и скормит константу компилятору :-)

Если кратко резюмировать, то: наличие возможностей, отсутствующих в Си и при этом не утяжеляющие язык настолько, что он становится неприменим там, где используется Си.

Лужа и только :-)

Ты забываешь про буст.

Я в одной штуке бешеный макрос навелосипедил, а бустом этот велосипед намного короче (где-то мне на SO отвечали).

Ну а смысл пользоваться чем-то более сложным, если можно пользоваться чем-то более простым и с тем же результатом?

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

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

Да, квалификация для написания std::vector на C++ нужна повыше, чем для последующего использования std::vector в коде. Тем не менее, это лучше, чем голый C, в котором динамический вектор, да еще для «тяжелых» структур данных — это простая задача, но очень сложно реализуемая без багов.

Или даже с лучим результатом? :-)

Ну и где этот лучший результат?

При этом на C пишут гораздо больше людей, чем на C++ :-)

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

На C++ переходят единицы, взвесив «за» и «против» наитщательнейшим образом :-)

Мне в 92-м году для этого не пришлось ничего взвешивать, выбор был тривиален: на C++ я мог легко написать свой собственный set, а на C это была задача, требующая гораздо больше внимания и осторожности. С тех пор разрыв в выразительных способностях этих двух языков увеличился еще больше и достиг совсем уж неприличных размеров.

Ты забываешь про буст.

Я на него давно забил уже :-) Зачем мне ядерная субмарина в речке шириной 300 м? :-) Мне комфортней на экскурсионном катере, или на скутере :-)

потому что даже описывать GUI на цепепе - это не для слабонервных

На С++03 - да. На С++11 я для себя написал библиотеку в один хедер, и UI прекрасно себе создается, например, так:

            tab( tr("Authentication") ) ^
            vbox
            {
                form
                {
                    { tr("User:")     , user_ -hgrow() },
                    { tr("Password:") , password_ -hgrow() }
                }
                -hgrow(),

                expander()
            }

А кто хочет поныть, тот всегда найдет повод.

Интересно, у этого решения есть какие-то «технические» минусы кроме оверхеда?

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

Допустим, что мы завершаем группу объектов(массив, например). Пытаемся завершить очередной объект - исключение. Что делать? Отлавливать и чистить следующие объекты? Или просто прокидывать дальше? Можно ли очищать память под объект, который не удалось завершить? В каком он находится состоянии? Как его удалить «еще раз»? Очень много вопросов.

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

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

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

десятки твоих зашкваров валяются на лоре, а сотни выпилены

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