Teste StringLen eklendi ve dize farklı şekilde başlatıldı . Belgeleme bir şeydir, aslında tamamen farklı bir davranıştır. Ve bu durumda arabellek 260'ı değil 0'ı gösterir.
Belgeler, 0 döndürüldüğünde ve belirtilen durum için uygun olduğunu söylüyor
Belgeler: 0 değeri, dizenin sabit olduğu ve arabelleğin içeriğinin değiştirilemeyeceği anlamına gelir.
Dize "_" sabitiyle başlatılır ve derleyici dizeyi koşullu olarak (verimlilik amacıyla) bir sabit olarak değerlendirir - neden olmasın? Çelişki nedir? Ayrıca, onunla başka bir işlem yapılmaz.
260 sayısıyla, derleyicinin kendisinin bir StringBufferLen arabelleği ayırdığını anlıyorum. İlk boyut 260'tır. Ve eğer dizinin uzunluğu 260'tan azsa, o zaman StringBufferLen, dizinin gerçek uzunluğunu değil, tam olarak 260'ı yazdırır! Dizinin uzunluğu 260'tan büyükse dizinin gerçek değeri görüntülenir.
Yani, dize uzunluğu 260 karakterden az olan StringBufferLen işlevini kullanarak, dizenin gerçek uzunluğunu alamayız ve her zaman 260 alırız. Görünüşe göre bunda bir hata var. Terim 260 karakteri geçer geçmez, uzunluğun gerçek değerini alırız.
Yani, dize uzunluğu 260 karakterden az olan StringBufferLen işlevini kullanarak, dizenin gerçek uzunluğunu alamayız ve her zaman 260 alırız. Görünüşe göre bunda bir hata var. Terim 260 karakteri geçer geçmez, uzunluğun gerçek değerini alırız.
Kesin olarak konuşursak, dize uzunluğu: StringLen ve arabellek uzunluğu: StringBufferLen, oldukça nadir bir özelliktir. Ve genel durumda, çakışmayabilirler
Toplamda, en az iki şüpheli durum vardır:
voidOnStart ()
{
string s1 = "_" ;
Print ( StringBufferLen (s1)); //(1)//Ожидалось 260 вместо 0 - строка s1 далее может быть увеличенаStringInit (s1, 1 , '_' );
conststring s2 = s1;
Print ( StringBufferLen (s2)); //(2)//Ожидалось 0\1 вместо 260 - строка s2 константная и не может быть далее увеличена
}
Strateji test cihazı optimizasyon hatası henüz düzeltilmedi.
Lütfen düzeltin.
Kullandığım optimizasyon ayarı denge + keskin oran ama ekran görüntüsündeki gibi anormal bir optimizasyon değeri çıkıyor ve sonraki optimizasyon neslinde bu anormal değerden dolayı normal optimizasyon oluşuyor. Bu imkansız.
Kullandığım optimizasyon denge + keskin oran ama anormal optimizasyon değeri ekran görüntüsündeki gibi çıkıyor ve sonraki optimizasyon neslinde bu anormal değerden dolayı normal bir optimizasyon oluşuyor. Bu imkansız
Önceden tahsis edilmiş dize bellek boyutu, derleyicinin dahili bir meselesidir ve ona tahsis edilmemelidir.
Yürütme sonuçları Sabit bir dize için gerekenden daha fazla bellek tahsis edilir (prensipte uzunluğunu artırmak imkansız olacaktır)
Const olmayan bir dize için fazladan bellek tahsis edilmez (uzunluğu arttığında, yeni bir bellek tahsisi gerekecektir)
Kullanıcı dizeyi StringInitInit aracılığıyla başlatırsa, o zaman gerekenden daha fazla bellek tahsis edilir, çünkü arabellek boyutu kullanıcı tarafından açıkça ayarlanır ve çoğu durumda artırılmaz (kullanıcı zaten hangi son arabelleği alacağını düşünmüştür). ihtiyaçlarını ve boyutunu açıkça ayarlayın)
Yürütme sonuçları Sabit bir dize için gerekenden daha fazla bellek tahsis edilir (prensipte uzunluğunu artırmak imkansız olacaktır)
Const olmayan bir dize için fazladan bellek tahsis edilmez (uzunluğu arttığında, yeni bir bellek tahsisi gerekecektir)
Kullanıcı dizeyi StringInitInit aracılığıyla başlatırsa, o zaman gerekenden daha fazla bellek tahsis edilir, çünkü arabellek boyutu kullanıcı tarafından açıkça ayarlanır ve çoğu durumda artırılmaz (kullanıcı zaten hangi son arabelleği alacağını düşünmüştür). ihtiyaçlarını ve boyutunu açıkça ayarlayın)
Dizeler için arabelleklerin ön tahsisinin boyutu, derleyicinin dahili bir meselesidir.
Teste StringLen eklendi ve dize farklı şekilde başlatıldı . Belgeleme bir şeydir, aslında tamamen farklı bir davranıştır.
Ve bu durumda arabellek 260'ı değil 0'ı gösterir.
Belgeler, 0 döndürüldüğünde ve belirtilen durum için uygun olduğunu söylüyor
Belgeler, 0 döndürüldüğünde ve belirtilen durum için uygun olduğunu söylüyor
Belgeler mevcut davranışla hiç uyuşmuyor!
Ve sonuçlar farklıİki başlatma türü arasındaki fark nedir?
Ve soldaki 260 sayısının nereden geldiği hiç belli değil.
Belgeler mevcut davranışla hiç eşleşmiyor!
Belgeler: 0 değeri, dizenin sabit olduğu ve arabelleğin içeriğinin değiştirilemeyeceği anlamına gelir.
Dize "_" sabitiyle başlatılır ve derleyici dizeyi koşullu olarak (verimlilik amacıyla) bir sabit olarak değerlendirir - neden olmasın? Çelişki nedir? Ayrıca, onunla başka bir işlem yapılmaz.
Ve soldaki 260 sayısının nereden geldiği hiç belli değil.
Moderatör, davanın nerede ve neden olduğunu açıkladı
görünmüyor - kontrol nedeni
moderatör nerede açıkladı
260 sayısıyla, derleyicinin kendisinin bir StringBufferLen arabelleği ayırdığını anlıyorum. İlk boyut 260'tır.
Ve eğer dizinin uzunluğu 260'tan azsa, o zaman StringBufferLen, dizinin gerçek uzunluğunu değil, tam olarak 260'ı yazdırır!
Dizinin uzunluğu 260'tan büyükse dizinin gerçek değeri görüntülenir.
Yani, dize uzunluğu 260 karakterden az olan StringBufferLen işlevini kullanarak, dizenin gerçek uzunluğunu alamayız ve her zaman 260 alırız.
Görünüşe göre bunda bir hata var.
Terim 260 karakteri geçer geçmez, uzunluğun gerçek değerini alırız.
ps belgeler güncel olmadığı için yanıltıcıdır.
Yani, dize uzunluğu 260 karakterden az olan StringBufferLen işlevini kullanarak, dizenin gerçek uzunluğunu alamayız ve her zaman 260 alırız.
Görünüşe göre bunda bir hata var.
Terim 260 karakteri geçer geçmez, uzunluğun gerçek değerini alırız.
Kesin olarak konuşursak, dize uzunluğu: StringLen ve arabellek uzunluğu: StringBufferLen, oldukça nadir bir özelliktir. Ve genel durumda, çakışmayabilirler
Toplamda, en az iki şüpheli durum vardır:
Yürütme sonuçları Sabit bir dize için gerekenden daha fazla bellek tahsis edilir (prensipte uzunluğunu artırmak imkansız olacaktır)
Yürütme sonuçları Sabit bir dize için gerekenden daha fazla bellek tahsis edilir (prensipte uzunluğunu artırmak imkansız olacaktır)
Dizeler için arabelleklerin ön tahsisinin boyutu, derleyicinin dahili bir meselesidir.
İşi tekrar tekrar dizelerle değiştireceğiz.