О каких это трех уровнях ввода-вывода языка СИ имеют ввиду? , идеально чистый СИ (С89)

Всем хай!

Прочел тут недавно в одном пособии упоминание о ТРЕХ уровнях ввода-вывода языка СИ. Призадумался...хм...
В своих прожках юзаю: FILE*, fopen, fclose, fputc, fgets, fread+fwrite+fseek(для файлов бинарных-прямого доступа). Допустим, это самый верхний уровень ввода-вывода языка СИ.

Потом есть такая функция chsize(#include <io.h>) - это, как я понимаю уже какой-то др.уровень считается, да?

Еще есть вроде низкоуровневые функции просто read, write, они возвращают в качестве ответа кол-во прочитанных/записанных байтов (в каком инклюде находятся - не знаю, но явно не в stdio.h).

Поясните плз по этим 3 уровням или это деление на 3 уровня какое-то условное в СИ?

Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление. Если попробовать восстановить, то получится что-то типа этого:

1. <io.h> включает низкоуровневые функции, типы и структуры данных, сильно зависимые от ОС. Фактически создан по образу и подобию POSIX API и ориентирован на него. Большей частью может быть реализован на базе иных API, но с ограничениями и особенностями. Не включён в Стандарт языка.
2. <stdio.h> включает функции, независимые от ОС, включён в Стандарт. Имеет две категории функций, типов и структур данных:
   • бинарный ввод/вывод; оперирует нетипизированными массивами байт, хорошо подходит для быстрого обмена с внешними носителями информации; ввиду сильной зависимости от бинарной репрезентации данных непереносим между разными платформами и даже нередко между разными версиями одной и той же платформы или реализации; кроме того, бинарная репрезентация крайне неудобна для восприятия человеком, поэтому на внешнем носителе файлы большей частью нечитаемы человеком без специальных программных средств;
   • форматированный ввод/вывод; выполняет преобразование бинарной репрезентации данных в текстовый формат и обратно перед (после) обменом (обмена) с внешними носителями информации; медленнее, в ряде случаев значительно, бинарного из-за дополнительного кода по преобразованию представления данных, однако обладает свойством абсолютной переносимостью между разными исполнительными платформами; кроме того, текстовая форма хорошо воспринимается человеком, поэтому файлы на внешнем носителе обычно легко им читаются без специальных программных средств.

<io.h> представлен в основном такими функциями как _open(), _read(), _write(), _close() и др. Формально может быть легко заменён на бинарный ввод/вывод из <stdio.h>. Также там есть низкоуровневые средства по управлению файлами, типа _dup(), _filelength(), _commit() итп, которые не имеют аналогов в <stdio.h>.
Бинарный ввод/вывод в <stdio.h> представлен г.о. fread() и fwrite(), используемыми совместно с другими, общими с форматированным в/в функциями. Форматированный в/в, представленный большим количеством таких функций, как fprintf()/fscanf(), fputs()/fgets(), ftell()/fseek() итп, несмотря на свою переносимость, однако может столкнуться с трудностями из-за национальных и культурных различий в представлении данных, из-за чего нередко встаёт задача их учёта посредством <locale.h>, что может добавить дополнительного оверхеда.

Сообщение отредактировано: Qraizer - 24.12.19, 14:10

Цитата Qraizer @ 24.12.19, 14:06

Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление.

Скорее всего именно так. Если взять исходники стандартной либы, покопаться в ее обустройстве, то да - можно условно выделить три "уровня":

1) Функции из Стандарта
2) Функции из POSIX'а
3) Функции реализации для конкретной платформы

FasterHarder, последние два "уровня" смотреть в /io/fcntl.c и в подкаталогах /sys/ и /bits/. Но я бы не рекомендовал на это сильно тратить время. Ибо для переносимости - Стандарт и подразумевался. А если нужно что-то выдушить по производительности - лучше смотреть на системные вызовы конкретной платформы. Накрайняк накидать свой ограниченный wrapper их для "псевдопереносимости". Естественно, написанное мою выше - ИМХО.

Для ознакомления

Qraizer, задвинул МОЩНО, КРУТО, ГРАМОТНО, ЧИТАБЕЛЬНО, ПРОФЕССИОНАЛЬНО!

все малое имхо
1 вообще, для меня низкоуровневость в первую очередь ассоциируется с неудобством + высокой производительностью, когда 1-а строчка кода "выполняет крайне мала работы", но делает это крайне эффективно (ассемблер - язык низкоуровневый, очень неудобный/сложный/нюансовый/аппаратно-зависимый вроде, и язык C# - высокоуровневый, удобный, 1 строчка кода выполняет "много работы" по статистике Макконела 1строка С# = 4.5 строкам Си)

2. также низкоуровневость проявляется в БЛИЗОСТИ к процессору, АЛУ, регистрам процессора) (пример: Ассемблер, где можно обратиться напрямую к регистру какому-нибудь)

Qraizer, т е правильнее делить на 2 уровня, как я понял:
1. <io.h>
2. <stdio.h>

на чем удобнее программировать, не знаю, т к не использую <io.h>, но видимо, что на функциях из <stdio.h> гораздо приятнее) (хотя понятно, что удобнее на том, что лучше знаешь...)
и, вероятно, эти уровни можно СМЕШИВАТЬ в рамках 1-й программы, но, наверное, нежелательно)

Qraizer, JoeUser, спс.!

<io.h> скорее не по вводу/выводу, а по файлам в общем. Ну там, сдублировать открытый handle, сбросить кеш, проверить доступ... и опять-таки, из-за ориентированности на POSIX, причём сильно ранний, вместо него в C имеет смысл явно использовать API своей ОСи, а в Плюсах его нынче прекрасно заменяет std::filesystem. То, что в <io.h> относится к в/в, имеет аналоги в <stdio.h>, так что использовать <io.h> по факту-то и незачем.

Пожалуй, в stdio.h нет только аналогов dup и dup2 (за всю жизнь пришлось воспользоваться только один раз), без остальных функций io.h вроде можно обойтись