ใครเป็นผู้สร้าง / ออกแบบ IOStream ของ C ++ และจะยังถือว่าได้รับการออกแบบมาอย่างดีตามมาตรฐานปัจจุบันหรือไม่ [ปิด]

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

ในความหวังในการได้รับข้อมูลเชิงลึกบางเป็นวิธีการกรอบลำธาร / อนุกรมที่ทันสมัยควรจะได้รับการออกแบบที่ฉันเพิ่งได้ตัวเองสำเนาของหนังสือc ++ มาตรฐาน IOStreams และตำแหน่งที่ตั้งโดย Angelika แลงเกอร์และเคลาส์ Kreft ฉันคิดว่าถ้า IOStreams ไม่ได้รับการออกแบบมาอย่างดีมันจะไม่ทำให้มันอยู่ในไลบรารีมาตรฐาน C ++ ตั้งแต่แรก

หลังจากได้อ่านส่วนต่างๆของหนังสือเล่มนี้ฉันเริ่มมีข้อสงสัยว่า IOStreams สามารถเปรียบเทียบกับเช่น STL จากมุมมองทางสถาปัตยกรรมโดยรวมได้หรือไม่ อ่านเช่นบทสัมภาษณ์ของ Alexander Stepanov ("นักประดิษฐ์" ของ STL)เพื่อเรียนรู้เกี่ยวกับการตัดสินใจในการออกแบบบางอย่างที่เข้าสู่ STL

สิ่งที่ทำให้ฉันประหลาดใจเป็นพิเศษ :

• ดูเหมือนว่าจะไม่ทราบว่าใครเป็นผู้รับผิดชอบการออกแบบโดยรวมของ IOStreams (ฉันชอบอ่านข้อมูลพื้นฐานเกี่ยวกับเรื่องนี้ - มีใครรู้แหล่งข้อมูลดีๆบ้างไหม);

• เมื่อคุณเจาะลึกลงไปใต้พื้นผิวของ IOStreams ในทันทีเช่นหากคุณต้องการขยาย IOStreams ด้วยคลาสของคุณเองคุณจะเข้าสู่อินเทอร์เฟซที่มีชื่อฟังก์ชันสมาชิกที่ค่อนข้างคลุมเครือและสับสนเช่นgetloc/ imbue, uflow/ underflow, snextc/ sbumpc/ sgetc/ sgetn, pbase/ pptr/ epptr(และมี อาจเป็นตัวอย่างที่แย่กว่านั้น) สิ่งนี้ทำให้เข้าใจการออกแบบโดยรวมและการทำงานร่วมกันของชิ้นส่วนเดี่ยวได้ยากขึ้นมาก แม้หนังสือที่ผมกล่าวข้างต้นไม่ได้ช่วยที่มาก (IMHO)

ดังนั้นคำถามของฉัน:

หากคุณมีที่จะตัดสินตามมาตรฐานวิศวกรรมซอฟต์แวร์ของวันนี้ (ถ้ามีจริงเป็นข้อตกลงใด ๆ ทั่วไปเกี่ยวกับเหล่านี้) จะ c ++ 's IOStreams ยังถือว่ามีการออกแบบที่ดี? (ฉันไม่ต้องการพัฒนาทักษะการออกแบบซอฟต์แวร์จากสิ่งที่ถือว่าล้าสมัยโดยทั่วไป)

หลายความคิดที่ไม่ดีรู้สึกพบวิธีที่พวกเขาเป็นมาตรฐาน: auto_ptr, vector<bool>, valarrayและexportเพียงเพื่อชื่อไม่กี่ ดังนั้นฉันจะไม่นำ IOStreams มาเป็นสัญลักษณ์ของการออกแบบที่มีคุณภาพ

IOStreams มีประวัติตาหมากรุก จริงๆแล้วพวกเขาเป็นการนำไลบรารีสตรีมก่อนหน้านี้มาใช้ใหม่ แต่ถูกเขียนขึ้นในช่วงเวลาที่ไม่มีสำนวน C ++ ในปัจจุบันจำนวนมากดังนั้นนักออกแบบจึงไม่ได้รับประโยชน์จากการมองย้อนกลับไป ปัญหาหนึ่งที่เห็นได้ชัดเมื่อเวลาผ่านไปคือแทบจะเป็นไปไม่ได้เลยที่จะใช้ IOStreams ได้อย่างมีประสิทธิภาพเท่ากับ stdio ของ C เนื่องจากการใช้ฟังก์ชันเสมือนจำนวนมากและการส่งต่อไปยังวัตถุบัฟเฟอร์ภายในที่ละเอียดที่สุดและยังต้องขอบคุณความแปลกประหลาดที่ไม่อาจหยั่งรู้ได้ ในวิธีการกำหนดและใช้งานโลแคล ความทรงจำของฉันเกี่ยวกับเรื่องนี้ค่อนข้างคลุมเครือฉันยอมรับ ฉันจำได้ว่ามันเป็นประเด็นที่ถกเถียงกันอย่างหนักเมื่อหลายปีก่อนบน comp.lang.c ++.

เกี่ยวกับผู้ออกแบบห้องสมุดดั้งเดิมนั้น (ไม่น่าแปลกใจ) ที่สร้างขึ้นโดย Bjarne Stroustrup จากนั้นนำไปใช้ใหม่โดย Dave Presotto จากนั้นสิ่งนี้ได้รับการออกแบบใหม่และนำมาใช้ใหม่อีกครั้งโดย Jerry Schwarz สำหรับ Cfront 2.0 โดยใช้แนวคิดของผู้ควบคุมจาก Andrew Koenig ไลบรารีเวอร์ชันมาตรฐานขึ้นอยู่กับการใช้งานนี้

ที่มา "The Design & Evolution of C ++", section 8.3.1.

หากคุณต้องตัดสินตามมาตรฐานวิศวกรรมซอฟต์แวร์ในปัจจุบัน (หากมีข้อตกลงทั่วไปเกี่ยวกับสิ่งเหล่านี้จริง) IOStream ของ C ++ จะยังคงได้รับการพิจารณาว่าได้รับการออกแบบมาอย่างดีหรือไม่? (ฉันไม่ต้องการพัฒนาทักษะการออกแบบซอฟต์แวร์จากสิ่งที่ถือว่าล้าสมัยโดยทั่วไป)

ฉันจะตอบว่าไม่ด้วยเหตุผลหลายประการ:

การจัดการข้อผิดพลาดไม่ดี

operator void*เงื่อนไขข้อผิดพลาดควรมีการรายงานมีข้อยกเว้นไม่ได้กับ

"การวัตถุผีดิบ" ต่อต้านรูปแบบเป็นสิ่งที่ทำให้เกิดข้อผิดพลาดเช่นนี้

การแยกไม่ดีระหว่างการจัดรูปแบบและ I / O

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

นอกจากนี้ยังเพิ่มโอกาสในการเขียนข้อบกพร่องเช่น:

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

หากเป็นเช่นนั้นคุณเขียนว่า:

cout << pad(to_hex(x), 8, '0') << endl;

จะไม่มีบิตสถานะที่เกี่ยวข้องกับการจัดรูปแบบและไม่มีปัญหา

โปรดทราบว่าในภาษา "สมัยใหม่" เช่น Java, C # และ Python อ็อบเจ็กต์ทั้งหมดมีtoString/ ToString/ __str__ฟังก์ชันที่เรียกโดยรูทีน I / O AFAIK มีเพียง C ++ เท่านั้นที่ทำในทางอื่นโดยใช้stringstreamเป็นวิธีมาตรฐานในการแปลงเป็นสตริง

รองรับ i18n ไม่ดี

เอาต์พุตที่ใช้ Iostream จะแยกตัวอักษรสตริงออกเป็นชิ้น ๆ

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

จัดรูปแบบสตริงใส่ประโยคทั้งหมดลงในตัวอักษรสตริง

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

แนวทางหลังนี้ง่ายกว่าในการปรับให้เข้ากับไลบรารีสากลเช่น GNU gettext เนื่องจากการใช้ประโยคทั้งหมดให้บริบทมากขึ้นสำหรับผู้แปล หากรูทีนการจัดรูปแบบสตริงของคุณรองรับการเรียงลำดับใหม่ (เช่น$พารามิเตอร์POSIX printf) ก็จะจัดการความแตกต่างของลำดับคำระหว่างภาษาได้ดีขึ้น

ฉันโพสต์ข้อความนี้เป็นคำตอบแยกต่างหากเนื่องจากเป็นความคิดเห็นที่บริสุทธิ์

การดำเนินการอินพุตและเอาต์พุต (โดยเฉพาะอินพุต) เป็นปัญหาที่ยากมากดังนั้นจึงไม่น่าแปลกใจที่ไลบรารี iostreams เต็มไปด้วย bodges และสิ่งต่างๆที่มีการมองย้อนกลับที่สมบูรณ์แบบน่าจะทำได้ดีกว่า แต่สำหรับฉันแล้วดูเหมือนว่าไลบรารี I / O ทั้งหมดไม่ว่าจะเป็นภาษาอะไรก็ตาม ฉันไม่เคยใช้ภาษาโปรแกรมที่ระบบ I / O เป็นสิ่งสวยงามที่ทำให้ฉันรู้สึกทึ่งในตัวนักออกแบบ ไลบรารี iostreams มีข้อดีโดยเฉพาะเหนือไลบรารี CI / O (ความสามารถในการขยายความสามารถในการพิมพ์ ฯลฯ ) แต่ฉันไม่คิดว่าจะมีใครถือเป็นตัวอย่างของ OO ที่ยอดเยี่ยมหรือการออกแบบทั่วไป

ความคิดเห็นของฉันเกี่ยวกับ C ++ iostreams ได้รับการปรับปรุงอย่างมากเมื่อเวลาผ่านไปโดยเฉพาะอย่างยิ่งหลังจากที่ฉันเริ่มขยายความจริงด้วยการใช้คลาสสตรีมของฉันเอง ฉันเริ่มชื่นชมความสามารถในการขยายตัวและการออกแบบโดยรวมแม้จะมีชื่อฟังก์ชันของสมาชิกที่ไม่ดีอย่างน่าขันเช่นxsputnหรืออะไรก็ตาม โดยไม่คำนึงถึงฉันคิดว่าสตรีม I / O เป็นการปรับปรุงครั้งใหญ่เหนือ C stdio.h ซึ่งไม่มีความปลอดภัยและเต็มไปด้วยข้อบกพร่องด้านความปลอดภัยที่สำคัญ

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

std::stringstream ss;
std::string output_string = "Hello world";
ss << output_string;

...

std::string input_string;
ss >> input_string;
std::cout << input_string;

ที่นี่สิ่งที่เราได้รับจากอินพุตไม่ใช่สิ่งที่เราส่งออกไปยังสตรีมในตอนแรก เนื่องจากตัว<<ดำเนินการส่งออกสตริงทั้งหมดในขณะที่>>ตัวดำเนินการจะอ่านจากสตรีมจนกว่าจะพบอักขระเว้นวรรคเนื่องจากไม่มีข้อมูลความยาวที่เก็บไว้ในสตรีม ดังนั้นแม้ว่าเราจะส่งออกสตริงออบเจ็กต์ที่มีคำว่า "hello world" แต่เราจะป้อนเฉพาะสตริงที่มีคำว่า "hello" เท่านั้น ดังนั้นในขณะที่สตรีมทำหน้าที่เป็นอุปกรณ์อำนวยความสะดวกในการจัดรูปแบบ แต่ก็ล้มเหลวในการทำให้เป็นอนุกรมอย่างถูกต้องจากนั้นจึงยกเลิกการกำหนดค่าเริ่มต้นของวัตถุ

คุณอาจพูดได้ว่าสตรีม IO ไม่ได้ออกแบบมาให้เป็นสิ่งอำนวยความสะดวกในการทำให้เป็นอนุกรม แต่ถ้าเป็นเช่นนั้นอินพุตสตรีมมีไว้เพื่ออะไร นอกจากนี้ในทางปฏิบัติสตรีม I / O มักใช้เพื่อทำให้เป็นอนุกรมวัตถุเนื่องจากไม่มีสิ่งอำนวยความสะดวกในการทำให้เป็นอนุกรมมาตรฐานอื่น ๆ พิจารณาboost::date_timeหรือboost::numeric::ublas::matrixหากคุณส่งออกวัตถุเมทริกซ์ด้วยตัว<<ดำเนินการคุณจะได้เมทริกซ์ที่แน่นอนเหมือนกันเมื่อคุณป้อนข้อมูลโดยใช้>>ดำเนินการ แต่เพื่อให้บรรลุเป้าหมายนี้นักออกแบบ Boost ต้องจัดเก็บข้อมูลจำนวนคอลัมน์และข้อมูลการนับแถวเป็นข้อมูลที่เป็นข้อความในเอาต์พุตซึ่งจะส่งผลต่อการแสดงผลที่มนุษย์อ่านได้จริง อีกครั้งเป็นการผสมผสานระหว่างสิ่งอำนวยความสะดวกในการจัดรูปแบบข้อความและการทำให้เป็นอนุกรม

สังเกตว่าภาษาอื่น ๆ ส่วนใหญ่แยกสิ่งอำนวยความสะดวกทั้งสองนี้อย่างไร ตัวอย่างเช่นใน Java การจัดรูปแบบทำได้โดยใช้toString()วิธีการนี้ในขณะที่การทำให้เป็นอนุกรมทำได้ผ่านไฟล์Serializableอินเทอร์เฟซ

ในความคิดของฉันทางออกที่ดีที่สุดคือการแนะนำสตรีมแบบไบต์ควบคู่ไปกับสตรีมตามอักขระมาตรฐาน สตรีมเหล่านี้จะทำงานบนข้อมูลไบนารีโดยไม่ต้องกังวลกับการจัดรูปแบบ / การแสดงผลที่มนุษย์อ่านได้ สามารถใช้เป็นสิ่งอำนวยความสะดวกในการทำให้เป็นอนุกรม / deserialization เพื่อแปลวัตถุ C ++ เป็นลำดับไบต์แบบพกพา

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

โดยส่วนตัวแล้วการออกแบบและการใช้งานสตรีมที่ดีที่สุดที่ฉันเคยพบนั้นอยู่ในภาษาโปรแกรม Ada เป็นแบบจำลองในการแยกส่วนความสุขในการสร้างสตรีมรูปแบบใหม่และฟังก์ชันเอาต์พุตจะทำงานตลอดเวลาโดยไม่คำนึงถึงสตรีมที่ใช้ นี่ต้องขอบคุณตัวส่วนร่วมน้อยที่สุด: คุณส่งออกไบต์ไปยังสตรีมและนั่นก็คือมัน ฟังก์ชั่นสตรีมดูแลการใส่ไบต์ลงในสตรีมไม่ใช่หน้าที่ของพวกเขาเช่นจัดรูปแบบจำนวนเต็มให้เป็นเลขฐานสิบหก (แน่นอนว่ามีชุดแอตทริบิวต์ประเภทเทียบเท่ากับสมาชิกคลาสที่กำหนดไว้สำหรับจัดการการจัดรูปแบบ)

ฉันหวังว่า C ++ เป็นเรื่องง่ายสำหรับสตรีม ...

ฉันคิดว่าการออกแบบ IOStreams นั้นยอดเยี่ยมในแง่ของความสามารถในการขยายและประโยชน์

1. บัฟเฟอร์สตรีม: ดูส่วนขยาย boost.iostream: สร้าง gzip, tee, คัดลอกสตรีมในไม่กี่บรรทัดสร้างตัวกรองพิเศษและอื่น ๆ มันจะเป็นไปไม่ได้เลยถ้าไม่มีมัน

2. การรวมการแปลและการรวมการจัดรูปแบบ ดูสิ่งที่สามารถทำได้:

   std::cout << as::spellout << 100 << std::endl;

   สามารถพิมพ์: "หนึ่งร้อย" หรือแม้กระทั่ง:

   std::cout << translate("Good morning")  << std::endl;

   สามารถพิมพ์ "Bonjour" หรือ "בוקרטוב" ตามสถานที่ที่ต้องการได้ std::cout !

   สิ่งดังกล่าวสามารถทำได้เพียงเพราะ iostreams มีความยืดหยุ่นมาก

จะทำได้ดีกว่านี้ไหม

แน่นอนมันทำได้!ที่จริงมีหลายอย่างที่ควรปรับปรุง ...

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

แต่เมื่อมองย้อนกลับไปเมื่อหลายปีก่อนฉันยังคงออกแบบห้องสมุดได้ดีพอที่จะนำเสนอสินค้ามากมาย

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

(คำตอบนี้เป็นไปตามความคิดเห็นของฉัน)

ฉันคิดว่า IOStreams มีความซับซ้อนมากกว่าฟังก์ชันที่เทียบเท่ากัน เมื่อฉันเขียนใน C ++ ฉันยังคงใช้ส่วนหัว cstdio สำหรับ I / O "แบบเก่า" ซึ่งฉันพบว่าสามารถคาดเดาได้มากกว่ามาก หมายเหตุด้านข้าง (แม้ว่าจะไม่สำคัญนัก แต่ความแตกต่างของเวลาที่แน่นอนเป็นเรื่องเล็กน้อย) IOStreams ได้รับการพิสูจน์หลายครั้งว่าช้ากว่า CI / O

ฉันมักจะพบกับความประหลาดใจเมื่อใช้ IOStream

ไลบรารีดูเหมือนจะเน้นข้อความและไม่เน้นไบนารี นั่นอาจเป็นเรื่องแปลกใจครั้งแรก: การใช้แฟล็กไบนารีในสตรีมไฟล์ไม่เพียงพอที่จะรับพฤติกรรมไบนารี ผู้ใช้ Charles Salvia ข้างต้นสังเกตเห็นได้อย่างถูกต้อง: IOStreams ผสมลักษณะการจัดรูปแบบ (ที่คุณต้องการผลลัพธ์ที่สวยงามเช่นตัวเลขที่ จำกัด สำหรับการลอยตัว) กับลักษณะการทำให้เป็นอนุกรม (ซึ่งคุณไม่ต้องการให้ข้อมูลสูญหาย) อาจจะเป็นการดีที่จะแยกแง่มุมเหล่านี้ Boost.Serialization ทำครึ่งนี้ คุณมีฟังก์ชันซีเรียลไลซ์ที่กำหนดเส้นทางไปยังตัวแทรกและตัวแยกหากคุณต้องการ คุณมีความตึงเครียดระหว่างทั้งสองด้านแล้ว

ฟังก์ชั่นจำนวนมากยังทำให้ความหมายสับสน (เช่น get, getline, ไม่สนใจและอ่านบางตัวแยกตัวคั่นบางตัวก็ไม่ได้ตั้งค่า eof ด้วย) นอกจากนี้ในบางรายกล่าวถึงชื่อฟังก์ชันแปลก ๆ เมื่อใช้สตรีม (เช่น xsputn, uflow, underflow) สิ่งต่างๆเลวร้ายยิ่งขึ้นเมื่อใช้ตัวแปร wchar_t wifstream ทำการแปลเป็นหลายไบต์ในขณะที่ wstringstream ไม่ทำ ไบนารี I / O ไม่ทำงานนอกกรอบด้วย wchar_t: คุณมีการเขียนทับ codecvt

c ที่บัฟเฟอร์ I / O (เช่น FILE) จะไม่ทรงพลังเท่ากับ C ++ คู่กัน แต่มีความโปร่งใสมากกว่าและมีพฤติกรรมที่ตอบโต้ได้ง่ายกว่ามาก

ทุกครั้งที่ฉันสะดุดกับ IOStream ฉันจะดึงดูดมันเหมือนแมลงเม่าที่ลุกเป็นไฟ อาจจะเป็นเรื่องดีถ้าผู้ชายฉลาด ๆ สักคนจะดูสถาปัตยกรรมโดยรวมได้ดี

ฉันไม่สามารถช่วยตอบคำถามส่วนแรกได้ (ใครเป็นคนทำ?) แต่ก็ตอบในกระทู้อื่น.

สำหรับส่วนที่สองของคำถาม (ออกแบบมาอย่างดี?) คำตอบของฉันคือ "ไม่!" ดังก้อง นี่คือตัวอย่างเล็ก ๆ น้อย ๆ ที่ทำให้ฉันสั่นหัวด้วยความไม่เชื่อตั้งแต่ปี:

#include <stdint.h>
#include <iostream>
#include <vector>

// A small attempt in generic programming ;)
template <class _T>
void ShowVector( const char *title, const std::vector<_T> &v)
{
    std::vector<_T>::const_iterator iter;
    std::cout << title << " (" << v.size() << " elements): ";
    for( iter = v.begin(); iter != v.end(); ++iter )
    {
        std::cout << (*iter) << " ";
    }
    std::cout << std::endl;
}
int main( int argc, const char * argv[] )
{
    std::vector<uint8_t> byteVector;
    std::vector<uint16_t> wordVector;
    byteVector.push_back( 42 );
    wordVector.push_back( 42 );
    ShowVector( "Garbled bytes as characters output o.O", byteVector );
    ShowVector( "With words, the numbers show as numbers.", wordVector );
    return 0;
}

โค้ดด้านบนก่อให้เกิดเรื่องไร้สาระเนื่องจากการออกแบบ iostream ด้วยเหตุผลบางประการที่อยู่นอกเหนือความเข้าใจของฉันพวกเขาถือว่า uint8_t ไบต์เป็นอักขระในขณะที่ประเภทอินทิกรัลที่ใหญ่กว่าจะถือว่าเป็นตัวเลข การออกแบบที่ไม่ดีของ Qed

นอกจากนี้ยังไม่มีวิธีที่ฉันคิดว่าจะแก้ไขปัญหานี้ได้ ประเภทอาจเป็น float หรือ double แทน ... ดังนั้นการโยนไปที่ 'int' เพื่อทำให้ iostream โง่เข้าใจว่าตัวเลขที่ไม่ใช่ตัวอักษรเป็นหัวข้อจะไม่ช่วย

หลังจากได้รับการโหวตลงคะแนนสำหรับการตอบกลับของฉันอาจจะมีคำอธิบายอีกสองสามคำ ... การออกแบบ IOStream มีข้อบกพร่องเนื่องจากไม่ได้ให้วิธีการที่โปรแกรมเมอร์ระบุวิธีการปฏิบัติต่อรายการ การใช้งาน IOStream จะทำการตัดสินใจโดยพลการ (เช่นปฏิบัติกับ uint8_t เป็นอักขระไม่ใช่จำนวนไบต์) นี่เป็นข้อบกพร่องของการออกแบบ IOStream เนื่องจากพวกเขาพยายามที่จะบรรลุสิ่งที่ไม่สามารถทำได้

C ++ ไม่อนุญาตให้จำแนกประเภท - ภาษาไม่มีสิ่งอำนวยความสะดวก ไม่มีสิ่งที่เรียกว่า is_number_type () หรือ is_character_type () IOStream สามารถใช้เพื่อทำการเลือกอัตโนมัติที่สมเหตุสมผลได้ การเพิกเฉยต่อสิ่งนั้นและพยายามหลีกหนีโดยการเดาว่าเป็นข้อบกพร่องของการออกแบบห้องสมุด

ยอมรับว่า printf () จะล้มเหลวในการทำงานในการใช้งาน "ShowVector ()" ทั่วไป แต่นั่นไม่ใช่ข้อแก้ตัวสำหรับพฤติกรรม iostream แต่มีความเป็นไปได้มากว่าในกรณี printf () ShowVector () จะถูกกำหนดเช่นนี้:

template <class _T>
void ShowVector( const char *formatString, const char *title, const std::vector<_T> &v );

C ++ iostreams มีข้อบกพร่องมากมายดังที่ระบุไว้ในคำตอบอื่น ๆ แต่ฉันต้องการทราบบางอย่างในการป้องกัน

C ++ แทบจะไม่ซ้ำกันระหว่างภาษาที่ใช้งานอย่างจริงจังซึ่งทำให้อินพุตและเอาต์พุตตัวแปรตรงไปตรงมาสำหรับผู้เริ่มต้น ในภาษาอื่นการป้อนข้อมูลของผู้ใช้มีแนวโน้มที่จะเกี่ยวข้องกับการบังคับประเภทหรือการจัดรูปแบบสตริงในขณะที่ C ++ ทำให้คอมไพเลอร์ทำงานทั้งหมด เช่นเดียวกันกับเอาต์พุตเป็นส่วนใหญ่แม้ว่า C ++ จะไม่ซ้ำกันในเรื่องนี้ ถึงกระนั้นคุณสามารถจัดรูปแบบ I / O ได้ค่อนข้างดีใน C ++ โดยไม่ต้องเข้าใจคลาสและแนวคิดเชิงวัตถุซึ่งมีประโยชน์ในการสอนและไม่ต้องเข้าใจไวยากรณ์รูปแบบ อีกครั้งหากคุณกำลังสอนผู้เริ่มต้นนั่นเป็นข้อดีอย่างมาก

ความเรียบง่ายสำหรับผู้เริ่มต้นนี้มาพร้อมกับราคาซึ่งอาจทำให้ปวดหัวกับการจัดการกับ I / O ในสถานการณ์ที่ซับซ้อนมากขึ้น แต่หวังว่าเมื่อถึงจุดนั้นโปรแกรมเมอร์ได้เรียนรู้มากพอที่จะรับมือกับพวกเขาได้หรืออย่างน้อยก็อายุมากพอ ดื่ม.