Опубликованы C++ Core Guidelines

Отлично. Спасибо. Заодно и английский подучу :-)

А ты быстрый, новости-то уж неделя. Но всё равно хорошо.

общий смысл документа:

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

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

PS/ С++ даже в окружении STL/boost стремительно говнеет.

шлеп, шлеп, шлеп) ай, малаца, авторитетный)

C++ выпал в корку ?

Вот когда изобретёшь альтернативу (Да, я про скорость выполнения и бестолковую трату ресурсов современными языками), тогда и будешь кукаретиковать.

нам известны 100500 способов сделать криво

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

Сишечка, D, Rust.

На сишечке писать гораздо больше, чем на плюсах и способов прострелить себе ногу ни разу не меньше. Rust, D - они не догоняют по скорости и на них написано около 0 проектов.

Prefer concept names over auto for local variables
Reason: auto is the weakest concept. Concept names convey more meaning than just auto.

vector<string> v;
auto& x = v.front();    // bad
String& s = v.begin();  // good

Мда.

Спасибо, не пойду читать.

Не за что. Пробежать глазами главу о шаблонах мб можно. А в целом Страус как-то удивляет.

От документа готова от силы треть :(

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

I.12: Declare a pointer that must not be null as not_null

Reason: To help avoid dereferencing nullptr errors. To improve performance by avoiding redundant checks for nullptr.

Example:

int length(const char* p);      // it is not clear whether strlen(nullptr) is valid

length(nullptr);                // OK?

int length(not_null<const char*> p);        // better: we can assume that p cannot be nullptr

int length(const char* p);              // we must assume that p can be nullptr

not_null - это что вообще за велосипед такой?

Или вот

I.3: Avoid singletons

... bla-bla-bla ...

Exception: You can use the simplest «singleton» (so simple that it is often not considered a singleton) to get initialization on first use, if any:

X& myX()
{
    static X my_x {3};
    return my_x;
}

А тебе этот лисапед написать самому предлагают. Выше по тексту также предлагается array_view. Его я на GitHub уже нашёл у какого-то кренделя.

Да-да, array_view вот тоже озадачило.

Они предлагают использовать Guideline support library, в которую вынесли подобную мелочевку.

Понятно. Не дочитал дотуда.

Конечно, лучше позже, чем никогда. Но когда позже на 20 лет - это даже не смешно...

Лично меня огорчает направленность авторов в сторону, мол: «ОЛОЛО! Правильно передать длину массива и указатель на него так сложно! Давайте нагородим килограмм шаблонной магии и всяких SFINAE, чтобы длина сама посчиталась!»

А огорчает вот почему. Это дико тормозит компиляцию. Недавно создавал темку об STL-контейнерах в режиме «нет исключений». Пока шёл спор там, я навелосипедил копии вектора и однонаправленного списка. Причём брал прямо из GCC-шной библиотеки, декриптил те письмена, писал своё. Там всё утыкано всякими enable_if, is_same и т.д. Вот это я не брал, уж больно много. И вот что получилось: на моем EeePC тест с моим вектором компилился также быстро, как код на C. А вот со стандартным — раза в три дольше.

И вот ещё что я понять не могу: когда я косячил в коде, ошибки компиляции моего вектора были нормальные вполне, типа «в методе push_back, строка такая-то, не могу найти подходящую перегрузку...». В стандартной либе эта же ошибка, спору нет, отлавливается много раньше, сетью из этих самых enable_if, но блин, именно они порождают эту адскую лапшу в сотню строк в сообщении, которой STL прямо-таки знаменит. А в итоге? И там и там не скомпилялось, только во втором случае понять, что случилось, вообще нельзя, можно только догадаться.

array_view - это C++17.

на моем EeePC

this

(пока у всех нормальных разрабов рабочие станции с Xeon'ами...)

Это неправильный подход к разработке.

Нет. Машина разработчика должна быть достаточно мощной.

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

(пока у всех нормальных разрабов рабочие станции с Xeon'ами...)

У кого «всех»? Линус работает на хромбуке %)

Нет. Машина разработчика должна быть достаточно мощной.

Это тот самый подход java-разработчиков, за который критикуют их нещадно.
Более того, это отторгает новых адептов. Минусов много слишком для такого подхода.

У кого «всех»? Линус работает на хромбуке %)

И код не пишет. Обычный почтовый червь.

Машина разработчика должна быть достаточно мощной.

Да, и именно потому, что затраты на тачку многократно окупаются выгодами в рабочем времени, в том числе и непрямыми (типа во время конпеляции пошел на ЛОР и завис на ерзенте на пол часа).

У кого «всех»? Линус работает на хромбуке %)

И код не пишет.

Не всегда разработчик должен писать код. Впрочем, тех, кто пишет код на ноутах, более чем достаточно.

Конечно, лучше позже, чем никогда. Но когда позже на 20 лет - это даже не смешно...

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

Hear, hear! I've been thinking about something similar recently. Instead of inventing all these «simple», «safe» languages we should just learn to use modern C++ properly.

Так что завязывай со своим рустом, лол.

Не всегда разработчик должен писать код.

Кто не конпеляет - пусть хоть с планшета сидит.

Instead of inventing all these «simple», «safe» languages we should just learn to use modern C++ properly.

Так что завязывай со своим рустом, лол.

Ждем Safe C++, чо.

Гитлер.Путин (А то тянете че-то долго... И даже двух страниц не набралось)

Не всегда разработчик должен писать код.

Кто не конпеляет

Линус компилирует как бы не больше тебя.

Это уже должно быть смертельно серьезно.

Линус компилирует

Он не компилирует - он сразу бинарь набирает.

Конечно, лучше позже, чем никогда. Но когда позже на 20 лет - это даже не смешно...

Это уже должно быть смертельно серьезно.

Да, 20 лет собираться с духом - это должно быть серьезно.

Выстрел в ногу - серьезный бизнес.

Ждем Safe C++, чо.

«Хорошая попытка, майкрософт...» (с)

У Microsoft был Managed C++.

Яйца в профиль + перспективные искажения.

okay.jpg

Даешь безопасные бензопилы :)

Интересно, что микрософт - один из главных участников. Что бы это значило? Сначала заявление о Microsoft Linux, активное участие в развитии C++. Уж не собираются ли они закопать свой C# вместе со студией как ошибку юности? Или это просто разные течения внутри одной компании (так то микрософт хорошо известна самой кривой реализацией компилятора C++)?

разве оно еще не сдохло?

CPL.1: Prefer C++ to C

Дальше можно не читать

Что бы это значило?

Действуют по принципу «не можешь победить - возглавь».

объясните нубу, чем С++ от С отличается?

На втором можно написать ядро, на первом — нет.

наглая ложь