MQL5 Derleyici, bir sınıf ile ona yönelik bir işaretçi arasında ayrım yapmaz - sayfa 6
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
bu işaretçinin bir nesneye örtük dökümü
Buna "Örtülü işaretçi referansı" demek daha doğru olur.
Yalnızca aşağıdaki gibi bir sınıf üyesine atıfta bulunurken, örtük referans kaldırmayı yasaklama, bırakma önerisini destekliyorum:
Burada, tam tersine, a işaretçisi dolaylı olarak nesneye atılır (başvurusu kaldırılır) ve ardından ona = operatörü uygulanır. Dün fxsaber bundan da bahsetti.
Ve bu durumda, bu tür davranışları yasaklamanın daha iyi olduğuna katılıyorum. Mantıksal olarak MQL kurallarıyla çelişmese de (çünkü = operatörünü çağırmak başka herhangi bir nesne yöntemini çağırmaya eşdeğerdir), bu tür kodun belirsiz algılanmasına ve ince hatalara yol açar. Ve bu sadece = operatörü için değil, aynı zamanda en azından == ve != için de geçerlidir. Ve belki de diğer operatörler için bu tür dökümleri yasaklamak gerekir. Çünkü C++'da operatörlere başvurabilirsiniz: +-<>[].
Kısacası, karar şudur: C++'da işaretçiler için izin verilen bir işaretçiye operatörler uygularken, bu işaretçinin bir nesneye örtük olarak yayınlanmasını yasaklayın. Buna göre yukarıdaki örnekte bir derleme hatası olacaktır.
Evet, bu anlaşılabilir. Bu basit örnekleri kullanarak, bir işaretçi ve bir nesnenin farklı varlıklar olduğundan ve hiçbir şekilde müdahale edilemeyeceğinden şüphe duyan herkese göstermek istedim.
Ve bu durum en azından belirli bir kod yazma stilini ima eder, böylece yanlışlıkla (bilgi değil) kişi derleyen ve hatta testi geçen ancak gerçek koşullarda başarısız olan bir kod oluşturmaz, satış için yazılmışsa çok daha kötüdür. . Her şeyin "örtülü olarak" eşdeğer olduğu koddaki hatanın yerini bulmak oldukça zor bir iş olacaktır.
Her şeyin "örtülü olarak" eşdeğer olduğu koddaki hatanın yerini bulmak oldukça zor bir iş olacaktır.
Geliştiriciler her şeyi olduğu gibi bıraksa daha iyi olurdu. Şimdi tekrar değişmeye başlarlarsa, dil, bir grup program derlemeyi durdurur veya daha da kötüsü beklendiği gibi çalışmayı durdurursa, evrensel nix yükselecektir.
Benim bakış açıma göre, μl'deki otomatik nesneler bir temeldir, sınırlı işlevlere sahip (otomatik silmeli sabit bir işaretçi) alt işaretçilerdir ve genel olarak kullanılmamalıdırlar (çöp toplayıcının altında hariç).
Geliştiriciler her şeyi olduğu gibi bıraksa daha iyi olurdu. Şimdi tekrar değişmeye başlarlarsa, dil, bir grup program derlemeyi durdurur veya daha da kötüsü - beklendiği gibi çalışmayı durdurursa, evrensel nix yükselecektir.
Burada minimal değişiklikler var. Sadece derleme kuralları ekleyin
Böylece şimdi uygun görülen sapkınlığın derlenmesine izin vermiyor.
Böylece şimdi uygun görülen bu sapkınlığın derlenmesine izin vermiyor.
A tipi a = yeni A? Veya özellikle) strict artık herkes tarafından kullanılıyor, bu yüzden hiçbir etkisi yok
burada, A tipi geri yazma ile a, *b = a; bir çalışma zamanı hatası ortaya çıkıyor, bu durumda derleyicinin diğer tüm türlerde olduğu gibi "başlatılmamış değişken 'b' olası kullanımı" uyarısını açıkça vermesi gerekir. Hiç bir derleme hatası değilse. Ancak atamanın kendisi nedeniyle değil, başlatılmamış bir değişken üzerinde aşırı yüklenmiş bir işlevin kullanılması nedeniyle, elbette bir çalışma zamanı hatasına yol açar. Bu gerçekten bir hata ve aşırı kod optimizasyonu ile bağlantılı görünüyor.
Genel olarak, bir arabayı bir dyno'ya atamanın bir sapkınlığı yoktur ve bunun tersi de geçerlidir, bunlar yararlı çipler olabilir.
Ancak nesnelerin örtülü kopyalanması gibi bir özelliği tamamen iptal ederim. With ++'da da standart olmasına rağmen. Onun yüzünden, aslında, tüm bu sorunlar ortaya çıkıyor.A tipi a = yeni A? ya da tam olarak ne)
Pekala, söylemeye gerek yok. Burada bir bellek sızıntısı var.
Genel olarak, bir arabayı bir dyno'ya atamanın bir sapkınlığı yoktur ve bunun tersi de geçerlidir, bunlar yararlı çipler olabilir.
Evet, olsun. Ama bariz. Ve bu benim hatam yüzünden değil, buna ihtiyacım olduğu için yapılacak.
Pekala, söylemeye gerek yok. Burada bir bellek sızıntısı var.
Bu sızıntı tamamen senin hatan. Solda bir nesneniz varsa, neden böyle bir yapı yazıyorsunuz?
Ancak tam tersi durumda, bir işaretçiye bir şey atadığınızda ve aniden referansı kaldırıldığında, bu zaten bariz bir hatadır.
Burada her şeyi bir yığın halinde karıştırdılar, sinekler ve pirzolalar. Konunun tartışılmasından bahsediyorum.
Solda bir nesneniz varsa, neden böyle bir yapı yazıyorsunuz?
İnsan faktörü! Derleyici bunu minimumda tutmalıdır.
İnsan faktörü! Derleyici bunu minimumda tutmalıdır.