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

Yeni yorum
 
Georgiy Merts :

Numara. Bu durumda, bloktan çıkarken değişkenin silinmesi gerektiği açıktır.

new tarafından yaratılan nesnelerden bahsediyorum:

C# standardı şunu belirtir: " Yapılar gibi değer türü nesneleri ve sınıflar gibi başvuru türü nesneleri otomatik olarak yok edilir, ancak değer türü nesneleri içeren bağlam yok edildiğinde, referans türü nesneler çöp tarafından yok edilir. toplayıcı, onlara yapılan son referansın kaldırılmasından sonra süresiz olarak "

Şimdi, bu "belirsiz zamanı" sevmiyorum. Her ne kadar çöp toplayıcının nesneyi kendimden çok daha verimli bir şekilde kaldırabildiğini bile itiraf ediyorum, nesneyi onu oluşturan sınıfın yıkıcısında siliyor.

Mantıksal olarak, kimse referans vermediğinden, nesneye artık kimsenin ihtiyaç duymadığı, bir sonraki çöp toplamada silineceği anlamına gelir. Zamanlama tahmin edilemez, evet, ancak GC'den yapıyı hemen yapmasını isteyebilirsiniz. Ama bu aynı zamanda bir istek, bir emir değil))

 
Georgiy Merts :

Yani çöp toplayıcının canlı bir nesneyi veya işaretçiyi sileceğini söylemiyorum. İstediği zaman sileceği gerçeğinden bahsediyorum.

Keskin nişancılar, bir nesneyi çöp toplayıcı tarafından silinmekten korumak için bir işlev sağlar.

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.gchandle.alloc?view=netcore-2.0

 // for standalone object
public byte [] RawSerialize( object objAny)
{
int rawsize = Marshal.SizeOf(objAny);
byte [] m_obj = new byte [rawsize];

        GCHandle hObj = GCHandle.Alloc(m_obj, GCHandleType. Pinned );

        Marshal.StructureToPtr(objAny, hObj.AddrOfPinnedObject(), false );
        hObj.Free();

return (m_obj);
}
GCHandle.Alloc Method (System.Runtime.InteropServices)
GCHandle.Alloc Method (System.Runtime.InteropServices)
  • dotnet-bot
  • docs.microsoft.com
Выделяет дескриптор для указанного объекта.Allocates a handle for the specified object.
 
Alexey Navoykov :

Ve şimdi çaresizce neden bilmediğine dair bahaneler üretmeye başlıyorsun ;)

Tanıtıldığında ne fark eder: hemen mi yoksa bir ay sonra mı? Onu bilmiyordun, söylemesem de bilemezsin)

Utançtan yanmaktan korkuyorum ama fxsaber'ı bir yerde görene kadar & yakın zamana kadar bilmiyordum. Aksi takdirde GetPointer'ı kullanırdım.

Ancak Eylül ayında, bir yerde nesnelerle yapılan bazı işlemlerin aşırı yüklenemediğini fark ettim ve kendim farklı şekillerde çözmeye çalıştım ve birkaç kişi bana böyle bir olasılığın olmadığını yazdı. Ve şimdi öyle olduğu ortaya çıktı, bu yüzden tam olarak ne zaman ortaya çıktığını (ve neden sertifikada olmadığını) merak ediyorum.

 
SemenTalonov :

Muhtemelen, "yönetilen kodda" hiçbir işaretçinin olmadığı ve her şeyin bir nesne olduğu C# yönünde gidecekler, hatta basit türler bile bool int double, vb.

Bu kötü olmazdı, ancak bu yönde herhangi bir şeyi değiştirmeleri pek mümkün değil çünkü. bu, uçbirim dili kavramında tam bir değişikliktir ve bu nadiren hiç yapılır.

SemenTalonov :

BURADA, IMHO'ya göre, tam olarak neyle uğraştığınızı (bir nesne veya ona bir işaretçi) unutmamak için bu gereklidir.

Unutmamak için nesneleri hangi durumlarda hangi pointerlarda kullandığınıza tam olarak en baştan karar vermeniz gerekir (ideal durumda asla objeler ve her zaman pointerlar).

Ve bunun için her seferinde fazladan mektup yazmak (özellikle parantezli bir buhar banyosu yapmak) açıkçası aptalca

Ek olarak, bu durumda, sizin tarafınızdan açıklanan atama işlemi nesneyle ilgili olarak değil, nesne olmayan alanıyla ilgili olarak kullanılır, bu da prensipte bir hata olasılığını ortadan kaldırır (böyle bir işaretçinin türü). operasyon önemli değil)

 
Ilya Malev :

Unutmamak için nesneleri hangi durumlarda hangi pointerlarda kullandığınıza tam olarak en baştan karar vermeniz gerekir (ideal durumda asla objeler ve her zaman pointerlar).

Kendi kodunuzu bile açmıyorsunuz, ancak uzun bir süre sonra (bir veya iki yıl) açıp “ince” yerlerde yorum bırakmadığınız için kendinizi azarlıyorsunuz ve nesneler de işaretçilerden ayırt edilemezse, genellikle ahtung olur. Ayrıca otomatik nesnelerin reddedilmesine de katılmıyorum. Kullanımları, kodu belirgin şekilde daha kompakt hale getirir ve artık ihtiyaç duyulmadığında nesnenin kaderiyle ilgilenir. Ayrıca, böyle bir nesnenin ömrü derleyici tarafından önceden bilindiği için, dinamik oluşturma durumunda olduğundan daha optimize bir kod verebileceğinden eminim.

İlya Malev :

Ve bunun için her seferinde fazladan mektup yazmak (özellikle parantezli bir buhar banyosu yapmak) açıkçası aptalca

Ek olarak, bu durumda, sizin tarafınızdan açıklanan atama işlemi nesneyle ilgili olarak değil, nesne olmayan alanıyla ilgili olarak kullanılır, bu da prensipte bir hata olasılığını ortadan kaldırır (böyle bir işaretçinin türü). operasyon önemli değil)

Bu aptallık, MQL'de bir nesneye erişimi bir işaretçi ile göstermenin bir yolunun olmaması gerçeğinden kaynaklanmaktadır. C / C ++'da elbette daha özlü olurdu 

pA->iValue

Okun olmamasının nedeni muhtemelen başlangıçtaki ' * ' ile aynıdır (bilinmiyor). Benim Qt'mde (ve muhtemelen VS'de de) editör otomatik olarak '.' yerine geçer. '->' nesneye bir işaretçi tarafından erişiliyorsa, yani. 0 ekstra hareket Hiç şüphem yok ki, istenirse MQ'nun editöre böyle bir işlevsellik ekleyebileceğinden şüphem yok. Ve böylece, yukarıdaki örnekte, bir işaretçi ile uğraştığınızın tek işareti, isimdeki 'p' önekidir. Ve sadece unutmadığım için. Herkes çok "düşünceli" ise, o zaman her şey yolunda))

Onlar. koddaki potansiyel olarak tehlikeli yerler açıkça işaretlenmelidir. Onları hatırlamana gerek yok, görmen gerek. Nesnelerle böyle bir "ilişki formülasyonu" ihtiyacı, yukarıdakinden daha karmaşık örneklerde daha açık olacaktır. Örneğin, bir sınıf üyesinin kendisi bir şeyin göstergesi olduğunda.

POINTER_AUTOMATIC ve POINTER_DYNAMIC ile çalışmak için tek tip bir yaklaşım sağlayarak, bu işaretçi türlerinin benzerliği konusunda yanıltıcı bir izlenim ediniriz. Ama aslında bunlar farklı varlıklardır ve farklı bir tutum gerektirir. Konunun ana konusu bu. Tabii ki en bariz olanı: POINTER_AUTOMATIC her zaman gerçek hayattaki bir nesneye işaret ediyorsa, POINTER_DYNAMIC de boş olabilir .

Ve size sadece her türlü veri erişim varyasyonunu hatırlatacağım (yollarımız çakıştığı sürece C/C++ bile)

Şebeke Sözdizimi Aşırı yüklenebilir Uygulanan   Xi Misal
T tipi üye Sınıf dışında tanım
Bir dizi öğesine erişme bir [ b ] Evet Evet R   T :: operatör   []( S   b );
 n/a
Dolaylı erişim ("belirtilen nesne   bir ") * bir Evet Evet R   T :: operatör   * (); R   Şebeke   * ( T   bir );
Bağlantı ("adres   bir ") &a Evet Evet R   T :: operatör   & (); R   Şebeke   & ( T   bir );
Bir yapının bir üyesine atıfta bulunmak ("üye   b   işaret ettiği nesne   bir ") a -> b Evet Evet R *   T :: operatör   -> (); [not 5]
 n/a
Bir yapının bir üyesine atıfta bulunmak ("üye   b   nesne   bir ") bir . b Değil Evet n/a
Üye işaret etti   b   işaret edilen nesnede   bir [not 6] a ->* b Evet Değil R   T :: operatör   ->* ( S   b ); R   Şebeke   ->* ( T   bir _   S   b );
Üye işaret etti   b   nesnede   a a .* b Değil Değil n/a
 
SemenTalonov :

Tabii ki en bariz olanı: POINTER_AUTOMATIC her zaman gerçek hayattaki bir nesneye işaret ediyorsa, POINTER_DYNAMIC de boş olabilir .

"En bariz" zaten yanlışsa, diğer her şeyi ciddi olarak düşünmeye ve yanıtlamaya değer mi?

POINTER_AUTOMATIC bir değişken tipi değil, onun durumudur. Bir sonraki an, durumu tamamen farklı olabilir. Elbette POINTER_INVALID dahil
 
Ilya Malev :

"En bariz" zaten yanlışsa, diğer her şeyi ciddi olarak düşünmeye ve yanıtlamaya değer mi?

Mümkünse bu konuda biraz açıklama istiyorum.

 
Ilya Malev :
 POINTER_AUTOMATIC bir değişken tipi değil, onun durumudur. Bir sonraki an, durumu tamamen farklı olabilir.

tipi olmadığı kesin. Onlar. autoobject örneğin POINTER_DYNAMIC durumuyla işaretçi olur mu? Tabii ki, POINTER_INVALID durumu, örneğin bir işaretçi bildirirken kastedilmiştir.

 
SemenTalonov :

Mümkünse bu konuda biraz açıklama istiyorum.

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. Aynı zamanda, değişkenin gizli bir sabitlik özelliği vardır (* olmadan bildirilirse), ancak bu onu esasen başka türden bir değişken yapmaz, yalnızca ona başka bir tanıtıcı atanmasını yasaklar.

 

Yani, beyan 

   A* const b= new A;

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

1...5678910111213
Yeni yorum