Malloc'un sonucunu atar mıyım?

Gelen bu soruya , birisi bir önerilen yorumun ı gerektiğini değil sonucunu döküm malloc, yani

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

ziyade:

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

Neden böyle olsun?

Hayır ; Eğer yok çünkü sonuç dökme:

• Bu durumda void *otomatik olarak ve güvenli bir şekilde diğer işaretçi türlerine yükseltildiği için gereksizdir .
• Koda karmaşa ekler, dökümlerin okunması çok kolay değildir (özellikle işaretçi türü uzunsa).
• Kendinizi tekrarlamanızı sağlar, bu genellikle kötüdür.
• Eklemeyi unuttuysanız bir hatayı gizleyebilir <stdlib.h>. Bu, çökmelere neden olabilir (veya daha da kötüsü, kodun tamamen farklı bir bölümünde ileride bir çökmeye neden olmaz ). İşaretçiler ve tamsayılar farklı boyutlarda olursa ne olacağını düşünün; yayınlayarak bir uyarıyı gizlersiniz ve iade ettiğiniz adresin bitlerini kaybedebilirsiniz. Not: C99'dan itibaren örtük işlevler C'den gitmiştir ve kayıt dışı işlevlerin geri döndüğü otomatik varsayımı olmadığından bu nokta artık geçerli değildir int.

Bir açıklama olarak, not dedim, değil "sen yok "Eğer döküm yok" ihtiyaç döküm için". Bence, doğru anlasanız bile oyuncu kadrosunu dahil etmek bir başarısızlık. Bunu yapmanın hiçbir faydası yoktur, ancak bir dizi potansiyel risk vardır ve oyuncu kadrosu dahil olmak, riskler hakkında bilmediğinizi gösterir.

Ayrıca, yorumcuların belirttiği gibi, yukarıdaki C ++ değil düz C hakkında konuştuğuna dikkat edin. C ve C ++ 'a ayrı diller olarak inanıyorum.

Daha fazla eklemek için kodunuz, inthatalara neden olabilecek tür bilgilerini ( ) gereksiz yere tekrarlar . İkisini birlikte "kilitlemek" için dönüş değerini saklamak için kullanılan işaretçiye atıfta bulunmak daha iyidir:

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

Bu ayrıca lengthdaha fazla görünürlük için ön tarafa doğru hareket eder ve gereksiz parantezleri sizeof; onlar sadece ihtiyaç vardır argüman bir tür adı olduğunda. Birçok insan bunu bilmiyor gibi görünüyor (veya görmezden geliyor), bu da kodlarını daha ayrıntılı hale getiriyor. Unutmayın: sizeofbir işlev değildir! :)

Taşırken lengthöne olabilecek bazı nadir durumlarda görünürlüğünü artırmak, bir de genel durumda, olarak ifade yazmak daha iyi olması gerektiğini dikkat etmelidir:

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

İlkini tutmak, sizeofbu durumda, çarpma en azından size_tmatematik ile yapılmasını sağlar .

Karşılaştırma: malloc(sizeof *sieve * length * width)vs malloc(length * width * sizeof *sieve)ikinci taşabilir length * widthzaman widthve lengthdaha küçük türleridir size_t.

C'de, dönüş değerini kullanmanıza gerek yoktur malloc. Tarafından döndürülen boşluk işaretçisi otomatik olarak mallocdoğru türe dönüştürülür. Ancak, kodunuzun bir C ++ derleyicisi ile derlenmesini istiyorsanız, bir döküm gerekir. Topluluk arasında tercih edilen bir alternatif aşağıdakileri kullanmaktır:

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

bu da türünü değiştirirseniz ifadenin sağ tarafını değiştirmek konusunda endişelenmenize gerek kalmaz sieve.

İnsanların işaret ettiği gibi, yayınlar kötüdür. Özellikle işaretçi atışları.

Sen yok , dökme, çünkü:

• Kodunuzu C ve C ++ arasında daha taşınabilir hale getirir ve SO deneyiminin gösterdiği gibi, birçok programcı gerçekten C ++ (veya C artı yerel derleyici uzantıları) yazarken C'de yazdıklarını iddia eder.
• Aksi halde bir hata gizleyebilirsiniz : notu yazmak için zaman kafa karıştırıcı tüm SO örnekleri type *karşı type **.
• Sizi #includeuygun bir başlık dosyasında başarısız olduğunuzu fark etmenizi engellediği fikri , ağaçlar için ormanı özlüyor . "Derleyiciden prototipleri görmekten şikayet etmesini istemediğiniz için endişelenmeyin - bu sinir bozucu stdlib.h hatırlanması gereken GERÇEK önemli şey!"
• Ekstra bilişsel bir çapraz kontrolü zorlar . İstenen (iddia edilen) türü, değişkenin ham boyutu için yaptığınız aritmetiğin hemen yanına koyar. Bahse girerim, malloc()bir döküm olduğunda hataların çok daha hızlı yakalandığını gösteren bir SO çalışması yapabilirsiniz . İddialarda olduğu gibi, niyeti ortaya çıkaran ek açıklamalar hataları azaltır.
• Kendinizi makinenin kontrol edebileceği bir şekilde tekrarlamak genellikle harika bir fikirdir. Aslında, bir iddia budur ve bu döküm kullanımı bir iddiadır. İddialar hala kodları düzeltmek için sahip olduğumuz en genel tekniktir, çünkü Turing yıllarca önce bu fikri ortaya attı.

Diğerlerinin belirttiği gibi, C için değil C ++ için gereklidir. C kodunuzu bir C ++ derleyicisiyle derleyeceğinizi düşünüyorsanız, herhangi bir nedenle, bir makro kullanabilirsiniz, örneğin:

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

Bu şekilde yine de çok kompakt bir şekilde yazabilirsiniz:

int *sieve = NEW(int, 1);

ve C ve C ++ için derlenir.

Gönderen Vikipedi :

Döküm avantajları

• Dökümün dahil edilmesi bir C programının veya fonksiyonunun C ++ olarak derlenmesine izin verebilir.

• Oyuncular, başlangıçta bir char * döndüren malloc'un 1989 öncesi sürümlerine izin veriyor.

• Döküm, özellikle işaretçi malloc () çağrısından uzakta bildirilirse, hedef işaretçi türünün değişmesi durumunda geliştiricinin tür boyutlandırmasındaki tutarsızlıkları tanımlamasına yardımcı olabilir.

Döküm için dezavantajlar

• ANSI C standardı altında, döküm yedeklidir.

• Oyuncunun eklenmesi stdlib.h üstbilgisini ekleyememeyi maskeleyebilirmalloc için prototip bulunur. Malloc için bir prototip olmadığında standart, C derleyicisinin malloc'un bir int döndürdüğünü varsaymasını gerektirir. Yayın yoksa, işaretçiye bu tamsayı atandığında bir uyarı verilir; ancak, oyuncu kadrosunda bu uyarı üretilmez ve bir hata gizlenir. Belirli mimarilerde ve veri modellerinde (uzun ve işaretçilerin 64 bit ve int 32 bit olduğu 64 bit sistemlerde LP64 gibi), dolaylı olarak bildirilen malloc 32- döndürdüğü için bu hata aslında tanımsız davranışa neden olabilir. gerçekte tanımlanan işlev 64 bit değerini döndürür. Arama kurallarına ve bellek düzenine bağlı olarak, bu durum yığın parçalanmasına neden olabilir. Modern derleyicilerin bu sorunun fark edilmemesi daha az olasıdır, çünkü kayıt dışı bir işlevin kullanıldığına dair uyarılar düzenli olarak üretildiğinden, bir uyarı görüntülenmeye devam edecektir. Örneğin, GCC'nin varsayılan davranışı, kadronun mevcut olup olmadığına bakılmaksızın "yerleşik işlevin uyumsuz örtülü bildirimi" yazan bir uyarı göstermektir.

• İşaretçinin türü bildiriminde değiştirilirse, malloc'un çağrıldığı ve yayınlandığı tüm satırların değiştirilmesi gerekebilir.

Her ne kadar döküm olmadan malloc tercih edilen yöntemdir ve en deneyimli programcılar seçmek , sen sorunların farkında olması gibi hangisi sizi kullanmalıdır.

yani: C programını C ++ olarak derlemeniz gerekiyorsa (her ne kadar ayrı bir dil olsa da) kullanım sonucunu vermelisiniz malloc.

C'de bir voidişaretçiyi başka bir işaretçiye dolaylı olarak dönüştürebilirsiniz , bu nedenle bir döküm gerekli değildir. Birini kullanmak, sıradan gözlemciye, bir kişinin neden gerekli olduğuna dair yanıltıcı olabilecek bir neden olduğunu önerebilir.

Malloc'un sonucunu kullanmazsınız, çünkü bunu yapmak kodunuza anlamsız bir karmaşa ekler.

İnsanların malloc sonucunu kullanmasının en yaygın nedeni, C dilinin nasıl çalıştığından emin olmamalarıdır. Bu bir uyarı işareti: Belirli bir dil mekanizmasının nasıl çalıştığını bilmiyorsanız, tahmin etmeyin . Bakın ya da Stack Overflow'da sorun.

Bazı yorumlar:

• Bir boş işaretçi, açık bir işaret (C11 6.3.2.3 ve 6.5.16.1) olmadan başka bir işaretçi türüne / bu işaretçi türünden dönüştürülebilir.

• Ancak C ++ void*ile başka bir işaretçi türü arasında örtük bir yayınlamaya izin verilmez . Yani C ++ 'da oyuncu kadrosu doğru olurdu. Ancak C ++ 'da program yaparsanız newmalloc () kullanmamalısınız. Ve C kodunu asla C ++ derleyicisi kullanarak derlememelisiniz.

  Hem C hem de C ++ 'ı aynı kaynak kodla desteklemeniz gerekiyorsa, farklılıkları işaretlemek için derleyici anahtarlarını kullanın. Her iki dil standardını da aynı kodla doyurmaya çalışmayın, çünkü bunlar uyumlu değildir.

• Üstbilgiyi eklemeyi unuttuğunuz için C derleyicisi bir işlev bulamazsa, bununla ilgili bir derleyici / bağlayıcı hatası alırsınız. Yani <stdlib.h>bu bir biggie eklemeyi unuttuysanız , programınızı oluşturamazsınız.

• 25 yıldan daha eski olan standardın bir versiyonunu takip eden eski derleyicilerde, dahil <stdlib.h>etmeyi unutmak tehlikeli davranışlara neden olacaktır. Çünkü bu eski standartta, görünür bir prototip olmadan işlevler dolaylı olarak dönüş türünü dönüştürür int. Sonuç malloc'dan açıkça yayınlandığında bu hata gizlenir.

  Ama bu gerçekten bir sorun değil. 25 yaşında bir bilgisayar kullanmıyorsunuz, neden 25 yaşında bir derleyici kullanıyorsunuz?

C de void *diğer (veri) imlecinden örtük bir dönüşüm elde edersiniz .

Tarafından döndürülen değeri yayınlama malloc() artık gerekli değil, ancak kimsenin işaret etmediği bir nokta eklemek istiyorum:

Önce eski günlerde olduğunu, ANSI C sağlar void *işaretçiler jenerik türü olarak, char *bu tür bir kullanım için türüdür. Bu durumda, oyuncu derleyici uyarılarını kapatabilir.

Referans: C SSS

Sadece deneyimlerimi ekleyerek, bilgisayar mühendisliği okuduğumda, C'de yazarken gördüğüm iki veya üç profesörün her zaman malloc oluşturduğunu görüyorum, ancak sorduğum (muazzam bir CV ve C anlayışı ile) bunun kesinlikle gereksiz olduğunu söyledi ama sadece mutlak olarak spesifikti ve öğrencileri mutlak özgüllük anlayışına soktu. Aslında döküm, nasıl çalıştığında hiçbir şeyi değiştirmez, tam olarak söylediği şeyi yapar, bellek ayırır ve döküm onu ​​etkilemez, aynı belleği alırsınız ve yanlışlıkla başka bir şeye dökseniz bile (ve bir şekilde derleyiciden kaçarsanız) C) buna aynı şekilde erişecektir.

Edit: Döküm belirli bir noktaya sahiptir. Dizi gösterimini kullandığınızda, oluşturulan kod bir sonraki öğenin başlangıcına ulaşmak için kaç bellek yeri ilerletmek zorunda olduğunu bilmek zorundadır, bu döküm yoluyla elde edilir. Bu şekilde bir çift için 8 bayt ileri giderken bir int için 4, vb. Bu nedenle işaretçi gösterimi kullanırsanız bir etkisi olmaz, dizi gösterimlerinde gerekli olur.

Sonuçlarının yayınlanması zorunlu değildir malloc, çünkü geri döner void*ve void*herhangi bir veri tipine işaret edilebilir.

Bir geçersiz işaretçi, genel bir nesne işaretleyicisidir ve C, bir boş işaretçi türünden diğer türlere örtük dönüştürmeyi destekler, bu nedenle açıkça yazımına gerek yoktur.

Ancak, aynı kodun örtülü dönüşümü desteklemeyen bir C ++ platformunda mükemmel uyumlu çalışmasını istiyorsanız, dakikayı yapmanız gerekir, bu nedenle her şey kullanılabilirliğe bağlıdır.

Bu nedir GNU C Kütüphanesi Başvuru kılavuzu diyor ki:

mallocISO C, türü void *gerektiğinde otomatik olarak başka bir işaretçi türüne dönüştürdüğü için , sonucu herhangi bir işaretçi değişkeni içinde herhangi bir işaretçi olmadan saklayabilirsiniz . Ancak, atama işleçleri dışındaki bağlamlarda veya kodunuzun geleneksel C'de çalışmasını istiyorsanız, oyuncu kadrosu gereklidir.

Ve gerçekten de ISO C11 standardı (p347) şöyle diyor:

Ayırma başarılı olursa döndürülen işaretçi, temel hizalama gereksinimi olan herhangi bir nesne türüne bir işaretçiye atanabilmesi için uygun şekilde hizalanır ve sonra ayrılan alandaki bu tür bir nesneye veya bu tür nesnelerden oluşan bir diziye erişmek için kullanılır ( boşluk açıkça yer değiştirmiştir)

Döndürülen tür geçersizdir *, kayıttan çıkarılabilir olması için istenen veri işaretçisine dönüştürülebilir.

C dilinde, herhangi bir işaretçiye bir geçersiz işaretçi atanabilir, bu nedenle bir tür döküm kullanmamalısınız. "Güvenli yaz" ayırması istiyorsanız, C projelerimde her zaman kullandığım aşağıdaki makro işlevlerini önerebilirim:

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

Bunlar yerinde olduğunda şunu söyleyebilirsiniz:

NEW_ARRAY(sieve, length);

Dinamik olmayan diziler için, üçüncü olması gereken işlev makrosu

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

dizi döngülerini daha güvenli ve kullanışlı hale getirir:

int i, a[100];

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

Programlama diline ve derleyiciye bağlıdır. mallocC dilinde kullanırsanız , otomatik olarak cast yazacağından cast yazmaya gerek yoktur. Ancak, C ++ kullanıyorsanız, mallocbir void*tür döndüreceği için cast yazmalısınız .

GCC ve Clang için kullanılan insanlar şımarık. Dışarıda o kadar iyi değil.

Kullandığım şaşırtıcı derecede yaşlı derleyiciler tarafından yıllar boyunca oldukça dehşete düştüm. Genellikle şirketler ve yöneticiler, derleyicileri değiştirmek için ultra muhafazakar bir yaklaşım benimser ve hatta test etmezler. yeni bir derleyicinin (daha iyi standartlara uygunluk ve kod optimizasyonu ile) sistemlerinde çalışıp çalışmayacağını . Çalışan geliştiriciler için pratik gerçeklik, kodlama yaparken üslerinizi örtmeniz gerektiğidir ve ne yazık ki, kodunuza hangi derleyicinin uygulanabileceğini kontrol edemiyorsanız mallokları dökmek iyi bir alışkanlıktır.

Birçok kuruluş kendilerine ait bir kodlama standardı geçerli olduğunu ben de öneririm ve o bu o tanımlanmışsa yöntem insanların takip olmalıdır. Açık rehberliğin yokluğunda, bir standarda körü körüne bağlı kalmak yerine, her yerde derleme eğilimindeyim.

Mevcut standartlar altında gerekli olmadığı iddiası oldukça geçerlidir. Ancak bu argüman gerçek dünyanın pratikliklerini atlıyor. Biz sadece günün standardı tarafından yönetilen bir dünyada değil, "yerel yönetimin gerçeklik alanı" olarak adlandırmayı sevdiğim şeylerin pratiklikleri ile kod yazıyoruz. Ve bu, uzay zamanından daha fazla bükülmüş ve bükülmüş. :-)

YMMV.

Malloc dökümünü savunma operasyonu olarak düşünmeye meyilliyim. Hoş değil, mükemmel değil, ama genellikle güvenli. (Sonra stdlib.h dahil değildir verdiyseniz Dürüstçe, ettik yolu malloc döküm daha fazla probleme!).

Ben sadece kötü dönüşüm getirmek için hiçbir döküm kullanılmasa bile, aşağıdaki snippet gibi kodun tanı olmadan derlemek için izin verir, tür sistemindeki çirkin deliğin onaylanmamış göstermek için döküm koymak:

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

Keşke var olmasaydı (ve C ++ 'da yok) ve bu yüzden yaptım. Zevkimi ve programlama politikamı temsil ediyor. Sadece bir işaretçi değil, etkili bir şekilde, bir oy pusulası ve aptallık şeytanlarını atıyorum . Eğer gerçekten aptallık yapamıyorsam , en azından bunu bir protesto hareketiyle dile getirmeme izin ver.

Aslında, iyi bir uygulama, malloc(ve arkadaşlarınızı) geri dönen işlevlerle unsigned char *sarmaktır ve temelde asla void *kodunuzda kullanılmaz. Herhangi bir nesneye genel bir işaretçi gerekiyorsa, bir char *veya kullanın unsigned char *ve her iki yönde de yayınlar yapın. Şımartılabilecek bir rahatlama, belki de, döküm gibi memsetve memcpyolmadan işlevler kullanmaktır .

Bunu kodunuzu yazarsanız döküm ve C ++ uyumluluğu konusunda, o C ve C hem ++ (bu durumda siz derler zorunda dönüş değer dağıtmak mallocdışında bir şeye atarken void *), çok yararlı yapabilirsiniz kendiniz için bir şey: C ++ olarak derlenirken C ++ stil dökümlerine dönüşen ancak C olarak derlerken C dökümüne indirgeyen döküm için makrolar kullanabilirsiniz:

/* 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

Bu makrolara bağlı kalırsanız, grepbu tanımlayıcılar için kod tabanınızda yapılan basit bir arama size tüm yayınlarınızın nerede olduğunu gösterir, böylece bunlardan herhangi birinin yanlış olup olmadığını inceleyebilirsiniz.

Daha sonra, kodu düzenli olarak C ++ ile derlerseniz, uygun bir dökümün kullanımını zorlar. Örneğin, strip_qualyalnızca bir constveya öğesini kaldırmak için kullanırsanız volatile, ancak program şimdi bir tür dönüştürmenin yer alacağı şekilde değişirse, bir tanı alırsınız ve istenen dönüşümü elde etmek için bir dizi kombinasyonu kullanmanız gerekir.

Bu makrolara uymanıza yardımcı olmak için, GNU C ++ (C! Değil) derleyicisinin güzel bir özelliği vardır: C stili yayınların tüm oluşumları için üretilen isteğe bağlı bir tanılama.

     -Wold stili döküm (yalnızca C ++ ve Objective-C ++)
         Boş olmayan bir türe dökülen eski bir stil (C stili) kullanılıyorsa uyar
         C ++ programında. Yeni stil yayınları (dynamic_cast,
         static_cast, reinterpret_cast ve const_cast) daha az savunmasız
         istenmeyen etkileri ve aramak çok daha kolay.

C kodunuz C ++ olarak derleniyorsa, bu -Wold-style-castseçeneği (type), kodun içine girebilecek döküm sözdiziminin tüm örneklerini bulmak ve yukarıdaki makrolar (veya bir gerekirse kombinasyon).

Dönüşümlerin bu tedavisi, bir "Temiz C" de çalışmak için tek ve en büyük bağımsız teknik gerekçedir: kombine C ve C ++ lehçesi, bu da teknik olarak dönüş değerinin dökülmesini haklı çıkarır malloc.

Mümkün olduğunda C dilinde programlama yaparken yapılacak en iyi şey:

1. Programınızın tüm uyarılar açıkken bir C derleyicisi aracılığıyla derlenmesini sağlayın -Wallve tüm hataları ve uyarıları düzeltin
2. Olarak tanımlanmış değişken olmadığından emin olun auto
3. Sonra -Wallve ile bir C ++ derleyicisi kullanarak derleyin -std=c++11. Tüm hataları ve uyarıları düzeltin.
4. Şimdi C derleyicisini kullanarak tekrar derleyin. Programınız artık herhangi bir uyarı yapmadan derlenmeli ve daha az hata içermelidir.

Bu prosedür, C ++ katı tip kontrolünden yararlanmanızı sağlar, böylece hata sayısını azaltır. Özellikle, bu prosedür sizi dahil etmeye zorlar stdlib.hveya alırsınız

malloc bu kapsamda beyan edilmedi

ve ayrıca sonucunu yayınlamanız için sizi zorlar mallocveya

Geçersiz dönüşüm void*içinT*

veya hedef türünüz ne olursa olsun.

Bulabildiğim C ++ yerine C ile yazmanın tek faydası

1. C iyi belirlenmiş bir ABI'ye sahiptir
2. C ++ daha fazla kod oluşturabilir [istisnalar, RTTI, şablonlar, çalışma zamanı polimorfizmi]

Statik polimorfik özellik ile birlikte C için ortak alt kümeyi kullanırken ikinci eksilerin ideal durumda kaybolması gerektiğine dikkat edin .

C ++ katı kurallarını uygunsuz bulanlar için, C ++ 11 özelliğini çıkarım türüyle kullanabiliriz

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

Hayır, sonucunu yayınlamıyorsunuz malloc().

Genel olarak, yayın yapamaz veya yayın yapamazsınızvoid * .

Bunu yapmamak için verilen tipik bir sebep, başarısızlığın #include <stdlib.h>fark edilmeyebilmesidir. C99, örtük işlev bildirimlerini yasadışı hale getirdiğinden , bu uzun bir süredir sorun değil , bu nedenle derleyiciniz en az C99'a uyuyorsa, bir tanı mesajı alırsınız.

Ancak gereksiz işaretçi atımlarını tanıtmamak için çok daha güçlü bir neden var :

C'de bir işaretçi kadrosu neredeyse her zaman bir hatadır . Bunun nedeni aşağıdaki kuraldır ( C11 için son taslak olan N1570'te §6.5 p7 ):

Bir nesnenin depolanmış değerine yalnızca aşağıdaki türlerden birine sahip bir değer değeri ifadesiyle erişilir:
- nesnenin
etkili türüyle uyumlu bir tür,
- nesnenin etkili türüyle uyumlu bir türün nitelikli bir sürümü, - nesnenin etkili türüne karşılık gelen
imzalı veya imzasız tür olan bir tür,
- nesnenin etkili türünün nitelikli bir sürümüne karşılık gelen imzalı veya imzasız tür olan bir tür, üyeleri arasında yukarıda belirtilen türlerin (özyinelemeli olarak bir alt küme veya içerdiği birliğin bir üyesi dahil) veya
- bir karakter türü.

Bu aynı zamanda katı takma adlandırma kuralı olarak da bilinir . Yani aşağıdaki kod tanımsız davranış :

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

Ve bazen şaşırtıcı bir şekilde aşağıdakiler de geçerlidir:

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;

Bazen, do dökme işaretçiler gerekir, ancak verilen sıkı örtüşme kuralı , onunla çok dikkatli olmak zorunda. Bu nedenle, kodunuzda bir işaretçi kademesi oluşması , geçerliliğini iki kez kontrol etmeniz gereken bir yerdir . Bu nedenle, asla gereksiz bir işaretçi kadrosu yazmazsınız.

tl; Dr.

Özetle: C'de, bir işaretçi kadrosunun herhangi bir oluşumu, özel dikkat gerektiren kod için kırmızı bir bayrak kaldırmalıdır, asla gereksiz işaretçi atmaları yazmamalısınız.

Yan notlar:

• Aslında durumlar vardır gerek bir döküm yapılmasını void *Eğer bir işaretçi yazdırmak istiyorsanız, örneğin:

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

  Oyuncular burada gereklidir, çünkü printf()değişken bir işlevdir, bu nedenle örtük dönüşümler işe yaramaz.

• C ++ 'da durum farklıdır. İşaretçi türlerinin seçilmesi, türetilmiş sınıfların nesneleriyle uğraşırken biraz yaygındır (ve doğrudur). Bu nedenle, C ++, ve dönüştürme mantıklı void *olduğunu değil örtük. C ++, farklı döküm lezzetlerine sahiptir.

Oyuncu kadrosunu yapmayı tercih ederim, ama elle yapmamayı En sevdiğim glib'den g_newve g_new0makroları kullanmak . Eğer glib kullanılmazsa, benzer makrolar eklerdim. Bu makrolar, tür güvenliğinden ödün vermeden kod çoğaltmayı azaltır. Türü yanlış alırsanız, bir uyarı (C ++ hata) hataya neden olmayan geçersiz işaretçiler arasında örtülü bir döküm alırsınız. Tanımlayan üstbilgiyi eklemeyi unutursanız g_newve g_new0bir hata alırsınız. g_newve g_new0her ikisi de aynı argümanları mallocalır , aksine bu daha az argüman alır calloc. 0Sıfır başlangıçlı bellek almak için ekleyin . Kod değişiklik yapılmadan bir C ++ derleyicisi ile derlenebilir.

Döküm sadece C ++ değil C içindir.

Geçersiz işaretçinin arkasındaki kavram, herhangi bir veri türüne dökülebilmesidir, bu nedenle malloc geçersizdir. Ayrıca otomatik tiplemenin de farkında olmalısınız. Bu yüzden işaretçiyi yapmak zorunda olmanız şart değildir. Kodun temiz tutulmasına yardımcı olur ve hata ayıklamaya yardımcı olur

Bir geçersiz işaretçi genel bir işaretleyicidir ve C, bir boş işaretçi türünden diğer türlere örtük dönüştürmeyi destekler, bu nedenle açıkça yazımına gerek yoktur.

Ancak, aynı kodun örtülü dönüşümü desteklemeyen bir C ++ platformunda mükemmel uyumlu çalışmasını istiyorsanız, dakikayı yapmanız gerekir, bu nedenle her şey kullanılabilirliğe bağlıdır.

1. Diğer belirtildiği gibi, C için değil, C ++ için gereklidir.

2. Dökümün dahil edilmesi bir C programının veya fonksiyonunun C ++ olarak derlenmesine izin verebilir.

3. C'de gereksizdir, çünkü void * otomatik olarak ve diğer herhangi bir işaretçi türüne güvenli bir şekilde yükseltilir.

4. Ancak o zaman yayın yaparsanız, stdlib.h dosyasını eklemeyi unuttuysanız bir hatayı gizleyebilir . Bu, çökmelere neden olabilir (veya daha da kötüsü, kodun tamamen farklı bir bölümünde ileride bir çökmeye neden olmaz).

   Çünkü stdlib.h malloc için prototip içeriyor. Malloc için bir prototip olmadığında standart, C derleyicisinin malloc'un bir int döndürdüğünü varsaymasını gerektirir. Yayın yoksa, işaretçiye bu tamsayı atandığında bir uyarı verilir; ancak, oyuncu kadrosunda bu uyarı üretilmez ve bir hata gizlenir.

Mallocun dökümü C'de gereksiz, ancak C ++ 'da zorunludur.

C'de döküm yapmak gereksizdir:

• void * C durumunda otomatik olarak ve güvenli bir şekilde diğer işaretçi türlerine yükseltilir.
• Eklemeyi unuttuysanız bir hatayı gizleyebilir <stdlib.h>. Bu çökmelere neden olabilir.
• İşaretçiler ve tamsayılar farklı boyutlara sahipse, bir uyarıyı yayınlayarak gizlersiniz ve iade ettiğiniz adresin bitlerini kaybedebilirsiniz.
• İşaretçinin türü bildiriminde değiştirilirse malloc, çağrılan ve yayınlanan tüm satırları da değiştirmeniz gerekebilir .

Öte yandan, döküm programınızın taşınabilirliğini artırabilir. yani, bir C programının veya fonksiyonunun C ++ olarak derlenmesini sağlar.

Benim için, eve götürmek ve sonuç malloc, C'de dökümün tamamen gerekli DEĞİLDİR, ancak eğer yayınlarsanız , yine de size talep edilen kutsanmış hafıza alanınızı tahsis edeceği mallocgibi etkilemeyecektir malloc. Başka bir eve götürmek, insanların döküm yapmasının nedeni veya nedenlerinden biridir ve bu, aynı programı C veya C ++ 'da derlemelerini sağlamaktır.

Başka nedenler olabilir, ancak diğer nedenler, kesinlikle, er ya da geç ciddi bir belaya neden olur.

Yapabilirsiniz, ancak C'ye basmanız gerekmez. Bu kod C ++ olarak derlenmişse yayınlamanız gerekir.