MQL5 Derleyici, bir sınıf ile ona yönelik bir işaretçi arasında ayrım yapmaz - sayfa 13

Yeni yorum
 
Ilya Malev :

Sadece MKL'de her şey görünüşe göre C ++ ile aynı değil. Burada işaretçi ayrı bir veri türü değildir ve bu nedenle her ikisi de bir nesnedir ve tutamacı değişkendedir.

Böyle?

 // тот же класс А что был выше

A a; // будет создан автообъект с реальным выделением памяти и инициализацией. 'a' является указателем со статусом POINTER_AUTOMATIC

A* pA; // память под объект не выделена, объекта нет. pA является указателем со статусом POINTER_INVALID или POINTER_DYNAMIC?

İşaretçinin oluşturulduktan sonra alacağı durum, POINTER_INVALID veya POINTER_DYNAMIC, tartışmayacağım. Teoride, adres new adresinden alınana kadar POINTER_INVALID olmalıdır.

 
Ilya Malev :

Yani, beyan

Ve tamamen aynı "otomatik nesneye" sahip olacaksınız, sadece kendiniz sileceksiniz

artık araba değil ..

 
SemenTalonov :

İşaretçinin oluşturulduktan sonra alacağı durum, POINTER_INVALID veya POINTER_DYNAMIC, tartışmayacağım. Teoride, adres new adresinden alınana kadar POINTER_INVALID olmalıdır.

Her şey doğru, durum POINTER_INVALID olacak. Ancak a ve pA değişkenleri aynı tiptedir. Yalnızca a sabittir ve oluşturma sırasında yapıcı çağrılır ve bloktan çıktıktan sonra yıkıcı çağrılır, pA ise rastgele erişime ve yapıcı ile yıkıcının keyfi bir çağrısına sahiptir.

* olmadan bildirilen bir değişkene özel hileler olmadan POINTER_INVALID durumu verilemez, bu da doğrudur, ancak değişkenler farklı türde olduğundan değil, derleyici yapıcıyı ve yıkıcıyı iyi kontrol ettiğinden ve ona farklı bir değer atamayı yasakladığından.

Ve değişkenler aynı türden olduğu için, aslında, onlar aracılığıyla sınıf yöntemlerine farklı şekillerde erişmenin bir mantığı yoktur.

 
Ilya Malev :

Her şey doğru, durum POINTER_INVALID olacak. Ancak a ve pA değişkenleri aynı tiptedir. Yalnızca a sabittir ve oluşturma sırasında yapıcı çağrılır ve bloktan çıktıktan sonra yıkıcı çağrılır, pA ise rastgele erişime ve yapıcı ile yıkıcının keyfi bir çağrısına sahiptir.

Yani tüm bor peynirleri sadece ayırt edilmeleri gerektiği gerçeğinden kaynaklanmaktadır. Onlar. işaretçi daha sorumlu bir tutum gerektirir ( DİNAMİK olan).

 
SemenTalonov :

Yani tüm bor peynirleri sadece ayırt edilmeleri gerektiği gerçeğinden kaynaklanmaktadır. Onlar. işaretçi daha sorumlu bir tutum gerektirir ( DİNAMİK olan).

Benim düşünceme göre, OOP'nin anlamı yalnızca nesnelere yapılan referansların iletilebilmesi ve saklanabilmesi ve bunlara farklı davranışlara sahip farklı sınıfların yazılabilmesidir. Polimorfizme dokunmadan bile bir "otomatik nesne" referansını saklamaya başladığınızda, zaten tüm ayrımlarını kaybedersiniz (çünkü A& gibi kullanıcı tanımlı değişkenler yoktur)

 
Ilya Malev :

* olmadan bildirilen bir değişkene özel hileler olmadan POINTER_INVALID durumu verilemez , bu da doğrudur, ancak değişkenler farklı türde olduğundan değil, derleyici yapıcıyı ve yıkıcıyı iyi kontrol ettiğinden ve ona farklı bir değer atamayı yasakladığından.

Aynen öyle. Otomatik nesne işaretçisi durumunu değiştirmez ve POINTER_DYNAMIC işaretçisi program çalışması sırasında kolayca geçersiz hale gelebilir. Sebepler, böyle bir olayın olasılığı kadar önemli değildir.

 
SemenTalonov :

Aynen öyle. Otomatik nesne işaretçisi durumunu değiştirmez ve POINTER_DYNAMIC işaretçisi program çalışması sırasında kolayca geçersiz hale gelebilir. Sebepler, böyle bir olayın olasılığı kadar önemli değildir.

Bunun için mükemmel ve sorunsuz bir tedavi var:

 class A{~A(){}};

void OnStart ()
 {
  A*a= new A;
   delete a; // oops =))
 };
Tamam, genel olarak, programcının kendisinin nesnelerin ömrünü ve değişkenlere erişme yöntemini izlemesi gerektiğini ve baştan düşünülen mimarinin, kodu yazdıktan en az bir veya iki yıl sonra hataları en aza indireceğini düşünüyorum ...
 
Aslında, bir nesnenin ömrü, ona "canlı" işaretçilerin ömrüne karşılık gelmelidir. POINTER_DYNAMIC türünden dinamik bir nesne, elbette, aynı zamanda kötü tasarlanmış kodlamayla sorun yaratan gönülsüz bir çözümdür. Ancak POINTER_AUTOMATIC , nesnelerle normal çalışma için gerekli olan ölçeklenebilirlik düzeyini sağlamaz. Bunun böyle olması gerekir - bloktan çıkışta, oluşturulduğu otomatik değişken dışında nesneye yönelik hiçbir işaretçi oluşturulmamışsa - nesneyi silin. Geçerli bloğun dışındaki bağlantılar alındıysa, bu bağlantılar canlıyken nesneyi silmeyin. Ardından ölçeklenebilirlik görünecek ve kodlayıcının silme işlemini sürekli olarak izlemesi gerekmeyecek ... (örneğin, şimdi A* a = yeni A; ve ardından a = yeni yazarsanız Ve yine, ilk nesne sonsuza kadar kaybolacak , ve programdan çıktığınızda günlüklerde kesinlikle bellek sızıntısı hataları olacaktır, ancak bu sefer övülen kod iyileştirici nereye bakıyor?)
 
Ilya Malev :
Aslında, bir nesnenin ömrü, ona "canlı" işaretçilerin ömrüne karşılık gelmelidir. POINTER_DYNAMIC türünden dinamik bir nesne, elbette, aynı zamanda, kötü tasarlanmış kodlama ile sorun yaratan gönülsüz bir çözümdür. Ancak POINTER_AUTOMATIC , nesnelerle normal çalışma için gerekli olan ölçeklenebilirlik düzeyini sağlamaz. Bunun böyle olması gerekir - bloktan çıkarken, içinde oluşturulduğu otomatik değişken dışında bir nesneye yönelik hiçbir işaretçi oluşturulmamışsa - nesneyi silin. Geçerli bloğun dışındaki bağlantılar alındıysa, bu bağlantılar canlıyken nesneyi silmeyin. Ardından ölçeklenebilirlik görünecek ve kodlayıcının silme işlemini sürekli olarak izlemesi gerekmeyecek ... (örneğin, şimdi A* a = yeni A; ve ardından a = yeni yazarsanız Ve yine, ilk nesne sonsuza kadar kaybolacak , ve programdan çıktığınızda , günlüklerde bellek sızıntısı hataları olacağı garanti edilir... Ve övülen kod iyileştirici bu sefer nereye bakıyor?)

Bu da bir çok sürpriz. Ne de olsa, sızdırılan her baytı kesin olarak biliyor ve onu serbest bırakmak istemiyor. Yani şu anda dino işaretçilerini hiç takip etmiyor mu? Sadece istenen bellek ile sonunda serbest bırakılan bellek arasındaki farkı sayar.

Ve kullanım ömrü ve boş/kayıp işaretçiler sorunlardan sadece bir tanesidir. Daha önce, nesnelere işaretçilerin örtük olarak dökülmesiyle ilgili sorunları tartıştık, bu tam bir çöp) Yanlışlıkla (buna göre, derleyici bu tür bir kodun derlenmesine izin vermemeliydi), beklenen işaretçi yerine, şunları alabilirsiniz: örneğin, sırayla hiçbir yere işaret edebilir). Karşılaştırma işlemleri hakkında kendiniz yazdınız. Ayrıca çok belirsiz.

 
SemenTalonov :

1. Bu da beni çok şaşırttı. Sonuçta, sızdırılan her baytı kesin olarak biliyor ve onu serbest bırakmak istemiyor. Yani şu anda dino işaretçilerini hiç takip etmiyor mu? Sadece istenen bellek ile sonunda serbest bırakılan bellek arasındaki farkı sayar.

2. Ömür boyu ve boş/kayıp işaretçiler sorunlardan sadece bir tanesidir.

1. Pek değil, geliştiriciler için dinamik nesneler için basit bir GC yazmak çocuk oyuncağı olurdu, ancak kodlayıcıların programlarında bir aksaklık olduğunu görebilmeleri için bu mesajları kasten bıraktılar. Dinamik nesneleri yarı C# olduğundan (bu konuda uzman değilim ama duyduklarıma göre) - sanki nesneler aynı şekilde davranıyormuş gibi (işaretçi yok, ama her şey nesnelerdir) ve iyi- onlar için düşünülmüş bir alt sistem geliştirilmemiştir.

2. Evet, tabii ki, eğer nesne değişkenleri aynı tipte olsaydı (yani: otomatik veya bağımsız olarak değil, onlara referans olmadığında yerleşik çöp toplayıcı tarafından silindi), o zaman onlara tüm erişimler kesinlikle tekdüze meydana gelir.

1...678910111213
Yeni yorum