İşaretçilerin bu şekilde kullanımını tahmin edilemez kılan nedir?

Şu anda ipuçları öğreniyorum ve profesörüm bu kodu örnek olarak verdi:

//We cannot predict the behavior of this program!

#include <iostream>
using namespace std;

int main()
{
    char * s = "My String";
    char s2[] = {'a', 'b', 'c', '\0'};

    cout << s2 << endl;

    return 0;
}

Yorumlara, programın davranışını tahmin edemeyeceğimizi yazdı. Bunu tam olarak öngörülemez yapan nedir? Ben yanlış bir şey görmüyorum.

Programın davranışı, kötü biçimlendirilmiş olduğu için mevcut değildir.

char* s = "My String";

Bu yasa dışıdır. 2011'den önce 12 yıldır kullanımdan kaldırılmıştı.

Doğru satır:

const char* s = "My String";

Bunun dışında program gayet iyi. Profesörünüz daha az viski içmeli!

Cevap şudur: hangi C ++ standardına karşı derlediğinize bağlıdır. Tüm kod, bu satır haricinde tüm standartlarda mükemmel şekilde biçimlendirilmiştir:

char * s = "My String";

Şimdi, dize değişmezinin türü var const char[10]ve biz ona const olmayan bir gösterici başlatmaya çalışıyoruz. charDize değişmezleri ailesi dışındaki tüm diğer türler için , böyle bir başlatma her zaman yasadışıdır. Örneğin:

const int arr[] = {1};
int *p = arr; // nope!

Bununla birlikte, C ++ 11 öncesi, dize değişmezleri için, §4.2 / 2'de bir istisna vardı:

Geniş dize değişmezi olmayan bir dizge değeri (2.13.4), " işaretçi karakter " türünde bir rvalue değerine dönüştürülebilir ; [...]. Her iki durumda da sonuç, dizinin ilk elemanına bir göstericidir. Bu dönüştürme, yalnızca açık bir uygun işaretçi hedef türü olduğunda ve bir l değerinden bir r değerine dönüştürmeye genel bir ihtiyaç olduğunda dikkate alınmaz. [Not: bu dönüşüm kullanımdan kaldırıldı . Ek D'ye bakınız. ]

Dolayısıyla C ++ 03'te kod mükemmeldir (kullanımdan kaldırılmış olsa da) ve net, öngörülebilir davranışa sahiptir.

C ++ 11'de, bu blok mevcut değildir - dönüştürülen dize değişmezleri için böyle bir istisna yoktur. char* ve bu nedenle kod, az önce int*verdiğim örnek kadar biçimsizdir . Derleyici bir tanılama yayınlamak zorundadır ve ideal olarak, bunun gibi C ++ tipi sistemin açık ihlalleri olan durumlarda, iyi bir derleyicinin sadece bu konuda uyumlu olmasını değil (örneğin bir uyarı yayınlayarak) başarısız olmasını bekleriz. düpedüz.

Kod ideal olarak derlenmemelidir - ancak hem gcc hem de clang'da işe yarar (sanırım, bu tür sistem deliğinin on yıldan fazla bir süredir kullanımdan kaldırılmasına rağmen, muhtemelen az kazançla kırılacak çok sayıda kod var). Kod kötü biçimlidir ve bu nedenle kodun davranışının ne olabileceği konusunda mantık yürütmek mantıklı değildir. Ancak bu özel durumu ve daha önce izin verilen geçmişini göz önünde bulundurarak, ortaya çıkan kodu örtük bir const_castşeymiş gibi yorumlamanın mantıksız bir uzantı olduğuna inanmıyorum, şöyle bir şey:

const int arr[] = {1};
int *p = const_cast<int*>(arr); // OK, technically

Bununla, programın geri kalanı mükemmel bir şekilde, çünkü bir daha asla dokunmuyorsunuz s. Oluşturulmuş bir nesneyi işaretçi olmayan bir şekilde okumak tamamen tamamdır. Oluşturulmuş bir nesneyi böyle bir işaretçi aracılığıyla yazmak tanımsız bir davranıştır:constconstconst

std::cout << *p; // fine, prints 1
*p = 5;          // will compile, but undefined behavior, which
                 // certainly qualifies as "unpredictable"

sKodunuzun herhangi bir yerinde herhangi bir değişiklik olmadığından, program C ++ 03'te iyidir, C ++ 11'de derlenemez, ancak yine de yapar - ve derleyicilerin buna izin verdiği göz önüne alındığında, içinde hala tanımlanmamış bir davranış yoktur † . Derleyicilerin hala C ++ 03 kurallarını [yanlış] yorumladıkları izinlerle, "öngörülemeyen" davranışa yol açacak hiçbir şey görmüyorum. sYine de yazın ve tüm bahisler kapanır. Hem C ++ 03 hem de C ++ 11'de.

Diğer cevaplar, bir const chardizinin bir .net dosyasına atanması nedeniyle bu programın C ++ 11'de kötü biçimlendirildiğini kapsamaktadır char *.

Ancak program C ++ 11 öncesinde de kötü biçimlendirilmişti.

operator<<Aşırı yükler vardır <ostream>. Şartı iostreamdahil etmekostream C ++ 11 ilave edildi.

Geçmişte çoğu uygulama iostreamşunları içeriyordu:ostream belki Uygulama kolaylığı açısından ya da belki daha iyi bir QoI sağlamak amacıyla, her neyse.

Ancak aşırı yüklemeleri tanımlamadan iostreamyalnızca ostreamsınıfı tanımlamak uygun olacaktır operator<<.

Bu programda gördüğüm ufak tefek yanlış olan tek şey, bir değişkene değişmez bir dize atamamanız gerektiğidir. char , göstericiye , ancak bu genellikle bir derleyici uzantısı olarak kabul edilir.

Aksi takdirde, bu program bana iyi tanımlanmış görünüyor:

• Karakter dizilerinin parametre olarak aktarıldığında nasıl karakter işaretçisi haline geleceğini belirleyen kurallar (örneğin, cout << s2 ) iyi tanımlanmıştır.
• Dizi, operator<<a char*(veya a const char*) için bir koşul olan boş sonlandırılmıştır .
• #include <iostream>içerir <ostream>, sırayla tanımlar operator<<(ostream&, const char*), böylece her şey yerinde görünür.

Yukarıda belirtilen nedenlerden dolayı derleyicinin davranışını tahmin edemezsiniz. ( Olmalı derlemek için başarısız, ama olmayabilir de.)

Derleme başarılı olursa, davranış iyi tanımlanmıştır. Kesinlikle programın davranışını tahmin edebilirsiniz.

Derleme başarısız olursa, program yoktur. Derlenmiş bir dilde, program kaynak kodu değil yürütülebilirdir. Yürütülebilir bir dosyanız yoksa, bir programınız da yoktur ve var olmayan bir şeyin davranışından bahsedemezsiniz.

Bu yüzden hocanızın açıklamasının yanlış olduğunu söyleyebilirim. Bu kodla karşılaştığınızda derleyicinin davranışını tahmin edemezsiniz, ancak bu, programın davranışından farklıdır . Yani nit seçecekse, haklı olduğundan emin olsa iyi olur. Ya da elbette onu yanlış aktarmış olabilirsiniz ve hata onun söylediklerini çevirmenizdedir.

Diğerlerinin de belirttiği gibi, önceki sürümlerde geçerli olmasına rağmen, kod C ++ 11 kapsamında yasadışıdır. Sonuç olarak, C ++ 11 için bir derleyicinin en az bir tanılama yayınlaması gerekir, ancak derleyicinin davranışı veya derleme sisteminin geri kalanı bunun ötesinde belirtilmez. Standarttaki hiçbir şey, bir derleyicinin bir hataya yanıt olarak aniden çıkmasını engellemez, bir bağlayıcının geçerli olduğunu düşündüğü kısmen yazılmış bir nesne dosyası bırakarak, bozuk bir yürütülebilir dosya verir.

İyi bir derleyici çıkmadan önce, üretmiş olması beklenen herhangi bir nesne dosyasının ya geçerli, yok ya da geçersiz olarak tanınabilir olmasını her zaman sağlamalıdır, ancak bu tür sorunlar Standardın yargı alanının dışında kalır. Tarihsel olarak başarısız bir derlemenin, yüklendiklerinde keyfi bir şekilde kilitlenen yasal görünen yürütülebilir dosyalara neden olabileceği bazı platformlar varken (ve hala olabilir) (ve bağlantı hatalarının genellikle bu tür davranışlara sahip olduğu sistemlerle çalışmak zorunda kaldım) Sözdizimi hatalarının sonuçlarının genellikle tahmin edilemez olduğunu söylemem. İyi bir sistemde, denenen bir derleme genellikle ya bir derleyicinin kod üretme konusundaki en iyi çabasıyla bir yürütülebilir dosya üretir ya da bir yürütülebilir dosya üretmez. Bazı sistemler, başarısız bir derlemeden sonra eski yürütülebilir dosyayı geride bırakır,

Kişisel tercihim, disk tabanlı sistemlerin çıktı dosyasını yeniden adlandırması, bu yürütülebilir dosyanın yanlışlıkla yeni kod çalıştırdığına inanmaktan kaynaklanabilecek kafa karışıklığını önlerken yararlı olacağı nadir durumlara izin vermesi ve gömülü programlama olacaktır. Sistemler, bir programcının her proje için, normal ad altında geçerli bir yürütülebilir dosya yoksa yüklenmesi gereken bir programı belirlemesine izin verir [ideal olarak, kullanılabilir bir programın eksikliğini güvenli bir şekilde gösteren bir şey]. Gömülü sistemler araç seti, genellikle böyle bir programın ne yapması gerektiğini bilmenin hiçbir yolu yoktur, ancak çoğu durumda, bir sistem için "gerçek" kod yazan biri, kolayca uyarlanabilen bazı donanım testi koduna erişebilir. amaç. Yeniden adlandırma davranışını gördüğümü bilmiyorum, ancak