Şimdiye kadar değerlendirme sırasının belirtilmemiş olduğu bazı yaygın durumlar ile belirtilir ve geçerlidir C++17. Bazı tanımlanmamış davranışlar artık bunun yerine belirtilmemiş durumda.
i = 1;
f(i++, i)
tanımsızdı, ancak şimdi belirtilmedi. Spesifik olarak belirtilmeyen, her bir argümanın fdiğerlerine göre değerlendirildiği sıradır . i++daha önce iveya tam tersi değerlendirilebilir. Aslında, aynı derleyici altında olmasına rağmen ikinci bir çağrıyı farklı bir sırada değerlendirebilir.
Bununla birlikte, her bir argümanın değerlendirilmesi , herhangi bir başka argümanın yürütülmesinden önce tüm yan etkilerle birlikte tamamen yürütülmesi için gereklidir . Yani f(1, 1)(ikinci argüman ilk değerlendirilir) veya f(1, 2)(ilk argüman ilk değerlendirilir) alabilirsiniz. Ama asla f(2, 2)bu türden bir şey alamayacaksın .
std::cout << f() << f() << f();
belirtilmedi, ancak operatör önceliğiyle uyumlu hale gelecek ve böylece ilk değerlendirme fakışta ilk sırada olacak (aşağıdaki örnekler).
f(g(), h(), j());
hala belirtilmemiş g, h ve j değerlendirme sırasına sahiptir. Söz konusu Not getf()(g(),h(),j()), kurallar devlet o getf()önce değerlendirilir g, h, j.
Ayrıca, teklif metninden aşağıdaki örneğe dikkat edin:
std::string s = "but I have heard it works even if you don't believe in it"
s.replace(0, 4, "").replace(s.find("even"), 4, "only")
.replace(s.find(" don't"), 6, "");
Örnek, The C ++ Programming Language , 4th edition, Stroustrup'tan geliyor ve önceden belirtilmemiş bir davranıştı, ancak C ++ 17 ile beklendiği gibi çalışacak. Devam ettirilebilir işlevlerle ( .then( . . . )) benzer sorunlar vardı .
Başka bir örnek olarak şunları düşünün:
#include <iostream>
#include <string>
#include <vector>
#include <cassert>
struct Speaker{
int i =0;
Speaker(std::vector<std::string> words) :words(words) {}
std::vector<std::string> words;
std::string operator()(){
assert(words.size()>0);
if(i==words.size()) i=0;
auto word = words[i] + (i+1==words.size()?"\n":",");
++i;
return word;
}
};
int main() {
auto spk = Speaker{{"All", "Work", "and", "no", "play"}};
std::cout << spk() << spk() << spk() << spk() << spk() ;
}
C ++ 14 ile ve öncesinde aşağıdaki gibi sonuçlar alabiliriz (ve alacağız):
play
no,and,Work,All,
onun yerine
All,work,and,no,play
Yukarıdakilerin aslında aynı olduğuna dikkat edin
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Ancak yine de, C ++ 17'den önce ilk aramaların akışa ilk geleceği garantisi yoktu.
Referanslar: Kabul edilen tekliften :
Sonek ifadeleri soldan sağa doğru değerlendirilir. Bu, işlev çağrılarını ve üye seçim ifadelerini içerir.
Atama ifadeleri sağdan sola doğru değerlendirilir. Bu, bileşik atamaları içerir.
Operatörleri kaydırmak için işlenenler soldan sağa doğru değerlendirilir. Özetle, aşağıdaki ifadeler a, sonra b, sonra c, sonra d sırasıyla değerlendirilir:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Ayrıca, aşağıdaki ek kuralı öneriyoruz: aşırı yüklenmiş bir operatörü içeren bir ifadenin değerlendirme sırası, işlev çağrıları için kurallar değil, karşılık gelen yerleşik operatörle ilişkili sırayla belirlenir.
Notu düzenle: Orijinal cevabım yanlış yorumlandı a(b1, b2, b3). Sırası b1, b2, b3hala belirsizdir. (teşekkür ederim @KABoissonneault, tüm yorumcular.)
Ancak, (@Yakk işaret ettiği gibi) ve bu önemli: dahi b1, b2, b3, önemsiz olmayan ifadelerdir her biri tamamen değerlendirilir ve ilgili fonksiyon parametreye bağlı Diğerleri değerlendirilmeye başlanmıştır önce. Standart bunu şu şekilde ifade eder:
§5.2.2 - İşlev çağrısı 5.2.2.4:
. . . Sonek ifadesi, ifade listesindeki her ifadeden ve herhangi bir varsayılan bağımsız değişkenden önce sıralanır. Bir parametrenin başlatılmasıyla ilişkili her değer hesaplaması ve yan etki ve başlatmanın kendisi, her değer hesaplamasından ve sonraki herhangi bir parametrenin başlatılmasıyla ilişkili yan etkiden önce sıralanır.
Ancak, GitHub taslağında şu yeni cümlelerden biri eksik :
Bir parametrenin başlatılmasıyla ilişkili her değer hesaplaması ve yan etki ve başlatmanın kendisi, her değer hesaplamasından ve sonraki herhangi bir parametrenin başlatılmasıyla ilişkili yan etkiden önce sıralanır.
Örnek olduğunu var. Onlarca yıllık sorunları ( Herb Sutter tarafından açıklandığı gibi ) istisnai güvenlik ile çözer.
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
çağrılardan biri get_raw_a(), diğer ham işaretçi akıllı işaretçi parametresine bağlanmadan önce atarsa sızıntı olur .
TC'nin belirttiği gibi, ham göstericiden benzersiz_ptr yapısı açık olduğundan, bunun derlenmesini engellediğinden örnek kusurludur. *
Ayrıca, bu klasik not soruyu (etiketli C , değil C ++ ):
int x=0;
x++ + ++x;
hala tanımsız.