Яке обґрунтування того, як Fread / Fwrite приймає розмір і зараховується як аргументи?

Ми тут на роботі обговорили, чому fread та fwrite беруть розмір для кожного члена та підраховують та повертають кількість прочитаних / написаних членів, а не просто беручи буфер та розмір. Єдине використання для нього, яке ми могли б придумати, це якщо ви хочете прочитати / записати масив структур, які не рівномірно діляться на вирівнюванні платформи і, отже, були забиті, але це не може бути настільки загальним, щоб виправдати цей вибір в дизайні.

З FREAD (3) :

Функція fread () зчитує елементи nmemb даних, довжиною кожного байта, з потоку, на який вказує потік, зберігаючи їх у місці, заданому ptr.

Функція fwrite () записує елементи nmemb даних довжиною кожного байту в потік, на який вказує потік, отримуючи їх із розташування, заданого ptr.

fread () та fwrite () повертають кількість успішно прочитаних чи записаних елементів (тобто не кількість символів). Якщо виникає помилка або досягається кінець файлу, повертається значення - короткий підрахунок (або нуль).

Це базується на тому, як реалізований Fread .

В Єдиній специфікації UNIX сказано

Для кожного об'єкта потрібно зробити виклики розміру функції fgetc (), а результати, збережені в порядку читання, у масиві непідписаного символу, який точно накладає об'єкт.

fgetc також має таку примітку:

Оскільки fgetc () працює з байтами, для читання символу, що складається з декількох байт (або "багатобайтового символу"), може знадобитися кілька викликів до fgetc ().

Звичайно, це передує вигадливим змінним байтовим кодуванням, таким як UTF-8.

SUS зазначає, що це фактично взято з документів ISO C.

Різниця у fread (buf, 1000, 1, stream) та fread (buf, 1, 1000, stream) полягає в тому, що в першому випадку ви отримуєте лише один шматок з 1000 байт або нутину, якщо файл менший і в в другому випадку ви отримуєте все у файлі менше і до 1000 байт.

Це чисті припущення, однак у ті часи (Деякі існують досі) багато файлових систем не були простими байтовими потоками на жорсткому диску.

Багато файлових систем базувалися на записах, отже, щоб ефективно задовольнити такі файлові системи, вам доведеться вказати кількість елементів ("записів"), що дозволяє 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, тому я можу лише здогадуватися. Я думаю, що, швидше за все, відповідь полягає в тому, що Керніган і Річі, можливо, просто думали, що виконання бінарних операцій вводу-виводу було б найбільш природно робити на масивах об'єктів. Крім того, вони могли думати, що блок вводу-виводу буде швидшим / простішим у впровадженні чи іншим способом на деяких архітектурах.

Незважаючи на те, що стандарт C визначає, що fread()і fwrite()буде впроваджено з точки зору fgetc()і fputc(), пам’ятайте, що стандарт з’явився довгий час після того, як C був визначений K&R і що речі, зазначені в стандарті, могли не бути в оригінальних ідеях дизайнерів. Можливо, навіть те, що сказано в «Мові програмування C» K&R, може бути не таким, як у той час, коли мова розроблялася вперше.

Нарешті, ось що має сказати П. Дж. Плаугер fread()у "Стандартній бібліотеці С":

Якщо size(другий) аргумент більший за одиницю, ви не можете визначити, чи функція також зчитує до size - 1додаткових символів понад те, що вона повідомляє. Як правило, вам краще не викликати функцію, fread(buf, 1, size * n, stream);а не fread(buf, size, n, stream);

По суті, він каже, що fread()інтерфейс "порушений". Адже fwrite()він зазначає, що "помилки при написанні зазвичай рідкісні, тому це не є серйозним недоліком" - із твердженням, з яким я б не погодився.

Ймовірно, це повертається до способу реалізації файлового вводу-виводу. (назад у той день) Можливо, швидше було писати / читати у файли блоками, аніж писати все одразу.

Наявність окремих аргументів розміру та підрахунку може бути вигідним для реалізації, яка дозволяє уникнути читання будь-яких часткових записів. Якби хтось використовував однобайтові зчитування з чогось на зразок конвеєра, навіть якщо використовував дані фіксованого формату, потрібно було б передбачити можливість розділення запису на два зчитування. Якщо б замість цього міг просити, наприклад, неблокуючий зчитування до 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 низькі байти елемента, що б ви зробили?

У деяких системах (через вирівнювання) ви не можете отримати доступ до одного байта цілого числа без створення копії та зсуву.