Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.21.97.61] |
|
Сообщ.
#1
,
|
|
|
Всем хай!
Прочел тут недавно в одном пособии упоминание о ТРЕХ уровнях ввода-вывода языка СИ. Призадумался...хм... В своих прожках юзаю: FILE*, fopen, fclose, fputc, fgets, fread+fwrite+fseek(для файлов бинарных-прямого доступа). Допустим, это самый верхний уровень ввода-вывода языка СИ. Потом есть такая функция chsize(#include <io.h>) - это, как я понимаю уже какой-то др.уровень считается, да? Еще есть вроде низкоуровневые функции просто read, write, они возвращают в качестве ответа кол-во прочитанных/записанных байтов (в каком инклюде находятся - не знаю, но явно не в stdio.h). Поясните плз по этим 3 уровням или это деление на 3 уровня какое-то условное в СИ? |
Сообщ.
#2
,
|
|
|
Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление. Если попробовать восстановить, то получится что-то типа этого:
<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>, что может добавить дополнительного оверхеда. |
Сообщ.
#3
,
|
|
|
Цитата Qraizer @ Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление. Скорее всего именно так. Если взять исходники стандартной либы, покопаться в ее обустройстве, то да - можно условно выделить три "уровня": 1) Функции из Стандарта 2) Функции из POSIX'а 3) Функции реализации для конкретной платформы FasterHarder, последние два "уровня" смотреть в /io/fcntl.c и в подкаталогах /sys/ и /bits/. Но я бы не рекомендовал на это сильно тратить время. Ибо для переносимости - Стандарт и подразумевался. А если нужно что-то выдушить по производительности - лучше смотреть на системные вызовы конкретной платформы. Накрайняк накидать свой ограниченный wrapper их для "псевдопереносимости". Естественно, написанное мою выше - ИМХО. Для ознакомления |
Сообщ.
#4
,
|
|
|
Qraizer, задвинул МОЩНО, КРУТО, ГРАМОТНО, ЧИТАБЕЛЬНО, ПРОФЕССИОНАЛЬНО!
все малое имхо 1 вообще, для меня низкоуровневость в первую очередь ассоциируется с неудобством + высокой производительностью, когда 1-а строчка кода "выполняет крайне мала работы", но делает это крайне эффективно (ассемблер - язык низкоуровневый, очень неудобный/сложный/нюансовый/аппаратно-зависимый вроде, и язык C# - высокоуровневый, удобный, 1 строчка кода выполняет "много работы" по статистике Макконела 1строка С# = 4.5 строкам Си) 2. также низкоуровневость проявляется в БЛИЗОСТИ к процессору, АЛУ, регистрам процессора) (пример: Ассемблер, где можно обратиться напрямую к регистру какому-нибудь) Qraizer, т е правильнее делить на 2 уровня, как я понял: 1. <io.h> 2. <stdio.h> на чем удобнее программировать, не знаю, т к не использую <io.h>, но видимо, что на функциях из <stdio.h> гораздо приятнее) (хотя понятно, что удобнее на том, что лучше знаешь...) и, вероятно, эти уровни можно СМЕШИВАТЬ в рамках 1-й программы, но, наверное, нежелательно) Qraizer, JoeUser, спс.! |
Сообщ.
#5
,
|
|
|
<io.h> скорее не по вводу/выводу, а по файлам в общем. Ну там, сдублировать открытый handle, сбросить кеш, проверить доступ... и опять-таки, из-за ориентированности на POSIX, причём сильно ранний, вместо него в C имеет смысл явно использовать API своей ОСи, а в Плюсах его нынче прекрасно заменяет std::filesystem. То, что в <io.h> относится к в/в, имеет аналоги в <stdio.h>, так что использовать <io.h> по факту-то и незачем.
|
Сообщ.
#6
,
|
|
|
Пожалуй, в stdio.h нет только аналогов dup и dup2 (за всю жизнь пришлось воспользоваться только один раз), без остальных функций io.h вроде можно обойтись
|