การใช้ 'อัตโนมัติ' ของ C ++ 11 สามารถปรับปรุงประสิทธิภาพได้หรือไม่

ฉันเห็นได้ว่าทำไมautoประเภทใน C ++ 11 ช่วยปรับปรุงความถูกต้องและการบำรุงรักษา ฉันอ่านแล้วว่ามันยังสามารถปรับปรุงประสิทธิภาพได้ ( เกือบจะอัตโนมัติทุกครั้งโดย Herb Sutter) แต่ฉันพลาดคำอธิบายที่ดี

• จะautoปรับปรุงประสิทธิภาพได้อย่างไร
• ใครสามารถยกตัวอย่างได้บ้าง

autoสามารถช่วยประสิทธิภาพการทำงานโดยการหลีกเลี่ยงการแปลงนัยเงียบ ตัวอย่างที่ฉันคิดว่าน่าสนใจมีดังต่อไปนี้

std::map<Key, Val> m;
// ...

for (std::pair<Key, Val> const& item : m) {
    // do stuff
}

เห็นข้อบกพร่องหรือไม่ ที่นี่เราคิดว่าเราใช้ทุกรายการในแผนที่โดยการอ้างอิง const และใช้ช่วงใหม่สำหรับการแสดงออกเพื่อทำให้เจตนาของเราชัดเจน แต่จริงๆแล้วเรากำลังคัดลอกทุกองค์ประกอบ นี้เป็นเพราะstd::map<Key, Val>::value_typeเป็นไม่ได้std::pair<const Key, Val> std::pair<Key, Val>ดังนั้นเมื่อเรา (โดยนัย) มี:

std::pair<Key, Val> const& item = *iter;

แทนที่จะทำการอ้างอิงไปยังวัตถุที่มีอยู่แล้วปล่อยให้เป็นแบบนั้นเราต้องทำการแปลงแบบ คุณได้รับอนุญาตให้ทำการอ้างอิง const ไปยังออบเจ็กต์ (หรือชั่วคราว) ประเภทอื่นตราบใดที่ยังมีการแปลงโดยนัยเช่น:

int const& i = 2.0; // perfectly OK

การแปลงประเภทเป็นการแปลงโดยนัยที่ได้รับอนุญาตด้วยเหตุผลเดียวกับที่คุณสามารถแปลงเป็นconst Keya Keyแต่เราต้องสร้างชั่วคราวของประเภทใหม่เพื่อให้อนุญาต ดังนั้นลูปของเราจึงมีประสิทธิภาพ:

std::pair<Key, Val> __tmp = *iter;       // construct a temporary of the correct type
std::pair<Key, Val> const& item = __tmp; // then, take a reference to it

(แน่นอนว่าไม่มี__tmpวัตถุจริงๆมันมีไว้เพื่อประกอบภาพเท่านั้นในความเป็นจริงชั่วคราวที่ไม่มีชื่อจะถูกผูกไว้กับitemตลอดชีวิตของมัน)

เพิ่งเปลี่ยนเป็น:

for (auto const& item : m) {
    // do stuff
}

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

เนื่องจากautoลดขนาดประเภทของนิพจน์การเตรียมใช้งานจึงไม่มีการแปลงประเภทที่เกี่ยวข้อง เมื่อรวมกับอัลกอริธึม templated ซึ่งหมายความว่าคุณจะได้รับการคำนวณโดยตรงมากขึ้นกว่าการสร้างประเภทของตัวเองโดยเฉพาะอย่างยิ่งเมื่อคุณต้องรับมือกับนิพจน์ที่คุณไม่สามารถตั้งชื่อประเภท!

ตัวอย่างทั่วไปมาจาก (ab) โดยใช้std::function:

std::function<bool(T, T)> cmp1 = std::bind(f, _2, 10, _1);  // bad
auto cmp2 = std::bind(f, _2, 10, _1);                       // good
auto cmp3 = [](T a, T b){ return f(b, 10, a); };            // also good

std::stable_partition(begin(x), end(x), cmp?);

ด้วยcmp2และcmp3อัลกอริธึมทั้งหมดสามารถอินไลน์การเปรียบเทียบการเปรียบเทียบในขณะที่ถ้าคุณสร้างstd::functionวัตถุไม่เพียง แต่การโทรไม่สามารถ inline แต่คุณยังต้องผ่านการค้นหา polymorphic ในการลบภายในประเภทของฟังก์ชั่นการห่อหุ้ม

อีกตัวแปรในชุดรูปแบบนี้คือคุณสามารถพูดได้:

auto && f = MakeAThing();

นี่คือการอ้างอิงเสมอถูกผูกไว้กับค่าของนิพจน์การเรียกใช้ฟังก์ชันและไม่เคยสร้างวัตถุเพิ่มเติมใด ๆ หากคุณไม่ทราบชนิดค่าที่ส่งกลับของคุณอาจจะถูกบังคับให้สร้างวัตถุใหม่ (อาจจะเป็นชั่วคราว) T && f = MakeAThing()ผ่านสิ่งที่ต้องการ (ยิ่งไปกว่านั้นauto &&ยังสามารถใช้งานได้เมื่อชนิดส่งคืนไม่สามารถเคลื่อนย้ายได้และค่าส่งคืนจะเป็นค่า prvalue)

มีสองประเภทคือ

autoสามารถหลีกเลี่ยงการลบประเภท มีประเภทที่ไม่สามารถแก้ไขได้ (เช่น lambdas) และประเภทที่เกือบจะไม่มีชื่อ (เช่นผลลัพธ์ของstd::bindหรือเทมเพลตนิพจน์อื่น ๆ ที่คล้าย ๆ )

โดยไม่ต้องคุณสิ้นสุดมีการลบข้อมูลประเภทลงไปบางอย่างเช่นauto std::functionการลบประเภทมีค่าใช้จ่าย

std::function<void()> task1 = []{std::cout << "hello";};
auto task2 = []{std::cout << " world\n";};

task1มีการลบประเภทค่าใช้จ่าย - การจัดสรรฮีปที่เป็นไปได้ความยากในการอินไลน์และค่าใช้จ่ายการเรียกใช้ตารางฟังก์ชันเสมือน task2ไม่มีเลย แลมบ์ดาต้องการรูปแบบการหักอัตโนมัติหรือรูปแบบอื่น ๆ เพื่อจัดเก็บโดยไม่ลบประเภท ประเภทอื่น ๆ นั้นซับซ้อนจนพวกมันต้องการในทางปฏิบัติเท่านั้น

ประการที่สองคุณสามารถพิมพ์ผิด ในบางกรณีประเภทที่ไม่ถูกต้องจะทำงานได้อย่างสมบูรณ์แบบ แต่จะทำให้เกิดสำเนา

Foo const& f = expression();

ถ้าจะรวบรวมexpression()ผลตอบแทนBar const&หรือBarหรือแม้กระทั่งการBar&ที่สามารถสร้างขึ้นมาจากFoo Barชั่วคราวFooจะถูกสร้างจากนั้นผูกติดกับfและอายุการใช้งานของมันจะขยายออกไปจนกว่าfจะหายไป

โปรแกรมเมอร์อาจมีความหมายBar const& fและไม่ได้ตั้งใจจะทำสำเนาที่นั่น แต่ทำสำเนาโดยไม่คำนึงถึง

ตัวอย่างที่พบบ่อยที่สุดคือประเภทของ*std::map<A,B>::const_iteratorซึ่งstd::pair<A const, B> const&ไม่ใช่std::pair<A,B> const&แต่ข้อผิดพลาดเป็นหมวดหมู่ของข้อผิดพลาดที่เงียบประสิทธิภาพ คุณสามารถสร้างจากstd::pair<A, B> std::pair<const A, B>(กุญแจบนแผนที่คือ const เพราะการแก้ไขมันเป็นความคิดที่ไม่ดี)

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

คำตอบสามคำตอบที่มีอยู่ให้ตัวอย่างที่การใช้autoช่วย"ทำให้มีโอกาสน้อยที่จะทำให้ลดราคาโดยไม่ตั้งใจ" ได้อย่างมีประสิทธิภาพทำให้ "ปรับปรุงประสิทธิภาพ"

มีด้านพลิกไปที่เหรียญ การใช้autoกับออบเจ็กต์ที่มีโอเปอเรเตอร์ที่ไม่ส่งคืนออบเจคพื้นฐานอาจส่งผลให้โค้ดไม่ถูกต้อง (ยังคงคอมไพล์และสามารถรันได้) ตัวอย่างเช่นคำถามนี้ถามว่าการใช้งานautoให้ผลลัพธ์ที่แตกต่าง (ไม่ถูกต้อง) โดยใช้ห้องสมุด Eigen อย่างไรเช่นบรรทัดต่อไปนี้

const auto    resAuto    = Ha + Vector3(0.,0.,j * 2.567);
const Vector3 resVector3 = Ha + Vector3(0.,0.,j * 2.567);

std::cout << "resAuto = " << resAuto <<std::endl;
std::cout << "resVector3 = " << resVector3 <<std::endl;

ส่งผลให้ผลผลิตที่แตกต่างกัน เป็นที่ยอมรับว่าส่วนใหญ่เป็นผลมาจากการประเมิน Eigens ขี้เกียจ แต่รหัสนั้น / ควรจะโปร่งใสกับผู้ใช้ (ห้องสมุด)

ในขณะที่ประสิทธิภาพไม่ได้รับผลกระทบมากที่นี่การใช้autoเพื่อหลีกเลี่ยงการมองในแง่ร้ายโดยไม่เจตนาอาจจัดเป็นการเพิ่มประสิทธิภาพก่อนกำหนดหรืออย่างน้อยก็ผิด)