Hatalar, hatalar, sorular - sayfa 706
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
1.
Yapılara (dizilere) işaretçi dizileri oluşturmak için. Sonraki başlatma ile for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. Anlamlı veri dizilerinin katı (paketlenmiş) formunu korumak.
Ham OpenCL arabelleklerine veri çıkışı ile çalışırken (veya bir DLL'ye gönderirken, dosyalara yazarken vb.)
Bu, verileri yeniden yazmadan veri erişimini (örneğin , işaretçileri sıralarken ) yeniden sıralama olasılığını korur (görünür).
Güvenli bir dil, doğrudan erişim sağlamamalı/vermemelidir.
Sınıfların daha fazla koruması vardır ve bu yüzden bir tutamaçları vardır.
Güvenlik daha önemli olduğu için diğer nesneler için tutamaçlar önemli olmayacaktır.
Yapılar da dahil olmak üzere herhangi bir veri türü, verileri OpenCL'ye geçirmek için kullanılabilir. Boşluk* kullanır. Tek tip verileri doğru formatta hazırlayın ve çalışın. "Ama istemiyorum, kendi yolumda istiyorum" sorusunu tahmin ederek, işe yaramayacağını - güvenlik daha önemli olduğunu cevaplayacağım.
1. OpenCL'ye veri aktarmak için yapılar dahil herhangi bir veri türünü kullanabilirsiniz. Boşluk* kullanır. Tek tip verileri doğru formatta hazırlayın ve çalışın. "Ama istemiyorum, kendi yolumda istiyorum" sorusunu tahmin ederek, işe yaramayacağını cevaplayacağım - güvenlik daha önemli.
2. Güvenli yürütmeye sahip bir dil, doğrudan erişim sağlamamalı/vermemelidir.
1. "Kendi yolumda" ne istediğimle ilgili değil. Ve en ilkel olanlar da dahil olmak üzere tüm sınıflar için, mql5 derleyicisi, nesnelerde karşılık gelen gizli bir alana (VMT'ye bir işaretçi) sahip bir VMT oluşturur. Ve bana göre bu işaretçi ham arabellekte (dosya) - boğazın karşısında. Sadece yer kaplayan çöp olmakla kalmaz, aynı zamanda paketlerdeki verilerin hizalanmasını tamamen uygunsuz bir şekilde ihlal eder (OpenCL arabelleklerinde hizalama 128 bittir). Bütün mesele bu. Sınıfları kullanmak caziptir: onlarla mql'de çalışmak uygundur. Ama... yukarıya bakın.
Delphi'nin iyi bir alternatif uygulama örneği var. VMT ve buna bağlı olarak, VMT'ye yönelik bir işaretçi, yalnızca sınıf hiyerarşisinde ilk sanal yöntemin görünmesinden sonra sınıflarda görünür. Aynısı mql5'te olsaydı, durum çok daha yönetilebilir olurdu. Sınıfları yapılar yerine sanal yöntemler olmadan kullanmak mümkün olacak ve yapıyı bozan "ekler" olmayacaktı.
Şimdi, bir dizi yapıyı içine alan soyut (miras için amaçlanan) bir sınıfın uygulanmasının, devralınan hizmetleri (sıralama gibi) enjekte etmeye uygun olmadığı bir durumla karşı karşıyayım. Bir dizi yapıyı bir dizi sınıfla değiştirmek bu sorunu çözer, ancak başka bir tane oluşturur... (yukarıya bakın).
2. Ve ben herhangi bir "doğrudan erişim" istemiyorum. Ve hiçbir adres aritmetiği beni ilgilendirmiyor. Neden sebepsiz yere çocukları korkutuyorsun? :) mql5 tanıtıcısı "ham" bir işaretçi olmaya yakın bile değil. Ve eğer (gizlice) öyleyse, o zaman gerçek güvenlik açığı buradadır ve herhangi bir kullanıcı verisine tanıtıcıların (sözde işaretçiler) uygulanmasında değildir.
---
Artık sanal işlevleri olmayan (ve sırasıyla VMT) sınıflar olan yapılara sahipsiniz. Tamam bu harika. Onlara biraz daha sınıf özelliği (tutamaçları) ekleyin. Tam teşekküllü çalışma için doğru olacaktır. Ardından, dizilere yönelik işaretçilere artık çok acil ihtiyaç yoktur (gerekirse bunları yapılara sarabilirsiniz).
1. "Kendi yolumda" ne istediğimle ilgili değil. Ve en ilkel olanlar da dahil olmak üzere tüm sınıflar için, mql5 derleyicisi, nesnelerde karşılık gelen gizli bir alana (VMT'ye bir işaretçi) sahip bir VMT oluşturur. Ve ham bir arabellekteki (dosyadaki) bu işaretçi boğazımı zorluyor. Sadece yer kaplayan çöp olmakla kalmaz, aynı zamanda paketlerdeki verilerin hizalanmasını tamamen uygunsuz bir şekilde ihlal eder (OpenCL arabelleklerinde hizalama 128 bittir). Bütün mesele bu. Sınıfları kullanmak caziptir: onlarla mql'de çalışmak uygundur. Ama... yukarıya bakın.
Delphi'nin iyi bir alternatif uygulama örneği var. VMT ve buna bağlı olarak, VMT'ye yönelik bir işaretçi, yalnızca sınıf hiyerarşisinde ilk sanal yöntemin görünmesinden sonra sınıflarda görünür. Aynısı mql5'te olsaydı, durum çok daha yönetilebilir olurdu. Yapılar yerine sanal yöntemler olmadan sınıfları kullanmak mümkün olacak ve yapıyı bozan "ekler" olmayacaktı.
Şimdi, bir dizi yapıyı içine alan soyut (miras için amaçlanan) bir sınıfın uygulanmasının, kendisine devralınan hizmetlerin (sıralama gibi) enjekte edilmesine izin vermediği bir durumla karşı karşıyayım. Bir dizi yapıyı bir dizi sınıfla değiştirmek bu sorunu çözer, ancak başka bir tane oluşturur... (yukarıya bakın).
2. Ve ben herhangi bir "doğrudan erişim" istemiyorum. Ve hiçbir adres aritmetiği beni ilgilendirmiyor. Neden sebepsiz yere çocukları korkutuyorsun? :) mql5 tanıtıcısı "ham" bir işaretçi olmaya yakın bile değil. Ve eğer (gizlice) öyleyse, gerçek güvenlik açığı buradadır ve herhangi bir kullanıcı verisine tanıtıcıların (sözde işaretçiler) uygulanmasında değildir.
Soyut verilerle (ki bu zaten çok sayıda dahili meta veri ve ilişki anlamına gelir) karmaşık bir sistem oluşturmak ve ardından onu zor bir şekilde değiştirilebileceği kontrolsüz bir OpenCL ortamına aktarmak istiyorsunuz. İşte bu yüzden sanal tabloların üzerine yazma yeteneği olmadan yalnızca basit nesneler ve diziler üzerinde özgürce çalışmanıza izin veriyoruz.
Aslında örtük olarak "soyut yapıların özgürlüğü" yoluyla doğrudan erişim istiyorsunuz. Bu konu tarafımızca iyi çalışılmış ve güvenlik adına mimari olarak ele alınmıştır. MQL5'teki sınıflar, güvenlik vurgusu ile kendi kurallarına göre yaşar. Diğer türlerin tutamaçları olmayacaktır. Basit türler ve yapılar için tutamaçlar yerine dizi dizinlerini kullanabilirsiniz.
MQL5'teki tutamaçların kendileri doğru (birden artan), kontrol edebilirsiniz.
1. Soyut verilerle (ki bu zaten çok sayıda dahili meta veri ve ilişki anlamına gelir) karmaşık bir sistem oluşturmak ve ardından onu zor bir şekilde değiştirilebileceği kontrolsüz bir OpenCL ortamına aktarmak istiyorsunuz. İşte bu yüzden sanal tabloların üzerine yazma yeteneği olmadan yalnızca basit nesneler ve diziler üzerinde özgürce çalışmanıza izin veriyoruz.
2. Aslında örtük olarak "soyut yapıların özgürlüğü" üzerinden doğrudan erişim istiyorsunuz. Bu konu tarafımızca iyi çalışılmış ve güvenlik adına mimari olarak ele alınmıştır. MQL5'teki sınıflar, güvenlik vurgusu ile kendi kurallarına göre yaşar.
3. MQL5'teki tutamaçlar doğrudur (birden başlayarak), kendiniz kontrol edebilirsiniz.
1. Her şey kesinlikle tam tersidir. Herhangi bir meta veri (tutamaç) olmadan kesinlikle saf verileri arabelleğe aktarmak istiyorum. mql5 işleme içinde rahat çalışma için tutamaçlar gereklidir. Bu meta verilere arabellekte ihtiyacım yok. Bana müdahale ediyorlar. Ve onları oraya koyamayacağım - CLBufferWrite() izin vermiyor. Ve doğru.
2. Gerçekten herhangi bir doğrudan erişim istemiyorum . Doğrudan erişim için (isterseniz) bir DLL kullanabilirim. Normal memcpy()
aPointer = memcpy(a,a);
ham işaretçi alma sorununu çözer. Renat, asıl sorunu çözmeye çalış. Var olmayan herhangi bir "aslında" icat etmeyin. Aslında olan her şey - Ben doğrudan ve denizaltılar olmadan talepte açıklanmıştır. Mümkün olduğunca yapıcı ve güvenlik konularını tam olarak anlayarak.
3. Bu harika.
--
Yapıların dinamik olarak oluşturulması ve silinmesi (yeni, silme) yapılmasına hiç gerek yoktur. Hatta hiçbir şekilde. O zaman güvenlik sorunu olmayacak. Sorunun "gerçekten" ne olduğunu anlıyorum (sizin dilinizde). Dinamik nesneler için gerçek türü belirleme sorunu var. Sınıflar için, büyük olasılıkla VMT'ye yönelik işaretçinin analizi yoluyla çözülür. Ancak: dinamik yapılar yoktur - böyle bir sorun yoktur.
Herhangi bir ölçekteki bir varlıkla ilgili olarak bir "tutamaç"ın ne olduğunu düşünün?
Sayı olarak makul olan nesnelere (sınıflar, dosyalar vb.) tanıtıcı sağlamak mümkündür. Ancak, herhangi bir boyuttaki dizi alanına giderseniz, herhangi bir tutamaç, yalnızca bir bellek parçasına doğrudan bağlantı olma şansına sahiptir. Aksi takdirde, "handle -> memory" eşleme tablosu başvurulan varlıktan daha fazla bellek tüketecektir.
Ve güvenlik durumuna bağlı olarak, doğrudan belleğe işaret eden tutamaçlara sahip olamazsınız. Bu nedenle, "herhangi bir sınırsız varlık" için tanıtıcı yoktur.
Renat :
1. Sayısı makul olan nesnelere (sınıflar, dosyalar vb.) tanıtıcılar sağlayabilirsiniz. Ancak, herhangi bir boyuttaki dizi alanına giderseniz, herhangi bir tutamaç, yalnızca bir bellek parçasına doğrudan bağlantı olma şansına sahiptir. Aksi takdirde, "handle -> memory" eşleme tablosu başvurulan varlıktan daha fazla bellek tüketecektir.
2. Ve güvenlik durumuna bağlı olarak, doğrudan belleğe işaret eden tutamaçlara sahip olamazsınız. Bu nedenle, "herhangi bir sınırsız varlık" için tanıtıcı yoktur.
1. Yapıcı iyidir. Düşündüm. Sorun tam olarak büyük yapılarla bağlantılı olarak ortaya çıktı. Küçük yapılar için kopyalama süresi zaten kısadır. Burada bana öyle geliyor ki, sorunlar yalnızca kullanıcının mantıksızlığı nedeniyle ortaya çıkabilir. Ancak "aptallıktan" ve böylece belleği herhangi bir şeyle doldurabilirsiniz (örneğin, gösterge arabellekleriyle bile). Kesinlikle gerekli olmadıkça kimsenin tutamaçları statik yapılara tercih etmesini beklemiyorum. Eh, hafıza taşacak - bu onun kendi hatası. İnsanların aptallıkları hakkında çok fazla endişelenmeyin, aynı şekilde, her şeyi önlemenin (ve hatta tahmin etmenin) bir yolu yoktur. :)
2. Hayır, hayır. Doğrudan işaretçiler gerekli değildir. Ancak tutamaçlar, "herhangi bir sınırsız varlık için" bile zarar vermez. Ana şey, onları kullanma zorunluluğu olmamasıdır. O zaman herkes için yeterli hafıza olacak. :)
Ah, kahretsin, burada ne mızrak kırdığını anlamıyorum. Tutamaçlar istiyorsanız, yapılarınızı sınıflar olarak bildirin , mesele bu.
Belleğe doğrudan erişmek istiyorsanız dll yazın.
Ah, kahretsin, burada ne mızrak kırdığını anlamıyorum.
1. Eğer tutamaçlar istiyorsanız, yapılarınızı sınıflar olarak tanımlayın , mesele bu.
2. Belleğe doğrudan erişmek istiyorsanız dll yazın.
1. Sorunlu olduğu nokta tam da bu. Tampona bir dizi sınıf yazmam gerekmiyor (ve bu imkansız). Orada yapıları yazmam gerekiyor. Ve hızlı bir şekilde (sınıflardan yapılara üye bazında yeniden yazma olmadan). Ve yeniden sıralanmış erişim için tutamaçlara ihtiyaç vardır (ayrıca farklı tuşlara göre sıralama için).
Bir değiştirme, kendi dizin tablom olabilir - ancak daha sonra, bir kez yazılmış hizmetlerle birlikte (sıralama ve ikili arama) devralma olasılığı olan bir dizi yapıyla kapsülleyen bir sınıf yapamam.
2. İstemiyorum! !! !!! Maviden dikmek için bana yeter! :))
Hayır, bu tür kulplar yapmayacağız. Bu, sonuna kadar cevap vermek zorunda kalacağımız açık bir kötülük.
İdeal çözüm parametreleştirilebilir sınıflar olacaktır.
class MyClass<T> { T MyArray[]; .... };Ama artık üzerinde durmuyorum. Belki boşuna?