LINUX.ORG.RU

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

 ,


10

8

Бьерн Страуструп и Герб Саттер опубликовали в открытом доступе объемный документ, содержащий основные принципы разработки на современном С++. Авторы надеются, что следование данным принципам позволит разработчикам эффективно использовать язык и писать безопасный и поддерживаемый код.

C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md/

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

FIL ★★★★
()

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

mix_mix ★★★★★
()

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

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от MKuznetsov

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

anonymous
()
Ответ на: комментарий от MKuznetsov

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

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

Stahl ★★☆
()
Ответ на: комментарий от Gvidon

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

anonymous
()

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



Мда.

Solace ★★
()
Ответ на: комментарий от BruteForce

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

Solace ★★
()

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

vzzo ★★★
()

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

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;
}
Здрасте... Ну так именно это в большинстве источников и называется самой правильной реализацией синглетона (которая, впрочем, тоже не избавляет от всех проблем). Зачем наводить тень на плетень?

asaw ★★★★★
()
Ответ на: комментарий от asaw

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

uuwaan ★★
()

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

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

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

uuwaan ★★
()
Ответ на: комментарий от Solace

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

Solace ★★
()
Ответ на: комментарий от intelfx

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

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

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

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Конечно, лучше позже, чем никогда. Но когда позже на 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.

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

mix_mix ★★★★★
()
Ответ на: комментарий от mix_mix

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

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

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

tailgunner ★★★★★
()

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

slackwarrior ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mix_mix

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

asaw ★★★★★
()

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

anonymous
()
Ответ на: комментарий от asaw

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

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

anatoly
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.