Распространённые функции библиотеки , не имеющие аналогов в Стандарте

Ну вот printf часто удобнее cout'а. Да и _getch'а вроде как нет в C++.

Добавлено 07.08.18, 17:20
Как пример...

Эта тема была разделена из темы "long double 80 бит (Windows)"

За printf() vs std::cout – это в Холивары. Я лично с этим в корне не согласен. Что до _getch(), то в Стандарте такой функции нет, даже в C. Это расширение языка, хоть и распространённое, но только потому, что сама платформа, для которой эта функция нужна, распространена.

Добавлено 07.08.18, 17:31
P.S. Аналогов нет – пользуй на здоровье.

Цитата Qraizer @ 07.08.18, 17:30

Я лично с этим в корне не согласен.

С чем "с этим"?

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

Вот с этим:

Цитата Jin X @ 07.08.18, 17:14

Ну вот printf часто удобнее cout'а.

Добавлено 07.08.18, 19:49
Единственная ситуация, когда он удобнее, это когда он есть, а std::cout-а нет. Т.е. в C.

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

Qraizer, ты считаешь средства форматирования в потоках i/o удобнее printf/sprintf?

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

Цитата Jin X @ 07.08.18, 17:14

Да и _getch'а вроде как нет в C++.

std::cin.get();

?

Добавлено 08.08.18, 05:09

Цитата JoeUser @ 08.08.18, 03:57

Qraizer, ты считаешь средства форматирования в потоках i/o удобнее printf/sprintf?

С ними работать удобнее и безопаснее в С++(с потоками в смысле).
Допустим та же sprintf не безопасна.

Добавлено 08.08.18, 05:11
Ну и Сишные функции заточены исключительно на голые указатели, что как бы намекает - на то, что ты направил ствол в ногу, и пальцем дергаешь курок. Выстрелит - не выстрелит

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

Сообщение отредактировано: Wound - 09.08.18, 20:26

Цитата Wound @ 08.08.18, 04:15

?

_getch() подавляет эхо, std::cin.get() - нет.

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

Цитата JoeUser @ 08.08.18, 05:12

_getch() подавляет эхо, std::cin.get() - нет.

Отключи его системными функциями, если тебе нужно именно так:

    HANDLE hStdin = GetStdHandle(STD_INPUT_HANDLE);
    DWORD mode = 0;
    GetConsoleMode(hStdin, &mode);
    SetConsoleMode(hStdin, mode & (~ENABLE_ECHO_INPUT));

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

Цитата Wound @ 08.08.18, 04:15

С ними работать удобнее

На счет безопасности не говорим. Тут вопросов нет. А вот на счет удобства форматирования я бы поспорил.
К примеру, изобрази это манипуляторами потоков i/o:

char i = 12;
printf("%04d :: %0*x",i,4,i);

Добавлено 08.08.18, 05:28

Цитата Wound @ 08.08.18, 05:21

Отключи его системными функциями, если тебе нужно именно так:

А смысл городить эту "лапшу", если просто можно использовать _getch()?

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

Цитата JoeUser @ 08.08.18, 05:26

К примеру, изобрази это манипуляторами потоков i/o:

Загляни в iomanip, выбери интересующий тебя манипулятор - напиши его.

Вот тебе обратная задача, изобрази своими sprintf'ми:

MyObject object;
std::string message = "message";
std::ostringstream stream;
stream << "Message: " << message << << " Size: " << message.size() << object << std::endl;

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

Оффтопите. Да и Холивары у нас в отдельном разделе.


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

Сообщение отредактировано: JoeUser - 09.08.18, 20:26

Цитата Wound @ 08.08.18, 10:19

Загляни в iomanip, выбери интересующий тебя манипулятор - напиши его.

Зачем мне? У меня printf есть Я просто хотел показать несостоятельность твоего утверждения насчет мнимого "удобства" использования потоков в плане форматирования. А раз пошла песня "возьми и напиши ..." - значит я прав. Мне удобнее использовать готовое, чем изобретать велик

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

Цитата Wound @ 08.08.18, 10:19

Вот тебе обратная задача, изобрази своими sprintf'ми:

Еврейский у тя подход Не ответив на мой вопрос, задаешь свой

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

#include <iostream>
#include <sstream>
#include <cstdio>
 
class MyObject {
  public:
    char* str() {
      return const_cast<char*>(Data);      
    };
  private:
    const char* Data = "MyObject";
};
 
int main() {
  MyObject object;
  std::string message = "message";
  std::ostringstream stream;
  //stream << "Message: " << message << " Size: " << message.size() << object << std::endl;
  printf("Message: %s Size: %d%s\n",message.c_str(),message.size(),object.str());
  return 0;
}

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

Цитата Wound @ 08.08.18, 05:21

Отключи его системными функциями, если тебе нужно именно так

Ага. Т.е. ради принципа использовать функции C++ я должен нагромождать код всякой ерундой?
К тому же, я не о getchar говорю, а о _getch. Мне нужен не ввод строки до Enter'а, а 1 клавиша. Не надо путать.

Добавлено 09.08.18, 06:31
Короче... каждый инструмент имеет свои + и -, так что всё нужно применять с умом и к месту.
Вот и всё. Хотя эти + и - знать не мешает. Просто не надо говорить, что "а" однозначно лучше, чем "б".

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

Цитата Jin X @ 09.08.18, 06:29

Т.е. ради принципа использовать функции C++ я должен нагромождать код всякой ерундой?

Вообщето getch, _getch это не стандартная функция С++, это расширение от Майкрософт. На других системах твой код работать не будет.

Добавлено 09.08.18, 08:08

Цитата Jin X @ 09.08.18, 06:29

Короче... каждый инструмент имеет свои + и -, так что всё нужно применять с умом и к месту.
Вот и всё. Хотя эти + и - знать не мешает. Просто не надо говорить, что "а" однозначно лучше, чем "б".

Да, применять Сишные функции в языке С++, когда в нем есть аналоги - это не с умом и не к месту. И я сейчас говорю не о функции getch(так как она не имеет отношения не к С, не к С++).
Потому как проще тогда уже взять чистый Си и писать на нем, если на нем проще и удобней реализовать какую то задачу, чем на С++.

Добавлено 09.08.18, 08:12

Цитата Wound @ 09.08.18, 07:54

На других системах твой код работать не будет.

Даже банально может не скомпилироваться, когда ты вдруг внезапно перейдешь на другой компилятор.
В случае нагроможденного кода всякой ерундой, по крайней мере будет больше гарантий, что это будет работать и компилироваться в одной системе, но разными компиляторами.

Добавлено 09.08.18, 08:27
Ну и если заглянуть в MSDN, то можно внезапно обнаружить такую ремарку(https://msdn.microsoft.com/ru-ru/library/078sfkak.aspx):

This API cannot be used in applications that execute in the Windows Runtime. For more information, see CRT functions not supported with /ZW.

То есть оно даже к твоему удивлению может перестать работать, после изменения настроек компилятора.

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

Сообщение отредактировано: Wound - 09.08.18, 20:23

Цитата Wound @ 08.08.18, 05:21

Отключи его системными функциями, если тебе нужно именно так:

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

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

Цитата JoeUser @ 09.08.18, 08:39

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

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

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

Цитата Wound @ 09.08.18, 08:45

Вариант с _getch/getch - так же не подойдет, и?

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

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

Цитата JoeUser @ 09.08.18, 09:10

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

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

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

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

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

Зачем ты приплел охрану указателя? Вопрос был простой - считать символ с консоли венды. Все. Ничего более.

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

Цитата JoeUser @ 09.08.18, 09:39

Зачем ты приплел охрану указателя?

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

Цитата JoeUser @ 09.08.18, 09:39

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

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

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

Цитата Wound @ 09.08.18, 09:45

Стандартными средствами

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

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

Цитата JoeUser @ 09.08.18, 10:16

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

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

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

Цитата JoeUser @ 09.08.18, 09:10

А эффект тот же.

Тот же - от getchar.

Цитата Wound @ 09.08.18, 10:58

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

GCC нормально компилит. Но под виндой, в Linux'е нет (что, в принципе, ожидаемо).

Цитата Qraizer @ 09.08.18, 11:28

Jin X, тебя это всё тут устраивает? Может быть перейдёте в отдельную тему?

Мне это интересно.
Но если тебя смущает всё это именно в этой теме, раздели на 2 части, там и продолжим

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

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

M

Done

Сообщение отредактировано: Qraizer - 09.08.18, 20:28

Цитата JoeUser @ 08.08.18, 13:51

Еврейский у тя подход Не ответив на мой вопрос, задаешь свой

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

Цитата JoeUser @ 08.08.18, 13:51

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

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

Потоки:

#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 - 10.08.18, 08:30

Цитата JoeUser @ 08.08.18, 05:26

К примеру, изобрази это манипуляторами потоков i/o:

char i = 12;
printf("%04d :: %0*x",i,4,i);

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

Добавлено 10.08.18, 08:55
Короче, аргумент против сишного ввода-вывода ровно такой же, как и против динамической типизации в сравнении со статической. Но поскольку апологеты динамики, как правило, в принципе не понимают аргументы противоположной стороны, то, вангую, тут будет то же самое

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

Цитата JoeUser @ 10.08.18, 09:20

Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc .

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

Цитата OpenGL @ 10.08.18, 09:27

о сферическоваккумном удобстве форматирования стандартных типов

Да ладно? https://doc.rust-lang.org/std/fmt/

И к чему это тут? Если что, всё вышесказанное мной против сишного IO к расту не применимо - trait Debug ты можешь определить для своих типов, а форматная строка парсится во время компиляции, так что в вышеописанных случаях программа просто не скомпилится.

Цитата JoeUser @ 10.08.18, 09:20

Лишь говорю о том, что маска вывода у printf/sprint делает форматирование гораздо удобнее и лаконичнее, чем все эти std::hex, std::oct, std::setw, etc ... И не более. Никаких сравнений C vs C++.

Так в том и дело, что ты рассматриваешь только удобство форматирования, и все. Но почему то использование функций для этого форматирования, как я понял - ты не рассматриваешь. Почему - не понятно.
Ты ведь изначально написал, что printf часто удобнее std::cout. На практике - не удобнее ни разу.
Может быть ты и напишешь меньше букв, но проблем в коде, от этого у тебя не убавится, а напротив - добавятся. Ты это не учитываешь.
Я ж выше пример приводил, что проще написать int* p = new int, чем писать всякие std::shared_ptr и им подобные, меньше букв ведь выходит, но вот есть ли профит в этом? Вот у тебя выходит ровно то же самое.

Сообщение отредактировано: Wound - 10.08.18, 09:49

Цитата OpenGL @ 10.08.18, 09:39

И к чему это тут?

Это я о якобы "сферическовакуумном удобстве" форматной строки. Если уж в относительно новом языке Раст это пользуется (строка форматирования), значит - это не сферично, а удобно. Остальное, что ты написал я не понимаю.

Добавлено 10.08.18, 12:08

Цитата Wound @ 10.08.18, 09:47

не убавится, а напротив - добавятся.

Это не то место - где нужно боятся ошибок. В Си-подобных конструкциях есть более другие боле опасные места. Тут - ни а чем.

Цитата JoeUser @ 10.08.18, 12:00

Это не то место - где нужно боятся ошибок.

Угу, конечно:
Printf#Уязвимости

Цитата JoeUser @ 10.08.18, 12:00

Это я о якобы "сферическовакуумном удобстве" форматной строки.

А, то есть ты и слово "сферическовакуумный" не понимаешь

Вы все врети (С)

Цитата Wound @ 10.08.18, 08:29

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

Я это делаю уже лет 15, больше чем на 10 языках, разницы принципиально никакой.
точнее она мизерная, но ее зачем то пытаяюся раздуть, до астрономических
размеров . Единсвенный недостаток - нет деструкторов, хотя верояность
забыть close(fd) почти нулевая ,

Вот пример кода нa Cи, на С++ если не брать либы , будет тоже самое,
Не использовать Си в крестах значит отказаться от целого рада задач,

  struct pollfd fds[1];
  while(1) {
       rc= poll(fds,1,0);
       if(rc< 0) {
            perror(" poll error") ;
       }
        
        rc= read(fds[0].fd,buf, sizeof(buf));
        if(rc < 0 ) {
             perror(" pipe close");
            continue;
        }
        buf[rc] ='\0';
        printf(" reading : %s", buf);
    }

C++ это сегодня - условно "быстрая жава", язык для апликации,
если нужно работать с памятью, сетью, портами и т.д. то придеться вставлять С,
хоть та крестах хоть на звездах

Цитата settler @ 11.08.18, 07:26

Я это делаю уже лет 15, больше чем на 10 языках, разницы принципиально никакой.
точнее она мизерная, но ее зачем то пытаяюся раздуть, до астрономических
размеров . Единсвенный недостаток - нет деструкторов, хотя верояность
забыть close(fd) почти нулевая ,

Лол. Если ты выдашь бинарные данные в printf, то ничем хорошим это не закончится как минимум.

Цитата settler @ 11.08.18, 07:26

Вот пример кода нa Cи, на С++ если не брать либы , будет тоже самое,
Не использовать Си в крестах значит отказаться от целого рада задач,

Интересно, ты знаешь, что значит %s в строчке -> printf(" reading : %s", buf);
?
Каким образом бинарные данные превратились в строку? Ты судя по всему даже в типах данных не ориентируешься.

Цитата Wound @ 11.08.18, 08:41

Каким образом бинарные данные превратились в строку?

типом файла, точно также как в любом языке .

PollFD fds;
 
for(;;)
{
  fds.poll(0);
 
  std::string buf.resize(fds.tellg());
 
  fds.read(&buf[0]));
  std::cout << " reading : ", buf;
}

Цитата settler @ 11.08.18, 07:26

если нужно работать с памятью, сетью, портами и т.д. то придеться вставлять С,

Сочувствую.

Цитата settler @ 11.08.18, 14:04

типом файла, точно также как в любом языке .

То есть содержимое файла всегда является строкой? Ты точно ничего не путаешь? А если в бинарном файле вот такая последовательность символов будет:
"\0234sd\0\x234dsfg"
Расскажи, каким образом функция printf определит конец такой "строки"?

Цитата Qraizer @ 11.08.18, 14:18

Сочувствую.

т.е аргументов нет. ЧТД.

Добавлено 11.08.18, 15:14

Цитата Qraizer @ 11.08.18, 14:18

PollFD fds;
 
for(;;)
{
  fds.poll(0);
 
  std::string buf.resize(fds.tellg());
 
  fds.read(&buf[0]));
  std::cout << " reading : ", buf;
}

Цитата settler @ 11.08.18, 07:26

если нужно работать с памятью, сетью, портами и т.д. то придеться вставлять С,

Сочувствую.

PollFD fds;

чета Я такой структуры в С++ не нахожу, ну и обработку ошибок добавь,
профит будет мизерный, like I'v already said.

Цитата settler @ 11.08.18, 15:09

Цитата Qraizer @ 11.08.18, 14:18

Цитата settler @ 11.08.18, 07:26

если нужно работать с памятью, сетью, портами и т.д. то придеться вставлять С

Сочувствую.

т.е аргументов нет.

Есть. Это и был аргумент. Тебе придётся, мне не придётся. Впрочем, мы это уже проходили.

Цитата settler @ 11.08.18, 15:09

чета Я такой структуры в С++ не нахожу, ну и обработку ошибок добавь,
профит будет мизерный

Ты много чего в C++ не найдёшь, зато можешь добавить. Это мой класс. Обработка ошибок внутри.

Цитата Qraizer @ 11.08.18, 16:34

Это мой класс. Обработка ошибок внутри.

Который внутри, использует Си, сделать хотя не все (CreateRemoteThread для примера
на плюсах нет) или добраться до private members, по сути(взлом) только на Cи,
share memory на плюсах не сделаешь, а если сделаешь то большой вопрос,
стоит ли овчинка выделки? В 2011 ты смог оптимизировать снизив скорость с 400 до 12%,
a сможешь ли каждый раз так сделать?, а если ты заболел или ушел, кто вместо тебя это сделает? Не надо фанатизма, изобретать свой std::map глупо, также как насильно
пихать ООП once is not critical necessary.
Ошибки на Си try catch тоже делаются если очень надо,

Ну и еще фактор привычки, навыков и т.д.
А смешивать стили без необходимости нету смысла, если решил юзать cout ,
то пользуй std:endl a не "\n", and vice versa.

Цитата settler @ 11.08.18, 19:34

Который внутри, использует Си

Уверен?
А даже если и так, что с того? Написал один раз, использовать буду много, и всё по-Плюсовому. Твои C-функции тоже запросто могут быть написаны на ассемблере или паскале. К слову, RTL для C в новых MS-ных студиях написана на C++. Всё по-взрослому, на шаблонах, с RAI, итп. Ну-ну, пиши на C дальше.

Цитата Qraizer @ 11.08.18, 21:50

Цитата settler @ 11.08.18, 19:34

Который внутри, использует Си

Уверен?
А даже если и так, что с того? Написал один раз, использовать буду много, и всё по-Плюсовому. Твои C-функции тоже запросто могут быть написаны на ассемблере или паскале. К слову, RTL для C в новых MS-ных студиях написана на C++. Всё по-взрослому, на шаблонах, с RAI, итп. Ну-ну, пиши на C дальше.

Использовать много раз можно написав на чем угодно, а выбор языка зависит
от задачи, не понимаю твоей категоричности.

Ну напиши один раз обработку ошибок. Что ж ты её копируешь в каждую точку использования.
Язык вообще мало на что влияет, когда человек его плохо знает. Вот навыки человека реально влияют на качество использования языка.