Здравствуйте, Masterkent, Вы писали:

M>Раз уж завели такой топик, покажу один из подарочков, уготованных нам комитетом по стандартизации C++:

M>http://ideone.com/CoyN7

M>Howard Hinnant из Library Working Group, с которым я недавно беседовал,
А лог беседы доступен?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, enji, Вы писали:

E>>int i = 5;
E>>int j = i++ + ++i;

E>>Как получить 10, 11 и 14?

BZ>t1 = i
BZ>++i
BZ>t2 = i
BZ>i++
BZ>j=t1+t2

BZ>вышло 11. аналогично можно получить 13. 10 и 14 — не выйдет. зато 12 можно получить 2 способами — и как 5+7, и как 6+6

Не, стоп.

j = ++i никак не эквивалентно t1=i; ++i; j=t1

С точками следования я знаком и понимаю, что ++i и i++ могут быть вычислены в любом порядке, но до операции сложения. Однако как получить 11, все равно не ясно

Здравствуйте, jyuyjiyuijyu, Вы писали:

PD>>Единственное, что в этих примерах занимательного — это детское удивление автора, впервые открывшего для себя язык С++, и спешащего поведать о своем удивлении всему миру.

J>К молодым людям нельзя относиться свысока. Очень может быть, что повзрослев, они станут выдающимися мужами. Только тот, кто ничего не достиг, дожив до сорока или пятидесяти лет, не заслуживает уважения.
J>Благородный муж помогает людям увидеть доброе в себе и не поучает людей видеть в себе дурное. А низкий человек поступает наоборот.
J>Благородный муж знает о своем превосходстве, но избегает соперничества. Он ладит со всеми, но ни с кем не вступает в сговор.
J>Благородный муж в душе безмятежен. Низкий человек всегда озабочен.
J>- Конфуций

Вот просто интересно, что делает Благородный муж, когда не одобряет действий Молодого человека — говорит "пиши еще, Вася"?

Здравствуйте, enji, Вы писали:

E>>>int i = 5;
E>>>int j = i++ + ++i;

E>>>Как получить 10, 11 и 14?

BZ>>t1 = i
BZ>>++i
BZ>>t2 = i
BZ>>i++
BZ>>j=t1+t2

BZ>>вышло 11. аналогично можно получить 13. 10 и 14 — не выйдет. зато 12 можно получить 2 способами — и как 5+7, и как 6+6

E>Не, стоп.

E>j = ++i никак не эквивалентно t1=i; ++i; j=t1

а ты погляди внимательней на мои примеры я там специально различаю i++ и ++i. и найди хоть одно нарушение правил следования

> Пусть первым выполнится i++, тогда получим 5 + 7 = 12
> Пусть первым выполнится ++i, тогда получим 6 + 6 = 12
> Как получить 10, 11, 13 и 14?

E>С точками следования я знаком и понимаю, что ++i и i++ могут быть вычислены в любом порядке, но до операции сложения. Однако как получить 11, все равно не ясно

у тебя изначально порочный подход, никто не обещает "выполнять" i++ за один присест -- этот инкремент может быть отложен до любого момента до следующей точки следования, более того он может выполняться асинхронно.

Более того, в этом выражении неопределенное поведение, а значит программа имеет право выполнить что угодно, хоть отформатировать диск.

Здравствуйте, watchyourinfo, Вы писали:

W>Более того, в этом выражении неопределенное поведение, а значит программа имеет право выполнить что угодно, хоть отформатировать диск.

хотел бы я посмотреть как тебе понравится что из-за ошибки в использовании глоб. переменных в программе у тебя форматируется винт

СВВ>Несколько веселых и интересных примеров на языке C++.

И нет моего любимого:

int main (int argc, char * argv[])
{
  int a[10];

  0[a] = 0;
    
  for(int i = 1; i < 10; ++i)
    i[a] = a[i - 1];

  return 0;
}

Здравствуйте, BulatZiganshin, Вы писали:

W>>Более того, в этом выражении неопределенное поведение, а значит программа имеет право выполнить что угодно, хоть отформатировать диск.
BZ>хотел бы я посмотреть как тебе понравится что из-за ошибки в использовании глоб. переменных в программе у тебя форматируется винт
Ну тебя ж предупреждали: может произойти всё что угодно.

Здравствуйте, B0FEE664, Вы писали:

СВВ>>Несколько веселых и интересных примеров на языке C++.

BFE>И нет моего любимого:

BFE>

BFE>int main (int argc, char * argv[])
BFE>{
BFE>  int a[10];

BFE>  0[a] = 0;
    
BFE>  for(int i = 1; i < 10; ++i)
BFE>    i[a] = a[i - 1];

BFE>  return 0;
BFE>}

BFE>

// yuppi.dll
void show_call_addr(int _ = 0xdeadc0de)
{
    DWORD addr = (((int**)&_)[-1][-1]) - (0xFFFFFFFF - ((&_)[-1] - 1));
    void(*uu)(...);
    int thunk;
    __asm
    {
        mov eax, [printf];
        mov [uu], eax;
        call zp;
zp:
        pop eax;
        mov eax, [eax-12];
        mov [thunk], eax;
    }
    HMODULE hmod = GetModuleHandle("yuppi.dll");
    uu("0x%.8x addr 0x%.8x thunk 0x%.8x\n", hmod, addr, thunk);
}

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

Здравствуйте, Masterkent, Вы писали:
M>Раз уж завели такой топик, покажу один из подарочков, уготованных нам комитетом по стандартизации C++:
M>http://ideone.com/CoyN7
M>Howard Hinnant из Library Working Group, с которым я недавно беседовал, не видит ничего плохого в том, что у std::pair и std::tuple при инстанцировании их ссылочными типами copy/move конструкторы делают совсем не то же самое, что copy/move операторы присваивания, и вот такое необычное поведение программы его, похоже, полностью устраивает.

Логично. Инициализация ссылки и присваивание ссылке — совершенно разные вещи. Если вам такое поведение кажется необычным — не используйте кортежи ссылок.

Здравствуйте, Старостин Василий Викторович, Вы писали:

СВВ>Несколько веселых и интересных примеров на языке C++.

Ну про оператор "стрелочка", он же "копьё" тема уже была раскрыта

Автор: Arsenicum
Дата: 29.01.10

более подробно.

Здравствуйте, Старостин Василий Викторович, Вы писали:

СВВ>Статья:
СВВ>Занимательный C++

Автор(ы): Старостин Василий Викторович
Дата: 19.03.2011
Несколько веселых и интересных примеров на языке C++.

СВВ>Авторы:
СВВ> Старостин Василий Викторович

СВВ>Аннотация:
СВВ>Несколько веселых и интересных примеров на языке C++.

А как же 20 ключевых слов подряд

Автор: creatio
Дата: 05.07.05

?

Здравствуйте, watchyourinfo, Вы писали:

W>Более того, в этом выражении неопределенное поведение, а значит программа имеет право выполнить что угодно, хоть отформатировать диск.

Именно поэтому там написано "где-то от 10 до 14"

jazzer:

M>>Howard Hinnant из Library Working Group, с которым я недавно беседовал,
J>А лог беседы доступен?

Нет.

gegMOPO4:

M>>Раз уж завели такой топик, покажу один из подарочков, уготованных нам комитетом по стандартизации C++:
M>>http://ideone.com/CoyN7
M>>Howard Hinnant из Library Working Group, с которым я недавно беседовал, не видит ничего плохого в том, что у std::pair и std::tuple при инстанцировании их ссылочными типами copy/move конструкторы делают совсем не то же самое, что copy/move операторы присваивания, и вот такое необычное поведение программы его, похоже, полностью устраивает.

MOP>Логично. Инициализация ссылки и присваивание ссылке — совершенно разные вещи.

Объект и ссылка — совершенно разные вещи. pair<T1, T2> и tuple<Types...> — обычные объектные типы, и их экземплярам следует вести себя соответственно.

MOP>Если вам такое поведение кажется необычным — не используйте кортежи ссылок.

Оно-то, конечно, понятно, что если библиотека спроектирована через ж., её можно не использовать — собственно, поэтому разрешение core issues в текущей спецификации C++0x для меня представляет гораздо больший интерес, чем разрешение большинства library issues. Вопрос в том, зачем проектировать библиотеку через ж., когда есть возможность сделать всё по-людски. Если некая операция не является присваиванием в обычном понимании, то следует хорошенько подумать над тем, стоит ли её реализовывать в виде функции operator=. При надлежащей реализации tuple и vector в случае моего примера можно добиться ожидаемого поведения программы во время выполнения или хотя бы диагностики нарушения предусловий во время компиляции.

Здравствуйте, Masterkent, Вы писали:
M>gegMOPO4:
MOP>>Логично. Инициализация ссылки и присваивание ссылке — совершенно разные вещи.
M>Объект и ссылка — совершенно разные вещи. pair<T1, T2> и tuple<Types...> — обычные объектные типы, и их экземплярам следует вести себя соответственно.

Значит не «обычные», если содержат ссылки.

MOP>>Если вам такое поведение кажется необычным — не используйте кортежи ссылок.
M>Оно-то, конечно, понятно, что если библиотека спроектирована через ж., её можно не использовать — собственно, поэтому разрешение core issues в текущей спецификации C++0x для меня представляет гораздо больший интерес, чем разрешение большинства library issues. Вопрос в том, зачем проектировать библиотеку через ж., когда есть возможность сделать всё по-людски. Если некая операция не является присваиванием в обычном понимании, то следует хорошенько подумать над тем, стоит ли её реализовывать в виде функции operator=.

Конструирование кортежа — это вызов соответствующих конструкторов элементов. Для ссылки это — связывание с другим объектом (на всю жизнь). Логично? Логично.

Присваивание кортежу — это присваивание элементам. Для ссылки присваивание приводит к изменению значения связанного объекта. В этом смысл ссылок, если вам это не нужно, используйте указатели.

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

Мне всё понятно, всё выглядит последовательным и логичным. Если это не то, что вам нужно, используйте указатели, вместо ссылок.

M> При надлежащей реализации tuple и vector в случае моего примера можно добиться ожидаемого поведения программы во время выполнения или хотя бы диагностики нарушения предусловий во время компиляции.

Как? Как вы это реализуете, а главное, как обоснуете?

Здравствуйте, gegMOPO4, Вы писали:

MOP>Здравствуйте, Masterkent, Вы писали:
M>>gegMOPO4:
MOP>>>Логично. Инициализация ссылки и присваивание ссылке — совершенно разные вещи.
M>>Объект и ссылка — совершенно разные вещи. pair<T1, T2> и tuple<Types...> — обычные объектные типы, и их экземплярам следует вести себя соответственно.
MOP>Значит не «обычные», если содержат ссылки.
Причём здесь это? Речь идёт про невозможность использования связки vector+tuple<&> из-за различного поведения vector'а в зависимости от алгоритма размещения по памяти. Произошло перевыделение — вызываем конструкторы, не произошло — операторы??? А кто сказал что они одинаково работают вообще? vector? Ну так его и проблемы.

Здравствуйте, Старостин Василий Викторович, Вы писали:

СВВ>Статья:
СВВ>Занимательный C++

Автор(ы): Старостин Василий Викторович
Дата: 19.03.2011
Несколько веселых и интересных примеров на языке C++.

СВВ>Авторы:
СВВ> Старостин Василий Викторович

СВВ>Аннотация:
СВВ>Несколько веселых и интересных примеров на языке C++.

Еще можно так:

int i = 0;
A a(i);

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

T i = T(); // для T=int будет int i=0;
A a(i);

А теперь можно попробовать подсократить:

A a(T());

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Vain, Вы писали:
V>Речь идёт про невозможность использования связки vector+tuple<&> из-за различного поведения vector'а в зависимости от алгоритма размещения по памяти. Произошло перевыделение — вызываем конструкторы, не произошло — операторы??? А кто сказал что они одинаково работают вообще? vector? Ну так его и проблемы.

Нет, это проблемы типа элементов вектора. Вы ведь не будете предъявлять претензии к вектору за то, что в нём нельзя хранить auto_ptr?

Если мы создаём объект на месте, где ничего не было — вызывается конструктор. Если на месте другого объекта — оператор присваивания. В этом их разница.

Здравствуйте, jazzer, Вы писали:


J>А теперь можно попробовать подсократить:
J>

J>A a(T());
J>

J>

А что насчет ?

struct a { a(int) {} };

int main()
{
 a(i)(1);
 a(j)(i);
 a(k(a()));
}