เกิดอะไรขึ้นกับ cplusplus.com

นี่อาจไม่ใช่ฟอรัมที่เหมาะสมอย่างสมบูรณ์แบบสำหรับคำถามนี้ แต่ให้ฉันลองดูด้วยความเสี่ยงที่จะถูกย้ายออกไป

มีหลายที่อ้างอิงสำหรับไลบรารีมาตรฐาน C ++ รวมทั้งมาตรฐาน ISO ที่ทรงคุณค่ามีMSDN , IBM , cppreferenceและcplusplus โดยส่วนตัวเมื่อเขียน C ++ ฉันต้องการการอ้างอิงที่มีการเข้าถึงแบบสุ่มอย่างรวดเร็วเวลาโหลดสั้นและตัวอย่างการใช้งานและฉันได้พบว่า cplusplus.com มีประโยชน์มาก อย่างไรก็ตามฉันได้รับฟังความคิดเห็นเชิงลบเกี่ยวกับเว็บไซต์นั้นบ่อยครั้งที่นี่ดังนั้นฉันจึงต้องการเจาะจง:

ข้อผิดพลาดความเข้าใจผิดหรือคำแนะนำที่ไม่ดีที่ได้รับจาก cplusplus.com คืออะไร อะไรคือความเสี่ยงของการใช้มันเพื่อตัดสินใจการเข้ารหัส?

ให้ฉันเพิ่มจุดนี้: ฉันต้องการที่จะสามารถตอบคำถามที่นี่ใน SO ด้วยคำพูดที่ถูกต้องของมาตรฐานและดังนั้นฉันต้องการโพสต์ลิงค์ที่ใช้งานได้ทันทีและ cplusplus.com จะเป็นเว็บไซต์ที่ฉันเลือกไม่ได้ ปัญหานี้

แก้ไข:เอกสารสำหรับstd::removeได้รับการแก้ไขตั้งแต่คำตอบนี้ถูกเขียน list::removeสิ่งเดียวที่จะนำไปใช้

ให้ฉันยกตัวอย่างให้คุณดูว่า cpluscplus.com จะทำให้มันผิดได้อย่างไร

พิจารณาฟังก์ชั่นจากstd::remove<algorithm>

ความจริงก็คือstd::removeว่าไม่ได้ลบรายการจากภาชนะ มันเป็นเพราะstd::removeทำงานร่วมกับ iterators คู่เดียวเท่านั้นและไม่ทราบอะไรเกี่ยวกับภาชนะที่บรรจุสิ่งของจริงๆ ในความเป็นจริงมันเป็นไปไม่ได้ที่std::removeจะรู้ว่าคอนเทนเนอร์พื้นฐานเพราะมันไม่มีทางที่มันจะไปจากคู่ของตัววนซ้ำเพื่อค้นหาเกี่ยวกับคอนเทนเนอร์ที่ตัววนซ้ำอยู่ ดังนั้นstd::removeไม่ได้โดดลบรายการที่เพียงเพราะมันไม่สามารถ วิธีเดียวที่จะจริงเอารายการออกจากภาชนะคือการเรียกใช้ฟังก์ชันสมาชิกในภาชนะที่

ดังนั้นหากคุณต้องการที่จะลบรายการให้ใช้Erase-Remove Idiom :

 v.erase(std::remove(v.begin(), v.end(), 10), v.end()); 

แต่cplusplus.comจะช่วยให้ไม่ถูกต้องstd::removeข้อมูลเกี่ยวกับ มันบอกว่า

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

ซึ่งไม่ถูกต้อง ตัววนซ้ำในช่วง[new_end, old_end)ยังคงถูกยกเลิกการลงทะเบียนแต่นั่นไม่ได้หมายความว่าจะเก็บค่าเก่าไว้และยังคงสามารถเข้าถึงได้ พวกเขาไม่ได้ระบุ

ในทำนองเดียวกันcplusplus.comให้ข้อมูลที่ไม่ถูกต้องเกี่ยวกับlist::removeเช่นกัน มันบอกว่า ,

ขอให้สังเกตว่าฟังก์ชั่นอัลกอริทึมทั่วโลกลบอยู่กับพฤติกรรมที่คล้ายกันแต่การดำเนินงานระหว่างสองซ้ำ

ซึ่งผิดอย่างสมบูรณ์ เอาโลกคือstd::removeไม่ได้คล้ายกับlist::removeที่เราเห็นว่าอดีตไม่ได้โดดลบรายการจากภาชนะเพราะมันไม่สามารถในขณะที่หลัง (ฟังก์ชั่นสมาชิก) จริงๆไม่เอารายการเพราะมันสามารถ

คำตอบนี้ถูกคัดลอกมาจากคำตอบอื่นในหัวข้อต่อไปนี้โดยมีการดัดแปลงเล็กน้อย:

• การลบ STL ไม่ทำงานอย่างที่คาดไว้

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

ฉันจะเสนอความเห็นเล็กน้อยไปในทางตรงกันข้าม มีข้อมูลที่ดีมากมายใน cplusplus.com เลือกที่จะตายและใช่แน่นอนมันมีปัญหา แต่สิ่งที่เว็บไซต์ไม่ได้? ไม่แน่นอนเว็บไซต์นี้ คนที่อาศัยอยู่ในเรือนกระจกไม่ควรโยนก้อนหิน มีข้อมูลที่ผิดมากมายที่นี่เช่นกัน มีคำตอบที่ยอมรับซึ่งถูกแบนออกผิดคำตอบ downvote (ลบบาง!) ที่ถูกต้อง

ปัญหาหนึ่งของ cplusplus.com คือเว็บไซต์ดังกล่าวเป็นเว็บไซต์ปิด เช่นเดียวกันกับเว็บไซต์อ้างอิงอื่น ๆ ส่วนใหญ่ที่กล่าวถึง สิ่งนี้ขัดกับธัญพืชของไซต์ที่พัฒนาโดยชุมชนเช่น Stack Overflow การได้รับความสามารถในการแก้ไขที่เชื่อถือได้นั้นใช้เวลาไม่นานนักและแม้แต่มือใหม่รุ่นใหม่ล่าสุดก็สามารถให้คำแนะนำในการปรับปรุงได้อย่างง่ายดาย เปรียบเทียบกับ cplusplus.com คุณเป็นมือใหม่ตลอดหากคุณไม่ได้อยู่ในทีมงานของพวกเขา แม้ว่าคุณจะเป็นสมาชิกคนสำคัญของ WG21 คุณจะต้องผ่านกลไกการรายงานทางอีเมลของพวกเขาหากคุณเห็นข้อผิดพลาดบางแห่งในไซต์นั้น คำสาปแช่ง!

ทางออกสำหรับเราที่ไซต์นี้เพื่อพัฒนาการอ้างอิง C ++ ของเราเอง การทำงานนี้ค่อนข้างใช้เวลาสักหน่อย เราจะต้องระมัดระวังไม่ให้มีความเชื่องช้า / มีเทคนิคเกินไป เป็นที่ชัดเจนว่า cplusplus.com มีพนักงานด้านเทคนิคอย่างน้อยสองสามคนที่คอยดูแลคนเดินถนน เราจะต้องจัดเก็บข้อมูลอย่างดี คำถามที่พบบ่อยที่นี่มีการจัดระเบียบไม่ดี เราจะต้องระมัดระวังเป็นอย่างมากที่จะไม่พวยตรงจากมาตรฐานมากเกินไป มันผิดกฎหมาย

http://www.cplusplus.com/reference/clibrary/cstring/strncpy/

ไม่สามารถพูดถึงว่า "หากการคัดลอกเกิดขึ้นระหว่างวัตถุที่ทับซ้อนกันพฤติกรรมจะไม่ได้กำหนด" (4.11.2.4 ในมาตรฐาน C89 ฉันไม่มีสำเนาถึงมือของ C90 ซึ่งเป็นสิ่งที่ C ++ 03 อ้างถึงจริง ๆ แต่พวกเขาควรจะแตกต่างกันเฉพาะในสิ่งต่าง ๆ เช่นการกำหนดหมายเลขหน้า)

เอกสารที่ให้โดย cplusplus.com มักจะไม่ถูกต้องหรือไม่สมบูรณ์

เมื่อตัวอย่างดังกล่าวเป็นatoiเอกสารใน cplusplus.com

atoi
ในส่วน Return ไม่มีการกล่าวถึงค่าตอบแทน 0 หากไม่มีการแปลงใด ๆ ที่สามารถทำได้ในขณะที่ใช้ฟังก์ชั่น

cplusplus.com สถานะส่วนส่งคืน "... หากค่าที่แปลงแล้วจะอยู่นอกช่วงของค่าที่สามารถแทนได้โดย int จะทำให้เกิดพฤติกรรมที่ไม่ได้กำหนด"

สิ่งนี้ถูกต้องตามมาตรฐาน " หากค่าตัวเลขของสตริงไม่สามารถแสดงใน int ได้พฤติกรรมจะไม่ได้กำหนด "

อย่างไรก็ตามส่วนไม่เต็มเนื่องจากไม่ได้ระบุว่า 0 เป็นค่าส่งคืนซึ่งอาจทำให้เข้าใจผิด วลี "... ไม่มีการแปลงและส่งคืนค่าศูนย์" ถูกพบมาก่อนในย่อหน้าคำอธิบาย แต่จำเป็นที่จะต้องมีในส่วนReturn

ตัวอย่างซอร์สโค้ดจำนวนมากที่ให้ใน cplusplus.com นั้นไม่ถูกต้อง
มือใหม่จำนวนมากที่ค้นหาข้อมูลอ้างอิงเหล่านี้จะนำไปสู่ข้อผิดพลาดของ ballant

ในการอ้างถึงตัวอย่าง:

แก้ไข: ตัวอย่างที่ฉันอ้างถึงก่อนหน้านี้ไม่ถูกต้อง

เอกสารสำหรับtype_infoพยายามอธิบายtypeidก่อน แต่ล้มเหลว:

Typeid สามารถนำไปใช้โดยตรงกับประเภทซึ่งในกรณีนี้มันจะส่งกลับข้อมูลของมัน หรือไปยังวัตถุซึ่งในกรณีนี้มันจะส่งคืนข้อมูลเกี่ยวกับประเภทของวัตถุ

เมื่อ typeid ถูกนำไปใช้กับตัวชี้การลงทะเบียนกับวัตถุประเภท polymorphic class (คลาสที่ประกาศหรือสืบทอดฟังก์ชันเสมือน) มันจะพิจารณาชนิดไดนามิก (เช่นชนิดของวัตถุที่ได้รับมากที่สุด)

ตอนนี้ย่อหน้าที่สองไม่เห็นด้วยกับวรรคแรก ในtypeid(*ptr), typeidถูกนำไปใช้เพื่อการแสดงออก สิ่งนี้ค่อนข้างสำคัญเนื่องจากความคิดstaticและdynamicประเภทมีความเหมาะสมในบริบทของการแสดงออกไม่ใช่วัตถุ typeid(foo())นอกจากนี้ยังบอลเฉียงกรณีเช่น

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

เอกสารของstd::pair<T1,T2>::operator==บอกว่าองค์ประกอบทั้งสองมีการทดสอบเพื่อความเท่าเทียมกัน เอกสารของstd::pair<T1,T2>::operator<บอกว่าองค์ประกอบที่สองได้รับการพิจารณาเฉพาะในกรณีที่องค์ประกอบแรกมีค่าเท่ากัน

คำว่า "เท่ากัน" จะปรากฏในทั้งสองกรณี T::operator==แต่เฉพาะในกรณีแรกไม่ได้จริงๆหมายถึง ในกรณีที่สองหมายถึงเท่ากับ!(a.first<b.first || b.first<a.first)