На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
Страницы: (4) 1 [2] 3 4  все  ( Перейти к последнему сообщению )  
> Распространённые функции библиотеки , не имеющие аналогов в Стандарте
    Цитата Wound @
    Отключи его системными функциями, если тебе нужно именно так:

    Для POSIX-терминалов не пойдет, там нужно работать с другими сущностями - из termios.h.
    Вот поэтому кроссплатформенный ввод без эха и не реализован в Стандарте.

    Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
      Цитата JoeUser @
      Для POSIX-терминалов не пойдет, там нужно работать с другими сущностями - из termios.h.

      Конечно не подойдет, потому как даже по словам HANDLE/DWORD/GetConsoleMode и т.д. можно догадаться что речь идет о Windows.
      Вариант с _getch/getch - так же не подойдет, и? :-?

      Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
        Цитата Wound @
        Вариант с _getch/getch - так же не подойдет, и?

        _getch - для винды короче, чем std::cin.get :-? А эффект тот же.

        Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
          Цитата JoeUser @
          _getch - для винды короче, чем std::cin.get :-? А эффект тот же.

          Странная логика :whistle:

          int* p = new int;
          короче, чем
          std::unique_ptr<int> p = std::make_unique();
          А эффект тот же.

          Но почему то рекомендуется использовать второе, в противовес первому.

          Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
            Зачем ты приплел охрану указателя? Вопрос был простой - считать символ с консоли венды. Все. Ничего более.

            Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
              Цитата JoeUser @
              Зачем ты приплел охрану указателя?

              Затем же, зачем ты сравниваешь левую непереносимую функцию со стандартными возможностями языка :-?

              Цитата JoeUser @
              Вопрос был простой - считать символ с консоли венды. Все. Ничего более.

              Ну и как это лучше сделать? Стандартными средствами или не пойми чем, что не переносимо?

              Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
                Цитата Wound @
                Стандартными средствами

                "Стандартные средства" - также непереностимы, т.к. в обоих случаях нужна дополнительная настройка консоли/терминала. Автора топика не интересует переносимость, его интересует венда. Ему надо удобнее и короче, а это _getch. Все надоело переливать из пустого в порожнее. Для себя я вопрос закрываю.

                Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
                  Цитата JoeUser @
                  "Стандартные средства" - также непереностимы, т.к. в обоих случаях нужна дополнительная настройка консоли/терминала. Автора топика не интересует переносимость, его интересует венда. Ему надо удобнее и короче, а это _getch. Все надоело переливать из пустого в порожнее. Для себя я вопрос закрываю.

                  Автор топика завтра перейдет на другой компилятор, отличный от Visual Studio, и создаст тему "У миня не компилируется код, говорит что не находит conio.h", в случае с системными функциями - такой проблемы не возникает.

                  Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
                    Цитата JoeUser @
                    А эффект тот же.
                    Тот же - от getchar.

                    Цитата Wound @
                    Автор топика завтра перейдет на другой компилятор, отличный от Visual Studio, и создаст тему "У миня не компилируется код, говорит что не находит conio.h"
                    GCC нормально компилит. Но под виндой, в Linux'е нет (что, в принципе, ожидаемо).

                    Цитата Qraizer @
                    Jin X, тебя это всё тут устраивает? Может быть перейдёте в отдельную тему?
                    Мне это интересно.
                    Но если тебя смущает всё это именно в этой теме, раздели на 2 части, там и продолжим :)

                    Сообщения были разделены в тему "Распространённые функции библиотеки"

                    Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)"
                    M
                    Done
                    Сообщение отредактировано: Qraizer -
                      Цитата JoeUser @
                      Еврейский у тя подход :lol: Не ответив на мой вопрос, задаешь свой :lol:

                      Так я тебе ответил, открой заголовочный файл iomanip - там все реализации стандартных манипуляторов лежат. Выбери тот который тебе нужен, юзни его. Что тут не понятного?

                      Цитата JoeUser @
                      Ну примерно так будет:

                      Что это? А если полей класса у тебя с десяток? А если они при этом закрытые? А если нужно оперировать бинарными данными? Или считать из файла бинарные данные?

                      Потоки:
                      ExpandedWrap disabled
                        #include <iostream>
                        #include <iterator>
                        #include <algorithm>
                        #include <fstream>
                         
                        int main()
                        {
                           std::ifstream fin("main.cpp", std::ios_base::in | std::ios_base::binary);
                           std::ofstream fout("main.cpp.backup", std::ios_base::out | std::ios_base::binary | std::ios_base::trunc);
                         
                           std::cout << "Begin copy file..." << std::endl;
                           auto cout_buffer = std::cout.rdbuf();
                           std::cout.rdbuf(fout.rdbuf());
                         
                           std::cout << "===========Begin=============" << std::endl;
                           std::copy(std::istreambuf_iterator<char>(fin),
                                     std::istreambuf_iterator<char>(),
                                     std::ostream_iterator<char, char>(std::cout));
                           std::cout << std::endl << "============End==============" << std::endl;
                           fin.close();
                           fout.close();
                           std::cout.rdbuf(cout_buffer);
                           std::cout << "Done." << std::endl;
                          
                           std::cin.get();
                           return 0;
                        }

                      По моему довольно универсальное средство, явно удобнее сишных функций. Потому как Сишная функция может оперировать только '\0' строками и числами. А потоки могут оперировать всем, чем пожелаешь, могут расширяться. Допустим даже, если что то они не умеют, не состовит большого труда этому их научить. Сишные функции - захардкожены, и если что то не умеют делать, то учить их этому бессмысленно.
                      Соответственно io потоки удобнее Сишных функций.
                      Плюс ко всему плохой стиль смешивать Сишные функции с С++сными. Код становится вырвиглазным. И не безопасным.
                      О чем тут вообще можно спорить?
                      Сообщение отредактировано: Wound -
                        Цитата JoeUser @
                        К примеру, изобрази это манипуляторами потоков i/o:
                        ExpandedWrap disabled
                          char i = 12;
                          printf("%04d :: %0*x",i,4,i);

                        Ну будет чуть больше писанины. И что? Если ты пишешь мелкую простую прогу в пару сотен строк, то, конечно, и сишными функциями можно воспользоваться. Но если что-то более серьёзное, то преимущество потоков в их безопасности (ошибка "поменял тип или количество аргументов и забыл про форматную строку" с ними невозможна) с лихвой перекрывает несколько бОльшую многословность.

                        Добавлено
                        Короче, аргумент против сишного ввода-вывода ровно такой же, как и против динамической типизации в сравнении со статической. Но поскольку апологеты динамики, как правило, в принципе не понимают аргументы противоположной стороны, то, вангую, тут будет то же самое :D
                          Wound,OpenGL, вы не поняли сути спора, как я вижу. Ничего не имею против потоков i/o. Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc ... И не более. Никаких сравнений C vs C++.
                            Цитата JoeUser @
                            Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc .

                            Иными словами, речь идёт о сферическоваккумном удобстве форматирования стандартных типов и в полном отрыве от остальных характеристик? Ну ладно, тогда в таком случае я могу с тобой согласиться :D
                              Цитата OpenGL @
                              о сферическоваккумном удобстве форматирования стандартных типов

                              Да ладно? :lol: https://doc.rust-lang.org/std/fmt/
                                И к чему это тут? Если что, всё вышесказанное мной против сишного IO к расту не применимо - trait Debug ты можешь определить для своих типов, а форматная строка парсится во время компиляции, так что в вышеописанных случаях программа просто не скомпилится.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (4) 1 [2] 3 4  все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0506 ]   [ 17 queries used ]   [ Generated: 28.03.24, 22:50 GMT ]