Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 202
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Normal işlevler, argümanları soldan sağa alır.
Özel - sağdan sola.
Sonuç.
Yani amaçlandı mı?
Yani amaçlandı mı?
Bu, güvenilemeyecek bir UB'dir. Onlar. programın mantığının argümanların değerlendirme sırasına bağlı olduğu durumlardan açıkça kaçınmak gerekir.
Normal işlevler, argümanları soldan sağa alır.
İşte bir karşı örnek:
Sonuç: 2 1
Bu, güvenilemeyecek bir UB'dir. Onlar. programın mantığının argümanların değerlendirme sırasına bağlı olduğu durumlardan açıkça kaçınmak gerekir.
İşte bir karşı örnek:
Personel ile her şeyin kararsız olduğu ortaya çıktı. Kullanıcı ile - kesinlikle en baştan.
Personel ile her şeyin kararsız olduğu ortaya çıktı. Özel ile - kesinlikle en baştan.
Aradaki fark, normal işlevler (sağdan sola) ve satır içi işlevler (belirsiz sıra) olmasıdır.
satır içi işlevler hiç işlev değildir, yani. onların bir adresi yok. Bu açıdan, standart ve kullanıcı arasında hiçbir fark yoktur, bu nedenle, örneğin, en basit kullanıcı işlevinin (esas olarak satır içi olan) argümanları neden her zaman sağdan sola hesapladığı açık değildir. Gelecekte satır içi işlevler için sıranın değişebileceğini dışlamıyorum, bu nedenle
Bir keresinde, hesaplama sırasını güvenle kullanmak için satır içi anahtar kelimeyi tanıtmayı önermiştim:
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Hatalar, hatalar, sorular
A100 , 2017.10.05 14:30
Bu, C++ satır içi anahtar sözcüğünün kullanışlılığını bir kez daha kanıtlıyor (burada eski olduğu iddia edilen bir görüş vardı).
Diğer şeylerin yanı sıra, satır içi aslında programcının işlev parametrelerinin değerlendirme sırasını kullanmayı reddettiği anlamına gelir ve derleyici işlevi satır içi yapmaya karar verirse, derleyici doğrudan değerlendirme sırasını daha verimli olarak kullanabilir (tersi değerlendirme açıkça yalnızca çağrılan işlevler için etkilidir).
Aynı zamanda, derleyici satır içi olmayan bir işlevi satır içi yapmaya karar verirse, bu, verimlilik kaybına yol açsa bile (genel) ters değerlendirme sırasını kullanmalıdır (çünkü programcı, bildirimde bulunmadan bu sıraya güvenmiştir). işlev satır içi)
değerlendirme sırasının açıkça kontrol edilemediği MQL'de satır içi de uygun olacaktır.
Aradaki fark, normal işlevler (sağdan sola) ve satır içi işlevler (belirsiz sıra) olmasıdır.
satır içi işlevler hiç işlev değildir, yani. onların bir adresi yok. Bu açıdan, standart ve kullanıcı arasında hiçbir fark yoktur, bu nedenle, örneğin, en basit kullanıcı işlevinin (esas olarak satır içi olan) argümanları neden her zaman sağdan sola hesapladığı açık değildir. Gelecekte satır içi işlevler için sıranın değişebileceğini dışlamıyorum, bu nedenle
Bir keresinde, hesaplama sırasını güvenle kullanmak için satır içi anahtar kelimeyi tanıtmayı önermiştim:
Açıklama için teşekkürler, satır içi hakkında düşünmedim.
Bu seçenek sonucu etkilemez.
Açıklama için teşekkürler, satır içi hakkında düşünmedim.
Bu seçenek sonucu etkilemez.
Şimdi etkilemiyor, çünkü MQL'de şimdi orada değil gibi görünüyor
ve gelecekte gerçek anlamla doldurulabilir, yoksa neden tanıtılsın ki?
Şimdi etkilemiyor, çünkü MQL'de şimdi orada değil gibi görünüyor
ve gelecekte gerçek anlamla doldurulabilir, yoksa neden tanıtılsın ki?
Sürümün yardımından hatırladığım kadarıyla, *.h dosyalarının satır içine alınabilmesi için onu bir saplama olarak tanıtmışlardı.