อะไรคือเหตุผลสำหรับ fread / fwrite ที่มีขนาดและนับเป็นอาร์กิวเมนต์?

เราได้พูดคุยกันในที่ทำงานเกี่ยวกับสาเหตุที่ fread และ fwrite ใช้ขนาดต่อสมาชิกและนับและส่งคืนจำนวนสมาชิกที่อ่าน / เขียนแทนที่จะใช้แค่บัฟเฟอร์และขนาด การใช้งานเพียงอย่างเดียวที่เราสามารถทำได้คือถ้าคุณต้องการอ่าน / เขียนอาร์เรย์ของโครงสร้างที่ไม่สามารถหารด้วยการจัดตำแหน่งแพลตฟอร์มได้อย่างเท่าเทียมกันและด้วยเหตุนี้จึงได้รับการบุนวม แต่ไม่สามารถใช้ร่วมกันได้เพื่อรับประกันตัวเลือกนี้ ในการออกแบบ

จากFREAD (3) :

ฟังก์ชั่น fread () อ่านองค์ประกอบ nmemb ของข้อมูลแต่ละขนาดไบต์ยาวจากสตรีมที่ชี้ไปที่สตรีมจัดเก็บไว้ในตำแหน่งที่กำหนดโดย ptr

ฟังก์ชัน fwrite () เขียนองค์ประกอบ nmemb ของข้อมูลแต่ละขนาดไบต์ยาวไปยังสตรีมที่สตรีมชี้ไปโดยรับข้อมูลจากตำแหน่งที่กำหนดโดย ptr

fread () และ fwrite () ส่งคืนจำนวนรายการที่อ่านหรือเขียนสำเร็จ (กล่าวคือไม่ใช่จำนวนอักขระ) หากข้อผิดพลาดเกิดขึ้นหรือถึงจุดสิ้นสุดของไฟล์ค่าที่ส่งคืนจะเป็นการนับรายการสั้น ๆ (หรือศูนย์)

ก็ขึ้นอยู่กับวิธีการfreadจะดำเนินการ

ข้อกำหนด Single UNIX กล่าว

สำหรับแต่ละออบเจ็กต์การเรียกขนาดจะต้องทำกับฟังก์ชัน fgetc () และผลลัพธ์ที่จัดเก็บตามลำดับที่อ่านในอาร์เรย์ของถ่านที่ไม่ได้ลงนามซึ่งซ้อนทับวัตถุทั้งหมด

fgetcยังมีหมายเหตุนี้:

เนื่องจาก fgetc () ทำงานบนไบต์การอ่านอักขระที่ประกอบด้วยหลายไบต์ (หรือ "อักขระแบบหลายไบต์") อาจต้องใช้การเรียก fgetc () หลายครั้ง

แน่นอนว่าสิ่งนี้เกิดขึ้นก่อนการเข้ารหัสอักขระแบบไบต์ตัวแปรแฟนซีเช่น UTF-8

SUS ตั้งข้อสังเกตว่าสิ่งนี้นำมาจากเอกสาร ISO C

ความแตกต่างของ fread (buf, 1000, 1, stream) และ fread (buf, 1, 1000, stream) คือในกรณีแรกคุณจะได้รับเพียงชิ้นเดียวที่มีขนาด 1,000 ไบต์หรือ nuthin หากไฟล์มีขนาดเล็กกว่าและอยู่ใน กรณีที่สองคุณได้รับทุกอย่างในไฟล์น้อยกว่าและมากถึง 1,000 ไบต์

นี่เป็นการคาดเดาที่บริสุทธิ์ แต่ย้อนกลับไปในสมัยนั้น (บางระบบยังคงอยู่) ระบบไฟล์จำนวนมากไม่ใช่สตรีมไบต์แบบธรรมดาบนฮาร์ดไดรฟ์

ระบบไฟล์จำนวนมากใช้การบันทึกดังนั้นเพื่อตอบสนองระบบไฟล์ดังกล่าวอย่างมีประสิทธิภาพคุณจะต้องระบุจำนวนรายการ ("บันทึก") เพื่อให้ fwrite / fread ทำงานบนที่เก็บข้อมูลเป็นเร็กคอร์ดไม่ใช่เฉพาะสตรีมไบต์

ขอฉันแก้ไขฟังก์ชันเหล่านั้น:

size_t fread_buf( void* ptr, size_t size, FILE* stream)
{
    return fread( ptr, 1, size, stream);
}


size_t fwrite_buf( void const* ptr, size_t size, FILE* stream)
{
    return fwrite( ptr, 1, size, stream);
}

สำหรับเหตุผลของพารามิเตอร์ถึงfread()/ fwrite()ฉันทำสำเนา K&R หายไปนานแล้วดังนั้นฉันจึงเดาได้เท่านั้น ฉันคิดว่าคำตอบที่เป็นไปได้คือ Kernighan และ Ritchie อาจคิดเพียงว่าการแสดงไบนารี I / O จะทำได้อย่างเป็นธรรมชาติที่สุดในอาร์เรย์ของวัตถุ นอกจากนี้พวกเขาอาจคิดว่า block I / O จะใช้งานได้เร็วขึ้น / ง่ายขึ้นหรืออะไรก็ตามในบางสถาปัตยกรรม

แม้ว่ามาตรฐาน C จะระบุfread()และfwrite()นำไปใช้ในแง่ของfgetc()และfputc()โปรดจำไว้ว่ามาตรฐานนั้นมีมานานแล้วหลังจากที่ C ถูกกำหนดโดย K&R และสิ่งที่ระบุในมาตรฐานอาจไม่ได้อยู่ในแนวคิดของนักออกแบบดั้งเดิม แม้เป็นไปได้ว่าสิ่งที่พูดใน "ภาษาโปรแกรมซี" ของ K & R อาจไม่เหมือนกับตอนที่ออกแบบภาษาครั้งแรก

สุดท้ายนี้คือสิ่งที่ PJ Plauger กล่าวถึงfread()ใน "The Standard C Library":

หากsizeอาร์กิวเมนต์ (ที่สอง) มากกว่าหนึ่งคุณจะไม่สามารถระบุได้ว่าฟังก์ชันนั้นอ่านsize - 1อักขระเพิ่มเติมนอกเหนือจากที่รายงานหรือไม่ ตามกฎแล้วคุณควรเรียกใช้ฟังก์ชันfread(buf, 1, size * n, stream);แทน fread(buf, size, n, stream);

โดยพื้นฐานแล้วเขาบอกว่าfread()อินเทอร์เฟซเสีย สำหรับfwrite()เขาตั้งข้อสังเกตว่า "โดยทั่วไปข้อผิดพลาดในการเขียนมักจะหายากดังนั้นนี่จึงไม่ใช่ข้อบกพร่องที่สำคัญ" ซึ่งเป็นคำสั่งที่ฉันไม่เห็นด้วย

เป็นไปได้ว่าจะกลับไปใช้วิธีการใช้งานไฟล์ I / O (ย้อนกลับไปในวันนี้) การเขียน / อ่านไฟล์ในบล็อกอาจเร็วกว่านั้นในการเขียนทุกอย่างพร้อมกัน

การมีอาร์กิวเมนต์แยกกันสำหรับขนาดและจำนวนอาจเป็นประโยชน์ในการใช้งานที่สามารถหลีกเลี่ยงการอ่านบันทึกบางส่วน หากจะใช้การอ่านแบบไบต์เดียวจากบางสิ่งเช่นไพพ์แม้ว่าจะมีการใช้ข้อมูลรูปแบบคงที่ก็ตามก็ต้องอนุญาตให้มีความเป็นไปได้ที่จะมีการแบ่งระเบียนออกจากการอ่านสองครั้ง หากสามารถร้องขอแทนเช่นการอ่านแบบไม่ปิดกั้นได้ถึง 40 ระเบียน 10 ไบต์เมื่อมี 293 ไบต์ที่พร้อมใช้งานและให้ระบบส่งคืน 290 ไบต์ (29 ระเบียนทั้งหมด) ในขณะที่ปล่อยให้ 3 ไบต์พร้อมสำหรับการอ่านครั้งต่อไปซึ่งจะ สะดวกกว่ามาก

ฉันไม่รู้ว่าการใช้งานของ fread สามารถจัดการกับความหมายดังกล่าวได้ในระดับใด แต่แน่นอนว่าอาจมีประโยชน์ในการใช้งานที่สามารถสัญญาว่าจะสนับสนุนพวกเขา

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

พิจารณาสิ่งนี้:

int intArray[10];
fwrite(intArray, sizeof(int), 10, fd);

หาก fwrite ยอมรับจำนวนไบต์คุณสามารถเขียนสิ่งต่อไปนี้:

int intArray[10];
fwrite(intArray, sizeof(int)*10, fd);

แต่มันก็ไร้ประสิทธิภาพ คุณจะมีการเรียกระบบ sizeof (int) มากขึ้นหลายเท่า

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

ในบางระบบ (เนื่องจากการจัดตำแหน่ง) คุณไม่สามารถเข้าถึงหนึ่งไบต์ของจำนวนเต็มโดยไม่ต้องสร้างสำเนาและการขยับ