const short array pointer

[z]

Keil de const shor olarak tanimladigim arraye ulasmak icin *short pointer tanimlarsam warning aliyorum.

Pointeri const * short tanimlarsam warning kalkiyor.

Sana ne arrayin romda yada ramda olusundan diye ben de derleyciye warning yapiyorum.

Olayin espirisi nedir?

C neden bu duruma kiziyor?

[mr.engineer]

Normal bir durum hocam bu. Hatırladığım kadarıyla derleyicinizle ilgili değil bu sorun. C standartlarıyla doğrudan ilgili diye hatırlıyorum. C de tüm derleyiciler(benim gördüğüm) bu durumda uyarı veriyor. Aynı şekilde C++ da yazarsanız muhtemelen error verecek.

Ayrıca top level/low level qualifiers konusunda bunlarla ilgili bir şeyler anlatılıyordu bir göz atabilirsiniz.

[Tagli]

Normal bir durum. Bir değişkeni const short olarak tanımladığın zaman derleyiciye "ben bunu değiştirmeyeceğim" diye söz veriyorsun. Ama pointer'ı const short'u değil de normal short'u gösterecek şekilde tanımlandığında ortada böyle bir söz yok. Böyle bir pointer, işaret ettiği değişkeni değiştirebilme yeteneğine sahip olur (fiziksel bir engel yoksa tabi). Yani kendi dediğinle çelişiyorsun, derleyici de o yüzden uyarıyor seni.

Tersi durumda ise hata olmaz. Yani const olmayan bir değişkeni const short gibi bir pointer ile işaret edebilirsin. Ancak bu pointer'ı kullanarak bu değişkeni değiştiremezsin.

Bu arada, pointer'ın kendisinin const olması ile, const bir şeyi gösteriyor olması birbirinden faklı şeyler. Kafa karıştırıcı bir ayrıntı olsa da, temel C bilgisi olduğu için burada ayrıntısına girmiyorum, internette bolca örneği var zaten. Biz burada ikincisi üzerinde konuşuyoruz. Genelde de karşımıza bu çıkar.

[z]

Iyi de pointere sonucta bir adres atayip ardindan bu adresdeki verilere ulasacagim.

short dedigim icin erisilecek adresten hangi boyutta veri okuyacagim belli.

Bu durumda pointere atayacagim adres rom adresi olursa constand arraye erisecegim, ram daki bir arrain adresini atarsam da ramdaki araya erisecegim diye anliyorum.

Sonucta degisen sadece adres.

Bu yuzden derleyici neden uyariyor anlamadim.

Ha soyle denirse ok.

Sen array okuyacagim diyorsun ama hadi const arraye yazma yapacaksan. O zaman hakli olabilir.

[volkanunal]

Eğer anladığım şu ise,

#include "stdio.h"

int main()
{
    const short arr[4] = {12, 14, 15};
    short *ptr = &arr;
}

Burada bir tür dönüşümü söz konusu ve derleyici sizin bunu belirtmenizi istiyor. Belirtmediğiniz takdirde, bunu yanlışlıkla yaptığınızı düşünerek sizi uyarıyor ve tür dönüşümünü kendisi örtülü olarak yapıyor. Yani otomatik bir tür dönüşümü gerçekleşiyor.

Yani şöyle oluyor,

#include "stdio.h"

int main()
{
    const short arr[4] = {12, 14, 15};
   
    short *ptr = (short*)&arr;
}

Bu durumda derleyici bunu bilinçli olarak yaptığınızı anlıyor ve size herhangi bir uyarı mesajı vermiyor. C++ dillerinde const T* ifadelerinin bir çoğunda otomatik tür dönüşümü olmadığı için ve C derleyicilerine göre yükümlülükleri daha fazla olduğu için bu bir error olarak görülecektir.


Durumun keil ile alakası yok yani. Ve eğer non-cost bir pointer'a cast ederek, her elementi sadece okunur durumda olan arr nesnesinin üyelerinde bir değiştirme yapmak tanımsız bir davranış hocam.

[Tagli]

Sen array okuyacagim diyorsun ama hadi const arraye yazma yapacaksan. O zaman hakli olabilir.

Evet olay tam olarak bu zaten. Pointer const'a işaret ederse eğer, bunu kullanarak yazma yapamazsın. Derleyici başta const olarak tanımlanan şeyin yazılmaz olarak kalmasını garanti etmeye çalışıyor elinden geldiğince.

"Ben illaki bunun etrafından dolanacağım, derleyiciye pabucunu ters giydireceğim" dersen pointer casting ile işin içinden çıkabilirsin sanırım. Ancak elbette ki ROM'daki bir adrese yazmaya çalışmak muhtemelen sorun çıkaracaktır (normal çalışma durumunda olduğunu ve öncesinde Flash yazma prosedürünü izlemediğini varsayarsak).

[brandice5]

Bu konu literaturdeki "const correctness" ile ilgili. const pointer bunlardan sadece bir tanesi. Ayni sekilde const fonksiyon parametreleri ve C++'da const method da var.

Olayin mantigi, olabildigince butun degiskenleri (objeleri) const olarak tanimlamak. Bu ekstra bir guvenlik sagladigi gibi bazi durumlarda asagidaki videoda oldugu gibi inanilmaz bir hiz artisini da beraberinde getiriyor. Farki seyircilerin tepkisinden anlayabilirsiniz.

https://www.youtube.com/watch?v=zBkNBP00wJE&t=1616

[Tagli]

@z hocam bir de C++'a bulaşırsa aklını oynatır, sürekli derleyici ile kavga eder Sonunda da gidip komitedeki herkesi vurur  

C++'ta bu iş C ile kıyaslandığında daha da karmaşık. Bir de constexpr meselesi var ki daha da başka bir dünya...

Olayin mantigi, olabildigince butun degiskenleri const olarak tanimlamak.

Bunun bir istisnası class içindeki değişkenler olabilir. Bazı insanlar, bu durumun nesneleri birbirine = operatörü ile atamayı olanaksız kılacağı için kaçınılması gereken bir uygulama olduğunu savunuyorlar. Encapsulation zaten class seviyesinde yapıldığı için, üye değişkenin const olmasının anlamsız olduğu söyleniyor. Ancak emin değilim, belki optimizasyon açısından yine de faydası olabilir.

Ben STM32 için kendi C++ kütüphanelerimi oluşturmaya çalışıyorum ve mümkün olduğunca her şeyi constexpr olarak tanımlamaya çalışıyorum. Nesne zaten kendisi constexpr olunca, üye değişkenlerin const olup olmamasının pek anlamı kalmıyor sanırım.

[brandice5]

@Tagli Evet, class icindeki degiskenler bu kapsamin disinda. Boyle bir durumda objenin kendisini const yapabilir veya degiskenlere erisen method'u const olarak tanimlayabiliriz.