Вы теперь все так же пишете же ну?

Кэп, ты веский, но:

#include <iostream>

int main(int argc, char **argv) {
    std::cout << "Hello, world!" << std::endl;
    return 0;
}

Это генерят шаблонные проекты KDevelop, например :)

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

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

Упоротых фанатиков никто не любит :)

Это он в начале был процедурный :) Теперь он немножко «мультипарадигменный».

Если ты фанат «можно не писать, зачем писать» — эт не значит что все такие.

Я всех такими сделаю.

Упоротых фанатиков никто не любит :)

И вы меня полюбите.

Это генерят шаблонные проекты KDevelop, например :)

Шаблоны это не интересно.

https://github.com/uNetworking/uWebSockets/blob/master/examples/HelloWorld.cp...

https://github.com/microsoft/vcpkg/blob/master/toolsrc/src/vcpkg.cpp#L320

«А ты азартный, Парамоша! Вот что тебя губит» (с)

Шаблоны это не интересно.

Шаблоны это прекрасно с т.з. слегка охладить твое траханье :) Гугл «контрпример».

И оба варианта выглядят ужасно.

можно ужаснее

template<typename T>
[[nodiscard]]
extern constexpr 
T add(T const a, T const b) 
noexcept(noexcept(a+b))
requires(requires(T const x, T const y){{x + y} -> std::same_as<T>;});

И ведь пишут же цуканы. Далеко не раз сталкивался с ситуацией -funsigned-char и -fsigned-bitfields

С чарами это другое.

Третье! В голове должны быть мозги а не труха. А такую write-only чепуху писать как здесь дискутируется - ну бред же. Хз как у кого но у меня целые генерации мол. програмистов отучиваются он свеженького говна посля того как наступает момент дебага/багфикса не своего кода (но все еще в своем проекте).

И вопрос не в том что стандарт плохой. Вопрос в том что в основной своей массе программисты не готовы вот те все плюшки использовать во благо.

Це на якой мове?

Конечно, ведь чем больше кода тем лучше (НЕТ)

Эта фича абсолютно бесполезна в любых мало-мальски полезных программах. Экономия в одну строчку? Чтобы в редкие моменты, когда заглядываешь в код main() внезапно заметить отсутствие return, и буквально сразу вспоминать, что так можно, потому что это main()?

+1. Более того: по описанному тобой юз-кейсу (под которым тоже подписываюсь) – это даже не «бесполезно», а «вредно». Ещё один пример бардака.

C#. правда в c++ не транслируется

Я всех такими сделаю.

Я искренне надеюсь, что мне не придется с тобой пересекаться в одном проекте

auto

-> int

Где смысл?

И к тому же нельзя вот так. Смысла в auto нет)

int test () -> int {
   return 0;
}

Смысла нет. trailing return type нужен для того, чтобы можно было выводить его из типов аргументов:

decltype(x) foo(some_type x) { ... } // не скомпилируется
auto foo(some_type x) -> decltype(x) { ... } // все нормально

В Паскале такой проблемы изначально не было. Зачем придумали писать тип в начале - непонятно.

Это генерят шаблонные проекты KDevelop, например :)

Тут кстати дважды говнокод. Кроме return 0; ещё и std::endl;. Не зря царь с этого позора перешёл на CLion.

C# очень сложный язык, в котором очень нужно много знать, чтобы писать адекватно. И сложно увидеть во что он компилируется из-за JIT. С++ намного проще как язык чем C#.

Да не, они недостаточно сложны, где нормальное метапрограммирование с рефлексией, а?

RTTI есть, но не всеобъемлющее.

Ну тут препроцессор еще влияет

Скорее шаблоны.

В Паскале такой проблемы изначально не было. Зачем придумали писать тип в начале - непонятно

Ты знаешь, я поискал в истоках ответ на этот вопрос... и не нашел его. Вот просто взяли и поставили в начало. Ну типа K&R — это бездонный колодец плохих архитектурных решений.

И оба варианта выглядят ужасно.

Кстати, на С уже почти также.

[[nodiscard]], [[maybe_unused]],[[deprecated]] уже в текущем драфте: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

и реализовано в текущих компиляторах: https://gcc.godbolt.org/z/bGxs6Y

А если примут предложения по constexpr и panic, то будет вообще похоже на С++…

А что мешает выводить его из типов аргументов, когда он описан в начале?

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

auto foo() {
    // ...
}

auto bar(auto x) -> ... {
    // ...
}

Ну сейчас не 80-е, заголовок функции это единая конструкция. В каком порядке в ней что идет - абсолютно неважно, все равно сперва надо прочитать весь заголовок и сформировать структуру-описание заголовка

Я на 99% процентов уверен, что сперва парсер превращает заголовок в что-то вида

{
   variable_type : "return type",
   function_name : "name",
   arguments : [
       {
           variable_type : "type",
           argument_name : "name"
       },
       ...
   ]
}

И уже потом типы выводятся итд

А если нет - то тем хуже, такой компилятор будет сложнее поддерживать и развивать

можно ужаснее

И что? Это что-то отменяет?

царя читай

Вредный совет.

в perl.

https://bash.im/quote/463127

Лол, быдлокод скорее всего в дизайне либы к языку («тут у нас сиплюсплюс, тут внезапно сишечкой запахло в гайдлаенах, тут рыбу заворачивали и сами не поняли чо хотели»). Зависит от цели же. Хочешь ты сразу flush или нет (многие хотят в известных случаях) :) В хеллуворлде с одной строчкой скорее всего все эти претензии к пуговицам — задрочки про реданданси и «деградацию перфоманса»? Серьезно? В... хелворлде? — это невыносимые моральные страдания эстетствующих мсьей (о чем прям в гайдлайнах сказано Эстеты все пидоры и царь тоже Они должны страдать) :)

Apart from the (occasionally important) issue of performance, the choice between '\n' and endl is almost completely aesthetic.

И в виках с комментариями стандарта написано

Notes

This manipulator may be used to produce a line of output immediately, e.g. when displaying output from a long-running process, logging activity of multiple threads or logging activity of a program that may crash unexpectedly. 

Если сломался хелуворлд и «анекспектедли» — это всем регрессиям регрессия :)

An explicit flush of std::cout is also necessary before a call to std::system, if the spawned process performs any screen I/O. In most other usual interactive I/O scenarios, std::endl is redundant when used with std::cout because any input from std::cin, output to std::cerr, or program termination forces a call to std::cout.flush(). Use of std::endl in place of '\n', encouraged by some sources, may significantly degrade output performance. 

«Избегайте endl» про это (деграданс перфоманса), а не «любой ценой всегда» — ну если подряд несколько строчек фигачишь, конечно предпочесть лучше «\n». (Но... это непоследовательный дизаен скорее... если не хуже — каких костылей не придумают, лишь бы не фиксить «деграданс»). В тривиальных случаях — монопенисуально и ни на что не влияет, кроме страданий мсьей.

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

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

Согласен ли ты что он понимает чето в оптимизациях?

с какой стороны гриба ставить плюсики в инкременте

Во многих проектах это так и сейчас. Например, в одной из статей PVS-Studio говорил такой совет, что всегда используйте преинкремент. Или например, в Microsoft STL используют преинкремент: https://imgur.com/a/sGkr22x

‘\n’ просто всегда лучше чем endl, Использование endl когда не нужен flush бред.

В интернете полно таких тестов:

I've run a program that does cout << "a" << endl; 10^6 times with stdout redirected to a file. Time measured by time was:

real	0m7.275s
user	0m1.680s
sys	0m5.584s

strace has shown, that data is flushed for each two bytes.

Then I changed endl to "\n", and the result was:

real	0m0.445s
user	0m0.432s
sys	0m0.008s

или вот: https://youtu.be/GMqQOEZYVJQ

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

Использование endl когда не нужен flush бред.

Чего ведь не придумают, чтоб кривой дизаен не исправлять :)

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

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

Можешь просто личинку царя уже включить :)

Его на конкурсе интел по многопоточности именно поэтому забанили :)

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

Просто кресты ракушками успели сильнее обрасти (так что мсьи их даже как ракушки не воспринимают, защищают свои воркэраунды «МОРОЖЕНО! МОРОЖЕНО! ШОКОЛАДНОЭ!» — используют подмножество которое асилели («си с классами» что там шаблоны... метапрограммирование... ой-все), вот и думают что «плюсы проще» )))

I’ve run a program that does cout << «a» << endl; 10^6

Ору с этого.

Если основная чать работы твоей софтины — это манипуляции с stdin->stdout (аля grep например), то \n будет иметь смысл, потому что в таком софте тебе важна в том числе и производительность вывода. Для большинства софта вывод в stdout — редкое логгирование, в котором важно иметь flush.

auto main () -> int {
   return 0;
}

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

думаецца на практике сферические в вакууме плюсисты, асилившие удобное подмножество С++11(++) (и даже мсьи в 100500 раз написав какой-то вложенный шаблон из-за которого присвоение уехало за экран), радостно перешли на авто чуть более чем везде :) Вот смена синтаксиса функций — это конечно полюбому повод для относительно свежего холивара в каментах к гайдлайнам каждого проекта где окопались ретрограды и консерваторы :)

дожили, C-диез сложнее крестов :)

Конечно. Деструкторов нет :(

Например, вот так выглядит аллокация массива, и это несколько сложнее, чем в С++, и больше похоже на С, нужно не забыть вернуть массив, а то будет утечка…

char[] pull = null;
Span<char> span = 
  count <= 512?
  stackalloc char[512] :
  (pool = ArrayPool<char>.Shared.Rent(count));

if (pool != null)
  ArrayPool<char>.Shared.Return(pool);

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

// good
s[2] = '!'; // проверка на выход за границы массива будет только одна
s[0] = 'H';
s[1] = 'i';

// bad, будет три проверки, при каждом присваивании.
s[0] = 'H';
s[1] = 'i';
s[2] = '!';

C# ужасно сложный язык.

Конечно. Деструкторов нет :(

«Деструкторы? Не нужны тебе деструкторы, бро!» (С) :)

«Никто:

Абсолютно никто:

Лоровец: stackalloc делает C# сложнее плюсов»

«В C# существует достаточно интересное и очень редко используемое ключевое слово stackalloc. Оно настолько редко встречается в коде (тут я даже со словом «редко» преуменьшил. Скорее, «никогда»), что найти подходящий пример его использования достаточно трудно а уж придумать тем более трудно: ведь если что-то редко используется, то и опыт работы с ним слишком мал. А все почему? Потому что для тех, кто наконец решается выяснить, что делает эта команда, stackalloc становится более пугающим чем полезным: темная сторона stackalloc — unsafe код» (с)

В общем, скорее всего не прошел кодревью :)

Прикинь, решетка там не просто так :) из шарпа еще и экспортов в натив нету без плясок с манагед C++ или IL — бай дизаен.

Какой мудак будет так писать? Конечно же без пробела перед скобкой. И с нормальным отступом, а не в 3 пробела.

Мнение про пробелы как дырка в жопе да, у каждого мудака есть :)

Согласен ли ты что он понимает чето в оптимизациях?

Хз. Может, и понимает.

Однако не думаю, что имеет смысл продираться сквозь волны словесных нечистот, чтобы найти какие-то крохи стоящих идей. Затраченные усилия не стоят результата. К тому же, он же не является источником этих знаний. Просто ретранслирует прочитанное где-то, щедро разбавляя руганью. Или даже не так. Основной его продукт — ругань и презрение ко всем. А знания в «оптимизациях» — попытка как-то привлечь хоть кого-нибудь к своим текстам.