Beberapa kasus umum di mana urutan evaluasi sejauh ini belum ditentukan , ditetapkan dan valid dengan C++17. Beberapa perilaku tidak terdefinisi kini malah tidak ditentukan.
i = 1;
f(i++, i)
tidak ditentukan, namun sekarang tidak ditentukan. Secara khusus, yang tidak ditentukan adalah urutan di mana setiap argumen fdievaluasi relatif terhadap yang lain. i++mungkin dievaluasi sebelumnya i, atau sebaliknya. Memang, itu mungkin mengevaluasi panggilan kedua dalam urutan yang berbeda, meskipun berada di bawah compiler yang sama.
Namun, evaluasi setiap argumen diperlukan untuk mengeksekusi secara lengkap, dengan semua efek samping, sebelum eksekusi argumen lainnya. Jadi Anda mungkin mendapatkan f(1, 1)(argumen kedua dievaluasi terlebih dahulu) atau f(1, 2)(argumen pertama dievaluasi terlebih dahulu). Tapi Anda tidak akan pernah mendapatkan f(2, 2)atau apapun dari sifat itu.
std::cout << f() << f() << f();
tidak ditentukan, tetapi akan kompatibel dengan prioritas operator sehingga evaluasi pertama fakan didahulukan dalam aliran (contoh di bawah).
f(g(), h(), j());
masih memiliki urutan evaluasi yang tidak ditentukan dari g, h, dan j. Perhatikan bahwa untuk getf()(g(),h(),j()), aturan state yang getf()akan dievaluasi sebelumnya g, h, j.
Perhatikan juga contoh berikut dari teks proposal:
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, "");
Contoh ini berasal dari The C ++ Programming Language , edisi ke-4, Stroustrup, dan digunakan untuk perilaku yang tidak ditentukan, tetapi dengan C ++ 17 ini akan berfungsi seperti yang diharapkan. Ada masalah serupa dengan fungsi yang dapat dilanjutkan ( .then( . . . )).
Sebagai contoh lain, pertimbangkan hal berikut:
#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() ;
}
Dengan C ++ 14 dan sebelumnya kita mungkin (dan akan) mendapatkan hasil seperti
play
no,and,Work,All,
dari pada
All,work,and,no,play
Perhatikan bahwa efek di atas sama seperti
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Tapi tetap saja, sebelum C ++ 17 tidak ada jaminan bahwa panggilan pertama akan datang lebih dulu ke streaming.
Referensi: Dari proposal yang diterima :
Ekspresi postfix dievaluasi dari kiri ke kanan. Ini termasuk panggilan fungsi dan ekspresi pemilihan anggota.
Ekspresi tugas dievaluasi dari kanan ke kiri. Ini termasuk tugas gabungan.
Operator untuk operator shift dievaluasi dari kiri ke kanan. Singkatnya, ekspresi berikut dievaluasi dalam urutan a, lalu b, lalu c, lalu d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Lebih lanjut, kami menyarankan aturan tambahan berikut: urutan evaluasi ekspresi yang melibatkan operator yang kelebihan beban ditentukan oleh urutan yang terkait dengan operator bawaan terkait, bukan aturan untuk pemanggilan fungsi.
Edit catatan: Jawaban asli saya salah ditafsirkan a(b1, b2, b3). Urutan b1, b2, b3masih tidak ditentukan. (terima kasih @KABoissonault, semua pemberi komentar.)
Namun, (sebagai @Yakk menunjukkan) dan ini penting: Bahkan ketika b1, b2, b3adalah ekspresi non-sepele, masing-masing dari mereka benar-benar dievaluasi dan diikat ke masing-masing parameter fungsi sebelum yang lain mulai dievaluasi. Standar menyatakan ini seperti ini:
§5.2.2 - Panggilan fungsi 5.2.2.4:
. . . Ekspresi-postfix diurutkan sebelum setiap ekspresi dalam daftar ekspresi dan argumen default apa pun. Setiap penghitungan nilai dan efek samping yang terkait dengan inisialisasi parameter, dan inisialisasi itu sendiri, diurutkan sebelum setiap penghitungan nilai dan efek samping yang terkait dengan inisialisasi parameter berikutnya.
Namun, salah satu kalimat baru ini hilang dari draf GitHub :
Setiap penghitungan nilai dan efek samping yang terkait dengan inisialisasi parameter, dan inisialisasi itu sendiri, diurutkan sebelum setiap penghitungan nilai dan efek samping yang terkait dengan inisialisasi parameter berikutnya.
Contoh adalah ada. Ini memecahkan masalah yang sudah berusia puluhan tahun ( seperti yang dijelaskan oleh Herb Sutter ) dengan pengecualian keamanan di mana hal-hal seperti itu
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
akan bocor jika salah satu panggilan get_raw_a()akan terlempar sebelum pointer mentah lainnya diikat ke parameter smart pointer-nya.
Seperti yang ditunjukkan oleh TC, contohnya cacat karena konstruksi unique_ptr dari pointer mentah bersifat eksplisit, mencegah ini dari kompilasi. *
Catat juga pertanyaan klasik ini (diberi tag C , bukan C ++ ):
int x=0;
x++ + ++x;
masih belum ditentukan.