![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Soru 1: Belgelerde bir yazım hatası olduğunu ve "Son okuma tarihi" yerine "Son açılış tarihi" gibi bir şey olması gerektiğini düşünüyor musunuz?
Evet, kelimesi kelimesine:
Dosyaya veya dizine en son erişildiği tarih ve saati almak için bir FILETIME yapısına yönelik bir işaretçi. Son erişim zamanı, dosya veya dizinin son yazıldığı, okunduğu veya yürütülebilir dosyalar olması durumunda çalıştırıldığı zamanı içerir.
Ücretsiz çeviri -- son erişim, dosyanın en son ne zaman okunduğunu, yazıldığını veya yürütüldüğünü (çalıştırılabilirse) içerir.
Kulpun tekrar kapanması konusunda muhtemelen yanılıyorum ama şöyle ilginç bir metin de var:
Tüm dosya sistemleri oluşturma ve son erişim zamanlarını kaydedemez ve tüm dosya sistemleri bunları aynı şekilde kaydetmez. Örneğin, FAT'ta oluşturma zamanı 10 milisaniyelik bir çözünürlüğe sahiptir, yazma zamanı 2 saniyelik bir çözünürlüğe sahiptir ve erişim zamanı 1 gün (aslında erişim tarihi) bir çözünürlüğe sahiptir. Bu nedenle, GetFileTime işlevi, SetFileTime işlevi kullanılarak ayarlanan aynı dosya saati bilgisini döndürmeyebilir.
NTFS, bir dosyanın son erişim zamanına yönelik güncellemeleri son erişimden sonra bir saate kadar geciktirir. NTFS, son erişim zamanı güncellemelerinin devre dışı bırakılmasına da izin verir. Son erişim zamanı, varsayılan olarak NTFS birimlerinde güncellenmez.
Mevcut durumda, tutamacı "yeniden açmadan" dosya özellikleri elde edildiğinde mutluluk beklenir.
Evet, kelimesi kelimesine:
Ücretsiz çeviri -- son erişim, dosyanın en son ne zaman okunduğunu, yazıldığını veya yürütüldüğünü (çalıştırılabilirse) içerir.
Kulpun tekrar kapanması konusunda muhtemelen yanılıyorum ama şöyle ilginç bir metin de var:
Görünüşe göre mutluluk olmayacak, en azından saniyeler söz konusu olduğunda.
Ufkunuzu genişlettiğiniz için teşekkür ederiz! M-dya... Serseri-efendim.
Bu komut dosyası, "Son okuma tarihi" yerine, FILE_ACCESS_DATE tanımlayıcısının genellikle önceki dosya kapanış saatini döndürdüğünü söylüyor:
Ancak, çılgın sonuçlara rağmen, testler hala gösterge niteliğindedir, bu nedenle geliştiricilerin, herhangi bir değişiklik olmadığında işlevin nasıl çalıştığına dair yorumlarını bekliyoruz.
Bana öyle geliyor ki FileClose yerine FileFlush kullanılırsa programı yavaşlatmamalı/hızlandırmamalı.
Her yazmada bir döngüde kullanmak mantıklı değil. Belgedeki her değişiklikten sonra yeniden kaydedilirse Word'ün çalışmasının nasıl yavaşlayacağını hayal edin (özellikle bu belgede bir sürü metin ve resim varsa). FileFLush yalnızca dosyaları kapatmadan kaydetmeyi kolaylaştırır.
Belki de geliştiriciler bunu kastetmiştir (örneğin):
OnInit - Dosya Aç
On Tick - FileWrite FileFlush
(ve burada veriler kaydedilir -FileFlash - döngüde, döngünün her geçişinde değil, döngünün bitiminden sonra)
OnDeinitFileClose.
FileFlash'ın özü, dosya tanıtıcısını ve mistik dosya arabelleğini sürekli olarak yeniden başlatmamak için danışmanın çalışması sırasında her zaman ona yazmaktır.
......belki)
Bu arada, son üç aydır hiç yorum almadım, bu yüzden şimdilik FileFlush() işlevini kullanmaktan kaçınıyorum.
FileFlush() işlevini kullanmanın anlamını daha iyi anlamak için, bir dosya giriş/çıkış arabelleği kavramı hakkında düşünmeniz gerekir... içeri gel) israfın yüksekliğidir! Bu işleme "donanım" tarafından bakarsanız, işletim sistemi, bir bayt yazma işlemi için her istekte sabit disk sürücüsünün "kayıt kafasını sarmak" zorunda kalacaktır! Ancak sabit disk kinematiktir! Başka bir deyişle, bilgisayar cihazlarının en yavaşı. Peki o zaman çıkış yolu nedir? Ve çok basit! Bilgisayar belleğinde (genellikle birkaç on kilobayttır) verilerin FileWrite işlevinden ve benzerlerinden gönderildiği bir veri arabelleği oluşturulur, bu arabellek tamamen dolduğunda sistem onu tamamen sabit diske yazar. Sürekli bir veri bloğu biçiminde, sürücü kafasında gereksiz manipülasyon yok, ancak veriler tek bir hamlede yazılıyor! Şimdi 32 kilobaytlık bilgiyi bir seferde yazma hızının, aynı hacimdeki her bir baytı ayrı ayrı yazmaya kıyasla kaç kat arttığını hesaplayın ;) Ve hesaplaması oldukça basit... Her yazma işlemi için önce sürücü kafası konumlandırılır, sonra kayıt yapılır. Ve bu, okuma/yazma sırasında sabit diskin tüm "ağır" çalışmasına girmiyor bile :) Bir tampon durumunda, kafayı bir kez konumlandırıyoruz ve tüm bloğu tek bir akışta yazıyoruz!
Ancak tüm bunlar, arabelleğiniz dolana kadar, verilerinizin dosyada (!!!) fiziksel olarak görünmeyeceğini veya dosyanın kendisini kapatana kadar, bu durumda arabellek (veya daha doğrusu içinde kalan) olduğunu gösterir. hemen diske yazılır. FileFlush işlevinin kurtarmaya geldiği yer burasıdır. Bir dosyaya bazı bilgileri "yazdığınızda" ve dosyada garantili fiziksel görünümüne ihtiyacınız olduğunda (örneğin, bu bilgi başka bir program, gösterge, danışman ... tarafından zaten gerekli olabilir), o zaman FileFlush işlevini çağırabilirsiniz, bu, vidadaki (dosyaya) tamponun içeriğini fiziksel olarak temizleyecektir!
Sonuç: FileFlush işlevinin sık kullanımı veya dosyayla çalışmayı hızlandırmak için döngüler halinde kullanılması, tam tersi bir sonuç verecektir, çünkü her çağrıldığında, sistemin G / Ç arabelleğinde fiilen bulunan bilgi miktarını hesaplaması gerekir. , işletim sistemini çağırın ve verilen hafıza alanını bir dosyaya yazma komutu verin! Örneğin, bir döngüde, bir dosyaya bir bayt yazılır ve hemen FileFlush işlevi çağrılır, diske yazmanın en yavaş yolunu BYBYTE alırız!!! ;)
Peki bir dosyaya yazmanın en hızlı yolu nedir? Evet, çok basit ;) Kafanızı kandırmayın ve FileFlush'a eziyet etmeyin :) Bu durumda, FileWrite ve pano arasında hızlı bir veri alışverişi elde edersiniz (bellek manipülasyonları en hızlıdır) ve sistemin kendisi izleyecektir. bu arabelleğin taşması ve gerekirse, akış yazma verisi (sabit sürücü gibi beceriksiz bir cihazla mümkün olan en hızlı işlem!) ve yeni veri almak için arabelleği temizleme!!!
Sonra soru ortaya çıkıyor - "Neden FileFlush işlevine ihtiyacınız var ???". Ve cevap basit - arabellek doldurmadan bağımsız olarak verilerin dosyaya fiziksel olarak yazılması gerektiğinde gereklidir. Böyle bir ihtiyaca bir örnek yukarıda verilmiştir.
Göstergemi MQL5 için yeniden yazmak zorunda kaldım ve ciddi bir yanlış anlaşılmayla karşılaştım :(
İşte kod:
Hata ayıklayıcıda neler olduğunu görmek için bu kadar çok sayıda değişkenin tanıtıldığını hemen açıklayacağım. Ve gördüm...
Dosya bir grup satır içerir, her satırın ";" ile ayrılmış 5 bölümü vardır. ilk arama
sTF = FileReadString (handle);
tüm dosyayı sTF değişkenine ve anlaşılmaz bir kodlamaya yönlendirir. Hata ayıklayıcıda gördüğüme göre (sTF değişkeninde bazı Çin hiyeroglifleri var), dosyanın içeriğini Unicode olarak okudu! Dosyayı açarken tüm geçerli kod sayfalarını denedim fakat sonuç aynı :( Dosyanın kendisi Windows kodlaması ile yazılmıştır.
Köpeğin nerede dolaştığı hakkında bir fikri olan var mı?
is_vale
Bilgi paylaşan herkese teşekkürler! Konuya tekrar dalacağım.
FILE_ANSI
Köpeğin nerede dolaştığı hakkında bir fikri olan var mı?
Uzun zamandır dosya işlemleriyle çalışmıyorum.Bakın FileOpen() kullanırken bir CSV dosyası bildirmişsiniz. Daha önce, tüm yazılı öğelerin unicode veya ansi dizelerine dönüştürüldüğü belirtilmişti. Belki burada bir köpek vardır?