Падает релиз, или корявые оптимизации

[Abstraction]

{ Arg arg = 10;  int val = arg;  cout<<"val = "<<val<<endl; }
{ int src = 20; Arg arg = &src;  int *ptr = arg;  cout<<"src = "<<*ptr<<endl; }

Раздел 8.5.3, пункты 5 и 6, подразумевают, что ссылки на POD-типы в части времени их жизни оговариваются теми же правилами, что и ссылки на объекты классов.
Раздел 12.2, пункт 5:

The temporary to which the reference is bound or
the temporary that is the complete object of a subobject to which the reference is bound persists for the lifetime of the
reference except as specified below. A temporary bound to a reference member in a constructor’s ctor-initializer (12.6.2)
persists until the constructor exits.

В обоих случаях создаётся временный объект, время жизни которого заканчивается сразу после инициализации arg. Далее, в соответствии с разделом 3.8 выделенная под временный объект память может быть reused. После того, как это произойдёт, *arg.mAddr можно будет использовать только в качестве lvalue (раздел 3.8, пункт 6):

Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated
or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any
lvalue which refers to the original object may be used but only in limited ways. Such an lvalue refers to allocated storage
(3.7.3.2), and using the properties of the lvalue which do not depend on its value is well-defined. If an lvalue-to-rvalue
conversion (4.1) is applied to such an lvalue, the program has undefined behavior

По-моему, как-то так.

[waleri]

Вспылил, был неправ:
Arg arg = 10;
по стандарту еквивалентно
Arg arg; arg = Arg(10);

Тогда как в MSVC будет напрямую:
Arg arg(10);

Вот вам код, который прокатит в MSVC 2010- и завалит GCC (в 2012 вроде пофикшено):

class CTest
{
public:
    CTest( int )    { }
private:
    CTest(const CTest&) { }
};
int main()
{
    CTest a(10);
    CTest b = 10;
    return 0;
}

[_Bers]

Сообщение от waleri

Да, данный код некорректен. Не зря его GCC не берет.

Далее, ваш код позволяет из const объекта сделать не-const, что тоже не очень хорошо.

1. Выше указанная ссылка с примером это вообще то как раз таки последняя версия gcc 4.8.0.

Там есть возможность выбирать разные версии компиляторов. Можете по-эскперементировать - этот код работает.

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

И вот только позавчера провалился релизный тест, что и привлекло моё внимание (есть пакет гугл-тестов, которые собираются на разных настройках компиляторов, и покрывают весь функционал механизма).

В действительности, Arg - это аргумент функции.
Изначально,я создал его для того, что бы имитировать шаблонные виртуальные функции:

//потомки смогут работать с любыми типами данных
virtual Arg Func(const Arg a)=0;

И можно понять, почему в боевом проекте баг не проявился:

void Foo(const Arg arg);
...

Foo(10); //пока функция не отработает, временный объект жив
//поэтому Arg содержит валидные данные.

2. То, что я показал по ссылке - это всего лишь пример. Реальный механизм содержит достаточно бизнес-логики, что бы обеспечить типо-безопасность.

Учитывает константность объектов. Умеет работать с любыми типами данных, включая массивы.

3. В действительности, ещё раз глянул тесты: релиз студии провалился на тесте, где Arg был использован вне пределов функции.

И поломался на временном объекте.

Резюмируя: использование Arg безопасно только если его использовать по назначению: внутри функций. И чревато если использовать снаружи функций...

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

Вот только знать бы как это вообще можно такой статический ассерт то вляпать...

[waleri]

Сделайте конструктор explicit - возможно поможет

[_Bers]

Сообщение от waleri

Вот вам код, который прокатит в MSVC 2010- и завалит GCC (в 2012 вроде пофикшено):

class CTest
{
public:
    CTest( int )    { }
private:
    CTest(const CTest&) { }
};
int main()
{
    CTest a(10);
    CTest b = 10;
    return 0;
}

http://liveworkspace.org/code/O7CSz$2

Вообще, понятия не имею, за каким макаром, гцц докалебался до приватного копирующего конструктора

[Somebody]

Сообщение от _Bers

http://liveworkspace.org/code/O7CSz$2

Вообще, понятия не имею, за каким макаром, гцц докалебался до приватного копирующего конструктора

Потому что

CTest b = 10;
// это
CTest b(CTest(10));
// а не
CTest b; b = CTest(10);

[Abstraction]

Потому что

Неверно. Обратите внимание на вывод. Если бы Вы были правы, выводилось бы COPY (оптимизация этого не должна изменять, ибо наблюдаемое поведение).

[Somebody]

Сообщение от Abstraction

(оптимизация этого не должна изменять, ибо наблюдаемое поведение)

Почему это?
C++11 12.8.31

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
...
when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move

[Abstraction]

Н-да. Нехорошо (с моей стороны). Может, подскажете, где лежат заведомо корректные стандарты 2003 и 2011?

[Somebody]

Заведомо корректные стандарты за деньги продаются :-(
А так
http://cs.nyu.edu/courses/spring13/C...ard%202003.pdf
http://www.open-std.org/jtc1/sc22/wg...2012/n3376.pdf