Hatalar, hatalar, sorular - sayfa 2724

Yeni yorum
 
Slava :

Numara. Başka birinin değiştirilen dosyayı okuyabilmesini istiyorsanız FileFlush bir zorunluluktur.

Sorun, MQL5 programının dosyayı açarken kendi arabelleğine okumasıdır. Ve dosyayı tekrar okuyana kadar dosyada bir şeylerin değiştiği gerçeği hakkında hiçbir şey bilmeyecek. Dosyayı ancak bu dosyayı kapatıp açtığınızda tekrar okuyabilirsiniz.

Teşekkürler, sorun bu. Lütfen yukarıda gönderdiğim bağlantıya bakın, onu çoğaltmak için kodu bulacaksınız.

Aynı dosya bir EA'dan açılıyor, 1 tutamaç yazma, 2. okuma, fileflush yazdıktan sonra kullanılıyor, okumaya çalışın ve düzgün çalışmıyor.

Tabii ki kapatırsanız/açarsanız çalışır, ancak o zaman FileFlush kullanmanıza gerek yoktur.

 
Alain Verleyen :

Teşekkürler, sorun bu. Lütfen yukarıda gönderdiğim bağlantıya bakın, onu çoğaltmak için kodu bulacaksınız.

Aynı dosya bir EA'dan açılıyor, 1 tutamaç yazma, 2. okuma, fileflush yazdıktan sonra kullanılıyor, okumaya çalışın ve düzgün çalışmıyor.

Tabii ki kapatırsanız/açarsanız çalışır, ancak o zaman FileFlush kullanmanıza gerek yoktur.

Anlattığınız sorunu anlıyorum.

1. danışman bir dosya yazar. Bu dosyayı kapatmayabilir, ancak bu durumda FileFlush'ı çağırmalıdır.

2. danışman dosyayı okur. Dosyayı her seferinde açmalı, sonra kapatmalıdır.

Sadece ikinci danışman için dosya açma ve kapatma!

 
Slava :

İşte tam da bundan bahsediyorum. Kapat sonra tekrar aç

Yoksa dosyayı kapatmadan önce FileFlush'ı mı kastediyorsunuz?

Evet, kapatmadan önce yıkamanız gerekiyor mu? Veya kapatma, kaydedilen dosyanın güncel olmasını sağlar.

 
Andrey Barinov :

Evet, kapatmadan önce yıkamanız gerekiyor mu? Veya kapatma, kaydedilen dosyanın güncel olmasını sağlar.

Hemen sonra kapatırsanız, yıkama işe yaramaz.
 
Slava :

Anlattığınız sorunu anlıyorum.

1. danışman bir dosya yazar. Bu dosyayı kapatmayabilir, ancak bu durumda FileFlush'ı çağırmalıdır.

2. danışman dosyayı okur. Dosyayı her seferinde açmalı, sonra kapatmalıdır.

Sadece ikinci danışman için dosya açma ve kapatma!

Bunun bir geçici çözüm olduğunu anlıyorum.

Ama hatayı düzeltmek daha iyi olurdu, kolay kolay mümkün değil sanırım?

 
Andrey Barinov :

Evet, kapatmadan önce yıkamanız gerekiyor mu? Veya kapatma, kaydedilen dosyanın güncel olmasını sağlar.

Gerekli değil. Kapatmadan önce FileFlush çağrılmazsa arabellekler otomatik olarak temizlenir

 

Hata МТ5 (derleme 2390) sınıf yapısının açıklamasında kaşlı ayraçların yanlış sayılması.

 class A{};
class B : public A ;  };  // Ok

class C : public A ;     

void OnStart ()
{
   A a;
}                       // Compile Error: '}' - unexpected end of program        
 
Slava :

Dosyayı okuyan Uzman Danışman bu dosyayı kapalı tutmalıdır.

Dosyaların MQL5'te uygulanmasının özelliği, dosyalardan gelen verileri kendi arabelleklerinde maksimum düzeyde tutmalarıdır. Bilgi miktarı arabelleğe sığmayacak kadar büyükse, işaretçiyi dosyanın başına ve ardından sonuna taşıma hileniz işe yarayabilir.

Şimdilik dosyayı açın , içeriğini kontrol edin ve ardından tekrar kapatın.

Yukarıda bildirdiğim gibi (cevapladığınız metinde), özellikle benim test durumumda, her şey tam tersi - gösterge okur, uzman yazar. Ama anladığım kadarıyla programın türü önemli değil. Sorun mimari.

MQL5'te belirtilen dosyaların uygulanması bir hatadır. Dosyayı kapatıp açmak geçici bir çözümdür, ancak paylaşılan bir dosyayı okumak için durum böyle olmamalıdır.

Performans optimizasyonu endişesi iyidir, ancak işlevselliği olumsuz etkilememelidir.

not. Hızlı ve kirli bir düzeltme olarak şu öneri: Okumak için açılan bir dosyadaki FileFlush çağrısına yanıt olarak, arabelleğini güncelleyin.

 
Vict :

Muhtemelen c++ benzer olduğundan ve C'den gelen yapılar oraya geldiği için.

Yapıcılara ihtiyaç var - sınıfları kullanın veya keskinliğe hoş geldiniz. Neden böyle bir çağrışımdan yapıyı mahrum bırakalım? Programlar sadece bundan daha anlamlı hale gelecektir. Burada birinin kodunu alacağım, görüyorum - bir sınıf yerine bir yapı ve sadece bir kelimeden çok fazla bilgi alacağım. Hiçbir şey elde edemezsiniz, anında aldığım sonucu elde etmek için kaynak kodunu özenle çalışacaksınız. Tecrübelerime göre, yapılar üzerindeki bu anlaşmaya saygı duyulur, belki biraz nihilist marjinalizmi mahveder.

C++'da yapılar ve sınıflar bir ve aynıdır. Bu nedenle, "kodların ifade gücü" hakkındaki tüm akıl yürütmeleriniz, şeylerin özünü etkilemez. struct veya class'a ek olarak sizin için başka herhangi bir anlamlı kelimeyi de tanımlayarak tanımlayabilirsiniz ve bu hiçbir şeyi değiştirmeyecek (C ++ hakkında konuşuyorum)

Bu nedenle yapıları sadece C# açısından düşünmelisiniz. Konsept buradan geliyor. Yapılar değer türleridir, bu nedenle sınıflardan çok daha kompakttırlar, polimorfik değildirler ve referans alınamazlar. Sonuncusu özellikle önemlidir.

Orada kötülük yok, sence. Hatta bunu standarda genişlettiler: başlatılmamış unsigned char ve std:: byte'ı okumak tanımsız davranış değildir. POD için başlatmayı toplamak mümkündür. Ve unutmayın - tüm bu başlatma ücretsiz değildir, bu gerçek bir kaynak maliyetidir (CPU, bellek, yürütülebilir boyut). Bunu numara kırıcınızla yaparsanız, bazı mikro denetleyiciler söz konusu olduğunda bu önemli olabilir. Sonuçta, C / C ++ sadece keskin gibi bir vida formu-tokat değildir.

Sadece bir değişkeni başlatmak, talimatların boyutunu %30 artırdı.

Hiç kimse başlatmanın kendi içinde ücretsiz olduğunu söylemez. Ama yine de ihtiyacı olacak. Bu nedenle, başlangıçlı ve başlangıçsız ölçümlerinizin anlamını gerçekten anlamıyorum.

Başka bir şey de, derleyicinin değişkenleri yeniden başlatmamasıdır:

 int a= 0 ;  // Эту инициализацию компилятор вырежет
//...
a= 10 ;

Bunları arka arkaya en az 100 kez başlatabilirsiniz. Bu nedenle, değişkenlerin önceden başlatılması korkusuyla ilgili tüm bu paranoya basitçe gülünçtür. 2020 yolda. Özellikle POD yapılarından bahsediyorsanız. Derleyici, başlatmalarını bir veya iki için hassas bir şekilde optimize eder.

Ön başlatma eksikliği, yalnızca başlatılmamış değişkenlerin okunmasını yasaklayan %100 derleyici denetimi olduğunda kabul edilebilir.

 
Alexey Navoykov :

C++'da yapılar ve sınıflar bir ve aynıdır. Bu nedenle, "kodların ifade gücü" hakkındaki tüm akıl yürütmeleriniz, şeylerin özünü etkilemez. struct veya class'a ek olarak sizin için başka herhangi bir anlamlı kelimeyi define ile tanımlayabilirsiniz ve bu hiçbir şeyi değiştirmeyecek (C ++ hakkında konuşuyorum)

İşte inatçı bir insan))) bu senin için de aynı, tanım yaparak bir şey tanımlamana gerek yok, zaten bir kelime yapısı var. Bunu görmezden gelebilirsiniz, ancak düzgün kodlayıcıların, özelliklerle dolu yapılarınızı gördüklerinde size bir bok kodlayıcı gibi bakacağına şaşırmayın. Belki de haçların başlangıcında bir hataydı - yapıların ve sınıfların haklarını eşitlemek için yapıları C'deki gibi bırakmak gerekiyordu.

Bu nedenle yapıları sadece C# açısından düşünmelisiniz. Konsept buradan geliyor. Yapılar değer türleridir, bu nedenle sınıflardan çok daha kompakttırlar, polimorfik değildirler ve referans alınamazlar. Sonuncusu özellikle önemlidir.

Keskinliğinizin açık bir alanda göründüğünü düşünüyor musunuz? Kökü C'de olan struct, fazladan şeker içermeyen aptal bir kaptır.

Başka bir şey de, derleyicinin değişkenleri yeniden başlatmamasıdır:

 int a= 0 ;  // Эту инициализацию компилятор вырежет
//...
a= 10 ;

Bunları arka arkaya en az 100 kez başlatabilirsiniz. Bu nedenle, değişkenlerin önceden başlatılması korkusuyla ilgili tüm bu paranoya basitçe gülünçtür. 2020 yolda. Özellikle POD yapılarından bahsediyorsanız. Derleyici, başlatmalarını bir veya iki için hassas bir şekilde optimize eder.

Böyle bir güven nereden geliyor? Farklı bir çeviri biriminden/farklı modülden/döngülerden/tür dışı derleyiciden/... . Optimize edicinin yeteneklerini abartmayın. Bu, derleyicilerin yapması gereken bir kopyalama seçme optimizasyonu değildir. Optimize ediciler çok akıllı hale gelir ve bir şeye mal olmayı bırakırsa, bir sonraki C standardında şunu yazarlar: "varsayılan başlatma, bir nesneyi belirsiz bir durumda bırakmaz."
1...271727182719272027212722272327242725272627272728272927302731...3184
Yeni yorum