นี่เป็นข้อผิดพลาดที่ทราบของ C ++ 11 สำหรับลูปหรือไม่?

สมมติว่าเรามีโครงสร้างสำหรับการถือครอง 3 คู่พร้อมฟังก์ชันสมาชิกบางอย่าง:

struct Vector {
  double x, y, z;
  // ...
  Vector &negate() {
    x = -x; y = -y; z = -z;
    return *this;
  }
  Vector &normalize() {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  // ...
};

นี่เป็นเพียงเล็กน้อยที่ออกแบบมาเพื่อความเรียบง่าย แต่ฉันแน่ใจว่าคุณยอมรับว่ามีรหัสที่คล้ายกันอยู่ที่นั่น วิธีการนี้ช่วยให้คุณเชื่อมโยงได้อย่างสะดวกตัวอย่างเช่น:

Vector v = ...;
v.normalize().negate();

หรือแม้กระทั่ง:

Vector v = Vector{1., 2., 3.}.normalize().negate();

ตอนนี้ถ้าเราให้ฟังก์ชั่นเริ่มต้น () และ end () เราสามารถใช้เวกเตอร์ของเราในรูปแบบใหม่สำหรับการวนซ้ำโดยพูดว่าจะวนรอบพิกัด 3 x, y และ z (คุณไม่ต้องสงสัยเลยว่าสร้างตัวอย่างที่ "มีประโยชน์" มากขึ้น โดยการแทนที่ Vector ด้วยเช่น String):

Vector v = ...;
for (double x : v) { ... }

เราสามารถทำได้:

Vector v = ...;
for (double x : v.normalize().negate()) { ... }

และนอกจากนี้ยังมี:

for (double x : Vector{1., 2., 3.}) { ... }

อย่างไรก็ตามสิ่งต่อไปนี้ (ดูเหมือนสำหรับฉัน) เสีย:

for (double x : Vector{1., 2., 3.}.normalize()) { ... }

ในขณะที่ดูเหมือนเป็นการรวมกันอย่างมีเหตุผลของสองการใช้งานก่อนหน้านี้ แต่ฉันคิดว่าการใช้งานครั้งล่าสุดนี้สร้างการอ้างอิงที่ห้อยลงในขณะที่สองอย่างก่อนหน้านั้นใช้ได้อย่างสมบูรณ์

• สิ่งนี้ถูกต้องและเป็นที่ชื่นชมอย่างกว้างขวางหรือไม่?
• ส่วนไหนของข้างต้นเป็นส่วนที่ "ไม่ดี" ที่ควรหลีกเลี่ยง?
• ภาษาจะได้รับการปรับปรุงโดยการเปลี่ยนนิยามของ range-based for loop เช่นที่ temporaries ที่สร้างใน for-expression มีอยู่ตลอดระยะเวลาของลูปหรือไม่

สิ่งนี้ถูกต้องและเป็นที่ชื่นชมอย่างกว้างขวางหรือไม่?

ใช่ความเข้าใจของคุณถูกต้อง

ส่วนไหนของข้างต้นเป็นส่วนที่ "ไม่ดี" ที่ควรหลีกเลี่ยง?

ส่วนที่ไม่ดีคือการอ้างอิงค่า l ไปยังการส่งคืนชั่วคราวจากฟังก์ชันและผูกเข้ากับการอ้างอิงค่า r มันแย่พอ ๆ กับสิ่งนี้:

auto &&t = Vector{1., 2., 3.}.normalize();

Vector{1., 2., 3.}ไม่สามารถขยายอายุการใช้งานชั่วคราวได้เนื่องจากคอมไพลเลอร์ไม่ทราบว่าค่าที่ส่งคืนจากnormalizeการอ้างอิงนั้น

ภาษาจะได้รับการปรับปรุงโดยการเปลี่ยนนิยามของ range-based for loop เช่นที่ temporaries ที่สร้างใน for-expression มีอยู่ตลอดระยะเวลาของลูปหรือไม่

ซึ่งจะไม่สอดคล้องอย่างมากกับวิธีการทำงานของ C ++

มันจะป้องกันไม่ให้ gotchas บางอย่างที่สร้างขึ้นโดยผู้คนโดยใช้นิพจน์ที่ถูกล่ามโซ่ไว้ในชั่วขณะหรือวิธีการประเมินความเกียจคร้านต่างๆสำหรับนิพจน์หรือไม่? ใช่. แต่ก็จะต้องใช้โค้ดคอมไพเลอร์กรณีพิเศษเช่นกันและสับสนว่าทำไมจึงไม่ทำงานกับโครงสร้างนิพจน์อื่น

วิธีแก้ปัญหาที่สมเหตุสมผลกว่ามากจะเป็นวิธีแจ้งคอมไพลเลอร์ว่าค่าที่ส่งคืนของฟังก์ชันเป็นข้อมูลอ้างอิงเสมอthisดังนั้นหากค่าที่ส่งคืนถูกผูกไว้กับโครงสร้างที่ขยายชั่วคราวก็จะขยายชั่วคราวที่ถูกต้อง นั่นเป็นวิธีแก้ปัญหาระดับภาษา

ในปัจจุบัน (หากคอมไพเลอร์รองรับ) คุณสามารถสร้างมันขึ้นมาเพื่อที่normalize ไม่สามารถเรียกใช้งานชั่วคราวได้:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector &normalize() && = delete;
};

สิ่งนี้จะทำให้เกิดVector{1., 2., 3.}.normalize()ข้อผิดพลาดในการคอมไพล์ในขณะที่v.normalize()ทำงานได้ดี เห็นได้ชัดว่าคุณจะไม่สามารถแก้ไขสิ่งต่างๆเช่นนี้ได้:

Vector t = Vector{1., 2., 3.}.normalize();

แต่คุณจะไม่สามารถทำสิ่งที่ไม่ถูกต้องได้เช่นกัน

หรือตามที่แนะนำในความคิดเห็นคุณสามารถทำให้เวอร์ชันอ้างอิง rvalue ส่งคืนค่าแทนการอ้างอิง:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector normalize() && {
     Vector ret = *this;
     ret.normalize();
     return ret;
  }
};

หากVectorเป็นประเภทที่มีทรัพยากรจริงให้ย้ายคุณสามารถใช้Vector ret = std::move(*this);แทนได้ การเพิ่มประสิทธิภาพมูลค่าผลตอบแทนที่ตั้งชื่อทำให้สิ่งนี้เหมาะสมที่สุดในแง่ของประสิทธิภาพ

สำหรับ (x คู่: เวกเตอร์ {1., 2. , 3.}. normalize ()) {... }

นั่นไม่ใช่ข้อ จำกัด ของภาษา แต่เป็นปัญหากับรหัสของคุณ การแสดงออกVector{1., 2., 3.}สร้างชั่วคราว แต่normalizeฟังก์ชั่นส่งกลับlvalue อ้างอิง เนื่องจากนิพจน์เป็นlvalueคอมไพลเลอร์จึงสันนิษฐานว่าอ็อบเจ็กต์จะยังมีชีวิตอยู่ แต่เนื่องจากเป็นการอ้างอิงถึงชั่วคราวอ็อบเจ็กต์จึงตายหลังจากที่นิพจน์แบบเต็มได้รับการประเมินดังนั้นคุณจึงเหลือการอ้างอิงที่ห้อยอยู่

ตอนนี้ถ้าคุณเปลี่ยนการออกแบบเพื่อส่งคืนวัตถุใหม่ตามค่าแทนที่จะเป็นการอ้างอิงไปยังวัตถุปัจจุบันก็จะไม่มีปัญหาและรหัสจะทำงานตามที่คาดไว้

IMHO ตัวอย่างที่สองมีข้อบกพร่องอยู่แล้ว การที่ตัวดำเนินการปรับเปลี่ยนกลับมา*thisนั้นสะดวกในแบบที่คุณพูดถึงนั่นคืออนุญาตให้มีการเชื่อมโยงตัวปรับแต่ง มันสามารถนำมาใช้สำหรับการมอบเพียงผลของการปรับเปลี่ยน แต่การทำเช่นนี้ผิดพลาดได้ง่ายเพราะสามารถมองข้ามได้ง่าย ถ้าฉันเห็นสิ่งที่ชอบ

Vector v{1., 2., 3.};
auto foo = somefunction1(v, 17);
auto bar = somefunction2(true, v, 2, foo);
auto baz = somefunction3(bar.quun(v), 93.2, v.qwarv(foo));

ฉันจะไม่สงสัยโดยอัตโนมัติว่าฟังก์ชั่นปรับเปลี่ยนvเป็นผลข้างเคียง แน่นอนพวกเขาทำได้แต่มันจะสับสน ดังนั้นถ้าฉันจะเขียนอะไรแบบนี้ฉันจะต้องแน่ใจว่ามันvคงที่ สำหรับตัวอย่างของคุณฉันจะเพิ่มฟังก์ชันฟรี

auto normalized(Vector v) -> Vector {return v.normalize();}
auto negated(Vector v) -> Vector {return v.negate();}

จากนั้นเขียนลูป

for( double x : negated(normalized(v)) ) { ... }

และ

for( double x : normalized(Vector{1., 2., 3}) ) { ... }

นั่นคือ IMO อ่านได้ดีกว่าและปลอดภัยกว่า แน่นอนว่าต้องใช้สำเนาพิเศษอย่างไรก็ตามสำหรับข้อมูลที่จัดสรรแบบฮีปสิ่งนี้อาจทำได้ในการย้าย C ++ 11 ราคาถูก