На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
  
> О каких это трех уровнях ввода-вывода языка СИ имеют ввиду?, идеально чистый СИ (С89)
    Всем хай!

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

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

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

    Поясните плз по этим 3 уровням или это деление на 3 уровня какое-то условное в СИ?
    I originate
    You must appreciate, all the others imitate

    SCOOTER "GUEST LIST"

    'Pon the mic I'm the teacher!
    Spread my words like a preacher!
    Yiiihhaaaa!!!!

    SCOOTER "WEEKEND"
      Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление. Если попробовать восстановить, то получится что-то типа этого:
      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 -
      Одни с годами умнеют, другие становятся старше.
        Цитата Qraizer @
        Впервые слышу. Вероятно, автор подразумевал некое своё субъективное деление.

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

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

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

        Для ознакомления :)
        Мои программные ништякиhttps://majestio.info
          Qraizer, задвинул МОЩНО, КРУТО, ГРАМОТНО, ЧИТАБЕЛЬНО, ПРОФЕССИОНАЛЬНО!

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

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

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

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

          Qraizer, JoeUser, спс.!
          I originate
          You must appreciate, all the others imitate

          SCOOTER "GUEST LIST"

          'Pon the mic I'm the teacher!
          Spread my words like a preacher!
          Yiiihhaaaa!!!!

          SCOOTER "WEEKEND"
            <io.h> скорее не по вводу/выводу, а по файлам в общем. Ну там, сдублировать открытый handle, сбросить кеш, проверить доступ... и опять-таки, из-за ориентированности на POSIX, причём сильно ранний, вместо него в C имеет смысл явно использовать API своей ОСи, а в Плюсах его нынче прекрасно заменяет std::filesystem. То, что в <io.h> относится к в/в, имеет аналоги в <stdio.h>, так что использовать <io.h> по факту-то и незачем.
            Одни с годами умнеют, другие становятся старше.
              Пожалуй, в stdio.h нет только аналогов dup и dup2 (за всю жизнь пришлось воспользоваться только один раз), без остальных функций io.h вроде можно обойтись
              Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
              1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
              0 пользователей:


              Рейтинг@Mail.ru
              [ Script Execution time: 0,0846 ]   [ 15 queries used ]   [ Generated: 22.02.20, 07:32 GMT ]