Fonksiyon parametreleri için 'const' kullanımı

Ne kadar uzağa gidiyorsun const? Sadece constgerektiğinde işlevler mi yapıyorsunuz yoksa tüm domuzu alıp her yerde mi kullanıyorsunuz? Örneğin, tek bir boolean parametresi alan basit bir mutator düşünün:

void SetValue(const bool b) { my_val_ = b; }

Bu constgerçekten faydalı mı? Şahsen, parametreler de dahil olmak üzere yaygın olarak kullanmayı tercih ediyorum, ancak bu durumda bunun değerli olup olmadığını merak ediyorum?

constBir işlev bildirimindeki parametrelerden atlayabileceğinizi , ancak işlev tanımına dahil edebileceğinizi öğrenmek için şaşırdım , örneğin:

.h dosyası

void func(int n, long l);

.cpp dosyası

void func(const int n, const long l)

Bunun bir sebebi var mı? Bana biraz alışılmadık geliyor.

Bunun nedeni, verilerin bir kopyası üzerinde çalıştığı için, parametrenin sabitinin yalnızca işlev içinde yerel olarak geçerli olmasıdır. Bu, işlev imzasının gerçekten de aynı olduğu anlamına gelir. Yine de bunu çok yapmak muhtemelen kötü bir stil.

Ben şahsen referans ve işaretçi parametreleri dışında const kullanma eğilimindedir. Kopyalanan nesneler için bu gerçekten önemli değildir, ancak işlev içinde niyet sinyali verdiğinden daha güvenli olabilir. Bu gerçekten bir karar çağrısı. Ben bir şey üzerinde döngü yaparken const_iterator kullanmaya eğilimindedir ve ben bunu değiştirmek niyetinde değilim, bu yüzden referans türleri için const doğruluğu titizlikle korunur sürece her biri kendi sanırım.

msgstr "arayanın nesnesini değiştirmeyeceğiniz için argüman değere göre iletildiğinde const anlamsız."

Yanlış.

Bu, kodunuzu ve varsayımlarınızı kendiniz belgelemeyle ilgilidir.

Kodunuz üzerinde çalışan birçok kişi varsa ve işlevleriniz önemsiz değilse, "const" i işaretleyebilirsiniz. Endüstriyel güç kodunu yazarken, her zaman iş arkadaşlarınızın sizi mümkün olan her şekilde elde etmeye çalışan psikopatlar olduğunu varsaymalısınız (özellikle gelecekte genellikle kendiniz olduğundan).

Ayrıca, daha önce de belirtildiği gibi, derleyicinin işleri biraz optimize etmesine yardımcı olabilir (uzun bir çekim olmasına rağmen).

Bazen (çok sık!) Başkasının C ++ kodunu çözmek zorundayım. Ve hepimiz bir başkasının C ++ kodunun neredeyse tanım gereği tam bir karmaşa olduğunu biliyoruz :) Yani yerel veri akışını deşifre etmek için yaptığım ilk şey derleyici havlayana kadar her değişken tanımında const koymak . Bu da const niteleyici değer argümanları anlamına gelir, çünkü bunlar sadece arayan tarafından başlatılan süslü yerel değişkenlerdir.

Ah, keşke değişkenler varsayılan olarak sabit olsaydı ve sabit olmayan değişkenler için değiştirilebilir gerekli :)

Aşağıdaki iki çizgi işlevsel olarak eşdeğerdir:

int foo (int a);
int foo (const int a);

Açıkçası , ikinci şekilde tanımlanmışsa, avücutta değişiklik yapamazsınız foo, ancak dışarıdan bir fark yoktur.

Nerede const gerçekten referans veya işaretçi parametreleri ile kullanışlı geliyor:

int foo (const BigStruct &a);
int foo (const BigStruct *a);

Bunun söylediği şey, foo'nun büyük bir parametre, belki de gigabayt boyutundaki bir veri yapısını kopyalamaksızın alabilmesi. Ayrıca, arayan kişiye "Foo * bu parametrenin içeriğini değiştirmeyecektir" der. Bir const referansı geçmek, derleyicinin belirli performans kararları vermesine de izin verir.

*: Sabitliği bozmadıkça, ama bu başka bir gönderi.

Ekstra Gereksiz const, bir API açısından kötüdür:

Değerden geçirilen gerçek tip parametreler için kodunuza fazladan gereksiz const koymak, API'nızı arayarak API veya API kullanıcısına anlamlı bir söz vermez (yalnızca uygulamayı engeller).

Bir API'de ihtiyaç duyulmadığında çok fazla 'const' " ağlayan kurt " gibidir, sonunda insanlar 'const'u görmezden gelmeye başlar, çünkü her yerde vardır ve çoğu zaman hiçbir şey ifade etmez.

API'da ekstra consts için "reductio ad absurdum" argümanı, bu ilk iki nokta için iyidir, daha fazla const parametresi iyi ise, o zaman bir const olabilecek her argümanın üzerinde bir const olması gerekir. Aslında, gerçekten iyi olsaydı, const'un parametreler için varsayılan olmasını ve yalnızca parametreyi değiştirmek istediğinizde "mutable" gibi bir anahtar kelimeye sahip olmasını istersiniz.

Yani, mümkün olan her yerde const koymayı deneyelim:

void mungerum(char * buffer, const char * mask, int count);

void mungerum(char * const buffer, const char * const mask, const int count);

Yukarıdaki kod satırını düşünün. Beyan sadece daha karmaşık ve uzun ve okunması daha zor olmakla kalmaz, aynı zamanda dört 'const' anahtar kelimeden üçü API kullanıcısı tarafından güvenli bir şekilde göz ardı edilebilir. Bununla birlikte, 'const'un ekstra kullanımı ikinci satırı potansiyel olarak TEHLİKELİ hale getirdi !

Neden?

İlk parametrenin hızlı bir şekilde yanlış okunması char * const buffer, aktarılan veri arabelleğindeki belleği değiştirmeyeceğini düşünmenizi sağlayabilir - ancak bu doğru değildir! Gereksiz 'const', hızlı bir şekilde tarandığında veya yanlış okunduğunda API'nız hakkında tehlikeli ve yanlış varsayımlara yol açabilir .

Gereksiz yapı, Kod Uygulama açısından da kötüdür:

#if FLEXIBLE_IMPLEMENTATION
       #define SUPERFLUOUS_CONST
#else
       #define SUPERFLUOUS_CONST             const
#endif

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count);

FLEXIBLE_IMPLEMENTATION doğru değilse, API işlevi ilk yoldan uygulamaya koymamak için “umut vericidir”.

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       // Will break if !FLEXIBLE_IMPLEMENTATION
       while(count--)
       {
              *dest++=*source++;
       }
}

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       for(int i=0;i<count;i++)
       {
              dest[i]=source[i];
       }
}

Bu çok aptalca bir söz. Neden arayana hiç fayda sağlamayan ve sadece uygulamanızı sınırlandıran bir söz vermelisiniz?

Bunların her ikisi de aynı işlevin mükemmel geçerli uygulamalarıdır, ancak yaptığınız tek şey gereksiz yere bir elinizin arkasına bağlanmıştır.

Dahası, kolayca (ve yasal olarak atlatılmış) çok sığ bir vaattir.

inline void bytecopyWrapped(char * dest,
   const char *source, int count)
{
       while(count--)
       {
              *dest++=*source++;
       }
}
void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source,SUPERFLUOUS_CONST int count)
{
    bytecopyWrapped(dest, source, count);
}

Bakın, sadece bir sarmalayıcı işlevini kullanmamaya söz vermiş olsam da bu şekilde uyguladım. Kötü adam bir filmdeki birini öldürmemeye söz verdiği ve onun adamına onları öldürmesini emrettiği zamanki gibi.

Bu gereksiz yapılar, kötü adam filminden bir vaatten daha değerli değildir.

Ancak yalan söyleme yeteneği daha da kötüleşir:

Ben sahte const kullanarak üstbilgi (bildirim) ve kod (tanım) const uyumsuz aydınlandı. Const-happy savunucuları bunun iyi bir şey olduğunu iddia ediyor çünkü const'u sadece tanımına koymanıza izin veriyor.

// Example of const only in definition, not declaration
class foo { void test(int *pi); };
void foo::test(int * const pi) { }

Ancak, tersi doğrudur ... sadece beyanda sahte bir sabit koyabilir ve tanımda görmezden gelebilirsiniz. Bu, bir API'daki gereksiz konstrüksiyonu daha korkunç bir şey ve korkunç bir yalan haline getirir - bu örneğe bakın:

class foo
{
    void test(int * const pi);
};

void foo::test(int *pi) // Look, the const in the definition is so superfluous I can ignore it here
{
    pi++;  // I promised in my definition I wouldn't modify this
}

Gereksiz tüm yapı, değişkeni değiştirmek veya değişkeni sabit olmayan referansla geçirmek istediğinde, başka bir yerel kopyayı veya bir sarmalayıcı işlevini kullanmaya zorlayarak uygulayıcının kodunu daha az okunabilir hale getirmektir.

Bu örneğe bakın. Hangisi daha okunabilir? İkinci fonksiyondaki ekstra değişkenin tek sebebinin, bazı API tasarımcılarının gereksiz bir yapıya atması olduğu açık mı?

struct llist
{
    llist * next;
};

void walkllist(llist *plist)
{
    llist *pnext;
    while(plist)
    {
        pnext=plist->next;
        walk(plist);
        plist=pnext;    // This line wouldn't compile if plist was const
    }
}

void walkllist(llist * SUPERFLUOUS_CONST plist)
{
    llist * pnotconst=plist;
    llist *pnext;
    while(pnotconst)
    {
        pnext=pnotconst->next;
        walk(pnotconst);
        pnotconst=pnext;
    }
}

İnşallah burada bir şeyler öğrendik. Gereksiz yapı, bir API-dağınıklık gözü, sinir bozucu bir nag, sığ ve anlamsız bir vaat, gereksiz bir engeldir ve bazen çok tehlikeli hatalara yol açar.

const, C ++ 'da varsayılan olmalıdır. Bunun gibi :

int i = 5 ; // i is a constant

var int i = 5 ; // i is a real variable

C ++ 'ı bir yaşam için kodladığımda, yapabileceğim her şeyi düşündüm. Const kullanmak, derleyicinin size yardımcı olması için harika bir yoldur. Örneğin, yöntem döndürme değerlerinizi korumak sizi aşağıdaki gibi yazım hatalarından kurtarabilir:

foo() = 42

ne demek istiyorsan:

foo() == 42

Const olmayan bir başvuru döndürmek için foo () tanımlanmışsa:

int& foo() { /* ... */ }

Derleyici, işlev çağrısı tarafından döndürülen anonim geçici dosyaya bir değer atamanıza izin verir. Sabit yapma:

const int& foo() { /* ... */ }

Bu olasılığı ortadan kaldırır.

Burada yönetilen comp.lang.c ++ 'ın eski "Haftanın Guru" makalelerinde bu konuda iyi bir tartışma var .

İlgili GOTW makalesine Herb Sutter'in web sitesinden ulaşabilirsiniz .

Ben senin const değer parametrelerinizi söylüyorum.

Bu araç işlevini düşünün:

bool isZero(int number)
{
  if (number = 0)  // whoops, should be number == 0
    return true;
  else
    return false;
}

Number parametresi const olsaydı, derleyici durur ve bizi hata konusunda uyarırdı.

Ben sadece [in] veri ve işlev tarafından değiştirilmez referanslar (veya işaretçiler) olan işlev parametreleri üzerinde const kullanın. Bir referans kullanmanın amacı, verilerin kopyalanmasını önlemek ve iletilen parametrenin değiştirilmesine izin vermemektir.

Örneğinizde boolean b parametresine const koymak yalnızca uygulamaya bir kısıtlama getirir ve sınıfın arabirimine katkıda bulunmaz (parametreleri değiştirmemeniz önerilir).

İçin işlev imzası

void foo(int a);

ve

void foo(const int a);

aynıdır, bu da .c ve .h'nizi açıklar

Asaf

Eğer kullanırsanız ->*veya.* operatörleri, bu bir zorunluluktur.

Gibi bir şey yazmanızı engeller

void foo(Bar *p) { if (++p->*member > 0) { ... } }

ki şu anda neredeyse yaptım ve muhtemelen niyetini yapmıyorsun.

Söylemek istediğim

void foo(Bar *p) { if (++(p->*member) > 0) { ... } }

Ben koymuştu ve eğer constaradaki Bar *ve p, derleyici bana bunu söylerdi.

Ah, zor biri. Bir tarafta, bir açıklama bir sözleşmedir ve bir sabit argümanı değere göre geçmek gerçekten mantıklı değildir. Öte yandan, işlev uygulamasına bakarsanız, bir bağımsız değişken sabiti bildirirseniz derleyiciye en iyi duruma getirme şansı verirsiniz.

const, arayanın nesnesini değiştirmeyeceğiniz için bağımsız değişken değere iletildiğinde anlamsızdır.

const, işlevin amacı aktarılan değeri değiştirmek olmadığı sürece referans ile geçerken tercih edilmelidir.

Son olarak, geçerli nesneyi (bu) değiştirmeyen bir işlev sabit olabilir ve muhtemelen bildirilmelidir. Aşağıda bir örnek verilmiştir:

int SomeClass::GetValue() const {return m_internalValue;}

Bu, bu çağrının uygulandığı nesneyi değiştirmeme vaadidir. Başka bir deyişle, şunları arayabilirsiniz:

const SomeClass* pSomeClass;
pSomeClass->GetValue();

Eğer işlev sabit değilse, bu bir derleyici uyarısına neden olur.

Değer parametrelerini 'const' olarak işaretlemek kesinlikle öznel bir şeydir.

Ancak ben aslında örnekte olduğu gibi const değer parametrelerini işaretlemeyi tercih ederim.

void func(const int n, const long l) { /* ... */ }

Bana verilen değer, işlev parametre değerlerinin işlev tarafından hiçbir zaman değiştirilmediğini açıkça göstermektedir. Başlangıçta sonunda olduğu gibi aynı değere sahip olacaklar. Benim için çok işlevsel bir programlama tarzına uymanın bir parçası.

Kısa bir işlev için, argümanların işlev tarafından değiştirilmediği genellikle açıktır, çünkü orada 'const' olması muhtemelen zaman / alan kaybıdır.

Bununla birlikte, daha büyük bir işlev için, bir uygulama belgesi biçimidir ve derleyici tarafından uygulanır.

'N' ve 'l' ile bir hesaplama yaparsam, farklı bir sonuç alma korkusu olmadan bu hesaplamayı yeniden düzenleyebilir / taşıyabilirim çünkü bir veya her ikisinin de değiştiği bir yeri kaçırdım.

Bir uygulama ayrıntısı olduğundan, tıpkı uygulamada kullanılanlarla aynı adlara sahip işlev parametrelerini bildirmeniz gerekmediği gibi, başlıktaki const değer parametrelerini bildirmeniz gerekmez.

Bu geçerli bir argüman olmayabilir. ancak bir işlev derleyicisinin içindeki bir const değişkeninin değerini artırırsak, bize bir hata verir: " hata: salt okunur parametrenin artışı ". yani bu, const anahtar sözcüğünü, işlevler içindeki değişkenlerimizi yanlışlıkla değiştirmeyi önlemenin bir yolu olarak kullanabileceğimiz anlamına gelir. yani derleme zamanında bunu yaparsak derleyici bunu bize bildirir. bu proje üzerinde çalışan tek kişi siz değilseniz bu özellikle önemlidir.

Mümkün olan yerlerde const kullanma eğilimindeyim. (Ya da hedef dil için uygun başka bir anahtar kelime.) Bunu sadece derleyicinin başka türlü yapamayacağı ekstra optimizasyonlar yapmasına izin verdiği için yapıyorum. Bu optimizasyonların ne olabileceği hakkında hiçbir fikrim olmadığından, aptal göründüğü yerlerde bile her zaman yaparım.

Bildiğim kadarıyla, derleyici bir const değeri parametresini çok iyi görebilir ve "Hey, bu işlev zaten değiştirmiyor, bu yüzden referansla geçebilir ve bazı saat döngülerini kaydedebilirim" diyebilir. İşlev imzasını değiştirdiği için böyle bir şey yapacağını sanmıyorum, ama bu noktaya değiniyor. Belki farklı yığın manipülasyonu falan yapar ... Mesele şu ki, bilmiyorum, ama derleyicinin sadece utanmamıza yol açtığından daha akıllı olmaya çalışıyorum.

C ++, doğruluk fikri ile bazı ekstra bagajlara sahiptir, bu yüzden daha da önemli hale gelir.

1. Değerlendirmeme dayalı en iyi cevap:

@Adisak'ın cevabı, değerlendirmeme dayanarak en iyi cevap. Not aynı zamanda, çünkü bu cevabı en iyi parçası olduğunu en iyi destekli gerçek kod örnekleri ile , ses ve iyi düşünülmüş mantığını kullanarak ek olarak.

2. Kendi sözlerim (en iyi yanıtı kabul ederek):

1. By-pass değeri için katmanın bir yararı yoktur const. Tek yaptığı:
   1. uygulayıcıyı, kaynak kodundaki bir giriş parametresini her değiştirmek istediklerinde bir kopya yapmak zorunda bırakmakla sınırlandırın (geçirilen değer, zaten by-pass değeri olduğundan zaten bir kopya olduğundan, bu değişikliğin herhangi bir yan etkisi olmayacaktır). Sıklıkla, değerin iletildiği bir giriş parametresinin değiştirilmesi işlevi uygulamak için kullanılır, böylece consther yere eklemek bunu engelleyebilir.
   2. ve constkodun consther yerde gereksiz yere eklenmesi const, güvenli kod olması için gerçekten gerekli olan şeylerden dikkat çekmektir .
2. İle uğraşırken işaretçiler veya referanslar , ancak, constgerekli ve ne zaman çok önemlidir gerekir kullanılabilir persistan değişikliklerle istenmeyen yan etkileri engeller olarak, dış fonksiyonu ve dolayısıyla her bir işaretçi veya referans gerekir kullanmak constPARM bir giriş sadece olduğunda, çıktı değil. kullanmaconst Yalnızca referans veya işaretçi tarafından geçirilen parametrelerde , hangi parametrelerin işaretçi veya referans olduğunu gerçekten belirgin hale getirmenin ek bir yararı vardır. Dışarı çıkıp "Dikkat et! constYanındaki herhangi bir parametre bir referans veya işaretçi!" Demek için bir şey daha var .
3. Yukarıda tarif ettiğim, sıklıkla çalıştığım profesyonel yazılım kuruluşlarında sağlanan fikir birliği oldu ve en iyi uygulama olarak görülüyordu. Bazen bile, kural katıdır: "değere göre iletilen parametrelerde sabit kullanmayın, ancak yalnızca girdilerse her zaman başvuru veya işaretçi tarafından geçirilen parametrelerde kullanın."

3. Google'ın kelimeleri (benimle ve en iyi yanıtı kabul ederek):

(" Google C ++ Stil Kılavuzu " ndan)

Değere göre iletilen bir işlev parametresi için const'ın arayan üzerinde hiçbir etkisi yoktur, bu nedenle işlev bildirimlerinde önerilmez. Bkz. TotW # 109 .

Yerel değişkenler üzerinde const kullanımı ne cesaretlendirilir ne de cesaret kırılır.

Kaynak: Google C ++ Stil Kılavuzu'nun "Sabit kullanım" bölümü: https://google.github.io/styleguide/cppguide.html#Use_of_const . Bu aslında gerçekten değerli bir bölüm, bu yüzden tüm bölümü okuyun.

"TotW # 109" un "Haftanın İpucu # 109: constİşlev Beyanlarında Anlamlı " anlamına geldiğini ve aynı zamanda yararlı bir okuma olduğunu unutmayın. Daha bilgilendirici ve yapılması gerekenler konusunda daha az kuralcı ve geldi bağlamına dayalı olduğu daha önce Google C ++ Stil Kılavuzu kuralconst yukarıda alıntılanan , ancak sağladığı netliğin bir sonucu olarak, constyukarıda alıntılanan kural Google C ++ 'a eklendi Stil rehberi.

Ayrıca, konumumu savunmak için burada Google C ++ Stil Kılavuzu'ndan alıntı yapmama rağmen, her zaman kılavuzu takip ettiğim veya her zaman kılavuzu takip etmeyi önermediğim anlamına gelmez. Tavsiye ettikleri şeylerden bazıları, "Sabit İsimler" için kendi kDaysInAWeekstil adlandırma kuralları gibi, sadece garip . Bununla birlikte, dünyanın en başarılı ve etkili teknik ve yazılım şirketlerinden birinin ben ve @Adisak gibi diğerleri ile aynı gerekçeyi ne zaman kullandığını belirtmek yine de yararlı ve önemlidir.

4. Clang'ın linter'i clang-tidy, bunun için bazı seçeneklere sahiptir:

C. Clang en linter, dikkati çekiyor da var clang-tidy, bir seçenek vardır readability-avoid-const-params-in-decls, burada açıklanan destekleme, bir kod tabanı zorlama değil kullanılarak constpass-by-value fonksiyon parametreleri için :

İşlev bildiriminin en üst düzey sabit olan parametrelere sahip olup olmadığını denetler.

beyanlardaki const değerleri bir fonksiyonun imzasını etkilemez, bu nedenle oraya konulmamalıdır.

Örnekler:

void f(const string);   // Bad: const is top level.
void f(const string&);  // Good: const is not top level.

İşte tamlık ve netlik için kendime eklediğim iki örnek daha:

void f(char * const c_string);   // Bad: const is top level. [This makes the _pointer itself_, NOT what it points to, const]
void f(const char * c_string);   // Good: const is not top level. [This makes what is being _pointed to_ const]

B. Ayrıca bu seçeneği vardır: readability-const-return-type- https://clang.llvm.org/extra/clang-tidy/checks/readability-const-return-type.html

5. Konuyla ilgili bir stil rehberini nasıl söyleyeceğime pragmatik yaklaşımım:

Bunu kopyalayıp stil kılavuzuma yapıştırırım:

[KOPYA / MACUN BAŞLANGIÇ]

1. constİçeriklerinin (işaret ettikleri şey) DEĞİŞTİRİLMEMESİ amaçlandığında daima referans veya işaretçi ile iletilen fonksiyon parametrelerini kullanın . Bu şekilde, referans veya işaretçi IS tarafından iletilen bir değişkenin ne zaman değiştirilmesi beklendiği açıktır, çünkü eksik olacaktır const. Bu kullanım durumunda const, işlevin dışındaki yan etkileri önler.
2. O edilir önerilmez kullanımına constçünkü değer geçirilecek fonksiyon parametreleri üzerine constarayanın üzerinde bir etkisi yoktur: değişken işlevinde değişse bile işlevi dışında hiçbir yan etkisi olmayacaktır. Ek gerekçe ve öngörü için aşağıdaki kaynaklara bakın:
   1. "Google C ++ Stil Kılavuzu" "Sabit kullanımı" bölümü
   2. "109. Haftanın İpucu: constİşlev Bildirimlerinde Anlamlı "
   3. Adisak'ın "İşlev parametreleri için 'sabit' kullanımı" konusundaki Yığın Taşması yanıtı
3. " Asla üst düzey const[yani: değere göre geçirilenconst parametrelerde ], tanım olmayan tanımlarda işlev parametrelerinde (ve anlamsız bir şekilde kopyalayıp yapıştırmamaya dikkat edin ). Derleyici tarafından anlamsız ve yok sayılır, görsel gürültüdür ve okuyucuları yanlış yönlendirebilir "( https://abseil.io/tips/109 , vurgu eklendi). const
   1. constDerleme üzerinde etkisi olan tek niteleyiciler, bir üstbilgi dosyasındaki bir işlev (yöntem) bildirimi gibi, işlevin ileri bir bildiriminde değil, işlev tanımına yerleştirilen niteleyicilerdir.
4. Bir işlev tarafından döndürülen değerlerde asla üst düzey const[yani: değere göre iletilenconst değişkenlerde ] kullanmayın .
5. constBir işlev tarafından döndürülen işaretçiler veya başvurularda kullanmak bazen yararlı olabileceğinden uygulayıcıya bağlıdır .
6. YAPILACAKLAR: Yukarıdakilerden bazılarını aşağıdaki clang-tidyseçeneklerle uygulayın:
   1. https://clang.llvm.org/extra/clang-tidy/checks/readability-avoid-const-params-in-decls.html
   2. https://clang.llvm.org/extra/clang-tidy/checks/readability-const-return-type.html

constYukarıda açıklanan kuralları göstermek için bazı kod örnekleri :

constParametre Örnekleri:
(bazıları buradan ödünç alınır )

void f(const std::string);   // Bad: const is top level.
void f(const std::string&);  // Good: const is not top level.

void f(char * const c_string);   // Bad: const is top level. [This makes the _pointer itself_, NOT what it points to, const]
void f(const char * c_string);   // Good: const is not top level. [This makes what is being _pointed to_ const]

constDönüş Türü Örnekleri:
(bazıları buradan ödünç alınır )

// BAD--do not do this:
const int foo();
const Clazz foo();
Clazz *const foo();

// OK--up to the implementer:
const int* foo();
const int& foo();
const Clazz* foo();

[KOPYA / MACUN SONU]

Bahsetmeniz durumunda, API'nızın arayanlarını etkilemez, bu yüzden yaygın olarak yapılmaz (ve başlıkta gerekli değildir). Yalnızca işlevinizin uygulanmasını etkiler.

Yapılması özellikle kötü bir şey değildir, ancak API'nızı etkilemediği ve yazmayı eklediği için faydaları o kadar da büyük değildir, bu yüzden genellikle yapılmaz.

Ben const değer geçirilen parametre için kullanmıyorum. Arayan kişi parametreyi değiştirip değiştirmemenizle ilgilenmez, bu bir uygulama detayıdır.

Gerçekten önemli olan, örneklerini değiştirmedikleri takdirde yöntemleri const olarak işaretlemektir. Aksi halde const_cast <> ile sonlanabilir veya bir yöntem const işaretlemenin const olarak işaretlenmiş olması gereken diğer yöntemleri çağırdığı için çok sayıda kodun değiştirilmesini gerektirdiğini görebilirsiniz.

Ayrıca bunları değiştirmek gerekmiyorsa yerel vars const işaretlemek eğilimindedir. Ben "hareketli parçaları" tanımlamayı kolaylaştırarak kodun anlaşılmasını kolaylaştırdığına inanıyorum.

Derleyici optimizasyonlarında: http://www.gotw.ca/gotw/081.htm

Yapabileceğim const kullanıyorum. Parametreler için sabit, değerlerini değiştirmemesi gerektiği anlamına gelir. Bu özellikle referansla geçerken değerlidir. const for function, işlevin sınıf üyelerini değiştirmemesi gerektiğini bildirir.

Özetlemek:

• "Normalde cons-by-pass değeri işe yaramaz ve en iyi ihtimalle yanıltıcıdır." Gönderen GOTW006
• Ancak bunları .cpp dosyasına değişkenlerle yaptığınız gibi ekleyebilirsiniz.
• Standart kitaplığın const kullanmadığını unutmayın. Örn std::vector::at(size_type pos). Standart kütüphane için yeterince iyi olan benim için iyidir.

Parametre değere göre iletilirse (ve bir referans değilse), genellikle parametrenin const olarak bildirilip bildirilmediği konusunda çok fazla fark yoktur (bir referans üyesi içermediği sürece - yerleşik türler için bir sorun değildir). Parametre bir referans veya işaretçi ise, genellikle işaretçinin kendisini değil, referans / işaretli belleği korumak daha iyidir (bence referansın kendisini sabitleyemezsiniz, hakemi değiştiremeyeceğiniz kadar önemli değil) . Const olarak yapabileceğiniz her şeyi korumak iyi bir fikir gibi görünüyor. Parametreler yalnızca POD'lar (yerleşik tipler dahil) ise ve yol boyunca daha fazla değişme şansı yoksa (örneğin, örneğinizde bool parametresinde) hata yapma korkusu olmadan atlayabilirsiniz.

.H / .cpp dosya bildirimi farkını bilmiyordum, ancak bir anlam ifade ediyor. Makine kodu düzeyinde hiçbir şey "const" değildir, bu nedenle bir işlevi (.h'de) const olmayan olarak bildirirseniz, kod const (dekarasyonlar) olarak bildirdiğinizle aynıdır. Ancak, derleyiciyi işlevin (.ccp) uygulanması içindeki değişkenin değerini değiştirmeyeceğinizi kaydetmenize yardımcı olur. Değişime izin veren bir arabirimden miras aldığınızda kullanışlı olabilir, ancak gerekli işlevselliği elde etmek için parametreye değiştirmeniz gerekmez.

Ben böyle parametreler üzerinde const koymak olmaz - herkes zaten bir boolean (bir boolean yerine) sabit olduğunu biliyor, bu yüzden eklemek eklemek "bekle, ne?" veya parametreyi referans olarak geçiyor olsanız bile.

const ile hatırlanması gereken şey, şeyleri başlangıçtan const yapmanın, daha sonra bunları denemekten çok daha kolay olmasıdır.

Bir şeyin değişmesini istemediğinizde const kullanın - bu, işlevinizin ne yaptığını ve ne olacağını açıklayan ek bir ipucudur. Bazıları, özellikle c-dizeleri kabul olanlar ile yapabileceği bir C API gördüm!

Cpp dosyasındaki const anahtar sözcüğünü başlıktan daha fazla atlamaya meyilli olurum, ancak onları kesip yapıştırmaya eğilimli olduğum için, her iki yerde de tutulurlardı. Derleyicinin buna izin verdiğine dair hiçbir fikrim yok, sanırım bu derleyici bir şey. En iyi yöntem, const anahtar kelimenizi her iki dosyaya da koymaktır.

İşlev bir değişkenin yine de bir kopyasını değiştirebileceğinden, bir value-parametresi "const" yapmak için hiçbir neden yoktur.

"Const" kullanmanın nedeni, referans olarak daha büyük bir şey (örn. Çok sayıda üyeli bir yapı) geçiriyorsanız, bu durumda işlevin değiştirememesini sağlar; daha doğrusu, geleneksel yolla değiştirmeye çalıştığınızda derleyici şikayet edecektir. Yanlışlıkla değiştirilmesini önler.

Const parametresi yalnızca parametre referans olarak iletildiğinde, yani başvuru veya işaretçi olduğunda kullanışlıdır. Derleyici bir const parametresi gördüğünde, parametrede kullanılan değişkenin işlev gövdesi içinde değiştirilmediğinden emin olun. Neden bir sabit değer parametresi yapmak istesin ki? :-)

Parametreler değere göre iletildikçe, çağıran işlevin perspektifinden const belirtip belirtmediğinizde herhangi bir fark yaratmaz.

Örneklerinizdeki tüm ifadelerin bir amacı yoktur. C ++ varsayılan olarak by-pass değeridir, bu nedenle işlev bu içeri ve boolean'ların kopyalarını alır. İşlev bunları değiştirse bile, arayanın kopyası etkilenmez.

Bu yüzden ekstra consts önlemek istiyorum çünkü

• Onlar indirgendir
• Metni karıştırıyorlar
• Yararlı ya da verimli olabileceği durumlarda aktarılan değeri değiştirmemi engellerler.

Sorunun "biraz" modası geçmiş olduğunu biliyorum ama karşı karşıya geldiğimde başka biri de gelecekte yapabilir ... ... yine de zavallı adamın yorumumu okumak için burada listelediğinden şüpheliyim :)

Bana öyle geliyor ki hala C tarzı düşünce tarzıyla sınırlı kalıyoruz. OOP paradigmasında, tiplerle değil nesnelerle oynarız. Sabit nesne, özellikle mantıksal sabit anlamında (bitsel-sabitin aksine), sabit olmayan bir nesneden kavramsal olarak farklı olabilir. Bu nedenle, işlev parametrelerinin sabit doğruluğu (belki de) POD'larda aşırı dikkatlilik olsa bile, nesneler için böyle değildir. Bir işlev bir const nesnesiyle çalışıyorsa, bunu söylemelidir. Aşağıdaki kod snippet'ini düşünün

#include <iostream>

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
class SharedBuffer {
private:

  int fakeData;

  int const & Get_(int i) const
  {

    std::cout << "Accessing buffer element" << std::endl;
    return fakeData;

  }

public:

  int & operator[](int i)
  {

    Unique();
    return const_cast<int &>(Get_(i));

  }

  int const & operator[](int i) const
  {

    return Get_(i);

  }

  void Unique()
  {

    std::cout << "Making buffer unique (expensive operation)" << std::endl;

  }

};

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void NonConstF(SharedBuffer x)
{

  x[0] = 1;

}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void ConstF(const SharedBuffer x)
{

  int q = x[0];

}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int main()
{

  SharedBuffer x;

  NonConstF(x);

  std::cout << std::endl;

  ConstF(x);

  return 0;

}

ps .: (const) referansının burada daha uygun olacağını ve size aynı davranışı vereceğini iddia edebilirsiniz. Tamam, doğru. Başka bir yerde görebildiğimden farklı bir tablo çiziyorum ...