Простой вопрос по консальному приложению
#include <conio.h>
void main()
{
char m_Text[500];
printf("Введите текст: ");
gets(m_Text);
printf("Вы ввели %s\n", m_Text);
getch();
}
Вопрос первый:
Размер массива m_Text указывается явно в начале программы, а хотелось бы сделать массив динамическим и определять его размер уже после ввода текста.
Вопрос второй:
Вместо "Введите текст" и "Вы ввели" отображается какая то херь нерусская. Хотя сам текст вводится\выводится вполне понятно и грамматически верно. Как бороться? В настройках компилятора тоже стоит русский - /l 0x419. Ставил English(USA) - ничерта не помогло
Размер массива m_Text указывается явно в начале программы, а хотелось бы сделать массив динамическим и определять его размер уже после ввода текста.
:) у тебя в качестве параметра функции gets стоит указатель на строку. как ты думаешь, что получиться, если ты будешь определять размер буффера в который ты считываешь уже после считывания? :)
использование символьных массивов с заранее заданным размером - вполне нормальная практика в C. в С++ - можно использовать string.
#include<stdio.h>
#include<alloc.h>
void my_gets(char *str)
{
char buf=malloc(80*25);
gets(buf);
str=malloc(strlen(buf));
strcpy(str,buf);
free(buf);
}
void main()
{
char *ptr;
my_gets(ptr);
printf("%s\n",ptr);
free(ptr);
}
Динамически создавать массивы можна используя malloc (calloc + etc из alloc.h). Возможно тебе поможет такое рещение.
#include<stdio.h>
#include<alloc.h>
void my_gets(char *str)
{
char buf=malloc(80*25);
gets(buf);
str=malloc(strlen(buf));
strcpy(str,buf);
free(buf);
}
void main()
{
char *ptr;
my_gets(ptr);
printf("%s\n",ptr);
free(ptr);
}
утверждать не буду, но по моему - это те же яйца, только вид с нестандартной стороны. смысла в таком решении задачи не вижу ;)
утверждать не буду, но по моему - это те же яйца, только вид с нестандартной стороны. смысла в таком решении задачи не вижу
Iktomy попросил динамическое выделение памяти под строку - он его получил. Хорошо так делать или нет - вопрос не ко мне. На счет яиц - сам бы я так писать не стал.;)
Iktomy попросил динамическое выделение памяти под строку - он его получил. Хорошо так делать или нет - вопрос не ко мне. На счет яиц - сам бы я так писать не стал.;)
зачем давать заведомо глупое, (или скажем мягче - нехорошее) решение??? ты не стал бы так делать, так зачем советуешь другим? не проще объяснить челу - как правильнее?
Сам я делаю именно так.
Причем считывание в буфер заведомого размера защищает от превышения возможнонужного размера строки.
вот и все :)
Другого нормального варианта кроме как считать строку в буфер заведомого размера, а потом перекинуть в переменную, которую сделать нужного размера, я не вижу.
Сам я делаю именно так.
Причем считывание в буфер заведомого размера защищает от превышения возможнонужного размера строки.
вот и все :)
А как на счет потоков?
#include <iostream>
int main()
{
std::string strText;
std::cout << "Введите текст: ";
std::getline(std::cin, strText);
std::cout << "Вы ввели: " << strText << std::endl;
return 0;
}
Дык вот скажите мне, можно ли преобразовать char в численный тип, правильно ли я мыслю по поводу решения вообще или лучше мне выпить валерьянки и еще раз подумать.
И хоть кто ни будь скажет таки, как побороть каракули при выводе.
Является ли символ цифрой - проверяй isdigit, из ctype.h. Преобразования строки в число - atoi - в int, atol - в long, atof - в double. Вот. Только повнимательнее с ошибками.
А вот на счет каракуль - не знаю. Может в свойствах exe' шника шрифт поменять?
char str[128];
strcpy(str, "Текст по русски");
CharToOem(str, str);
printf(str);
Тут все описано:
MSDN->Platform SDK->Windows Base Service->General Library->String manipulation->String manipulation reference->String manipulation functions
Итак.
Является ли символ цифрой - проверяй isdigit, из ctype.h. Преобразования строки в число - atoi - в int, atol - в long, atof - в double. Вот. Только повнимательнее с ошибками.
А почему бы не использовать С++, чтоб не допускать потенциальных ошибок?
#include <string>
#include <sstream>
template <typename T>
std::string toString(T val)
{
std::ostringstream oss;
oss<< val;
return oss.str();
}
template<typename T>
T fromString(const std::string& s)
{
std::istringstream iss(s);
T res;
iss >> res;
return res;
}
int main()
{
std::string str = toString(5.56);
float val = fromString<float>(str);
std::cout << "str=" << str <<std::endl;
std::cout << "val=" << val <<std::endl;
return 0;
}
P.S. в fromString необходимо ввести проверку, что первый символ является числом:
T fromString(const std::string& s)
{
if( !isdigit(s.at(0)) ) return 0;
std::istringstream iss(s);
T res;
iss >> res;
return res;
}
А почему бы не использовать С++, чтоб не допускать потенциальных ошибок?
#include <string>
#include <sstream>
template <typename T>
std::string toString(T val)
{
std::ostringstream oss;
oss<< val;
return oss.str();
}
template<typename T>
T fromString(const std::string& s)
{
std::istringstream iss(s);
T res;
iss >> res;
return res;
}
int main()
{
std::string str = toString(5.56);
float val = fromString<float>(str);
std::cout << "str=" << str <<std::endl;
std::cout << "val=" << val <<std::endl;
return 0;
}
P.S. в fromString необходимо ввести проверку, что первый символ является числом:
T fromString(const std::string& s)
{
if( !isdigit(s.at(0)) ) return 0;
std::istringstream iss(s);
T res;
iss >> res;
return res;
}
А почему бы не использовать C чтобы не допускать фрагментации памяти?
Green, кстати ты не в курсе, где исправляют различные глюки и тупой код в STL, WTL. Я хочу написать им. Так, например, по моему при включении <map> выводится warning 4702, а со скольки warningами сделан ATL/WTL и они просто там дисабляться страшно сказать.
А почему бы не использовать С++, чтоб не допускать потенциальных ошибок?
...
...
...
[/CODE]
5.56 это альфа и омега рациональных чисел?
В начале топика вроде говорилось о вводе каких-то данных через клавиатуру...
Второй вариант fromString()
-8.92 он примет за float? Или переведет в 0?
Первый вариант принимает за -8.92.
5.56 это альфа и омега рациональных чисел?
Это пример использования.
В начале топика вроде говорилось о вводе каких-то данных через клавиатуру...
Ну... и в чем проблема?
Кто мешает черпать из потока std::cin ?
Второй вариант fromString()
-8.92 он примет за float? Или переведет в 0?
Первый вариант принимает за -8.92.
Код в P.S. не является рабочим применительно к отрицательным значениям, согласен.
Думаю, релизовать правильную проверку не составит большого труда?
А почему бы не использовать C чтобы не допускать фрагментации памяти?
Почему? Мы сейчас опять сцепимся по поводу С/С++.
Фрагментация памяти? Ты о чем? :)
Green, кстати ты не в курсе, где исправляют различные глюки и тупой код в STL, WTL. Я хочу написать им. Так, например, по моему при включении <map> выводится warning 4702, а со скольки warningами сделан ATL/WTL и они просто там дисабляться страшно сказать.
STL я заменил на STLPort c stlport.com, там же на форуме можно оставить сообщение о найденных недостатках.
А WTL лучше взять последний с SourceForge, там многое пофиксено. Там же можно указать/узнать о багах: http://sourceforge.net/projects/wtl/
Код в P.S. не является рабочим применительно к отрицательным значениям, согласен.
float val = fromString<float>(".2");
std::cout << "val=" << val <<std::endl;
тоже печатает не то что надо, хоть 0.2 > 0
Конечно. Достаточно убрать из второго варианта первую команду.
float val = fromString<float>(".2");
std::cout << "val=" << val <<std::endl;
тоже печатает не то что надо, хоть 0.2 > 0
Конечно. Достаточно убрать из второго варианта первую команду.
Вообще-то, класс fromString обладает большей универсальностью, чем переводить из строки в число, поэтому в первом варианте и нет проверки.
Но! Если говорить о переводе в число, то есть вероятность неправильного перевода в случае, если строка начинается с буквы.
Что касается .2, то следует согласовать написание чисел и уж потом вводить соотв. проверку, т.к. невозможно создать программу, которая отследила бы все возможные варианты записи.
Я тут поэкпирементировал с atoi, atof и проч. Но ничерта хорошего из этого не вышло. Поставим вопрос по другому, как таки проверить является ли набор символов числом или нет? Есть ли вообще такие способы. А то эти ato и сотоварищи просто конвертят символы буквенные во всякую бредятину. Лучше бы возвращали сообщение об ошибке. Может они это и делают, но по крайней мере в MSDN я ничего не накопал. Или может копал неглубоко.:(
А за CharToOem спасибочки, глюки исчезли. Только вот жаль, что простое консольное приложение, которое по идее и в ДОС должно компилися теперь затребовало Виндошный хедэр. Ну да черт с ним.
Создание потока
создание объекта string при вызове str()
вызов конструктора копирования string для строки в теле главной функции
Вызов деструктора потока
вызов деструктора string для строки, созданной внутри тела функции
Вызов деструктора для string в теле главной функции при выходе из проги.
Два варианта оптимизации
1)посчитать сколько знаков и создать массив.
2)сделать нормальные операторы
template <typename T>
string &operator <<(string &str, T& t);
Выполнение кода - вызов функции toString
Создание потока
создание объекта string при вызове str()
вызов конструктора копирования string для строки в теле главной функции
Вызов деструктора потока
вызов деструктора string для строки, созданной внутри тела функции
Вызов деструктора для string в теле главной функции при выходе из проги.
Два варианта оптимизации
1)посчитать сколько знаков и создать массив.
2)сделать нормальные операторы
template <typename T>
string &operator <<(string &str, T& t);
Зачем?!
Зачем каждый раз изобретать велосипед именно для данного случая?
Почему бы не писать на ассемблере? Ничего лишнего.
Переписать все системные контролы, т.к. они делают много лишнего, переписать весь crt и т.д.
Зачем?!
Если у тебя настолько критичный код, пиши на ассме, т.к. даже на С в результат попадет много всего лишнего.
Почему бы не писать на ассемблере? Ничего лишнего.
Переписать все системные контролы, т.к. они делают много лишнего, переписать весь crt и т.д.
Боюсь на Асме это не совсем то что мне надо, мне нужен Си и только.
Да, я тут на выходных мозгами пораскинул, все проработал и поэтому сенкс всем, а я уж дальше сам.
Прошу товарища модератора считать тему закрытой!:!!!:
А за CharToOem спасибочки, глюки исчезли. Только вот жаль, что простое консольное приложение, которое по идее и в ДОС должно компилися теперь затребовало Виндошный хедэр. Ну да черт с ним.
Возможно я уже и опоздал, но вдогонку два соображения:
- Консольное приложение Win32 не имеет ничего общего с DOS - это обычная виндовая прога, просто интерфейс у нее такой. Поэтому вполне логично, что компилироваться она должна с учетом зависимости от платформы.
- Если вывод на экран делается файловыми фуккциями, тебе могут помочь AreFileApisANSI, SetFileApisToANSI, SetFileApisToOEM. Тогда не понадобится каждый раз переводить строку в набоор символов OEM самому.