Я кидаю результат малок?

У цьому питанні хтось запропонував у коментарі, що я не повинен наводити результат malloc, тобто

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

а не:

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

Чому це було б так?

Ні ; ви не кидаєте результат, оскільки:

• Це непотрібно, оскільки void *автоматично і безпечно просувається до будь-якого іншого типу вказівника в цьому випадку.
• Це додає безладу коду, касти читаються не дуже просто (особливо якщо тип вказівника довгий).
• Це змушує повторити себе, що взагалі погано.
• Він може приховати помилку, якщо ви забули включити <stdlib.h>. Це може спричинити збої (або, що ще гірше, не спричинити збої до подальшого шляху в якійсь абсолютно іншій частині коду). Поміркуйте, що станеться, якщо покажчики та цілі числа мають різний розмір; то ви приховуєте попередження, передаваючи і може втратити біти поверненої адреси. Примітка: на C99 неявні функції відійшли від C, і ця точка більше не є актуальною, оскільки немає автоматичного припущення про повернення незадекларованих функцій int.

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

Також зауважте, як зазначають коментатори, що вище сказано про пряму C, а не C ++. Я дуже твердо вірю в С та С ++ як окремі мови.

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

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

Це також пересуває на lengthпередню частину для збільшення видимості та скидає зайві дужки sizeof; вони потрібні лише тоді, коли аргумент - це ім'я типу. Багато людей, здається, не знають (або ігнорують) це, що робить їх код більш багатослівним. Пам'ятайте: sizeofце не функція! :)

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

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

Оскільки зберігання sizeofпершого, в цьому випадку, забезпечує множення, що робиться принаймні size_tматематикою.

Порівняйте: malloc(sizeof *sieve * length * width)порівняно malloc(length * width * sizeof *sieve)з другим може переповнювати типи length * widthколи widthі lengthменше size_t.

В C не потрібно вводити повернене значення malloc. Вказівник на недійсність, що повертається, mallocавтоматично перетворюється на правильний тип. Однак, якщо ви хочете, щоб ваш код компілювався з компілятором C ++, необхідний склад. Кращою альтернативою серед громади є використання наступного:

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

що додатково звільняє вас від турботи про зміну правої частини виразу, якщо коли-небудь ви змінюєте тип sieve.

Закиди погані, як вказували люди. Особливо кидає покажчик.

Ви робите роль, тому що:

• Це робить ваш код більш портативним між C і C ++, і як показує досвід SO, дуже багато програмістів стверджують, що вони пишуть на C, коли вони справді пишуть на C ++ (або C плюс локальні розширення компілятора).
• Якщо цього не зробити, можна приховати помилку : відзначте всі приклади ПУ, що плутають, коли писати type *проти type **.
• Ідея про те, що це не дозволяє вам помітити, що вам не вдалося до #includeвідповідного файлу заголовка, не вистачає лісу для дерев . Це те саме, що говорити "не хвилюйся про те, що ти не зміг попросити компілятора поскаржитися на те, що не бачив прототипів - це прискіпливий stdlib.h НАДЕЙСЬКЕ важливо пам'ятати!"
• Це змушує додаткову пізнавальну перехресну перевірку . Він (передбачуваний) бажаний тип розміщується поруч із арифметикою, яку ви робите для необмеженого розміру цієї змінної. Б'юсь об заклад, що ви могли б провести дослідження SO, яке показує, що malloc()помилки ловляться набагато швидше, коли є акторський склад. Як і у твердженнях, примітки, які розкривають помилки щодо намірів.
• Повторення себе таким чином, що машина може перевірити, часто є чудовою ідеєю. Насправді, ось що є твердженням, і таке використання акторського складу - це твердження. Твердження як і раніше є найбільш загальною методикою для правильного кодування, оскільки Тьюрінг придумав цю ідею стільки років тому.

Як заявили інші, вона не потрібна для C, але необхідна для C ++. Якщо ви думаєте, що збираєтесь зібрати свій код 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 і C ++.

З Вікіпедії :

Переваги кастингу

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

• У ролях передбачені версії malloc до 1989 року, які спочатку повернули знак *.

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

Недоліки лиття

• Відповідно до стандарту ANSI C, акторський склад є зайвим.

• Додавання амплітуди може замаскувати невключення заголовка stdlib.h, в якому знайдено прототип для malloc. За відсутності прототипу для malloc, стандарт вимагає, щоб компілятор C припустив, що malloc повертає int. Якщо немає введення, видається попередження, коли це ціле число призначено покажчику; однак, при ролях це попередження не видається, приховуючи помилку. У певних архітектурах та моделях даних (наприклад, LP64 на 64-бітних системах, де довгі та покажчики є 64-бітовими, а int - 32-розрядні), ця помилка може насправді призвести до невизначеного поведінки, оскільки неявно оголошений malloc повертає 32- бітове значення, тоді як фактично визначена функція повертає 64-бітове значення. Залежно від умов виклику та компонування пам’яті, це може призвести до розбиття стека. Ця проблема рідше залишиться непоміченою у сучасних компіляторах, оскільки вони рівномірно створюють попередження про те, що використовується незадекларована функція, то попередження все одно з’явиться. Наприклад, поведінка за замовчуванням GCC полягає в тому, щоб показувати попередження, яке читає "несумісне неявне декларування вбудованої функції", незалежно від того, присутній атрибут чи ні.

• Якщо тип вказівника змінено при його оголошенні, також може знадобитися змінити всі рядки, де викликується та передається malloc.

Хоча malloc без кастингу є кращим методом, і більшість досвідчених програмістів вибирають його , вам слід скористатися тим, що вам подобається, знаючи про проблеми.

тобто: Якщо вам потрібно скласти програму C як C ++ (Хоча це окрема мова), ви повинні вказати результат використання malloc.

У C ви можете неявно перетворити voidвказівник на будь-який інший вид вказівника, тому видання не потрібне. Використання одного може підказати випадковому спостерігачеві, що є якась причина, чому потрібна така, яка може ввести в оману.

Ви не кидаєте результат malloc, тому що це додає безглуздого безладу вашому коду.

Найпоширеніша причина, по якій люди кидають результат малоквороту - це те, що вони не впевнені в тому, як працює мова С. Це попереджувальний знак: якщо ви не знаєте, як працює певний мовний механізм, тоді не здогадуйтесь. Подивіться його або запитайте в Stack Overflow.

Деякі коментарі:

• Недійсний покажчик може бути перетворений в / з будь-якого іншого типу вказівника без явного виступу (C11 6.3.2.3 та 6.5.16.1).

• C ++, однак, не дозволить неявного введення між void*і іншим типом вказівника. Так що в C ++, акторський склад був би правильним. Але якщо ви програмуєте на C ++, вам слід використовувати, newа не malloc (). І ніколи не слід компілювати код C за допомогою компілятора C ++.

  Якщо вам потрібно підтримувати і C, і C ++ одним і тим же вихідним кодом, використовуйте перемикачі компілятора для позначення відмінностей. Не намагайтеся наситити обидва мовні стандарти одним і тим же кодом, оскільки вони не сумісні.

• Якщо компілятор C не може знайти функцію, оскільки ви забули включити заголовок, ви отримаєте помилку компілятора / посилання з цього приводу. Тож якщо ви забули включити, <stdlib.h>що це не велике, ви не зможете створити свою програму.

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

  Але це справді не питання. Ви не використовуєте 25-річний комп’ютер, тож чому б ви використовували компілятор 25 років?

У C ви отримуєте неявне перетворення з void *будь-якого іншого (даних) покажчика.

Передавати значення, що повертається, malloc()зараз не потрібно, але я хотів би додати один момент, який, здається, ніхто не зазначив:

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

Довідка: C FAQ

Тільки додаючи свій досвід, вивчаючи комп'ютерну техніку, я бачу, що два-три професора, яких я бачив, як писали на С, завжди кидають маловір, проте той, кого я запитав (з величезним резюме та розумінням С), сказав мені, що це абсолютно непотрібно, але використовувались лише для того, щоб бути абсолютно конкретними, і вбивати учнів у менталітет як абсолютно специфічний. По суті, кастинг нічого не змінить у тому, як він працює, він виконує саме те, що він каже, виділяє пам'ять, а кастинг не впливає на нього, ви отримуєте ту саму пам’ять і навіть якщо помилково відкинете її на щось інше (і якось ухиляєтесь від компілятора помилки) C отримає доступ до нього аналогічно.

Редагувати: Кастинг має певний момент. Коли ви використовуєте позначення масиву, згенерований код повинен знати, скільки місць пам'яті йому потрібно заздалегідь досягти початку наступного елемента, це досягається за допомогою кастингу. Таким чином, ви знаєте, що для подвійного ви йдете на 8 байт вперед, а для int - 4 і так далі. Таким чином, це не має ефекту, якщо ви використовуєте позначення вказівника, у позначенні масиву це стає необхідним.

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

Показник недійсності - це загальний об'єктний покажчик, і C підтримує неявне перетворення з типу пустоти вказівника в інші типи, тому немає необхідності в чіткому наборі цього типу.

Однак, якщо ви хочете, щоб той самий код працював ідеально сумісним на платформі C ++, яка не підтримує неявне перетворення, вам потрібно зробити набір даних, тому все залежить від зручності використання.

Про це говорить посібник з бібліотеки GNU C :

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

І справді стандарт ISO C11 (p347) говорить так:

Вказівник, повернутий у разі успішного розподілу, є відповідним чином вирівняним, щоб він міг бути призначений покажчиком на будь-який тип об'єктів з основними вимогами вирівнювання, а потім використовуватися для доступу до такого об’єкта або масиву таких об'єктів у виділеному просторі (до простір явно розміщений)

Повертається тип - недійсний *, який може бути переданий до потрібного типу вказівника даних, щоб бути відкинутим.

У мові C недійсним покажчиком може бути призначений будь-який вказівник, саме тому не слід використовувати тип набору. Якщо ви хочете виділити "безпечне" виділення, я можу порекомендувати наступні макрофункції, які я завжди використовую в своїх проектах 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);

Для нединамічних масивів третім макросом функції must-have є

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

що робить петлі масиву безпечнішими та зручнішими:

int i, a[100];

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

Це залежить від мови програмування та компілятора. Якщо ви використовуєте mallocв C, немає необхідності вводити його, оскільки він автоматично вводить роль. Однак якщо ви використовуєте C ++, вам слід ввести cast, тому що mallocповерне void*тип.

Люди, звикли до GCC та Clang, розбещені. Там все не так добре.

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

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

Аргумент, що це не потрібно в діючих стандартах, цілком справедливий. Але цей аргумент омиває практичність реального світу. Ми кодируємо не у світі, який керується виключно стандартом дня, а практичністю того, що я люблю називати "місцем реальності місцевого управління". І це зігнуто і скручено більше, ніж коли-небудь в космосі. :-)

YMMV.

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

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

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

Я б хотів, щоб його не існувало (а його немає в C ++), і тому я виступаю. Це репрезентує мій смак та мою політику програмування. Я не тільки кидаю вказівник, але ефективно, віддаю бюлетень і виганяю демонів дурості . Якщо я насправді не можу вигнати дурість , то, принаймні, дозвольте висловити бажання зробити це жестом протесту.

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

Що стосується теми кастингу та сумісності C ++, якщо ви пишете свій код так, що він компілюється як C, так і C ++ (у такому випадку вам потрібно передати повернене значення mallocпри призначенні його чомусь іншому, ніж void *), ви можете зробити дуже корисним Реч для себе: ви можете використовувати макроси для кастингу, які перекладаються на касти у стилі C ++ при компілюванні як C ++, але зменшують до символу 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пошук вашої кодової бази за цими ідентифікаторами покаже вам, де всі ваші трансляції, тож ви зможете перевірити, чи не вказано жодне з них.

Тоді, вперед, якщо ви регулярно компілюєте код з C ++, він буде примусово використовувати відповідний склад. Наприклад, якщо ви використовуєте strip_qualтільки для видалення constабо volatile, але зміни програми таким чином , що перетворення типу в даний час бере участь, ви отримаєте діагностики, і ви повинні будете використовувати комбінацію зліпків , щоб отримати бажане перетворення.

Щоб допомогти вам дотримуватися цих макросів, компілятор GNU C ++ (не C!) Має прекрасну особливість: додаткову діагностику, яка виробляється для всіх випадків кастингу стилю C.

     -Старий стиль (лише C ++ та Objective-C ++)
         Попередьте, якщо використовується старий стиль (C-стиль), призначений для недійсного типу
         в рамках програми C ++. У ролях нового стилю (dynamic_cast,
         static_cast, reinterpret_cast та const_cast) менш вразливі
         до ненавмисних ефектів і набагато простіше шукати.

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

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

Найкраще робити програмування на C, коли це можливо:

1. Зробіть компіляцію вашої програми через компілятор C із увімкненими попередженнями -Wallта виправте всі помилки та попередження
2. Переконайтесь, що немає змінних, оголошених як auto
3. Потім компілюйте його за допомогою компілятора C ++ з -Wallта -std=c++11. Виправте всі помилки та попередження.
4. Тепер знову компілюйте, використовуючи компілятор C. Тепер ваша програма повинна збиратись без будь-якого попередження та містити менше помилок.

Ця процедура дозволяє скористатися суворою перевіркою типу C ++, зменшивши, таким чином, кількість помилок. Зокрема, ця процедура змушує вас включити stdlib.hабо ви отримаєте

malloc не було задекларовано в межах цього обсягу

а також змушує вас кинути результат mallocабо ви отримаєте

недійсна конверсія від void*доT*

або будь-який ваш цільовий тип.

Єдині переваги від написання на C замість C ++ я можу знайти

1. C має добре вказаний ABI
2. C ++ може генерувати більше коду [винятки, RTTI, шаблони, поліморфізм часу виконання ]

Зауважте, що в ідеальному випадку другий мінус повинен зникнути при використанні підмножини, спільної для C разом зі статичною поліморфною ознакою.

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

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

Ні, ви не піддаєте результат malloc().

Взагалі ви не кидаєте на або з нихvoid * .

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

Але є набагато вагоміша причина не вводити зайві вказівки:

У C введення покажчика майже завжди є помилкою . Це пояснюється наступним правилом ( §6.5 p7 у N1570, останній проект для C11):

Об'єкт має збережене значення, доступ до якого має лише вираз lvalue, який має один з таких типів:
- тип, сумісний з ефективним типом об'єкта,
- кваліфікована версія типу, сумісна з ефективним типом об'єкта,
- тип, який є типовим або непідписаним типом, що відповідає ефективному типу об'єкта,
- тип, який є типовим або непідписаним типом, що відповідає кваліфікованій версії ефективного типу об'єкта,
- сукупний або об'єднаний тип, що включає в себе один вищезазначених типів серед його членів (у тому числі, рекурсивно, член субагрегату або вміщеного союзу), або
- тип символів.

Це також відомо як правило суворого псевдоніму . Отже, наступний код - це невизначена поведінка :

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;

Іноді вам дійсно потрібно литі покажчики, але , з огляду на суворе правило згладжування , ви повинні бути дуже обережні з ним. Отже, будь-яке виникнення вказівника, що викидається у ваш код, - це місце, яке ви повинні двічі перевірити на його дійсність . Тому ви ніколи не пишете зайвого актора вказівника.

тл; д-р

Коротше кажучи: оскільки у випадку C у будь-якому появі вказівника повинно виникати червоний прапор для коду, який потребує особливої ​​уваги, ви ніколи не повинні писати зайвих вказівників.

Бічні нотатки:

• Є випадки , коли ви на самому справі потрібно приведення до void *, наприклад , якщо ви хочете надрукувати покажчик:

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

  Тут необхідний склад, тому що printf()це варіативна функція, тому неявні перетворення не працюють.

• У С ++ ситуація інша. Типи вказівних кастингу є дещо поширеними (і правильними) при роботі з об'єктами похідних класів. Тому має сенс, що в C ++ перетворення на та з неvoid * є неявними. C ++ має цілий набір різних ароматів лиття.

Я вважаю за краще робити акторський склад, але не вручну. Моїм улюбленим є використання g_newі g_new0макросів із глібу. Якщо гліб не використовується, я б додав подібні макроси. Ці макроси зменшують дублювання коду без шкоди для безпеки типу. Якщо ви неправильно введете тип, ви отримаєте неявний заголовок між недійсними покажчиками, що може спричинити попередження (помилка в C ++). Якщо ви забудете включити заголовок, який визначає, g_newі g_new0ви отримаєте помилку. g_newі g_new0обидва беруть однакові аргументи, на відміну від того, mallocщо бере менше аргументів, ніж calloc. Просто додайте, 0щоб отримати нульову ініціалізовану пам'ять. Код можна скласти за допомогою компілятора C ++ без змін.

Кастинг призначений лише для C ++, а не для C. Якщо ви використовуєте компілятор C ++, краще змінити його на компілятор C.

Концепція пустоти вказівника полягає в тому, що він може бути переданий на будь-який тип даних, тому malloc повертає недійсність. Крім того, ви повинні знати про автоматичну клавіатуру. Таким чином, не обов'язково кидати покажчик, хоча ви повинні це зробити. Це допомагає зберігати код чистим та допомагає налагоджувати

Вказівник недійсності - це загальний покажчик, і C підтримує неявне перетворення з типу пустоти вказівника в інші типи, тому немає необхідності чітко вводити його.

Однак, якщо ви хочете, щоб той самий код працював ідеально сумісним на платформі C ++, яка не підтримує неявне перетворення, вам потрібно зробити набір даних, тому все залежить від зручності використання.

1. Як було сказано в іншому, він потрібен не для C, а для C ++.

2. Включаючи команду, можливо, програма C або функція можуть компілювати як C ++.

3. У C це непотрібно, оскільки void * автоматично та безпечно просувається до будь-якого іншого типу вказівника.

4. Але якщо ви будете робити це, ви можете приховати помилку, якщо ви забули включити stdlib.h . Це може спричинити збої (або, що ще гірше, не спричинити збої до подальшого шляху в якійсь абсолютно іншій частині коду).

   Оскільки stdlib.h містить прототип для malloc, знайдено. За відсутності прототипу для malloc, стандарт вимагає, щоб компілятор C припускав, що malloc повертає int. Якщо немає введення, видається попередження, коли це ціле число призначено покажчику; однак, при ролях це попередження не видається, приховуючи помилку.

Лиття малалоку непотрібне в С, але обов'язкове в С ++.

Кастинг в C не потрібний через:

• void * автоматично та безпечно просувається до будь-якого іншого типу вказівника у випадку С.
• Він може приховати помилку, якщо ви забули включити <stdlib.h> . Це може спричинити збої.
• Якщо вказівники та цілі числа мають різний розмір, ви приховуєте попередження шляхом кастингу і можуть втратити біти повернутої адреси.
• Якщо тип вказівника змінено при його оголошенні, можливо, знадобиться також змінити всі рядки, де mallocвикликається і вводиться.

З іншого боку, кастинг може збільшити портативність вашої програми. тобто це дозволяє програмі або функції C збирати як C ++.

Для мене, взяти додому і висновок тут полягає в тому, що кастинг mallocна C абсолютно не потрібен, але якщо ви все-таки киньте, це не буде впливати mallocякmalloc все-таки виділить вам потрібний благословенний простір пам'яті. Ще один прийом додому - це причина чи одна з причин, коли люди роблять кастинг, і це полягає в тому, щоб вони могли скласти ту саму програму або на C, або на C ++.

Можуть бути й інші причини, але інші причини, майже напевно, рано чи пізно приведуть вас до серйозних проблем.

Ви можете, але не потрібно робити це в C. Ви повинні подати, якщо цей код складений як C ++.