2015-01-07 4 views
0

Каковы некоторые законные и/или интересные применения для выполнения указателя-арифметики на «этом» указателе на C++, если таковые имеются?Арифметика указателя на указателе «this»

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

class Foo 
{ 
public: 
    Foo(bool terminate = false) 
     : _data(terminate ? -1 : 0) 
    {} 

    void Bar(void) 
    { 
     if (_data >= 0) 
     { 
      _data++; 
      this[1].Bar(); 
     } 
    } 

private: 
    int _data; 
}; 

void main() 
{ 
    std::vector<Foo> vec; 
    vec.push_back(Foo()); 
    vec.push_back(Foo()); 
    vec.push_back(Foo()); 
    vec.push_back(Foo()); 
    vec.push_back(Foo(true)); 

    vec[2].Bar(); 
} 
+6

Существует никаких законных оснований для этого, потому что объект не должен знать, что он является членом смежного массива (который это предполагает). И ваш код бесконечно рекурсивный. –

+5

Я не думаю, что длина будет источником неудовольствия в этом вопросе. –

+1

Переполнение стека не «спрашивает программиста что-нибудь». Это не нам, здесь есть правила. – Yakk

ответ

4

Короткий ответ: не следует.

Конечно, вы делаете все виды черной магии с этим, например. доступ к предыдущим или следующим элементам массива, как вы показали, доступ к частному члену базового класса через смещение указателя или получение «уникального» идентификатора объекта из его ячейки памяти, если он никогда не перемещается. Но все это, скорее всего, будет иметь неприятные последствия в какое-то время, и для всего, о чем я могу думать, существует более безопасное решение.

Одно законное использование, о котором я могу думать, это проверка выравнивания. Скажем, у вас есть класс float4, для которого требуется 16-байтовое выравнивание, вы можете поставить утверждение в конструкторе, которое гарантирует, что (((uintptr_t)(const void *)(this)) % 16 == 0).

0

Это законно, но, как сообщают вам комментарии, это ужасный стиль.

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

Смежные вопросы