`fsetpos()` สามารถใช้เพื่ออนุญาตการเข้าถึงแบบสุ่มในไฟล์ที่มีขนาดใหญ่เกินกว่าจะจัดการกับ `fseek()` ได้อย่างไร

ฉันเชื่อว่าในเมนเฟรมระบบบางไฟล์ (อาจเป็น โบราณ) ไฟล์ข้อความจะถูกจัดเก็บเป็นชุดของ "บันทึก" (บรรทัด) และตำแหน่งไฟล์จึงถูกสร้างขึ้นทั้งดัชนีบันทึกและตำแหน่งภายในบันทึก ซึ่งเป็นสิ่งที่ข้อความเหตุผลดูเหมือนจะอ้างถึง ที่ระดับระบบปฏิบัติการ การดำเนินการค้นหาต้องการทั้งดัชนีเร็กคอร์ดและตำแหน่งภายในเร็กคอร์ด แทนที่จะเป็นตำแหน่งไบต์ภายในไฟล์ สิ่งนี้นำไปสู่ปัญหาที่ต้องเข้ารหัสทั้งดัชนีบันทึกและตำแหน่งภายในภายในค่า long เพื่อใช้กับ fseek และ ftell ดังนั้น การใช้งานไลบรารีจำเป็นต้องกำหนดจำนวนบิตให้กับแต่ละดัชนีและตำแหน่งเร็กคอร์ด และนี่จะจำกัดจำนวนเรคคอร์ดและตำแหน่ง

ตัวอย่างเช่น หาก long มี 32 บิต ค่านี้อาจแบ่งออกเป็น 25 บิตสำหรับดัชนีบันทึก และ 7 บิตสำหรับตำแหน่งภายในบันทึก (อนุญาตให้มีความยาวบันทึกสูงสุดที่ใช้งานได้ 127 และ 2^25 ~= 33k บันทึก) อย่างไรก็ตาม ระบบอาจอนุญาตให้มีการบันทึกข้อมูลได้มากขึ้นเรื่อยๆ

(ข้อความข้างต้นเป็นความทรงจำที่คลุมเครือบางส่วน และอนุมานบางส่วนจากข้อความเหตุผล)

อย่างไรก็ตาม ปัญหาที่แท้จริงของ fseek และ ftell บนเดสก์ท็อปสมัยใหม่ก็คือค่า long อาจไม่เพียงพอที่จะแสดงถึงตำแหน่งไฟล์ทั้งหมด บนระบบ 32 บิต long มักจะเป็น 32 บิต แต่ไฟล์มักจะยังคงมีขนาดใหญ่กว่า 2GB ได้ ดังนั้นจึงจำเป็นต้องมีกลไกที่แตกต่างกันสำหรับการระบุออฟเซ็ตไฟล์

ฉันไม่เข้าใจว่าจะสามารถนำไปใช้กับ "การเข้าถึงแบบสุ่ม" อย่างมีประสิทธิภาพได้อย่างไร

ในกรณีนี้ "การเข้าถึงแบบสุ่ม" สิ่งที่พวกเขากำลังพูดถึงคือความสามารถในการค้นหาจุดใดๆ ที่เคยเยี่ยมชมแล้ว นั่นคือ คุณสามารถเปลี่ยนตำแหน่ง (โดยใช้ fsetpos) ตำแหน่งใดๆ ที่คุณได้รับแล้ว (ผ่าน fgetpos) มันไม่ได้เกี่ยวกับการค้นหาตำแหน่งไบต์ใดๆ "การเข้าถึงแบบสุ่ม" อาจเป็นคำที่ผิด แต่ฉันคิดว่าพวกเขาเพียงต้องการแยกความแตกต่างจากการเข้าถึงตามลำดับล้วนๆ