Вывести результат malloc?

В этот вопрос, кто-то предложил в comment, что я должен не введите результат malloc, т.е.

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

а не:

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

Почему это так?

2250
03 марта '09 в 13:13
источник поделиться
28 ответов

Нет; вы не произносите результат, так как:

  • Это необязательно, поскольку void * автоматически и безопасно продвигается к любому другому типу указателя в этом случае.
  • Он добавляет беспорядок в код, отливки не очень легко читать (особенно если тип указателя длинный).
  • Это заставляет вас повториться, что обычно плохо.
  • Он может скрыть ошибку, если вы забыли включить <stdlib.h>. Это может привести к сбоям (или, что еще хуже, не привести к сбою до конца позже в какой-то совершенно другой части кода). Подумайте, что произойдет, если указатели и целые числа по-разному; то вы скрываете предупреждение путем кастинга и можете потерять бит вашего возвращенного адреса. Примечание: с C11 неявные функции исчезли из C, и эта точка больше не актуальна, поскольку нет автоматического предположения о том, что необъявленные функции возвращают int.

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

Также обратите внимание, как отмечают комментаторы, что вышеперечисленные разговоры о прямом C, а не С++. Я очень твердо верю в C и С++ как отдельные языки.

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

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

Это также перемещает length на передний план для увеличения видимости и сбрасывает лишние круглые скобки с помощью sizeof; они нужны только тогда, когда аргумент является именем типа. Многие люди, похоже, не знают (или игнорируют) это, что делает их код более подробным. Помните: sizeof не является функцией!:)


При перемещении length на фронт может увеличиться видимость в некоторых редких случаях, следует также обратить внимание на то, что в общем случае лучше написать выражение как:

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

Так как сначала удерживая sizeof, в этом случае, умножение выполняется, по крайней мере, с помощью size_t math.

Compare: malloc(sizeof *sieve * length * width) vs. malloc(length * width * sizeof *sieve) второй может переполнить length * width, когда width и length являются меньшими типами, чем size_t.

2073
03 марта '09 в 13:17
источник

Связанные вопросы


Похожие вопросы

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

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

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

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

350
03 марта '09 в 13:17
источник

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

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

Как и указано, он не нужен для 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 и С++.

159
03 марта '09 в 14:17
источник

Из Википедии:

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

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

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

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

Недостатки кастинга

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

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

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

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

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

119
10 окт. '15 в 0:23
источник

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

98
03 марта '09 в 13:18
источник

Вы не произносите результат 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-летний компилятор?

90
20 марта '14 в 18:53
источник

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

85
03 марта '09 в 13:16
источник

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

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

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

66
09 июня '13 в 20:31
источник

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

49
08 февр. '13 в 1:22
источник

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

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

48
28 марта '14 в 21:21
источник

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

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

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

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

30
09 окт. '15 в 20:47
источник

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

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

29
13 июля '14 в 9:42
источник

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

28
26 апр. '13 в 19:43
источник

В языке 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++) {
   ...
}
26
04 сент. '15 в 14:52
источник

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

25
17 марта '14 в 16:16
источник

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

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

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

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

YMMV.

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

15
04 дек. '15 в 20:27
источник

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

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.

12
30 марта '16 в 3:23
источник

Лучшее, что нужно делать при программировании на 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...
12
12 июня '15 в 18:23
источник

Нет, вы не выполняете результат 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 * не соответствует не. С++ имеет целый набор различных вкусов кастинга.

11
16 авг. '17 в 15:25
источник

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

11
29 июня '16 в 10:30
источник

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

10
10 сент. '15 в 18:58
источник

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

9
29 июля '15 в 8:53
источник
  • Как и указано, он не нужен для C, но для С++.

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

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

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

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

6
08 нояб. '16 в 13:09
источник

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

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

6
18 июля '16 в 13:36
источник

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

4
21 дек. '18 в 8:33
источник

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

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

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

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

3
03 окт. '17 в 16:13
источник

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

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

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

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

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

-3
03 авг. '13 в 22:53
источник

Посмотрите другие вопросы по меткам или Задайте вопрос