Ну это смотря, кто такой Джун. Джуны есть везде. Но, да, за 3 месяца или даже полгода тебя в нормальную фирму, вряд ли, возьмут. У меня, вот, с порога было "на интерфейс, вот пиши обёртку под драйвер, используя SocketCAN. Вот ссылочка на наш code style, вот ссылочка на документацию SocketCan. (Все на английском, естественно)". Да и в компании, обычно, попадают, используя сарафанное радио. Там, где я сейчас тружусь, там, вроде, на сайте даже списка вакансий нет.
Ну, не знаю. Я свой первый язык (pawn) в 2011 учил, потому что хотел свой SAMP сервер сделать. Лучше учить первым тот язык, который сразу пригодится. Так, мотивации, как минимум, больше будет.
Аналогов Vla на C++ нет. Даже vla расширение g++ работает абсолютно по-другому, в отличии от C. Если вы соберёте C код C++ компилятором, то, вероятнее всего, там будет неопределённое поведение, но ещё более вероятно, что он не соберётся.
В смысле, в C не надо?! В C тоже надо. Да, там была фича, что если функция не объявлена, то считается, что она такая int foo(...). Для printf такое подойдёт, а вот malloc уже так работать не будет.
Они достаточно большие. Там, даже, сравнение указателей по разному работает. Разные объектные модели. Про type punning через union, vla, compound literals и прочие фишки C я даже говорить не буду.
Вместо (void)0, вы, наверное, хотели написать (void *)0. (uint64_t)(int)(void *)0 + плохая конструкция. Не стоит кастовать указатель к int, также как и к uint64_t. В данном случае, конечное, сработает, ибо у нас 0, но warning, наверное, будет. Указатели стоит кастовать к uintptr_t. Про strict alliasing непонятно. Данное выражение не содержит strict alliasing. При приведение данного выражения к условному float * тоже не даст проблем. Повторное кастование данного float * к условному int * тоже не даст проблем, ибо разыменоание делать, в любом случае, нельзя. Арифметику с нулевым указателем тоже, вроде, нельзя делать.
Что значит vla никто не поддерживает?! Gcc и clang давно поддерживают. Gcc даже принятые изменения C2x уже поддерживает. Что Gcc из C стандарта, кроме _Imaginary, не поддерживает?!
Единого синтаксиса и namespace не было. теперь можно писать, что-то типо [[gnu::cleanup(free), yourcompiler::defer(free)]]
Обещали(предлагали) safe int ещё завести.
NULL может быть 0, чтобы один хедер и к C, и к C++ коду подключать и проблем не было. Чтобы проблем с обратной совместимостью не было, введут nullptr, который везде (void *)0.
Это уже 4 версия данного документа. Стандарт сказал, что да, мы хотим, чтобы данные слова объявлялись в одном месте, но против того, чтобы они были first class. В итоге, автор предложения сейчас предлагает дать возможность компиляторам самим решать будут эти слова first class или нет. Кстати, true и false были убраны из этого предложения. Думаю, что максимум, что примет стандарт — введение нового заголовочного файла, где и будут перечислены данные слова. Вряд ли, они будут введены как first class.
Ну так в си в любом случае или _Typeof, или _Decltype будет. В ключевые слова decltype, как и typeof не внесут. Но будет заголовочный файл, где будет какой-нибудь макрос. А там, уже не особо важно decltype или typeof. В си даже bool, atomic и complex в ключевых словах нет, зато есть _Bool, _Atomic и _Complex.
По поводу strdup: данная функция использует malloc для выделения памяти. Если вы как-то по другому выделяете память (на стеке или mmap, или ещё как-то), то просто воспользуйтесь strcpy. Если вам нужно просто создать строку где-то вызывайте strdup, (на Linux, например, malloc может выделить память как в heap, так и напрямую вызвав mmap) если вам нужно конкретно где-то выделить память, то выделите её, а затем скопируйте туда строку (strcpy)
_Generic уже в C11 ввели, он как раз под данные задачи подходит. Единственное, он не умеет работать с динамическими типами, но их в C++ нет. Type Generic математические функции ещё с C99 в стандарте есть.
Ну, если ввести классы, то придётся менять объектную модель, что плохо. А вот против типажей без конструкторов, деструкторов и "перегруженных операторов" (на самом деле перегрузки операторов в C++ нет, есть только замена оператора на вызов функции, со всеми вытекающими) ничего не имею. Главное, чтобы объектная модель была сохранена и явное указание символов было.
Только, вряд ли, A common C/C++ core specification будет принята. Это, получается, некий новый язык, который не соответствует ни C, ни C++, да и ещё легаси ломает. Тут, вон, даже сравнение указателей абсолютно по-разному на C и C++ себя ведёт.
RAII — про локальность. Если в конструкторе ты допустишь ошибку логики, то этот принцип тебя никак не спасёт от неопределённого поведения.
Я бы ещё порекомендовал бы Agner fog. Там всё детально разбирается. Ну и официальные гайды, конечно же.
Ну это смотря, кто такой Джун. Джуны есть везде. Но, да, за 3 месяца или даже полгода тебя в нормальную фирму, вряд ли, возьмут. У меня, вот, с порога было "на интерфейс, вот пиши обёртку под драйвер, используя SocketCAN. Вот ссылочка на наш code style, вот ссылочка на документацию SocketCan. (Все на английском, естественно)". Да и в компании, обычно, попадают, используя сарафанное радио. Там, где я сейчас тружусь, там, вроде, на сайте даже списка вакансий нет.
Ну, не знаю. Я свой первый язык (pawn) в 2011 учил, потому что хотел свой SAMP сервер сделать. Лучше учить первым тот язык, который сразу пригодится. Так, мотивации, как минимум, больше будет.
Писать на ассемблере, может, часто и не надо. Но вот читать ассемблер требуется часто.
Аналогов Vla на C++ нет. Даже vla расширение g++ работает абсолютно по-другому, в отличии от C. Если вы соберёте C код C++ компилятором, то, вероятнее всего, там будет неопределённое поведение, но ещё более вероятно, что он не соберётся.
В смысле, в C не надо?! В C тоже надо. Да, там была фича, что если функция не объявлена, то считается, что она такая int foo(...). Для printf такое подойдёт, а вот malloc уже так работать не будет.
Они достаточно большие. Там, даже, сравнение указателей по разному работает. Разные объектные модели. Про type punning через union, vla, compound literals и прочие фишки C я даже говорить не буду.
Вместо (void)0, вы, наверное, хотели написать (void *)0. (uint64_t)(int)(void *)0 + плохая конструкция. Не стоит кастовать указатель к int, также как и к uint64_t. В данном случае, конечное, сработает, ибо у нас 0, но warning, наверное, будет. Указатели стоит кастовать к uintptr_t. Про strict alliasing непонятно. Данное выражение не содержит strict alliasing. При приведение данного выражения к условному float * тоже не даст проблем. Повторное кастование данного float * к условному int * тоже не даст проблем, ибо разыменоание делать, в любом случае, нельзя. Арифметику с нулевым указателем тоже, вроде, нельзя делать.
Что значит vla никто не поддерживает?! Gcc и clang давно поддерживают. Gcc даже принятые изменения C2x уже поддерживает. Что Gcc из C стандарта, кроме _Imaginary, не поддерживает?!
Только вот, в случае, C подхода можно точно сказать какие символы будут внешними. А вот при обычном использовании шаблонов — нет.
Это уже 4 версия данного документа. Стандарт сказал, что да, мы хотим, чтобы данные слова объявлялись в одном месте, но против того, чтобы они были first class. В итоге, автор предложения сейчас предлагает дать возможность компиляторам самим решать будут эти слова first class или нет. Кстати, true и false были убраны из этого предложения. Думаю, что максимум, что примет стандарт — введение нового заголовочного файла, где и будут перечислены данные слова. Вряд ли, они будут введены как first class.
Ну так в си в любом случае или _Typeof, или _Decltype будет. В ключевые слова decltype, как и typeof не внесут. Но будет заголовочный файл, где будет какой-нибудь макрос. А там, уже не особо важно decltype или typeof. В си даже bool, atomic и complex в ключевых словах нет, зато есть _Bool, _Atomic и _Complex.
По поводу strdup: данная функция использует malloc для выделения памяти. Если вы как-то по другому выделяете память (на стеке или mmap, или ещё как-то), то просто воспользуйтесь strcpy. Если вам нужно просто создать строку где-то вызывайте strdup, (на Linux, например, malloc может выделить память как в heap, так и напрямую вызвав mmap) если вам нужно конкретно где-то выделить память, то выделите её, а затем скопируйте туда строку (strcpy)
_Generic уже в C11 ввели, он как раз под данные задачи подходит. Единственное, он не умеет работать с динамическими типами, но их в C++ нет. Type Generic математические функции ещё с C99 в стандарте есть.
Ну, если ввести классы, то придётся менять объектную модель, что плохо. А вот против типажей без конструкторов, деструкторов и "перегруженных операторов" (на самом деле перегрузки операторов в C++ нет, есть только замена оператора на вызов функции, со всеми вытекающими) ничего не имею. Главное, чтобы объектная модель была сохранена и явное указание символов было.
А как extern поможет, если данное ключевое слово обрабатывается позже, чем стадия препроцессора?
Только, вряд ли, A common C/C++ core specification будет принята. Это, получается, некий новый язык, который не соответствует ни C, ни C++, да и ещё легаси ломает. Тут, вон, даже сравнение указателей абсолютно по-разному на C и C++ себя ведёт.