C'de neden bazı insanlar imleci serbest bırakmadan önce kullanıyor?

Ben eski bir kod tabanı üzerinde çalışıyorum ve hemen hemen ücretsiz () her çağrışımı kendi argümanı bir döküm kullanır. Örneğin,

free((float *)velocity);
free((float *)acceleration);
free((char *)label);

burada her işaretçi karşılık gelen (ve eşleşen) tiptedir. Bunu yapmanın bir anlamı yok. Çok eski bir kod, bu yüzden bir K&R şey olup olmadığını merak bıraktım. Eğer öyleyse, bunu gerektirebilecek eski derleyicileri desteklemek istiyorum, bu yüzden onları kaldırmak istemiyorum.

Bu kalıpları kullanmanın teknik bir nedeni var mı? Onları kullanmak için pragmatik bir neden bile görmüyorum. Veri tipini boşaltmadan hemen önce kendimize hatırlatmanın anlamı nedir?

EDIT: Bu soru diğer sorunun bir kopyası değil . Diğer soru, yakın seçmenlerin tüm cevapları okuyup okumadıklarının açık olduğunu düşündüğüm bu sorunun özel bir örneğidir.

Colophon: "Const answer" onay işaretini veriyorum çünkü bunun yapılması gerekebileceğinin gerçek bir sebebi; ancak, ANSI C öncesi bir özel (en azından bazı programcılar arasında) olmasının cevabı, benim durumumda kullanılmasının nedeni gibi görünüyor. Burada birçok kişi tarafından iyi noktalar. Katkılarınız için teşekkür ederiz.

Eğer işaretçiler varsa derleyici uyarılarını çözmek için döküm gerekebilir const. İşte ücretsiz argümanı yayınlamadan uyarı veren bir kod örneği:

const float* velocity = malloc(2*sizeof(float));
free(velocity);

Ve derleyici (gcc 4.8.3) diyor ki:

main.c: In function ‘main’:
main.c:9:5: warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type [enabled by default]
     free(velocity);
     ^
In file included from main.c:2:0:
/usr/include/stdlib.h:482:13: note: expected ‘void *’ but argument is of type ‘const float *’
 extern void free (void *__ptr) __THROW;

Eğer free((float*) velocity);derleyici kullanırsanız şikayet durur.

Ön standart C hiçbir vardı void*ama sadece char*sen iletilen tüm parametreleri döküm zorunda. Eski C koduyla karşılaşırsanız, bu nedenle bu tür dökümleri bulabilirsiniz.

Referanslar ile benzer bir soru .

İlk C standart yayımlandığında, malloc ve ücretsiz olarak prototipleri sahip olmaktan değişti char*için void*hala bugün sahip oldukları.

Ve elbette standart C'de, bu tür dökümler gereksizdir ve sadece okunabilirliğe zarar verir.

İşte özgür oyuncu kadrosu olmadan başarısız olacak bir örnek:

volatile int* p = (volatile int*)malloc(5 * sizeof(int));
free(p);        // fail: warning C4090: 'function' : different 'volatile' qualifiers
free((int*)p);  // success :)
free((void*)p); // success :)

C'de bir uyarı alabilirsiniz (VS2012'de bir tane var). C ++ ile hata alırsınız.

Nadir durumlarda, döküm sadece kodu şişiriyor ...

Düzenleme: Ben başarısızlık demo void*değil döküm int*. Örtük int*olarak dönüştürülecekle aynı şekilde çalışacaktır void*. int*Kod eklendi .

Eski sebep: 1. kullanarak free((sometype*) ptr), işaretçi free()çağrının bir parçası olarak kabul edilmesi gereken tür hakkında kod açıktır . Açık döküm, free()bir (kendin yap) ile değiştirildiğinde yararlıdır DIY_free().

#define free(ptr) DIY_free(ptr, sizeof (*ptr))

A DIY_free(), özellikle hata ayıklama modunda, serbest bırakılan işaretçinin çalışma zamanı analizini yapmanın bir yoluydu. Bu genellikle bir DIY_malloc()cümle, küresel bellek kullanım sayısı, vb. Eklemek için eşleştirilir. Grubum, daha modern araçlar görünmeden önce bu tekniği yıllarca kullandı. Serbest bırakılan öğenin türüne aktarılması zorunlu olarak tahsis edildi.

2. Bellek sorunlarını, vb. İzlemek için harcanan uzun saatler göz önüne alındığında, türü serbest bırakmak gibi küçük hileler hata ayıklamanın aranmasına ve daraltılmasına yardımcı olacaktır.

Modern: Manos Nikolaidis @ ve @egur tarafından ele alındığı gibi kaçınma constve volatileuyarılar . Düşünce Ben 3 etkilerini dikkate olur elemeleri : , , ve .constvolatilerestrict

Eklenen [değiştir] char * restrict *rp2başına @R .. comment

void free_test(const char *cp, volatile char *vp, char * restrict rp, 
    char * restrict *rp2) {
  free(cp);  // warning
  free(vp);  // warning
  free(rp);  // OK
  free(rp2);  // warning
}

int main(void) {
  free_test(0,0,0,0);
  return 0;
}

İşte başka bir alternatif hipotez.

Programın C89 öncesi yazıldığı söyleniyor, bu da prototipiyle bir tür uyumsuzluk etrafında çalışamayacağı anlamına geliyor free, çünkü sadece C89 gibi bir şey constya da void *öncesi gibi bir şey yoktu. C89'dan önceki bir fonksiyon prototipi . stdlib.hkendisi komitenin bir buluşuydu. Sistem başlıkları freehiç beyan etmekten rahatsız olsaydı, bunu şu şekilde yaparlardı :

extern free();  /* no `void` return type either! */

Şimdi, buradaki kilit nokta, fonksiyon prototiplerinin yokluğunun, derleyicinin argüman tipi kontrolü yapmadığı anlamına gelmesidir . Varsayılan argüman promosyonlarını (varyasyon fonksiyon çağrıları için hala geçerli olanlar) uyguladı ve hepsi bu. Her çağrı sahasındaki argümanları callee'nin beklentileriyle örtüştürme sorumluluğu tamamen programcıya aittir .

Bununla birlikte, bu hala tartışmayı freeçoğu K&R derleyicisine atmanın gerekli olduğu anlamına gelmez . Gibi bir işlev

free_stuff(a, b, c)
    float *a;
    char *b;
    int *c;
{
    free(a);
    free(b);
    free(c);
}

doğru derlenmiş olmalıdır. Örneğin, bir ortam: Ne biz burada var alışılmadık çevre için bir arabası derleyici ile başa çıkmak için yazılmış bir programdır düşünüyorum Yani sizeof(float *) > sizeof(int)derleyici ve olmaz sen noktada onları döküm sürece göstericiler için uygun çağrıdüzenini kullanmak çağrı.

Böyle bir ortamın farkında değilim, ama bu bir ortam olmadığı anlamına gelmez. Akla gelen en muhtemel adaylar, 1980'lerin başında 8- ve 16-bit mikronlar için "küçük C" derleyicileri kesti. Erken Crays'in böyle problemleri olduğunu öğrenmek beni şaşırtmaz.

free parametresi yalnızca sabit olmayan işaretçileri alır. Bu nedenle, sabit işaretçiler durumunda, sabit olmayan bir işaretçiye açık döküm yapılması gerekir.

C'de sabit işaretçiler serbest bırakılamıyor