Малоизвестные и интересные особенности C и C++

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

Так нет же, деструктор по умолчанию noexcept, если вылетает исключение, то terminate. Если поставил явно noexcept(false), то всё ещё никакого уб нет, откуда бы ему взяться? Ну вылетит исключение вот и всё. Если во время анвиндига, то опять же в стандарте написано, что вызывается terminate

https://godbolt.org/z/vxPaWdzcb

Вставлю свои 2 копейки

1. restrict - единственное ключевое слово из C, которое не поддерживается в C++

2. Есть заголовок <setjmp.h>, который (добавляет функции, возволяющие) позволяет делать нелокальные переходы. Т.е. можно вернуться вверх по стеку через несколько функций без явного return. В C++ она хоть есть, но если использовать, то можно забыть о всех деструкторах - они вызваны не будут.

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

Здрасьте, varargs не спросят даже на позицию по компиляторам или software stack в процессорные компании? Да в MIPS Technologies сидел специальный человек, которому зарплату платили за то, что он был экспертом по calling conventions. Наверняка такие же есть и в ARM, Intel, SiFive и других таких компаниях.

под Windows компилятор MSVC считает, что char — это unsigned char

А разве оно не определяется параметрвми компилятора? Не могу сказать уверенно про MSVC (хотя память упорно подсказывает, что такой параметр есть или был когда-то), а в других компилятораз такое точно было.

так для архитектуры x64 ясное дело __stdcall и __cdecl будут проигнорированы.

Не совсем так. Наличие или отсутствие cdecl в объявлении экспортируемой функции даже для архитектуры x64 как минимум указывает на особенности ее именования в разделяемой библиотеке (dll или so). В случае cdecl это будет имя функции, иначе к имени функции будут добавлены символы, кодирующие типы параметров и возвращаемого значения (причем для разных компиляторов этот код может отличвться, что может приводить к интересным ситуациям при попытке, например, подключить dll функциями LoadLibrary и GetProcAddress).

Для меня, как исключительно С++ разработчика, тыжсишник==тыжпрограммист, Си и С++ - это разные языки с различными парадигмами и подходами к разработке. Я не знаю Си, о чем открыто заявляю, когда на меня пытаются повесить подобные проекты. Разумеется я его знаю, на каком-то уровне, но не смогу на нем так же продуктивно работать. Т.е. С++ основной язык разработки, а python, Си, php и пр. примерно в одном ряду, как бы парадоксально это ни казалось.

А что на счет строковых литералов, например "string literal"? Это будет char*

Тут стоит заострить внимание на то, что именно char *, а не char const *. Почему это важно?
Случай из практики (писали мы на C тогда). Была у нас функция, которая принимала на вход строку char * и изменяла ее. Долго она у нас была, пока однажды мы не обнаружили место, где в функцию передается... строковый литерал. Функция бодро писала в литерал и всё работало, потому что в данном случае изменения заключались в удалении пробелов (так называемый trimming). То есть за пределы литерала ничего не писалось.
Но это открытие нас так напугало (мы то были абсолютно уверены, что литералы конечно же char const *, ну кому в здравом уме может прийти в голову сделать литералы изменяемыми?), что мы добавили в наш кодстайл обязательное требование все строковые литералы приводить к char const *

В двоичном интерфейсе приложений (ABI) x64 по умолчанию используется четырехрегистровое соглашение о вызове, т. н. x64 calling convention

Могу ошибаться, но это справедливо только для windows. В linux x86_64 ABI передаёт через регистры 8 целочисленных аргументов (остальные через стек).

Какой ужос. Это ж сколько всяких особенностей и UB нужно, по-хорошему, держать в голове помимо прочего. Хорошо что я не пишу на Си давно уже :)

Комменты - отличная иллюстрация что никто полноценно C и C++ не знает. У всех знания фрагментальны. Поэтому типовой собес это всего-лишь определение насколько фрагментальные знания собеседующего пересекаются с фрагментальными знаниями кандидата. Но какая в этом ценность? Гораздо ценнее кооперирующаяся команда с непересекающимися знаниями её участников.

// якобы здесь утечка памяти, т. к. по правилам RAII во время уничтожения
// Class, в деструкторе может возникнуть исключение; а т. к.

Дык утечка при бросании исключения будет если в отнаследованном классе в конструкторе бросать исключения. Т.к. происходит конструирование снизу вверх сконструируется родительский класс, потом попытается сконструироваться, потомок не конструируется в итоге выделенная память родителя остается. Ну и выделять все это дело надо не на стеке, т.к. RAII скорее всего всё почистит, включая родителя.

void f(...) {} добавили только в C23.

Уже с самого начала - дичайшее количесто ошибок в статье. Просто ошибка на ошибке.

Потому что объявление void f() является эллипсисом в языке C (ellipsis notation; их также часто называют как variadic arguments

Что??? Эллипсис в языке С - это именно ..., то есть действительно variadic arguments. Но объявление c ()никакого отношения к ellipsis или variadic arguments не имеет и никогда не имело. Это т.наз. объявление без прототипа, которое не указывает список параметров. Я не буду расписывать подробно, но замечу, что такое объявление не совместимо с ellipsis-определением. Функции с ellipsis-определением в С, то есть f(...), обязаны быть объявлены заранее именно с ..., иначе при вызове такой функции поведение не определено. Это одно из мест "классического" стандартного С, в котором требуется ранее (до первого вызова) объявление функции.

Т. е. следующий код абсолютно корректен и компилируется любым С-компилятором:

void f() { printf("f()"); }

int main() {
f(5, 3.2f, "test");

Да, такой код является формально корректным из-за того, что функция объявлена без прототипа. Однако поведение такого кода не определено. Вызов функции без прототипа эквивалентен вызову вообще не объявленной функции (в С89/90 такое разрешалось). При вызове функции без прототипа компилятор С обязан "придумать" прототип функции на основе переданных аргументов. В данном случае это будет f(int, double, char *)(именно double). Если при этом оказывается, что "придуманный" прототип не совпадает с фактическим определением функции, то проведение не определено. Именно это происходит и в вашем случае - проведение не определено.

Это "абсолютно корректен" или нет?

Чтобы указать компилятору языка C, что функция не принимает аргументов, нужно указать это явно с помощью аргумента void:

Ключевым различием здесь, которую я уже упомянул выше, является "объявление с прототипом" против "объявления без прототипа". Объявление с (void) - это уже объявление с прототипом. Кстати, объявления без прототипа давно являются deprecated и в С23 будут, наконец, формально запрещены.

Итак, подытожим в виде таблицы:

Таблица повторяет вышеуказанную бредятину о том, что () - это якобы "эллипсис". Это грубейше неверно.

Кстати, обратите внимание, в языках C/C++ аргументы часто передаются справа налево по C-декларации, это как раз нужно для того, чтобы работали такие функции как printf(). Чтобы на вершине стека был параметр, по которому мы сможем определить сколько данных лежит еще на стеке.

Очередной заряд полнейшей чуши... Функции printf()ничего подобного не нужно. Никакой передачи параметров "справа налево" не существует. Это не говоря уже о том, что современные ABI позволяют передавать даже variadic аргументы в регистрах процессора.

Историческая справка: до появления стандарта ANSI C, был и альтернативный стиль объявления аргументов функций, т. н. стиль Кернигана и Ричи (стиль K&R). Пример кода (нужно компилировать C компилятором):

Во-первых, то, о чем вы писали выше, это и есть "альтернативный стиль K&R". Всякий раз , когда в языке С вы пишете ()в объявлении или определении функции - это объявление без прототипа, то есть тот самый "альтернативный стиль K&R" - один из его частных случаев. Чтобы уйти от "альтернативного стиля K&R" для функции без параметров мы и пишем (void)

Во-вторых, не "до появления стандарта ANSI C", а и в стандарте ANSI С тоже. Стандарт ANSI С разрешает K&R объявления, хотя там они давно являются deprecated. Стандарт С89/90 разрешал вызов функций вообще без объявления. С99 запретил вызов без объявления, оставив однако возможность делать объявления без прототипа. Только C23 запрещает объявления без прототипа и K&R-стиль в целом. При этом хотя объявления функций c ()являются K&R объявлениями, в С23 они запрещены не будут - их "сконвертировали" в эквивалент (void), то есть все станет в точности как как в С++.

При передаче аргументов в variadic function применяются следующие правила неявных приведений типов аргументов (правило default argument promotions): 

Во-первых, default argument promotions состоят из integer promotions плюс преобразование float в double. Вы развернули описание, но у вас однако integer promotions описаны не совсем корректно. Ну да ладно.

Во-вторых, default argument promotions делаются при передаче не только variadic аргументов, но и при вызове функций без прототипа (именно поэтому в примере выше я указал, что передача аргумента 3.2fприводит к "придуманному" прототипу с параметром double). Вы это все, конечно, попытались запихать в свою теорию "это всё эллипсис", но это - полная чушь.

Дело в то, что существуют различные т. н. calling convensions (соглашения о вызовах функций)

Никакого отношения к языкам С и С++ это, разумеется, не имеет. Никаких calling conventions ни в С, ни в С++ нет. Что это делает в статье про "особенности С и С++" - не ясно.

А что на счет строковых литералов, например "string literal"? Это будет char*

Грубейше не верно. Строковый литерал - это массив, то есть char[N] в языке С и const char[N] в C++.

Ответ очень прост: char, signed char и unsigned char — это три разных типа. Но при этом стандарт не запрещает, чтобы char был псевдонимом либо signed char, либо unsigned char.

"Псевдонимами" в терминологии С и С++ называют идентичные типы, то есть одни и те же типы под разными именами. Так как char, signed char и unsigned charкак вы правильно заметили - это три разных типа, никаких "псевдонимов" тут нет и быть не может. О каком "стандарт не запрещает" вы ведете речь - не ясно.

Далее читать не стал...

Спасибо за статью!
Простите за оффтоп, но есть небольшой вопрос. Камрады, подскажите, есть ли какие-то более-менее централизованные базы/опиcания/списки/дайджесты неплохих библиотек на С++ (и тот же вопрос про Qt)? Знаю вот такой ресурс, а есть ли что-то еще?

Не знаю, малоизвестный факт или нет, но в функции/методе с типом результата void можно возвращать результат типа void:

#include <iostream>

void print (const string_view &message) { std::out << message << std::endl; }

void printMessage () { return print ("Hello World"); }

int main (int argc, char** argv) { printMessage(); return 0; }

Эта возможность особенно полезна в шаблонах, но работает и без шаблонов.