Eu transmito o resultado do malloc?

Em esta pergunta , alguém sugeriu em um comentário que eu deveria não converter o resultado de malloc, ou seja,

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

ao invés de:

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

Por que isso seria o caso?

Não ; você não transmite o resultado, pois:

• É desnecessário, pois void *é automaticamente e com segurança promovido para qualquer outro tipo de ponteiro nesse caso.
• Ele adiciona confusão ao código, as conversões não são muito fáceis de ler (especialmente se o tipo de ponteiro for longo).
• Isso faz você se repetir, o que geralmente é ruim.
• Pode ocultar um erro se você se esquecer de incluir <stdlib.h>. Isso pode causar falhas (ou, pior, não causar uma falha até muito mais tarde em alguma parte totalmente diferente do código). Considere o que acontece se ponteiros e números inteiros tiverem tamanhos diferentes; você está ocultando um aviso ao transmitir e pode perder partes do seu endereço retornado. Nota: a partir de C99, as funções implícitas passaram de C, e esse ponto não é mais relevante, pois não há suposição automática de que as funções não declaradas retornam int.

Como esclarecimento, observe que eu disse "você não lança", e não "você não precisa transmitir". Na minha opinião, é um fracasso em incluir o elenco, mesmo se você acertar. Simplesmente não há benefícios em fazê-lo, mas vários riscos em potencial, e a inclusão do elenco indica que você não conhece os riscos.

Observe também, como os comentaristas apontam, que o acima mencionado fala sobre C direto, não C ++. Eu acredito firmemente em C e C ++ como linguagens separadas.

Para adicionar ainda mais, seu código repete desnecessariamente as informações de tipo ( int) que podem causar erros. É melhor des-referenciar o ponteiro que está sendo usado para armazenar o valor de retorno e "bloquear" os dois juntos:

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

Isso também move o lengthpara a frente para aumentar a visibilidade e descarta os parênteses redundantes sizeof; eles são necessários apenas quando o argumento é um nome de tipo. Muitas pessoas parecem não saber (ou ignorar) isso, o que torna seu código mais detalhado. Lembre-se: sizeofnão é uma função! :)

Embora mover lengthpara a frente possa aumentar a visibilidade em alguns casos raros, também se deve prestar atenção que, no caso geral, deve ser melhor escrever a expressão como:

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

Como manter o sizeofprimeiro, neste caso, garante que a multiplicação seja feita com pelo menos size_tmatemática.

Compare: malloc(sizeof *sieve * length * width)vs. malloc(length * width * sizeof *sieve)o segundo pode exceder o length * widthquando widthe lengthsão tipos menores que size_t.

Em C, você não precisa converter o valor de retorno de malloc. O ponteiro para anular retornado por mallocé convertido automaticamente para o tipo correto. No entanto, se você deseja que seu código seja compilado com um compilador C ++, uma conversão é necessária. Uma alternativa preferida entre a comunidade é usar o seguinte:

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

o que, além disso, libera você de se preocupar em alterar o lado direito da expressão, se você alterar o tipo de sieve.

Elencos são ruins, como as pessoas apontaram. Especialmente ponteiro lança.

Você não fundido, porque:

• Isso torna seu código mais portátil entre C e C ++ e, como mostra a experiência do SO, muitos programadores afirmam que estão escrevendo em C quando realmente estão escrevendo em C ++ (ou C mais extensões de compilador local).
• Não fazer isso pode ocultar um erro : observe todos os exemplos de confusão quando escrever type *versus type **.
• A idéia de impedir que você observe que você falhou em #includeum arquivo de cabeçalho apropriado perde a floresta para as árvores . É o mesmo que dizer "não se preocupe com o fato de você ter falhado em pedir ao compilador para reclamar por não ter visto protótipos - que o irritante stdlib.h é a coisa realmente importante a lembrar!"
• Isso força uma verificação cruzada cognitiva extra . Ele coloca o tipo (suposto) desejado ao lado da aritmética que você está fazendo para o tamanho bruto dessa variável. Aposto que você poderia fazer um estudo de SO que mostra que os malloc()bugs são detectados muito mais rapidamente quando há um lançamento. Assim como as asserções, as anotações que revelam a intenção diminuem os erros.
• Repetir-se de uma maneira que a máquina possa verificar geralmente é uma ótima idéia. De fato, é isso que é uma afirmação, e esse uso do elenco é uma afirmação. As asserções ainda são a técnica mais geral que temos para obter o código correto, desde que Turing surgiu com a ideia há muitos anos.

Como outros declararam, não é necessário para C, mas necessário para C ++. Se você acha que vai compilar seu código C com um compilador C ++, por qualquer motivo, você pode usar uma macro, como:

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

Dessa forma, você ainda pode escrevê-lo de uma maneira muito compacta:

int *sieve = NEW(int, 1);

e ele será compilado para C e C ++.

De Wikipedia :

Vantagens para fundição

• A inclusão do elenco pode permitir que um programa ou função C seja compilado como C ++.

• O elenco permite versões pré-1989 do malloc que originalmente retornavam um caractere *.

• A transmissão pode ajudar o desenvolvedor a identificar inconsistências no tamanho do tipo, caso o tipo do ponteiro de destino seja alterado, principalmente se o ponteiro for declarado longe da chamada malloc () (embora compiladores modernos e analisadores estáticos possam alertar sobre esse comportamento sem exigir a transmissão).

Desvantagens para fundição

• Sob o padrão ANSI C, o elenco é redundante.

• Adicionar a conversão pode mascarar a falha para incluir o cabeçalho stdlib.h, no qual o protótipo do malloc é encontrado. Na ausência de um protótipo para malloc, o padrão exige que o compilador C assuma que malloc retorne um int. Se não houver conversão, um aviso será emitido quando esse número inteiro for atribuído ao ponteiro; no entanto, com o elenco, esse aviso não é produzido, ocultando um bug. Em certas arquiteturas e modelos de dados (como LP64 em sistemas de 64 bits, em que longos e ponteiros são de 64 bits e int é de 32 bits), esse erro pode realmente resultar em um comportamento indefinido, pois o malloc declarado implicitamente retorna um valor de 32 bits. valor de bit, enquanto a função realmente definida retorna um valor de 64 bits. Dependendo das convenções de chamada e do layout da memória, isso pode resultar em esmagamento da pilha. É menos provável que esse problema passe despercebido nos compiladores modernos, como eles produzem avisos uniformemente de que uma função não declarada foi usada, um aviso ainda aparecerá. Por exemplo, o comportamento padrão do GCC é mostrar um aviso que lê "declaração implícita incompatível da função interna" independentemente de a conversão estar presente ou não.

• Se o tipo do ponteiro for alterado em sua declaração, pode-se também precisar alterar todas as linhas nas quais o malloc é chamado e convertido.

Embora o malloc sem conversão seja o método preferido e os programadores mais experientes o escolham , você deve usar o que quiser ter conhecimento dos problemas.

ou seja: Se você precisar compilar o programa C como C ++ (embora seja uma linguagem separada), deverá converter o resultado do uso malloc.

Em C, você pode converter implicitamente um voidponteiro em qualquer outro tipo de ponteiro, para que uma conversão não seja necessária. O uso de um pode sugerir ao observador casual que existe alguma razão pela qual ele é necessário, o que pode ser enganoso.

Você não lança o resultado do malloc, porque isso adiciona uma confusão inútil ao seu código.

A razão mais comum pela qual as pessoas lançam o resultado do malloc é porque não têm certeza sobre como a linguagem C funciona. Esse é um sinal de alerta: se você não sabe como funciona um mecanismo de linguagem específico, não adivinhe. Procure ou pergunte no Stack Overflow.

Alguns comentários:

• Um ponteiro nulo pode ser convertido para / de qualquer outro tipo de ponteiro sem uma conversão explícita (C11 6.3.2.3 e 6.5.16.1).

• C ++, no entanto, não permitirá uma conversão implícita entre void*e outro tipo de ponteiro. Portanto, em C ++, o elenco estaria correto. Mas se você programa em C ++, deve usar newe não malloc (). E você nunca deve compilar código C usando um compilador C ++.

  Se você precisar oferecer suporte a C e C ++ com o mesmo código-fonte, use as opções do compilador para marcar as diferenças. Não tente classificar os dois padrões de idioma com o mesmo código, porque eles não são compatíveis.

• Se um compilador C não conseguir encontrar uma função porque você esqueceu de incluir o cabeçalho, você receberá um erro do compilador / vinculador sobre isso. Portanto, se você esqueceu de incluir <stdlib.h>isso não é nada demais, não poderá criar seu programa.

• Em compiladores antigos que seguem uma versão do padrão com mais de 25 anos, esquecer de incluir <stdlib.h>resultaria em comportamento perigoso. Porque nesse padrão antigo, funções sem um protótipo visível convertiam implicitamente o tipo de retorno em int. A transmissão explícita do resultado do malloc ocultaria esse bug.

  Mas isso é realmente um problema. Você não está usando um computador de 25 anos, então por que você usaria um compilador de 25 anos?

Em C, você obtém uma conversão implícita de void *para qualquer outro ponteiro (dados).

Lançando o valor retornado por malloc()Não é necessário converter agora, mas eu gostaria de acrescentar um ponto que parece que ninguém apontou:

Antigamente, ou seja, antes do ANSI C fornecer o void *tipo genérico de ponteiros, char *é o tipo para esse uso. Nesse caso, o elenco pode desligar os avisos do compilador.

Referência: C FAQ

Apenas adicionando minha experiência, estudando engenharia da computação, vejo que os dois ou três professores que eu vi escrevendo em C sempre lançam malloc, mas o que eu perguntei (com um imenso currículo e compreensão de C) me disse que é absolutamente desnecessário, mas costumava ser absolutamente específico e levar os alunos à mentalidade de serem absolutamente específicos. Essencialmente, a conversão não muda nada em como funciona, faz exatamente o que diz, aloca memória e a conversão não afeta, você obtém a mesma memória e, mesmo se a converter para outra coisa por engano (e de alguma forma evitar o compilador) erros) C acessará da mesma maneira.

Edit: Casting tem um certo ponto. Quando você usa a notação de matriz, o código gerado precisa saber quantos lugares de memória precisa avançar para alcançar o início do próximo elemento, isso é obtido através da conversão. Dessa forma, você sabe que, para um dobro, você avança 8 bytes, enquanto para um int, você avança 4, e assim por diante. Portanto, não tem efeito se você usar a notação de ponteiro; na notação de matriz, isso se torna necessário.

Não é obrigatório converter os resultados de malloc, pois ele retorna void*e a void*pode ser apontado para qualquer tipo de dados.

Um ponteiro nulo é um ponteiro de objeto genérico e C suporta conversão implícita de um tipo de ponteiro nulo para outros tipos, portanto, não há necessidade de lançá-lo explicitamente.

No entanto, se você deseja que o mesmo código funcione perfeitamente compatível em uma plataforma C ++, que não suporta conversão implícita, é necessário fazer a conversão de tipo, para que tudo dependa da usabilidade.

Isto é o que o manual de referência da biblioteca C GNU diz:

Você pode armazenar o resultado mallocem qualquer variável de ponteiro sem conversão, porque o ISO C converte automaticamente o tipo void *em outro tipo de ponteiro quando necessário. Mas a conversão é necessária em contextos diferentes dos operadores de atribuição ou se você quiser que seu código seja executado no C. tradicional

E, de fato, o padrão ISO C11 (p347) diz o seguinte:

O ponteiro retornado se a alocação for bem-sucedida está adequadamente alinhado para que possa ser atribuído a um ponteiro para qualquer tipo de objeto com um requisito de alinhamento fundamental e, em seguida, usado para acessar esse objeto ou uma matriz de tais objetos no espaço alocado (até o espaço é explicitamente desalocado)

O tipo retornado é nulo *, que pode ser convertido no tipo de ponteiro de dados desejado para ser desreferenciável.

No idioma C, um ponteiro nulo pode ser atribuído a qualquer ponteiro, e é por isso que você não deve usar uma conversão de tipo. Se você deseja alocação "tipo seguro", posso recomendar as seguintes funções de macro, que eu sempre uso nos meus projetos em C:

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

Com estes no lugar, você pode simplesmente dizer

NEW_ARRAY(sieve, length);

Para matrizes não dinâmicas, a terceira macro de função obrigatória é

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

o que torna os loops de matriz mais seguros e mais convenientes:

int i, a[100];

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

Depende da linguagem de programação e do compilador. Se você usarmalloc C, não há necessidade de digitar a conversão, pois ela digitará automaticamente a conversão. No entanto, se você estiver usando C ++, digite cast porque mallocretornará um void*tipo.

Pessoas acostumadas a GCC e Clang são mimadas. Não é tão bom assim por aí.

Fiquei bastante horrorizado ao longo dos anos pelos compiladores incrivelmente envelhecidos que fui obrigado a usar. Freqüentemente, empresas e gerentes adotam uma abordagem ultra-conservadora para alterar os compiladores e nem sequer testam se um novo compilador (com melhor conformidade com os padrões e otimização de código) funcionará em seu sistema. A realidade prática para os desenvolvedores que trabalham é que, quando você está codificando, precisa cobrir suas bases e, infelizmente, lançar mallocs é um bom hábito, se você não pode controlar qual compilador pode ser aplicado ao seu código.

Sugiro também que muitas organizações apliquem seus próprios padrões de codificação e que deve ser o método que as pessoas seguem se for definido. Na ausência de orientação explícita, tenho a tendência de compilar em todos os lugares, em vez da adesão servil a um padrão.

O argumento de que não é necessário sob os padrões atuais é bastante válido. Mas esse argumento omite os aspectos práticos do mundo real. Não codificamos em um mundo regido exclusivamente pelo padrão do dia, mas pelas práticas do que eu gosto de chamar de "campo da realidade da administração local". E isso é torcido e distorcido mais do que o tempo espacial jamais esteve. :-)

YMMV.

Costumo pensar em lançar malloc como uma operação defensiva. Não é bonito, não é perfeito, mas geralmente seguro. (Honestamente, se você não incluiu stdlib.h, você tem muito mais problemas do que lançar malloc!).

Eu coloquei no elenco simplesmente para mostrar a desaprovação do buraco feio no sistema de tipos, que permite que códigos como o seguinte trecho sejam compilados sem diagnóstico, mesmo que nenhum elenco seja usado para provocar uma conversão ruim:

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

Eu gostaria que isso não existisse (e não existe em C ++) e, por isso, fiz a transmissão. Representa meu gosto e minha política de programação. Não estou apenas lançando um ponteiro, mas efetivamente, votando e expulsando demônios da estupidez . Se eu realmente não posso expulsar a estupidez , pelo menos deixe-me expressar o desejo de fazê-lo com um gesto de protesto.

De fato, uma boa prática é agrupar malloc(e amigos) com funções que retornam unsigned char *e basicamente nunca usar void *em seu código. Se você precisar de um ponteiro genérico para qualquer objeto, use a char *ou unsigned char *e tenha projeções nas duas direções. O único relaxamento que pode ser tolerado, talvez, é usar funções como memsete memcpysem elencos.

No tópico fundição e compatibilidade com C ++, se você escrever seu código para que ele seja compilado tanto em C quanto em C ++ (nesse caso, você precisará converter o valor de retorno mallocao atribuí-lo a algo diferente de void *), poderá fazer uma ajuda muito útil coisa para você: você pode usar macros para conversão que convertem para conversões no estilo C ++ ao compilar como C ++, mas reduzem para uma conversão C ao compilar como 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

Se você aderir a essas macros, uma simples greppesquisa na sua base de códigos por esses identificadores mostrará onde estão todas as suas transmissões, para que você possa verificar se alguma delas está incorreta.

A partir de agora, se você compilar regularmente o código com C ++, ele aplicará o uso de uma conversão apropriada. Por exemplo, se você usar strip_qualapenas para remover um constou volatile, mas o programa mudar de tal maneira que uma conversão de tipo esteja envolvida, você receberá um diagnóstico e precisará usar uma combinação de conversões para obter a conversão desejada.

Para ajudá-lo a aderir a essas macros, o compilador GNU C ++ (não C!) Possui um recurso bonito: um diagnóstico opcional produzido para todas as ocorrências de conversões no estilo C.

     -Construção no estiloold (apenas C ++ e Objective-C ++)
         Avisar se uma conversão de estilo antigo (estilo C) para um tipo não nulo é usada
         dentro de um programa C ++. O novo estilo lança (dynamic_cast,
         static_cast, reinterpret_cast e const_cast) são menos vulneráveis
         para efeitos não intencionais e muito mais fáceis de pesquisar.

Se o seu código C for compilado como C ++, você poderá usar esta -Wold-style-castopção para descobrir todas as ocorrências da (type)sintaxe de conversão que podem surgir no código e acompanhar esses diagnósticos, substituindo-o por uma escolha apropriada dentre as macros acima (ou um combinação, se necessário).

Esse tratamento de conversões é a maior justificativa técnica autônoma para trabalhar em um "C limpo": o dialeto C e C ++ combinado, que por sua vez tecnicamente justifica lançar o valor de retorno de malloc.

A melhor coisa a fazer ao programar em C sempre que possível:

1. Faça seu programa compilar através de um compilador C com todos os avisos ativados -Walle corrija todos os erros e avisos
2. Verifique se não há variáveis ​​declaradas como auto
3. Em seguida, compile-o usando um compilador C ++ com -Walle -std=c++11. Corrija todos os erros e avisos.
4. Agora compile usando o compilador C novamente. Seu programa agora deve ser compilado sem nenhum aviso e conter menos erros.

Este procedimento permite tirar proveito da verificação estrita do tipo C ++, reduzindo assim o número de bugs. Em particular, este procedimento obriga a incluir stdlib.hou você receberá

malloc não foi declarado nesse escopo

e também obriga a lançar o resultado mallocou você receberá

conversão inválida de void*paraT*

ou qualquer que seja o seu tipo de alvo.

Os únicos benefícios de escrever em C em vez de C ++ que posso encontrar são

1. C tem uma ABI bem especificada
2. C ++ pode gerar mais código [exceções, RTTI, modelos, polimorfismo de tempo de execução ]

Observe que os segundos contras devem, no caso ideal, desaparecer ao usar o subconjunto comum a C junto com o recurso polimórfico estático .

Para aqueles que consideram as regras estritas do C ++ inconvenientes, podemos usar o recurso C ++ 11 com tipo inferido

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

Não, você não lança o resultado de malloc().

Em geral, você não transmite de ou paravoid * .

Um motivo típico para não fazer isso é que a falha em #include <stdlib.h>passar despercebida. Isso não é mais um problema há muito tempo, pois o C99 tornou ilegal a declaração implícita de funções . Portanto, se o seu compilador estiver em conformidade com pelo menos o C99, você receberá uma mensagem de diagnóstico.

Mas há uma razão muito mais forte para não introduzir projeções desnecessárias de ponteiros:

Em C, uma conversão de ponteiro é quase sempre um erro . Isso ocorre devido à seguinte regra ( §6.5 p7 no N1570, o último rascunho do C11):

Um objeto deve ter seu valor armazenado acessado apenas por uma expressão lvalue que possui um dos seguintes tipos:
- um tipo compatível com o tipo efetivo do objeto,
- uma versão qualificada de um tipo compatível com o tipo efetivo do objeto,
- um tipo que é o tipo assinado ou não assinado correspondente ao tipo efetivo do objeto,
- um tipo que é o tipo assinado ou não assinado, correspondente a uma versão qualificada do tipo efetivo do objeto,
- um tipo agregado ou de união que inclui um dos tipos mencionados acima entre seus membros (incluindo, recursivamente, um membro de uma união subagregada ou contida), ou
- um tipo de caractere.

Isso também é conhecido como regra estrita de alias . Portanto, o código a seguir é um comportamento indefinido :

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

E, às vezes surpreendentemente, também é o seguinte:

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;

Às vezes, você não precisa ponteiros do elenco, mas dada a regra aliasing estrita , você tem que ter muito cuidado com ele. Portanto, qualquer ocorrência de um ponteiro convertido em seu código é um local em que você deve verificar novamente sua validade . Portanto, você nunca escreve um elenco desnecessário de ponteiros.

tl; dr

Em poucas palavras: como em C, qualquer ocorrência de vazamento de ponteiro deve exibir uma bandeira vermelha para código que requer atenção especial, você nunca deve escrever vazamentos desnecessários de ponteiro.

Notas laterais:

• Há casos em que você realmente precisa de uma conversão void *, por exemplo, se deseja imprimir um ponteiro:

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

  O elenco é necessário aqui, porque printf()é uma função variável, portanto, as conversões implícitas não funcionam.

• Em C ++, a situação é diferente. A conversão de tipos de ponteiro é algo comum (e correto) ao lidar com objetos de classes derivadas. Portanto, faz sentido que, em C ++, a conversão de e para nãovoid * esteja implícita. O C ++ possui um conjunto completo de diferentes sabores de conversão.

Eu prefiro fazer o elenco, mas não manualmente. O meu favorito é usar g_newe g_new0macros de glib. Se glib não for usado, eu adicionaria macros semelhantes. Essas macros reduzem a duplicação de código sem comprometer a segurança do tipo. Se você errar o tipo, obteria uma conversão implícita entre ponteiros não nulos, o que causaria um aviso (erro em C ++). Se você esquecer de incluir o cabeçalho que define g_newe g_new0, você receberá um erro. g_newe g_new0ambos têm os mesmos argumentos, ao contrário de mallocque leva menos argumentos que calloc. Basta adicionar 0para obter memória inicializada com zero. O código pode ser compilado com um compilador C ++ sem alterações.

A conversão é apenas para C ++ e não C. No caso de você estar usando um compilador C ++, é melhor alterá-lo para o compilador C.

O conceito por trás do ponteiro nulo é que ele pode ser convertido para qualquer tipo de dados, por isso o malloc retorna nulo. Além disso, você deve estar ciente da conversão automática de tipos. Portanto, não é obrigatório lançar o ponteiro, embora você deva fazê-lo. Ajuda a manter o código limpo e ajuda na depuração

Um ponteiro nulo é um ponteiro genérico e C suporta conversão implícita de um tipo de ponteiro nulo para outros tipos, portanto, não há necessidade de lançá-lo explicitamente.

No entanto, se você deseja que o mesmo código funcione perfeitamente compatível em uma plataforma C ++, que não suporta conversão implícita, é necessário fazer a conversão de tipo, para que tudo dependa da usabilidade.

1. Como já foi dito, não é necessário para C, mas para C ++.

2. A inclusão do elenco pode permitir que um programa ou função C seja compilado como C ++.

3. Em C, isso é desnecessário, pois o void * é promovido de forma automática e segura para qualquer outro tipo de ponteiro.

4. Mas se você converter, poderá ocultar um erro se você esquecer de incluir stdlib.h . Isso pode causar falhas (ou, pior, não causar uma falha até muito mais tarde em alguma parte totalmente diferente do código).

   Como stdlib.h contém o protótipo para malloc, foi encontrado. Na ausência de um protótipo para malloc, o padrão exige que o compilador C assuma malloc retornando um int. Se não houver conversão, um aviso será emitido quando esse número inteiro for atribuído ao ponteiro; no entanto, com o elenco, esse aviso não é produzido, ocultando um bug.

A conversão do malloc é desnecessária em C, mas obrigatória em C ++.

A transmissão é desnecessária em C devido a:

• void * é promovido de forma automática e segura para qualquer outro tipo de ponteiro no caso de C.
• Pode ocultar um erro se você se esquecer de incluir <stdlib.h>. Isso pode causar falhas.
• Se ponteiros e números inteiros tiverem tamanhos diferentes, você estará ocultando um aviso ao transmitir e poderá perder bits do seu endereço retornado.
• Se o tipo do ponteiro for alterado em sua declaração, talvez seja necessário alterar todas as linhas em que mallocé chamado e convertido.

Por outro lado, a transmissão pode aumentar a portabilidade do seu programa. isto é, permite que um programa ou função C compile como C ++.

Para mim, a conclusão e conclusão aqui é que a transmissão mallocem C NÃO é totalmente necessária, mas, se você transmitir, isso não afetará, mallocpois mallocainda alocará o espaço de memória abençoado solicitado. Outra coisa que leva para casa é a razão ou uma das razões pelas quais as pessoas fazem a transmissão e isso lhes permite compilar o mesmo programa em C ou C ++.

Pode haver outras razões, mas outras, quase certamente, o colocariam em sérios problemas mais cedo ou mais tarde.

Você pode, mas não precisa converter em C. Você deve converter se esse código for compilado como C ++.