Я использую результат malloc?

В C вам не нужно указывать возвращаемое значение malloc. Указатель на void, возвращаемый malloc, автоматически преобразуется в правильный тип. Однако, если вы хотите, чтобы ваш код компилировался с помощью компилятора С++, вам необходимо выполнить актерский состав. Предпочтительной альтернативой для сообщества является использование следующего:

int *sieve = malloc(sizeof *sieve * length);

который дополнительно освобождает вас от необходимости беспокоиться об изменении правой части выражения, если вы измените тип sieve.

Касты плохие, как указывали люди. Специально накладывается указатель.

Вы делаем, потому что:

• Это делает ваш код более переносимым между C и С++, и, как показывает опыт SO, многие программисты утверждают, что они пишут на C, когда они действительно пишут на С++ (или локальный компилятор C плюс расширения).
• Неспособность сделать это может скрыть ошибку: обратите внимание на все SO-примеры запутывания при написании type * versus type **.
• Идея, что он не позволяет вам заметить, что вам не удалось #include соответствующий заголовочный файл пропускает лес для деревьев. Это то же самое, что сказать: "Не беспокойтесь о том, что вы не попросили компилятора жаловаться на то, что не видите прототипов, - что надоедливый stdlib.h - это важная вещь, которую нужно помнить!"
• Он заставляет дополнительную когнитивную перекрестную проверку. Он помещает (предполагаемый) желаемый тип рядом с арифметикой, которую вы делаете для необработанного размера этой переменной. Бьюсь об заклад, вы можете сделать исследование SO, которое показывает, что ошибки malloc() пойманы намного быстрее, когда есть бросок. Как и в случае с утверждениями, аннотации, которые показывают намерение, уменьшают количество ошибок.
• Повторение себя таким образом, что машина может проверять, часто является идеей большой. На самом деле, что такое утверждение, и это использование актеров - это утверждение. Утверждения по-прежнему являются наиболее общей техникой, которую мы имеем для правильного кода, поскольку Тьюринг много лет назад придумал эту идею.

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

#ifdef __cplusplus
# define NEW(type, count) ((type *)calloc(count, sizeof(type)))
#else
# define NEW(type, count) (calloc(count, sizeof(type)))
#endif

Таким образом, вы все равно можете записать его очень компактно:

int *sieve = NEW(int, 1);

и он будет скомпилирован для C и С++.

Из Wikipedia

Преимущества литья

• Включение роли может позволить программе или функции C скомпилироваться как С++.

• Листинг позволяет использовать версии malloc до 1989 года, изначально возвращенные char *.

• Кастинг может помочь разработчику выявить несоответствия в типе, если тип указателя назначения изменится, особенно если указатель объявлен далеко от вызова malloc() (хотя современные компиляторы и статические анализаторы могут предупреждать о таком поведении, не требуя литой).

Недостатки при литье

• В стандарте ANSI C литье является избыточным.

• Добавление роли может маскировать отказ включения заголовка stdlib.h, в для которого найден прототип malloc. В отсутствие прототип для malloc, стандарт требует, чтобы компилятор C предположим, что malloc возвращает int. Если нет броска, предупреждение выдается, когда этому целому числу присваивается указатель; однако, с бросок, это предупреждение не создается, скрывая ошибку. На определенных архитектуры и модели данных (например, LP64 на 64-битных системах, где long и указатели 64-бит, а int 32-бит), эта ошибка может фактически приводят к поведению undefined, поскольку неявно объявлено malloc возвращает 32-битное значение, тогда как фактически определенная функция возвращает 64-битное значение. В зависимости от соглашений вызова и памяти макета, это может привести к разрыву стека. Этот вопрос менее вероятен оставаться незамеченным в современных компиляторах, поскольку они равномерно производят предупреждения о том, что использовалась незаявленная функция, поэтому предупреждение будет все еще появляются. Например, поведение GCC по умолчанию - показать предупреждение, которое гласит "несовместимое неявное объявление встроенного функции" независимо от того, присутствует ли приведение или нет.

• Если тип указателя изменяется при его объявлении, можно также необходимо изменить все строки, в которых malloc вызывается и выполняется.

Хотя malloc без литья является предпочтительным методом, и большинство опытных программистов выбирают его, вы должны использовать то, что вам нравится знать о проблемах.

i.e: Если вам нужно скомпилировать C-программу как С++ (хотя это отдельный язык), вы должны использовать malloc с кастингом.

В C вы можете неявно преобразовывать указатель void в любой другой указатель, поэтому приведение не требуется. Используя один, вы можете предложить случайному наблюдателю, что есть какая-то причина, по которой требуется одна, что может ввести в заблуждение.

Вы не произносите результат malloc, потому что это добавляет бесполезный беспорядок в ваш код.

Наиболее распространенная причина, по которой люди приводят результат malloc, заключается в том, что они не уверены в том, как работает язык C. Это предупреждающий знак: если вы не знаете, как работает конкретный языковой механизм, не делайте предположений. Посмотрите его или спросите о переполнении стека.

Некоторые комментарии:

• Указатель void может быть преобразован в/из любого другого типа указателя без явного приведения (C11 6.3.2.3 и 6.5.16.1).

• Однако С++ не допускает неявного переноса между void* и другим типом указателя. Итак, на С++ литье было бы правильным. Но если вы программируете на С++, вы должны использовать new, а не malloc(). И вы никогда не должны компилировать C-код с помощью компилятора С++.

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

• Если компилятор C не может найти функцию, потому что вы забыли включить заголовок, вы получите сообщение об ошибке компилятора/компоновщика. Поэтому, если вы забыли включить <stdlib.h>, что нет biggie, вы не сможете создать свою программу.

• В древних компиляторах, которые следуют версии стандарта, которому больше 25 лет, забыть включить <stdlib.h> приведет к опасному поведению. Поскольку в этом древнем стандарте функции без видимого прототипа неявно преобразуют возвращаемый тип в int. Выделение результата из malloc явно скрывает эту ошибку.

  Но это действительно не проблема. Вы не используете 25-летний компьютер, так зачем использовать 25-летний компилятор?

В C вы получаете неявное преобразование из void* в любой другой указатель (data).

Теперь значение значения, возвращаемого malloc(), не требуется, но я хотел бы добавить одну точку, которая, как кажется, никто не указал:

В древние времена, то есть до ANSI C, void * в качестве общего типа указателей, char * является типом такого использования. В этом случае приведение может отключить предупреждения компилятора.

Ссылка: C Часто задаваемые вопросы

Не обязательно выводить результаты malloc, так как он возвращает void*, а void* можно указать на любой тип данных.

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

Изменить: У кастинга есть определенная точка. Когда вы используете нотацию массива, генерируемый код должен знать, сколько мест памяти он должен продвинуться, чтобы достичь начала следующего элемента, это достигается путем кастинга. Таким образом, вы знаете, что за двойной вы идете на 8 байт вперед, а для int вы идете 4 и т.д. Таким образом, это не имеет никакого эффекта, если вы используете нотацию указателя, в нотации массива она становится необходимой.

Возвращаемый тип - это void *, который может быть отнесен к нужному типу указателя данных, чтобы быть разыменованным.

Это то, что в Справочном руководстве библиотеки GNU C:

Вы можете сохранить результат malloc в любую переменную указателя без трансляции, потому что ISO C автоматически преобразует тип void * в другой тип указателя, когда это необходимо. Но бросок необходим в контексте, отличном от операторов присваивания, или если вы захотите, чтобы ваш код работал в традиционном C.

И действительно, стандарт ISO C11 (p347) говорит так:

Указатель возвращается, если выделение успешно выполняется соответствующим образом, чтобы его можно было назначить указателю на любой тип объекта с фундаментальным требованием к выравниванию, а затем использовать для доступа к такому объекту или массиву таких объектов в выделенном пространстве (до тех пор, пока пространство явно освобождено)

Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.

Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.

Это зависит от языка программирования и компилятора. Если вы используете malloc в C, нет необходимости вводить его, поскольку он будет автоматически набирать cast. Однако, если вы используете С++, тогда вы должны набирать cast, потому что malloc вернет тип void*.

В языке C указатель void может быть назначен любому указателю, поэтому вам не следует использовать тип. Если вы хотите выделить "безопасный тип", я могу рекомендовать следующие макрофункции, которые я всегда использую в своих проектах на C:

#include <stdlib.h>
#define NEW_ARRAY(ptr, n) (ptr) = malloc((n) * sizeof *(ptr))
#define NEW(ptr) NEW_ARRAY((ptr), 1)

С их помощью вы можете просто сказать

NEW_ARRAY(sieve, length);

Для нединамических массивов третий обязательный макрос функции

#define LEN(arr) (sizeof (arr) / sizeof (arr)[0])

что делает циклы массивов более безопасными и удобными:

int i, a[100];

for (i = 0; i < LEN(a); i++) {
   ...
}

Люди, привыкшие к GCC и Clang, испорчены. Это не все так хорошо.

Я ужасно испугался на протяжении многих лет потрясающе составленными компиляторами, которых я должен был использовать. Часто компании и менеджеры принимают ультраконсервативный подход к смене компиляторов и даже не будут проверять, будет ли в их системе новый компилятор (с лучшими стандартами и оптимизацией кода). Практическая реальность для работающих разработчиков заключается в том, что когда вы кодируете, вам нужно покрыть свои базы, и, к сожалению, отличные маллинги - хорошая привычка, если вы не можете контролировать, какой компилятор может быть применен к вашему коду.

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

Аргумент о том, что он не нужен в соответствии с действующими стандартами, вполне допустим. Но этот аргумент опускает практичность реального мира. Мы не кодируем в мире, управляемом исключительно стандартом дня, а практикой того, что мне нравится называть "областью локального управления реальностью". И это согнулось и исказилось больше, чем просто пространство.: -)

YMMV.

Я склонен думать о том, чтобы бросать malloc в качестве защитной операции. Не красиво, не идеально, но в целом безопасно. (Честно говоря, если вы не включили stdlib.h, у вас больше проблем, чем при использовании malloc!).

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

double d;
void *p = &d;
int *q = p;

Мне жаль, что этого не было (и это не в С++), и поэтому я бросил. Это мой вкус и моя политика программирования. Я не только набрасываю указатель, но и эффективно бросаю бюллетень, и изгоняет демонов глупости. Если я не могу на самом деле изгнать глупость, то, по крайней мере, позвольте мне выразить желание сделать это с жестом протеста.

На самом деле хорошей практикой является обернуть malloc (и друзей) функциями, возвращающими unsigned char *, и в основном никогда не использовать void * в вашем коде. Если вам нужен общий указатель на любой объект, используйте char * или unsigned char *, и у вас есть броски в обоих направлениях. Возможно, единственное расслабление, которое можно потворствовать, использует функции типа memset и memcpy без приведения.

По вопросу о литье и совместимости с С++, если вы пишете свой код, чтобы он компилировался как C и С++ (в этом случае вам нужно указать возвращаемое значение malloc при присвоении ему чего-то другого, кроме void *), вы можете сделать очень полезную вещь для себя: вы можете использовать макросы для кастинга, которые переводится в приведение стилей С++ при компиляции как С++, но сводятся к C-кадру при компиляции как C:

/* In a header somewhere */
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif

Если вы придерживаетесь этих макросов, тогда простой поиск grep вашей базы кода для этих идентификаторов покажет вам, где все ваши броски, поэтому вы можете проверить, не являются ли какие-либо из них неправильными.

Затем, продолжая, если вы регулярно компилируете код с С++, он будет применять использование соответствующего приведения. Например, если вы используете strip_qual только для удаления const или volatile, но программа изменяется таким образом, что теперь происходит преобразование типа, вы получите диагностику, и вам придется использовать сочетание отливок для получения желаемого преобразования.

Чтобы помочь вам придерживаться этих макросов, компилятор GNU С++ (не C!) имеет красивую функцию: необязательную диагностику, которая создается для всех вхождений приведения стиля C.

     -Wold-style-cast (C++ and Objective-C++ only)
         Warn if an old-style (C-style) cast to a non-void type is used
         within a C++ program.  The new-style casts (dynamic_cast,
         static_cast, reinterpret_cast, and const_cast) are less vulnerable
         to unintended effects and much easier to search for.

Если ваш C-код скомпилирован как С++, вы можете использовать этот параметр -Wold-style-cast, чтобы узнать все вхождения синтаксиса (type), который может входить в код, и следить за этими диагностиками, заменив его соответствующим выбор из вышеупомянутых макросов (или комбинация, если необходимо).

Эта обработка конверсий является самым большим автономным техническим обоснованием для работы в "Чистом C": комбинированном диалекте C и С++, который, в свою очередь, технически оправдывает литье возвращаемого значения malloc.

Нет, вы не выполняете результат malloc().

В общем, вы не прикладываете к или из void *.

Типичная причина, по которой это не делается, заключается в том, что отказ #include <stdlib.h> может остаться незамеченным. Это уже не проблема уже давно, так как C99 делает неявные декларации функций незаконными, поэтому, если ваш компилятор соответствует по крайней мере C99, вы получите диагностическое сообщение.

Но существует гораздо более сильная причина не вводить ненужные приведения указателей:

В C литье указателей почти всегда является ошибкой. Это происходит из-за следующего правила ( §6.5 p7 в N1570, последний черновик для C11):

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

Это также известно как правило строгого сглаживания. Таким образом, следующий код: undefined поведение:

long x = 5;
double *p = (double *)&x;
double y = *p;

И, иногда удивительно, следующее:

struct foo { int x; };
struct bar { int x; int y; };
struct bar b = { 1, 2};
struct foo *p = (struct foo *)&b;
int z = p->x;

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

TL;DR

В двух словах: потому что в C, любое появление указателя должно поднять красный флаг для кода, требующего особого внимания, вы никогда не должны писать ненужные приведения указателей.

Боковые заметки:

• Бывают случаи, когда вам действительно нужен бросок на void *, например. если вы хотите напечатать указатель:

  int x = 5;
  printf("%p\n", (void *)&x);
  

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

• В С++ ситуация другая. Типы указателей заливки несколько распространены (и правильны) при работе с объектами производных классов. Поэтому имеет смысл, что в С++ преобразование в и из void * не соответствует не. С++ имеет целый набор различных вкусов кастинга.

Я предпочитаю делать актеры, но не вручную. Мой любимый использует макросы g_new и g_new0 из glib. Если glib не используется, я бы добавил похожие макросы. Эти макросы уменьшают дублирование кода без ущерба для безопасности типа. Если вы ошиблись, вы получите неявный бросок между не-void указателями, что вызовет предупреждение (ошибка в С++). Если вы забудете включить заголовок, который определяет g_new и g_new0, вы получите сообщение об ошибке. g_new и g_new0 оба принимают те же аргументы, в отличие от malloc, который принимает меньше аргументов, чем calloc. Просто добавьте 0 для получения нулевой инициализации памяти. Код может быть скомпилирован с помощью компилятора С++ без изменений.

Кастинг предназначен только для С++, а не C. Если вы используете компилятор С++, вы лучше меняете его на компилятор C.

Лучшее, что нужно делать при программировании на C, когда это возможно:

• Сделайте компиляцию вашей программы с помощью компилятора C со всеми предупреждениями, включенными в -Wall, и исправьте все ошибки и предупреждения
• Убедитесь, что нет переменных, объявленных как auto
• Затем скомпилируйте его с помощью компилятора С++ с -Wall и -std=c++11. Исправьте все ошибки и предупреждения.
• Теперь скомпилируйте с помощью компилятора C еще раз. Ваша программа должна теперь компилироваться без предупреждения и содержать меньше ошибок.

Эта процедура позволяет вам использовать проверку строгих типов С++, тем самым уменьшая количество ошибок. В частности, эта процедура заставляет вас включать stdlib.h или вы получите

malloc не был объявлен в этой области

а также заставляет вас отображать результат malloc или вы получите

неверное преобразование от void* до T*

или какой бы тип вашего целевого объекта не был.

Единственные преимущества написания в C вместо С++, которые я могу найти, - это

• C имеет четко определенный ABI
• С++ может генерировать больше кода [исключения, RTTI, шаблоны, полиморфизм времени выполнения]

Обратите внимание на то, что второй недостаток в идеальном случае исчезает при использовании общего подмножества C вместе со статическим полиморфным признаком.

Для тех, кто считает строгие правила С++ неудобными, мы можем использовать функцию С++ 11 с выведенным типом

auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...

Концепция указателя void заключается в том, что он может быть применен к любому типу данных, поэтому malloc возвращает void. Также вы должны знать о автоматическом приведении типов. Поэтому не обязательно указывать указатель, хотя вы должны это делать. Это помогает сохранить код чистым и помогает отлаживать

• Как и указано, он не нужен для C, но для С++.

• Включение роли может позволить программе или функции C скомпилироваться как С++.

• В C нет необходимости, поскольку void * автоматически и безопасно продвигается к любому другому типу указателя.

• Но если вы затем нажмете, он может скрыть ошибку, если вы забыли включить stdlib.h. Это может привести к сбоям (или, что еще хуже, не вызвать сбой до конца позже в какой-то совершенно другой части кода).

  Потому что stdlib.h содержит прототип для malloc. в отсутствие прототипа для malloc, стандарт требует, чтобы C компилятор предполагает, что malloc возвращает int. Если нет броска, предупреждение выдается, когда этому целому числу присваивается указатель; однако, с литой, это предупреждение не создается, скрывая ошибку.

Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.

Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.

Здесь актерский состав не нужен вообще. Под языком C вы можете неявно конвертировать пустой указатель в любой другой указатель.

Кастинг malloc не нужен в C, но обязателен в C++.

Кастинг не нужен в C из-за:

• void * автоматически и безопасно продвигается к любому другому типу указателя в случае C.
• Он может скрыть ошибку, если вы забыли включить <stdlib.h>. Это может привести к сбоям.
• Если указатели и целые числа имеют разный размер, тогда вы скрываете предупреждение путем кастинга и можете потерять бит вашего возвращенного адреса.
• Если тип указателя изменяется при его объявлении, также может потребоваться изменить все строки, в которых malloc вызывается и выполняется.

С другой стороны, кастинг может увеличить переносимость вашей программы. т.е. он позволяет программе или функции C компилироваться как C++.

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

Таким образом, cast возвращаемый указатель из malloc. В следующем коде компилятор может быть уверен, что сите фактически присваивается точка целому числу.

    int *sieve = (int *) malloc(sizeof(int) * length);

Это уменьшает вероятность возникновения человеческой ошибки при изменении типа данных для сита.

Мне было бы интересно узнать, есть ли какие-либо "чистые" компиляторы C, которые бы помешали этому утверждению как ошибочные. Если да, сообщите мне, чтобы я мог избежать их, поскольку их отсутствие проверки типов увеличит общий расход на обслуживание программного обеспечения.