Неудачный выход, возможный переполнение переполнения?

Question

Я довольно новичок в C++, и сейчас я беру интро-курс в школе. Одно из заданий на этой неделе - решить довольно длительное уравнение. Так что я сделал, это разбить его на маленькие куски. Я получаю странный результат, когда я пытаюсь использовать функцию греха, так что я начал бездельничать немного и изолировав его к этому ...

#include <iostream> 
#include <cmath> 
using namespace std; 

int main() 
{ 
    double input1, input2, a; 
    cout << "Enter first input." << endl; 
    cin >> input1; 
    cout << "Enter second input." <<endl; 
    cin >> input2; 

    a = input2 - input1*2; 
    cout << a << endl; // This doesn't give expected output 
    cout << input2 - 2*input1 <<endl; //This gives the expected result 
    return 0; 
} 

И в качестве возвращаемого значения я получаю безумно маленькие номер: 6.95323e-310. Очевидный вопрос: почему?

Если это вообще помогает, я делаю это на Mac OS, используя g ++ 4.2.

Мои входные значения 5 и 2 ... поэтому я ожидаю -8.

Спасибо.

Answer 1

код, который вы размещены отлично работает для меня в различных компиляторов, однако я хотел бы предложить несколько усовершенствований:

cout << input2 - 2*input1 <<endl; Я изменил бы это cout << input2 - (2*input1) <<endl;

Я также хотел бы убедиться, что КИН полностью ясно, прежде чем принимать входной сигнал с помощью: следующий измененный код:

cout << "Enter first input." << endl; 
cin.clear(); 
cin >> input1; 
cout << "Enter second input." <<endl; 
cin.clear(); 
cin >> input2; 

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

После этого я несколько раз перешагнул программу и проверил выходы: когда переменные установлены неправильно (т.е. они содержат любое значение, находящееся в ячейке памяти, используемой переменной), я последовательно получаю ответы, похожие на ваши опубликовал один.

Итак, простой ответ заключается в том, что переменные не инициализированы, потому что буфер cin не очищается.

Надеется, что это помогает, и дайте мне знать, если вам нужно лучше/более глубокое объяснение :)

Добавление:

Несколько больше очков я просто подумал, что на чтение других комментариев:

using namespace std; - это прекрасно подходит для небольших проектов, которые вы полностью контролируете, то есть домашнее задание, небольшие задания и т. Д. Однако, когда вы используете разнообразный код (другие библиотеки, API и т. Д.), Более целесообразно напрямую управлять пространствами имен: они существуют для разрешения вы нацеливаете определенные функции в пределах определенного пространства имен и избегаете конфликтов имен/ambig в коде. Например, вы можете вызвать cin в настоящее время, позже, хотя вы можете включить в свой код другой API, позвольте ему назвать пространство имен TEST, поэтому вы добавляете using namespace TEST; TEST содержит свою собственную реализацию cin, которая автоматически обрабатывает очистку cin (удобна, потому что это может решить вашу проблему), однако ваш код не может компилироваться сейчас, потому что у вас есть std::cin и TEST::cin оба доступны, и потому что вы используете пространство имён для использования для обоих при вводе Это может быть и то, и другое.

Существовал также предложение использовать поплавок и не в два раза, пару точек на этом:

• с помощью поплавка или двойной позволит десятичные значения = TRUE
• с помощью поплавка, а не двойной исправит вас проблема = очень редко. Правда, существуют ограниченные экземпляры, где бит-размер поплавка исправляет проблему, вызванную битовым размером двойника.
• общего программирования конвенции: для эффективности использования памяти, использовать наименьший возможный тип, который может содержать все значения прецедентов (двойной номинально два раза превышает размер поплавка в памяти, поэтому 0.3f половина использование памяти 0.3d

Я знаю, что это для домашней работы, как вы упомянули, поэтому я добавил дополнительную информацию: всегда полезно получать дополнительную информацию, согласны ли вы с ней или нет, это позволит вам исследовать больше, глубина и соглашаться/доказывать или не соглашаться/опровергать исходную информацию, которую вы имели. Добро пожаловать в программирование, кстати, это только ухудшается!

Лучше! Я имел в виду лучше!