Сложение указателей

@CEBEP · Регистрация: 21.03.2010

Author24 — интернет-сервис помощи студентам

Чисто декларативно замечу что это не безсмысленная операция, как нам о том повествуют всюду.
пример:

C++

1
2
3

    ExpressionEdit* a = split ? leftInsert : rightInsert;
    ExpressionEdit* b = split ? rightInsert : leftInsert;
    split = !split;

можно бы было реализовать без второй операции ветвления следующим образом:

C++

1
2
3

    ExpressionEdit* a = split ? leftInsert : rightInsert;
    ExpressionEdit* b = rightInsert + leftInsert - a;
    split = !split;

@alex_x_x · 01.05.2012, 18:05

CEBEP, стандарт с вами не согласится

A subtraction of two pointers is only granted to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array).

For other values, the behavior depends on the system characteristics and compiler implementation.

кроме того второй код вразы психоделичней

@CEBEP · 01.05.2012, 18:21 **[ТС]**

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

CEBEP, стандарт с вами не согласится

В чём конкретно он со мной не согласится? То что эти указатели не объедены массивом это весомый момент, но, думаю, степень гипотетичности всего выражения в целом позволяет закрыть на это глаза, ведь сложение указателей должно будет вернуть указатель который вовсе не обязан иметь смысл как таковой, а лишь должен быть использован как левый аргумент в операции вычитания.
Да и вообще что толку апеллировать к стандарту, если зашла речь о сущности которую он предал анафеме? Я просто хотел заметить что чисто алгебраически такая операция может иметь смысл.

@alex_x_x · 01.05.2012, 18:24

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

В чём конкретно он со мной не согласится? То что эти указатели указывают не объеденные массивом это весомый момент, но, думаю, степень гипотетичности всего выражения в целом позволяет закрыть на это глаза, ведь сложение указателей должно будет вернуть указатель который вовсе не обязан иметь смысл как таковой, а лишь должен быть использован как левый аргумент в операции вычитания.

разность указателей дает тип ptrdiff_t
то что нельзя просто так орудовать с указателями говорит стандарт и эта тема [Задача] Адресная арифметика

@DU · 01.05.2012, 18:28

может быть и можно было бы второй вариант использовать, но для чего?
для обфускации, чтобы враги дольше код понимали?

@CEBEP · 01.05.2012, 18:45 **[ТС]**

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

для чего?

по моему второй вариант должен выполнятся существенно быстрее

@DU · 01.05.2012, 18:50

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

@alex_x_x · 01.05.2012, 18:54

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

rightInsert + leftInsert - a;

по угару
если rightInsert и leftInsert у верхней границы адресов, то rightInsert + leftInsert может дать переполнение (на 32битах) и результатом будет невалидный указатель

@CEBEP · 01.05.2012, 18:55 **[ТС]**

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

копеечная оптимизация

Не понимаю попытки доказать что это бессмысленно. Строго говоря, я обратного и не утверждал

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

результатом будет невалидный указатель

да, я об этом прямо упоминал во втором своём сообщении...

@grizlik78 · 01.05.2012, 19:09

C++

ExpressionEdit* a = rightInsert;
ExpressionEdit* b = leftInsert;
if (split) {
    a = leftInsert;
    b = rightInsert;
}
split = !split;

Оставьте уже машинную оптимизацию компилятору. Это его работа.

Добавлено через 1 минуту
Или даже так (хотя мне предыдущий больше по душе)

C++

ExpressionEdit* a;
ExpressionEdit* b;
if (split) {
    a = leftInsert;
    b = rightInsert;
} else {
    a = rightInsert;
    b = leftInsert;
}
split = !split;

@DU · 01.05.2012, 19:15

вы ассемблерный код то хотябы видели?
у вас там две арифметические операции с указателями. значит будет один промежуточный результат, его нужно в регистрах хранить что-то делать с этим всем. + не забыть учесть, что в арифметике указателей еще неявно учавствует размер. т.е. возможно там еще и умножение в каждой операции будет
Вот какой ассемблер у меня получился в дебаге:

C++

/*
  int* p1 = b ? left : right;
0041332E  movzx       eax,byte ptr [b] 
00413332  test        eax,eax 
00413334  je          F1+31h (413341h) 
00413336  mov         ecx,dword ptr [left] 
00413339  mov         dword ptr [ebp-0DCh],ecx 
0041333F  jmp         F1+3Ah (41334Ah) 
00413341  mov         edx,dword ptr [right] 
00413344  mov         dword ptr [ebp-0DCh],edx 
0041334A  mov         eax,dword ptr [ebp-0DCh] 
00413350  mov         dword ptr [p1],eax 
  int* p2 = b ? right : left;
00413353  movzx       eax,byte ptr [b] 
00413357  test        eax,eax 
00413359  je          F1+56h (413366h) 
0041335B  mov         ecx,dword ptr [right] 
0041335E  mov         dword ptr [ebp-0DCh],ecx 
00413364  jmp         F1+5Fh (41336Fh) 
00413366  mov         edx,dword ptr [left] 
00413369  mov         dword ptr [ebp-0DCh],edx 
0041336F  mov         eax,dword ptr [ebp-0DCh] 
00413375  mov         dword ptr [p2],eax 
*/
void F1(bool b, int* left, int* right)
{
  int* p1 = b ? left : right;
  int* p2 = b ? right : left;
}
 
/*
  int* p1 = b ? left : right;
00412E5C  movzx       eax,byte ptr [b] 
00412E60  test        eax,eax 
00412E62  je          F2+3Fh (412E6Fh) 
00412E64  mov         ecx,dword ptr [left] 
00412E67  mov         dword ptr [ebp-0F4h],ecx 
00412E6D  jmp         F2+48h (412E78h) 
00412E6F  mov         edx,dword ptr [right] 
00412E72  mov         dword ptr [ebp-0F4h],edx 
00412E78  mov         eax,dword ptr [ebp-0F4h] 
00412E7E  mov         dword ptr [p1],eax 
  int* p2 = left + x - y;
00412E81  mov         eax,dword ptr [x] 
00412E84  mov         ecx,dword ptr [left] 
00412E87  lea         edx,[ecx+eax*4] 
00412E8A  mov         eax,dword ptr [y] 
00412E8D  shl         eax,2 
00412E90  sub         edx,eax 
00412E92  mov         dword ptr [p2],edx 
*/
void F2(bool b, int* left, int* right)
{
  int x = 10;
  int y = 20;
  int* p1 = b ? left : right;
  int* p2 = left + x - y;
}
 
 
/*
  int* p1 = right;
0041277E  mov         eax,dword ptr [right] 
00412781  mov         dword ptr [p1],eax 
  int* p2 = left;
00412784  mov         eax,dword ptr [left] 
00412787  mov         dword ptr [p2],eax 
  if (b)
0041278A  movzx       eax,byte ptr [b] 
0041278E  test        eax,eax 
00412790  je          F3+3Eh (41279Eh) 
  {
    p1 = right;
00412792  mov         eax,dword ptr [right] 
00412795  mov         dword ptr [p1],eax 
    p2 = left;
00412798  mov         eax,dword ptr [left] 
0041279B  mov         dword ptr [p2],eax 
  }
*/
void F3(bool b, int* left, int* right)
{
  int* p1 = right;
  int* p2 = left;
  if (b)
  {
    p1 = right;
    p2 = left;
  }
}

Если вы специалист - считайте такты. Кстати, ваш код даже не компилируется в студии.

@grizlik78 · 01.05.2012, 19:26

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

Кстати, ваш код даже не компилируется в студии.

Ну он и не говорил, что компилируется. Это были размышления на тему "Ах если бы, ах если бы... Не жизнь была, а песня бы..."

Добавлено через 6 минут
Кстати, даже если допустить правильность и полезность подобной конструкции, то сложение указателей всё-равно не нужно.

C++

1	ExpressionEdit* b = rightInsert + (leftInsert - a);

@Toshkarik · 01.05.2012, 19:26

Ну можно тогда вообще так

C++

1	flag ? ( a = b, c = d ) : ( a = d, c = b );

@CEBEP · 01.05.2012, 19:35 **[ТС]**

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

Кстати, ваш код даже не компилируется в студии.

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

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

сложение указателей всё-равно не нужно.

ну в том варианте в котором вы предложили есть ссылка на

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

A subtraction of two pointers is only granted to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). For other values, the behavior depends on the system characteristics and compiler implementation.

@grizlik78 · 01.05.2012, 20:04

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

То что у вас есть компилятор который это проглотил меня удивило

Нет у него такого компилятора. Там просто целые складываются.

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

ну в том варианте в котором вы предложили есть ссылка на

A subtraction of two pointers is only granted to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). For other values, the behavior depends on the system characteristics and compiler implementation.

Разумеется. Но это-то, кстати, можно предусмотреть, выделяя элементы из одного массива

Но Баба-Яга всё-равно против

Добавлено через 25 минут
Ну и чтобы показать, насколько программист может усложнить "жизнь" компилятору, посмотрим, что делает GCC4.5 в режиме оптимизации -O3
Скомпилированы следующие 3 функции:

C++

bool F1(bool b, int* left, int* right)
{
  int* p1 = b ? left : right;
  int* p2 = b ? right : left;
  return p1 > p2;
}
 
bool F2(bool b, int* left, int* right)
{
  int* p1 = b ? left : right;
  int* p2 = left + (right - p1);
  return p1 > p2;
}
 
bool F3(bool b, int* left, int* right)
{
  int* p1 = right;
  int* p2 = left;
  if (b)
  {
    p1 = left;
    p2 = right;
  }
  return p1 > p2;
}

Первая породила такой код:

Assembler

    .cfi_startproc
    testb   %dil, %dil
    movq    %rsi, %rax
    cmove   %rdx, %rax
    cmovne  %rdx, %rsi
    cmpq    %rsi, %rax
    seta    %al
    ret
    .cfi_endproc

Ну, в общем, что просили, то и получили.

Из второй вышло такое:

Assembler

    .cfi_startproc
    xorl    %eax, %eax
    testb   %dil, %dil
    je  .L5
    movq    %rdx, %rax
    movq    %rsi, %rdx
    subq    %rsi, %rax
    andq    $-4, %rax
.L5:
    addq    %rax, %rsi
    cmpq    %rsi, %rdx
    seta    %al
    ret
    .cfi_endproc

Разве стало эффективнее? В прошлый раз были условные пересылки, но не было ветвления. Здесь же увы, условный переход.

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

Assembler

    .cfi_startproc
    testb   %dil, %dil
    movq    %rsi, %rax
    cmovne  %rdx, %rax
    cmove   %rdx, %rsi
    cmpq    %rax, %rsi
    seta    %al
    ret
    .cfi_endproc

Вариант Toshkarik даёт тоже точно такой код.
Выбирайте

DU, у тебя в третьей функции ошибка. По условию выполняется то же, что и без условия.

@DU · 01.05.2012, 20:15

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

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

@CEBEP · 01.05.2012, 20:15 **[ТС]**

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

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	01.05.2012, 19:35 [ТС]	14
	Сообщение от DU Кстати, ваш код даже не компилируется в студии. Второй вариант кода я и не пытался компилировать потому что был уверен что он не должен был компилироваться. То что у вас есть компилятор который это проглотил меня удивило. Сообщение от grizlik78 сложение указателей всё-равно не нужно. ну в том варианте в котором вы предложили есть ссылка на Сообщение от alex_x_x A subtraction of two pointers is only granted to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). For other values, the behavior depends on the system characteristics and compiler implementation. 0

@DU 1500 / 1146 / 165 Регистрация: 05.12.2011 Сообщений: 2,279
	01.05.2012, 20:15	16
	ну да, есть такое. оптимизатор мог бы вообще удалить проверки буля и всего того, что в ифе написано. код стал бы мегаоптимальным . Возвращаясь к предпосылкам возникновения темы: нехер писать подобного рода оптимизации, даже если они реально более оптимальны. выйгрыш копеечный. главное чтобы код оставался чистым, понимаемым, сопровождаемым. а то ведь если все писать в таком духе, где черт ногу словит, но зато "оптимально" одно случайное преобразование типа (скажем из конст чара в строку) из-за динамического выделения памяти в тыщу раз перекроет все эти потуги ради пары тактов. Впрочем, до понимания этих вещей нужно еще дорасти. Просто советы не работают. На себе проверено 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	01.05.2012, 20:15 [ТС]	17
	Всё таки зря я попытался искать в этой операции практическую суть. И тем не менее, ведь такое поведение связанно как раз с тем, что как такового сложения указателей не происходит. 0

@alex_x_x бжни 2473 / 1684 / 135 Регистрация: 14.05.2009 Сообщений: 7,162
	01.05.2012, 18:05	2
	CEBEP, стандарт с вами не согласится A subtraction of two pointers is only granted to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). For other values, the behavior depends on the system characteristics and compiler implementation. кроме того второй код вразы психоделичней 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	01.05.2012, 18:21 [ТС]	3
	Сообщение от alex_x_x CEBEP, стандарт с вами не согласится В чём конкретно он со мной не согласится? То что эти указатели не объедены массивом это весомый момент, но, думаю, степень гипотетичности всего выражения в целом позволяет закрыть на это глаза, ведь сложение указателей должно будет вернуть указатель который вовсе не обязан иметь смысл как таковой, а лишь должен быть использован как левый аргумент в операции вычитания. Да и вообще что толку апеллировать к стандарту, если зашла речь о сущности которую он предал анафеме? Я просто хотел заметить что чисто алгебраически такая операция может иметь смысл. 0

@alex_x_x бжни 2473 / 1684 / 135 Регистрация: 14.05.2009 Сообщений: 7,162
	01.05.2012, 18:24	4
	Сообщение от CEBEP В чём конкретно он со мной не согласится? То что эти указатели указывают не объеденные массивом это весомый момент, но, думаю, степень гипотетичности всего выражения в целом позволяет закрыть на это глаза, ведь сложение указателей должно будет вернуть указатель который вовсе не обязан иметь смысл как таковой, а лишь должен быть использован как левый аргумент в операции вычитания. разность указателей дает тип ptrdiff_t то что нельзя просто так орудовать с указателями говорит стандарт и эта тема [Задача] Адресная арифметика 1

@DU 1500 / 1146 / 165 Регистрация: 05.12.2011 Сообщений: 2,279
	01.05.2012, 18:28	5
	может быть и можно было бы второй вариант использовать, но для чего? для обфускации, чтобы враги дольше код понимали? 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	01.05.2012, 18:45 [ТС]	6
	Сообщение от DU для чего? по моему второй вариант должен выполнятся существенно быстрее 0

@DU 1500 / 1146 / 165 Регистрация: 05.12.2011 Сообщений: 2,279
	01.05.2012, 18:50	7
	копеечная оптимизация, да и то не факт. нужно в асм смотреть после компиляции с оптимизацией или замеры делать. в любом случае на производительность программы в целом это врятли повлияет. зато код стал такой хитромудрый, что не каждый его сможет осознать. 0

@alex_x_x бжни 2473 / 1684 / 135 Регистрация: 14.05.2009 Сообщений: 7,162
	01.05.2012, 18:54	8
	Сообщение от CEBEP rightInsert + leftInsert - a; по угару если rightInsert и leftInsert у верхней границы адресов, то rightInsert + leftInsert может дать переполнение (на 32битах) и результатом будет невалидный указатель 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	01.05.2012, 18:55 [ТС]	9
	Сообщение от DU копеечная оптимизация Не понимаю попытки доказать что это бессмысленно. Строго говоря, я обратного и не утверждал Сообщение от alex_x_x результатом будет невалидный указатель да, я об этом прямо упоминал во втором своём сообщении... 0