Я бы разделял области использования префиксов. Считаю, что в первую очередь публичный интерфейс класса должен быть чистым, и в нём не приветствую префиксы, даже если они помогают разработчикам в IDE и т.п. Интерфейс — для пользователей класса, и удобство его разработчиков здесь второстепенно. В реализации класса (protected, private секции) уже можно использовать наименования удобные для разработчиков. Я для приватных членов использую префикс m_, по причинам, которые выше уже отметили (отделить члены класса от локальных переменных, автодополнение в IDE и прочее). Думаю, что стоило отметить этот момент в начальном сообщении, чтобы оно не выглядело так категорично.

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

Ш>

Ш>  void shift(int x,int y)
Ш>   {
    this->>x += x ;
    this->>y += y ;
Ш>   }

Ш>  ....
Ш> };
Ш>

Это просто питосятина какая-то!

    def shift( self, x, y ) :
        self.x += x
        self.y += y

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

Ш>А это вообще-то хорошо. Напоминает, что тут вообще-то есть эта косвенность. Программистам на С++ иногда полезно вспоминать голый С.

Вовсе и не обязательно там есть эта косвенность.
Например, под виндой обычные автоматические переменные лежат по фиксированным смещения относительно ebp, а поля объект, по фиксированным смещениям относительно ebx.
И в чём принципиальная разница косвенности по ebp и по ebx?

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

E>Здравствуйте, Шахтер, Вы писали:

Ш>>А это вообще-то хорошо. Напоминает, что тут вообще-то есть эта косвенность. Программистам на С++ иногда полезно вспоминать голый С.

E>Вовсе и не обязательно там есть эта косвенность.
E>Например, под виндой обычные автоматические переменные лежат по фиксированным смещения относительно ebp, а поля объект, по фиксированным смещениям относительно ebx.
E>И в чём принципиальная разница косвенности по ebp и по ebx?

Память в стеке лучше локализована и лучше кэшируется. Т.е. локальные переменные -- самые быстрые, а члены -- вторые по скорости доступа.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

VT>Я бы разделял области использования префиксов. Считаю, что в первую очередь публичный интерфейс класса должен быть чистым, и в нём не приветствую префиксы, даже если они помогают разработчикам в IDE и т.п. Интерфейс — для пользователей класса, и удобство его разработчиков здесь второстепенно. В реализации класса (protected, private секции) уже можно использовать наименования удобные для разработчиков. Я для приватных членов использую префикс m_, по причинам, которые выше уже отметили (отделить члены класса от локальных переменных, автодополнение в IDE и прочее). Думаю, что стоило отметить этот момент в начальном сообщении, чтобы оно не выглядело так категорично.

С таким подходом, я пожалуй, соглашусь.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

E>Здравствуйте, Шахтер, Вы писали:

Ш>>

Ш>>  void shift(int x,int y)
Ш>>   {
    this->>>x += x ;
    this->>>y += y ;
Ш>>   }

Ш>>  ....
Ш>> };
Ш>>

E>Это просто питосятина какая-то!
E>

E>    def shift( self, x, y ) :
E>        self.x += x
E>        self.y += y
E>

Ну так оно сейчас популярно.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

R>которые лезут говнокодить в С++
Если общаться корректнее, то обсуждение будет конструктивнее...

R>и обильное использование этого приема в С++ надо бить по рукам и пихать ногами под зад и профессии
Такое обращение к полям и методам класса может оказаться полезным в шаблонных классах, из-за двухстадийтного разрешения имён в С++ шаблонах.

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


Ш>Память в стеке лучше локализована и лучше кэшируется. Т.е. локальные переменные -- самые быстрые, а члены -- вторые по скорости доступа.
Интересно, а у тебя какие характерные sizeof объектов? И какие размеры строк кэша на типичной архитектуре
Если объект не какой-то бесконечный слон на сорок килобайт sizеof'а, а какой-то условный итератор, теребимый в цикле, он закэшируется ничем не хуже стека, а возможно, и лежать будет на стеке же.
А если это объект из какой-то развесистой структуры данных, то через this-> ты будешь к ним обращаться или ещё через что, принципиальной роли играть не будет.
Хотя обращаться через адрес, хранимый в стеке всё рано медленнее, чем через закэшированный в регистре this...

я же уточнил — за обильное
это когда открываешь обычный класс, а там все методы с this
и хочется сразу прибить этого кодера

а вообще очень интересный коде стайл от делфистов в с++
где префиксы большие буквы

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

E>Здравствуйте, Шахтер, Вы писали:


Ш>>Память в стеке лучше локализована и лучше кэшируется. Т.е. локальные переменные -- самые быстрые, а члены -- вторые по скорости доступа.
E>Интересно, а у тебя какие характерные sizeof объектов? И какие размеры строк кэша на типичной архитектуре
E>Если объект не какой-то бесконечный слон на сорок килобайт sizеof'а, а какой-то условный итератор, теребимый в цикле, он закэшируется ничем не хуже стека, а возможно, и лежать будет на стеке же.
E>А если это объект из какой-то развесистой структуры данных, то через this-> ты будешь к ним обращаться или ещё через что, принципиальной роли играть не будет.
E>Хотя обращаться через адрес, хранимый в стеке всё рано медленнее, чем через закэшированный в регистре this...

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

Ш>Стек растёт и сокращается в ходе выполнения программы. При этом память переиспользуется.
Ну и что? Если какой-то популярный объект не в стеке, он тоже будет кэшироваться. А если мы всё равно перезаписываем, то почти всё равно по какому адресу, если только это в самый большой кэш попадает и по тому же адресу другая голова не лезет...

Ш>Проще говоря, у нас локальные переменные лучше локализованы по памяти, меньшее число кэш-линий и чаще обращение к ним.
Как локализованы переменные по памяти -- вопрос к используемому аллокатору. И сами объекты могут быть автоматическими, но код их методов при этом может через this работать.
В конце концов в самый быстрый кэш ты можешь загрузить какой-то конкретный объём данных. Как он при этом делится между объектами на стеке и не на стеке не особо важно. Если объекты переживают обсуждаемую операцию, то вообще не важно, и это надо где-то снаружи решать что где аллокировать, а если не переживают, то хранилище любого класса памяти можно переиспользовать...

Ш>Плюс, регистр под this обычно чаще перезагружется, чем регистр фрейма стека текущей функции.
А это вообще ни на что не влияет, кроме того, это, скорее всего, ещё и не правда: зачем перегружать регистр с this, если мы не делаем вызов метода? Можно же тогда и всю адрессацию по месту относительно стека пересчитать?