Şablon parametreli derleyici hatası = void* - sayfa 17
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret 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
Bir ihtimal piramidal bir destekçi kodu var mıydı? Eğer öyleyse, ben ilk olacağım.
Bir ihtimal piramidal bir destekçi kodu var mıydı? Eğer öyleyse, ben ilk olacağım.
Bu, yatay kodun destekçileri kampına atfedilebilir.
Bu, yatay kodun destekçileri kampına atfedilebilir.
Kabul ediyorum, iyi yapmadım. En iyi örnekler o kadar aşkındı ki, ölümlü gerçekliğimize geçişten sağ çıkamadılar...
Bir ihtimal piramidal bir destekçi kodu var mıydı? Eğer öyleyse, ben ilk olacağım.
Bu şaşırtmaca.
Bu şaşırtmaca.
Evet, senden uzaktayım. Tabiri caizse, çabalayacak bir şey var))
Genel olarak, evet, yapabilirsiniz.
Bir sarmalayıcı olmadan, o zaman bir sarmalayıcı ile silinmez, silinir, her şey çok nettir.
Not: ama yapsaydım, bunu standart artı kitaplığına (isimler, davranış vb.) mümkün olduğunca benzer yapardım, bu yüzden benim için başka seçenek yok. Her şey zaten yazılmışken neden başka bir belirtim üretelim?
- Dinamik OOP içinde otomatik yapılar oluşturmak saçmalık
- Dinamik yapılar, belirli bir süreç için (örnek üzerinde bir talep gibi) veya mevcut bir eleman setinden bir örnek olarak (ve karışık tipler olabilir) oluşturulanlara bölünmelidir.
- Bir nesneye "kendi" referanslarının sayısını hesaba katarak hala bir çıkış yolu görüyorum, bunun için onun için sarmalayıcılar oluşturmak hiç gerekli değil (aslında bunun sorunu nasıl çözeceği hakkında hiçbir fikrim yok) , ancak µl'de zaten var olan işaretçiler mekanizmasını çoğaltmak zorunda kalacağım, buna ek olarak kendi yöntemleri var, en azından bir referans sayacı dahil (bu arada bu, Habr'dan alıntı yaptığınız makalede tartışıldı, ancak ben sadece birkaç gün önce işaretçiler hakkında bir çözüm ararken ve kendimin de aynı çözüme ulaştığımı fark ettiğimde okudum).
- Tüm bunları uygulamaya çalışacağım, işe yarar bir şey olursa herhangi bir şekilde forumda ve/veya kod tabanında yayınlayacağım :)
- Dinamik OOP içinde otomatik yapılar oluşturmak saçmalık
- Dinamik yapılar, belirli bir süreç için (örnek üzerinde bir talep gibi) veya mevcut bir eleman setinden bir örnek olarak (ve karışık tipler olabilir) oluşturulanlara bölünmelidir.
- Bir nesneye "kendi" referanslarının sayısını hesaba katarak hala bir çıkış yolu görüyorum, bunun için onun için sarmalayıcılar oluşturmak hiç gerekli değil (aslında bunun sorunu nasıl çözeceği hakkında hiçbir fikrim yok) , ancak µl'de zaten var olan işaretçiler mekanizmasını çoğaltmak zorunda kalacağım, buna ek olarak kendi yöntemleri var, en azından bir referans sayacı dahil (bu arada bu, Habr'dan alıntı yaptığınız makalede tartışıldı, ancak ben sadece birkaç gün önce işaretçiler hakkında bir çözüm ararken ve kendimin de aynı çözüme ulaştığımı fark ettiğimde okudum).
- Tüm bunları uygulamaya çalışacağım, işe yarar bir şey olursa herhangi bir şekilde forumda ve/veya kod tabanında yayınlayacağım :)
Çok ilginç. Pi @ # unov bıktınız.
Pekala, hiç kimse bir dizi oluştururken ek bir seçenek iletmeyi yasaklamıyor - öğeleri silindiğinde veya silindiğinde silmeniz ve varsayılan olarak (zevkinize göre) açıp kapatmanız gerekir. Sonuçta, silmeniz gerekip gerekmediğini tahmin edemezsiniz.))
Böylece böyle bir dizi yazdınız ve sonuç olarak bir sürprizle karşılaşacaksınız: kopya operatörü=() ve kopya yapıcısını (varsayılan olarak zaten µl'de değildir) silinmesi gereken işaretçiler dizisinde nasıl yasaklarsınız? Burada, yapıcı aracılığıyla parametrenin önemsiz olduğu anlaşılır. İki fikriniz olacak:
1. Uzak operatörlü bir türü şablon parametreleri aracılığıyla iletin ve onu sınıfın bir üyesi yapın (ve bu ekstra bir kaynak maliyetidir).
2. işaretçiyi bir sarıcıya geçirin :) (evet, evet - o lanet olası sarıcı).
3. Kısmi uzmanlaşmanın yardımıyla çıkmak mümkün olabilir ama öyle değil.
Genel olarak, bir artı kitaplığı bir şaheserdir, daha iyi yazdığınızı düşünüyorsanız, büyük olasılıkla yanılıyorsunuz.
0. Böylece böyle bir dizi yazdınız ve sonuç olarak bir sürprizle karşılaşacaksınız: kopya operatörü=() ve kopya yapıcısını (varsayılan olarak zaten µl'de değildir) olması gereken işaretçi dizisinde nasıl yasaklayabilirsiniz? silindi? Burada, yapıcı aracılığıyla parametrenin önemsiz olduğu anlaşılır. İki fikriniz olacak:
1. Uzak operatörlü bir türü şablon parametreleri aracılığıyla iletin ve onu sınıfın bir üyesi yapın (ve bu ekstra bir kaynak maliyetidir).
2. işaretçiyi sarıcıya geçirin :) (evet, evet - o lanet olası sarıcı).
3. Kısmi uzmanlaşmanın yardımıyla çıkmak mümkün olabilir ama öyle değil.
Genel olarak, bir artı kitaplığı bir şaheserdir, daha iyi yazdığınızı düşünüyorsanız, büyük olasılıkla yanılıyorsunuz.
Büyük olasılıkla öyledir ve bir başyapıttır, ancak en makul TS'yi oluşturmak için gerekenden çok daha geniş bir görev yelpazesi için yazılmıştır. Sinir ağları, grafik işlemci kullanımı ve teflerle yapılan diğer danslar gibi seçenekleri dikkate almıyorum.
0. Dinamik zaten oluşturulmuş nesnelerin aktarıldığını söyledim. Bunlar ya özellikle seçim için oluşturulmuş nesnelerdir (daha sonra silinmeleri gerekir) ya da kullanılan ancak silinmemiş nesnelere bağlantılar. Liste nesnesi onu oluşturmaktan sorumlu değildir. yalnızca gerektiği kadar adresleme, erişim ve depolama için.
1. ...
2. ...
3...
Kısacası, soyut değil, belirli ayrıntılı görevleri dikkate almalıyız. Biraz GUI yazmanız gerekiyorsa, bundan da bahsetmiyorum. İşte bir sonraki daldaki bazı arkadaşlar kötü bir gui değil, saf yapılar hakkında hiçbir şey yazmamış gibi görünüyor)