Как лучше справляться с предупреждением c4305, когда тип может измениться?

Question

Я использую как Ogre, так и NxOgre, которые имеют Real typedef, который либо float, либо double в зависимости от флага компилятора. Это привело к тому, что большинство наших предупреждений компилятора теперь составляют:

warning C4305: 'argument' : truncation from 'double' to 'Ogre::Real' 

При инициализации переменных, например, 0,1. Обычно я использовал бы 0.1f, но если вы измените флаг компилятора на двойную точность, вы получите обратное предупреждение. Я думаю, что лучше всего выбрать один и придерживаться его, но я бы хотел написать их таким образом, чтобы они работали для любой конфигурации, если это было возможно.

Одним из исправлений было бы использование #pragma warning (disable : 4305) в файлах, где это происходит, я не знаю, есть ли какие-либо другие более сложные проблемы, которые могут быть скрыты, не имея этого предупреждения. Я понимаю, что я бы нажал и поместил их в заголовочные файлы, чтобы они не распространялись по всему коду.

Другой способ заключается в создании какой-то макрос, на основе флага компилятора точности, как:

#if OGRE_DOUBLE_PRECISION 
    #define INIT_REAL(x) (x) 
#else 
    #define INIT_REAL(x) static_cast<float>(x) 
#endif 

, который потребует изменения всех переменная инициализации сделано до сих пор, но, по крайней мере, было бы на будущее.

Любые предпочтения или что-то, о чем я не думал?

Answer 1

простое решение было бы просто добавить роли:

static_cast<Ogre::Real>(0.1); 

или вы могли бы написать функцию, чтобы сделать преобразование для вас (по аналогии с макросом, но избегая все противные проблемы макросов принести:

template <typename T> 
inline Ogre::Real real(T val) { return static_cast<Ogre::Real>(val); } 

Тогда вы можете просто позвонить real(0.1) и получить значение как Ogre::Real.

Answer 2

Очевидно, что если вы используете конкретную платформу, то должны быть и литералы. Те же проблемы возникают при использовании TCHAR, CStrings, LPCTSTR и т. Д. ..., только хуже: char не может быть преобразован в wchar_t.

Так что я предпочел бы, безусловно, перейти к инициализации макроса. Предупреждение об опасном действии.

Вы можете даже указать макрос для добавления «всплыть» буквальный тег:

//#define DOUBLEPREC 

#ifndef DOUBLEPREC 
typedef float REAL; 
#define INIT_REAL(r) (r##f) 
#else 
typedef double REAL; 
#define INIT_REAL(r) r 
#endif 

REAL r = INIT_REAL(.1); 
double d = INIT_REAL(.1); 
float f = INIT_REAL(.1); 

Answer 3

Что касается меня, то я бы придерживаться одного из типов и забыть об этом предупреждении. Во всяком случае, двойная/одинарная точность оказывает минимальное влияние на fps (в моих проектах это было < 3%).

Также, как я знаю, DirectX и OpenGL работают с единой точностью.

Если вы действительно хотите избавиться от этого предупреждения надлежащим образом, вы можете использовать материал #if, но не так, как вы. Лучший подход, чтобы сделать что-то вроде

#if OGRE_DOUBLE_PRECISION == 1 
    // Note that 
    typedef double Real; 
#else 
    typedef float Real; 
#endif 

Вы также можете написать свой код, используя Ogre :: Real как тип (или typedefing его так, что это будет удобно для вас).

Answer 4

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

Visual Studio, кажется, выполняет расширение во время компиляции даже в отладочных сборках, хотя результаты не совсем вдохновляют: передача 1.1f в функцию, которая принимает двойной проход 1.1000000238418579, но пропускает 1.1 в проходах 1.1000000000000001. (Оба эти значения не в соответствии с окном просмотра.)

(нет таких проблем с числами, которые имеют точное представление, конечно, например, 1.25f.)

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