Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.137.180.32] |
|
Страницы: (4) 1 [2] 3 4 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Для POSIX-терминалов не пойдет, там нужно работать с другими сущностями - из termios.h. Вот поэтому кроссплатформенный ввод без эха и не реализован в Стандарте. Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#17
,
|
|
|
Цитата JoeUser @ Для POSIX-терминалов не пойдет, там нужно работать с другими сущностями - из termios.h. Конечно не подойдет, потому как даже по словам HANDLE/DWORD/GetConsoleMode и т.д. можно догадаться что речь идет о Windows. Вариант с _getch/getch - так же не подойдет, и? Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#18
,
|
|
|
Цитата Wound @ Вариант с _getch/getch - так же не подойдет, и? _getch - для винды короче, чем std::cin.get А эффект тот же. Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#19
,
|
|
|
Цитата JoeUser @ _getch - для винды короче, чем std::cin.get А эффект тот же. Странная логика int* p = new int; короче, чем std::unique_ptr<int> p = std::make_unique(); А эффект тот же. Но почему то рекомендуется использовать второе, в противовес первому. Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#20
,
|
|
|
Зачем ты приплел охрану указателя? Вопрос был простой - считать символ с консоли венды. Все. Ничего более.
Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#21
,
|
|
|
Цитата JoeUser @ Зачем ты приплел охрану указателя? Затем же, зачем ты сравниваешь левую непереносимую функцию со стандартными возможностями языка Цитата JoeUser @ Вопрос был простой - считать символ с консоли венды. Все. Ничего более. Ну и как это лучше сделать? Стандартными средствами или не пойми чем, что не переносимо? Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#22
,
|
|
|
Цитата Wound @ Стандартными средствами "Стандартные средства" - также непереностимы, т.к. в обоих случаях нужна дополнительная настройка консоли/терминала. Автора топика не интересует переносимость, его интересует венда. Ему надо удобнее и короче, а это _getch. Все надоело переливать из пустого в порожнее. Для себя я вопрос закрываю. Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#23
,
|
|
|
Цитата JoeUser @ "Стандартные средства" - также непереностимы, т.к. в обоих случаях нужна дополнительная настройка консоли/терминала. Автора топика не интересует переносимость, его интересует венда. Ему надо удобнее и короче, а это _getch. Все надоело переливать из пустого в порожнее. Для себя я вопрос закрываю. Автор топика завтра перейдет на другой компилятор, отличный от Visual Studio, и создаст тему "У миня не компилируется код, говорит что не находит conio.h", в случае с системными функциями - такой проблемы не возникает. Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" |
Сообщ.
#24
,
|
|
|
Цитата JoeUser @ Тот же - от getchar.А эффект тот же. Цитата Wound @ GCC нормально компилит. Но под виндой, в Linux'е нет (что, в принципе, ожидаемо).Автор топика завтра перейдет на другой компилятор, отличный от Visual Studio, и создаст тему "У миня не компилируется код, говорит что не находит conio.h" Мне это интересно. Но если тебя смущает всё это именно в этой теме, раздели на 2 части, там и продолжим Сообщения были разделены в тему "Распространённые функции библиотеки" Это сообщение было перенесено сюда или объединено из темы "long double 80 бит (Windows)" M Done |
Сообщ.
#25
,
|
|
|
Так я тебе ответил, открой заголовочный файл iomanip - там все реализации стандартных манипуляторов лежат. Выбери тот который тебе нужен, юзни его. Что тут не понятного? Что это? А если полей класса у тебя с десяток? А если они при этом закрытые? А если нужно оперировать бинарными данными? Или считать из файла бинарные данные? Потоки: #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 потоки удобнее Сишных функций. Плюс ко всему плохой стиль смешивать Сишные функции с С++сными. Код становится вырвиглазным. И не безопасным. О чем тут вообще можно спорить? |
Сообщ.
#26
,
|
|
|
Цитата JoeUser @ К примеру, изобрази это манипуляторами потоков i/o: char i = 12; printf("%04d :: %0*x",i,4,i); Ну будет чуть больше писанины. И что? Если ты пишешь мелкую простую прогу в пару сотен строк, то, конечно, и сишными функциями можно воспользоваться. Но если что-то более серьёзное, то преимущество потоков в их безопасности (ошибка "поменял тип или количество аргументов и забыл про форматную строку" с ними невозможна) с лихвой перекрывает несколько бОльшую многословность. Добавлено Короче, аргумент против сишного ввода-вывода ровно такой же, как и против динамической типизации в сравнении со статической. Но поскольку апологеты динамики, как правило, в принципе не понимают аргументы противоположной стороны, то, вангую, тут будет то же самое |
Сообщ.
#27
,
|
|
|
Wound,OpenGL, вы не поняли сути спора, как я вижу. Ничего не имею против потоков i/o. Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc ... И не более. Никаких сравнений C vs C++.
|
Сообщ.
#28
,
|
|
|
Цитата JoeUser @ Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc . Иными словами, речь идёт о сферическоваккумном удобстве форматирования стандартных типов и в полном отрыве от остальных характеристик? Ну ладно, тогда в таком случае я могу с тобой согласиться |
Сообщ.
#29
,
|
|
|
Цитата OpenGL @ о сферическоваккумном удобстве форматирования стандартных типов Да ладно? https://doc.rust-lang.org/std/fmt/ |
Сообщ.
#30
,
|
|
|
И к чему это тут? Если что, всё вышесказанное мной против сишного IO к расту не применимо - trait Debug ты можешь определить для своих типов, а форматная строка парсится во время компиляции, так что в вышеописанных случаях программа просто не скомпилится.
|