Сужающие преобразования в C ++ 0x. Это только у меня, или это похоже на переломную ситуацию?

Я столкнулся с этим критическим изменением, когда использовал GCC. Компилятор напечатал ошибку для такого кода:

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {i & 0xFFFFFFFF, i >> 32};
}

В функции void foo(const long long unsigned int&):

ошибка: сужение преобразования (((long long unsigned int)i) & 4294967295ull) с long long unsigned int на unsigned int внутри {}

ошибка: сужение преобразования (((long long unsigned int)i) >> 32) с long long unsigned int на unsigned int внутри {}

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

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {static_cast<unsigned int>(i & 0xFFFFFFFF),
            static_cast<unsigned int>(i >> 32)};
}

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

Я был бы удивлен и разочарован, узнав, что любой код C ++, который я написал за последние 12 лет, имел такого рода проблемы. Но большинство компиляторов выдавали бы предупреждения о любых «сужениях» времени компиляции, если я чего-то не упускаю.

Это тоже сужает конверсию?

unsigned short b[] = { -1, INT_MAX };

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

Практический пример, с которым я столкнулся:

float x = 4.2; // an input argument
float a[2] = {x-0.5, x+0.5};

Числовой литерал неявно double, что вызывает повышение.

Не удивлюсь, если кого-нибудь поймают на словах вроде:

float ra[] = {0, CHAR_MAX, SHORT_MAX, INT_MAX, LONG_MAX};

(в моей реализации последние два не дают того же результата при преобразовании обратно в int / long, следовательно, сужаются)

Однако я не помню, чтобы когда-либо писал это. Это полезно, только если приближение к пределам полезно для чего-то.

Это тоже кажется хотя бы отдаленно правдоподобным:

void some_function(int val1, int val2) {
    float asfloat[] = {val1, val2};    // not in C++0x
    double asdouble[] = {val1, val2};  // not in C++0x
    int asint[] = {val1, val2};        // OK
    // now do something with the arrays
}

но это не совсем убедительно, потому что, если я знаю, что у меня ровно два значения, зачем помещать их в массивы, а не просто float floatval1 = val1, floatval1 = val2;? Но какова мотивация, почему это должно компилироваться (и работать, при условии, что потеря точности находится в пределах приемлемой точности для программы), а float asfloat[] = {val1, val2}; - нет? В любом случае я инициализирую два числа с плавающей запятой из двух целых чисел, просто в одном случае эти два числа с плавающей запятой являются членами агрегата.

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

char i = something();
static_assert(CHAR_BIT == 8);
double ra[] = {i}; // how is this worse than using a constant value?

Предполагая, что ошибки нет, по-видимому, исправление всегда состоит в том, чтобы сделать преобразование явным. Если вы не делаете что-то странное с макросами, я думаю, что инициализатор массива появляется только близко к типу массива или, по крайней мере, к чему-то, представляющему тип, который может зависеть от параметра шаблона. Таким образом, гипс должен быть простым, хотя и подробным.

Попробуйте добавить -Wno-сужение к своим CFLAGS, например:

CFLAGS += -std=c++0x -Wno-narrowing

Ошибки сужающегося преобразования плохо взаимодействуют с неявными целочисленными правилами продвижения.

У меня была ошибка с кодом, который выглядел как

struct char_t {
    char a;
}

void function(char c, char d) {
    char_t a = { c+d };
}

Что дает сужающую ошибку преобразования (что правильно по стандарту). Причина в том, что c и d неявно повышаются до int, и результирующий int не может быть сужен до char в списке инициализаторов.

OTOH

void function(char c, char d) {
    char a = c+d;
}

конечно все еще в порядке (иначе бы весь ад вырвался на свободу). Но что удивительно, даже

template<char c, char d>
void function() {
    char_t a = { c+d };
}

в порядке и компилируется без предупреждения, если сумма c и d меньше CHAR_MAX. Я все еще думаю, что это дефект C ++ 11, но люди там думают иначе - возможно, потому, что его нелегко исправить, не избавившись от неявного целочисленного преобразования (что является пережитком прошлого, когда люди писали код как char a=b*c/d, и ожидал, что он будет работать, даже если (b * c)> CHAR_MAX) или сужение ошибок преобразования (что, возможно, хорошо).

Это действительно было критическое изменение, поскольку реальный жизненный опыт использования этой функции показал, что gcc превратил сужение в предупреждение об ошибке во многих случаях из-за реальных жизненных проблем с переносом баз кода C ++ 03 на C ++ 11. См. этот комментарий в отчете об ошибке gcc:

Стандарт требует только, чтобы соответствующая реализация выдавала хотя бы одно диагностическое сообщение, поэтому компиляция программы с предупреждением разрешена. Как сказал Эндрю, -Werror = сужение позволяет вам сделать ошибку, если хотите.

G ++ 4.6 выдавал ошибку, но для версии 4.7 она была намеренно изменена на предупреждение, потому что многие люди (в том числе и я) обнаружили, что сужение преобразований является одной из наиболее часто встречающихся проблем при попытке скомпилировать большой C Кодовые базы ++ 03 как C ++ 11. Ранее правильно сформированный код, такой как char c [] = {i, 0}; (где i всегда будет в пределах диапазона char) вызвали ошибки, и их пришлось заменить на char c [] = {(char) i, 0}