[C++] член-указатель и const ссылка на объект

> не комлироваться часами?

руки вправлять надо, у меня ребилд для приблизительно 2000 файлов идет 3-4 минуты( Q9400 3.6Ghz, билд собирается в RAM, ес-но используются pch ), и ес-но полный ребилд не нужен - т.к. не имею привычки одни хедеры без нужды завязывать на другие, так что обычно после изменений билд идет буквально несколько секунд

> Может и не сработать (вывести «0 0»). man aliasing

Естественно может не сработать. А если класс имеет виртуальные функции, в некоторых реализациях вначале структуры может вообще оказаться указатель на таблицу виртуальных функций. Это был просто пример.

> можно ещё перед include сделать define private public ;)

это будет не доступ к private данным, а прищемление себе яиц дверью ;)

это будет не доступ к private данным, а прищемление себе яиц дверью ;)

ничем не хуже предыдущего метода. даже, пожалуй, помягче

> ничем не хуже предыдущего метода

в том методе таки идет реальное обращение к private-данным

> руки вправлять надо, у меня ребилд для приблизительно 2000 файлов идет 3-4 минуты( Q9400 3.6Ghz, билд собирается в RAM, ес-но используются pch )

Вы, наверное, буст не пользуете? Один .hh поменял — и превед, укуриться можно. 8))

> Вы, наверное, буст не пользуете?

нет, не вижу никаких объективных причин его использовать

в том методе таки идет реальное обращение к private-данным

вот ведь зануда, ну. у Саттера в «новых сложных задачах» описаны по крайней мере четыре метода доступа к приватным данным объекта

ну и антипаттерн Павлик Морозов всегда с нами

я ж не спорю что можно - но опять же это делается осознанно и по сути является хаком, а также порой спасением от кривых рук в чужих библиотеках( привет wxSTC )

>Есть способ изменить любой закрытый член и без адресной арифметики.

Может всёже расскажешь как?

например добавив в «friend» свой производный класс( что конечно вынуждает изменять исходный код, но позволяет обойти ограничение минимальной кровью )

class Calc;
typedef int (Calc::*PMember)(int);

class Calc {
   friend class CalcChild;
private:
   int Twice(int i) {return i;}
};

class CalcChild {
public:
   PMember CoughItUp() { return &Calc::Twice; }
};

int main() {
      CalcChild c;
      PMember p = c.CoughItUp(); // yields access to Twice(int)
      (((Calc*) &c)->*p)(21); // ok
}

если Absurd или любитель лиспа знают другие способы, без необходимости в изменении исходного класса - просим

>ну и антипаттерн Павлик Морозов всегда с нами

Что-то не встречал работающей реализации. Пьесу на rsdn видел, посмеялся, но скомпилировать не смог.

Не понимаю воплей тех, кто приводит примеры хаков и говорит что С++ гумно. Квалификаторы доступа помогают программисту, а не защищают от хаков. Если рожа крива, нечего на зеркало(язык) пенять.

> Не понимаю воплей тех, кто приводит примеры хаков и говорит что С++ гумно

а разве в топике такие есть? о_О

Тысячи их.

>Не понимаю воплей тех, кто приводит примеры хаков и говорит что С++ гумно.

Меня приватность и т.н const-корректность интересует в последнюю очередь. В лиспе и пистоне этого нет. Ну в жабе есть своеобразная фагготрия среди тех кто из С++ пришел - расставлять везде final и делать конструкторы с десятью параметрами чтобы иметь возможность поля класса тоже объявить как final. Я этого не понимаю.

>Меня приватность и т.н const-корректность интересует в последнюю очередь.
А чем плохо?

>А чем плохо?

Нет повода провести ночь в отладчике. Скучно ему.

>>А чем плохо?

Нет повода провести ночь в отладчике. Скучно ему.

В плане упреждающей элиминации ошибок толку у const и private - зеро. Это просто бесполезный фан ради бесполезного фана.

>В плане упреждающей элиминации ошибок толку у const и private - зеро
Какой ещё элиминации? Если я объявил в библиотек мембер в секции private, то я имею полное право делать с ним что хочу. А что касается const, то это делается в основном для декларации того, что данные не меняются, то есть для удобочитаемости. Если кто-то юзает хаки, то это его проблемы, а не мои. Никакой это не фан, нормальные фичи.

>Если я объявил в библиотек мембер в секции private, то я имею полное право делать с ним что хочу.

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

А что касается const, то это делается в основном для декларации того, что данные не меняются, то есть для удобочитаемости.

Кому вообще надо менять данные? Может всеже надо произвести расчеты над данными и вернуть результат? Но результат будет другого типа я так понимаю.

>Нифига. Вот с pimpl можно делать все что угодно

pimpl не нужен.

Кому вообще надо менять данные?

Функциональщина головного мозга.

Может всеже надо произвести расчеты над данными и вернуть результат?

Если исходные данные и результат одного типа и исходные данные не нужны (как, например, при сортировке), то зачем усложнять? меняй данные на месте. Быстро и просто.

>>Нифига. Вот с pimpl можно делать все что угодно

pimpl не нужен.

Ну не нужен так не нужен. Только pimpl позволяет приблизить ООП в С++ до уровня поддержки ООП в чистом Си. Ну ладно, допустим сам ООП не нужен.

Если исходные данные и результат одного типа и исходные данные не нужны (как, например, при сортировке), то зачем усложнять?

Если секвенция нелокальная, то дублировать всеже придется. А если локальная, то нафиг в ней нужен const?

>В плане упреждающей элиминации ошибок толку у const и private - зеро.

Да ты ЧЁ? У нас навый ветила в области ООП:))

Почитай Стива Маккнолена «Code Comlete» - «Совершенный код», он тебе голову на место поставит.

могу поспорить, что он читал - потому бесполезно

>позволяет приблизить ООП в С++ до уровня поддержки ООП в чистом Си

да простят меня модераторы - убейся! хватит уже чушь несусветную нести. в чистом Си(пример гтк) - ооп это ужас которым надо пугать детей.

>хватит уже чушь несусветную нести. в чистом Си(пример гтк) - ооп это ужас которым надо пугать детей.

Я наверное слишком категоричен:))) но пугать им можно:)

>могу поспорить, что он читал - потому бесполезно

если читал, значит надо перечитать )) для лучшего усвоения:)

Потому что программы пишутся не для машины, а для человека. Программист должен повторять эту мантру до полного просветления. Людей, которые до сих пор сомневаются в этом правиле, у нас как правило увольняют.

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

const_cast в C++ - это хак, исключение, здесь язык сам принуждает разработчика писать его явно, чтобы чётко знать, что он делает. Все const_cast как правило подробно комментируются и никак не влияют на работу других модулей, не нарушают потокобезопастность. Любой С-cast в C++ расценивается как ошибка.

А ваше невежество по отношению к константным квалификаторам всего лишь показывает ваш скромный кругозор в программировании.

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

Даст, даст.

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

Ага, особенно, если этот const_cast вообще в другой функции, которая из этой вызывается. И писал её другой человек, который чётко знал, что делает ОН, но понятия не имел, что будешь делать ты.

А ваше невежество по отношению к константным квалификаторам всего лишь показывает ваш скромный кругозор в программировании.

Вообще говоря, это именно ВАШЕ невежество. Модификатор const действительно не защищает ни от чего; единственная польза - проверять собственный код, который пишешь вот сейчас вот.

> И писал её другой человек, который чётко знал, что делает ОН, но понятия не имел, что будешь делать ты.

«другой человек» без мозгов и без понятия, что ключевое слово const пишут не просто так, может сделать все что угодно - вплоть до прищемления яиц, язык тут бессилен

Модификатор const действительно не защищает ни от чего

он как минимум служит как средство документации, а также как предупреждение - «автор кода рассчитывал, что это меняться не должно», что означает, что стоит пойти почитать комментарии + код, перед тем как шаловливыми руками забить на это предупреждение, если человеку просто наплевать на такое - то ему надо просто запрещать лезть в чужой код, т.к. помимо «const» он может накосячить где угодно

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

Я как топиккастер вам скажу...

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

Те не менее, до этого программа работала и выдавала правильный (или адекватный) результат, который всех устраивал. Улучшится ли наша программа от вправления const-ов я не знаю, но надеюсь на лучшее.

Вот так вот...

P.S. А вообще-то я изначально хотел понять, почему мои данные меняются в одном из алгоритмов. Теперь я это понял...

Я вам тоже скажу, что вопрос который вы задали является базовым. Вам лучше для начала почитать например Страуструпа, прежде чем писать на С++ большие проекты. Хотя думаю, что в стиле Си это вам под силу.

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

Я с трудом такое представляю. Иногда помогает mutable.

>И функцию, в которой все до одного переменные инициализированы как const распарсить взглядом на порядок проще.

Я вообще-то думал что переменные это счетчики циклов или какие-то флаги состояний обычно. Сделать const-счетчик цикла у меня что-то не получается. Зачем нужно const-состояние тоже не совсем понятно. Если какую-то структуру объявить как const, то лишишься возможности инициализировать ее поля иначе чем через параметры конструктора, что при отсутствии key-параметров в С++ снизит, а не повысит читаемость.

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

Она может измениться при вызове любого метода из другой единицы компиляции (т.н pointer aliasing).

А ваше невежество по отношению к константным квалификаторам всего лишь показывает ваш скромный кругозор в программировании.

Наоборот, это следствие широкого кругозора. Сonst фагготория - это локальный сиплюсплюсный культ. Есть конечно языки где вообще все const (Хаскель тот же), но почему-то там обычно писать надо в несколько раз меньше для тех же задач.

>>позволяет приблизить ООП в С++ до уровня поддержки ООП в чистом Си

да простят меня модераторы - убейся! хватит уже чушь несусветную нести. в чистом Си(пример гтк) - ооп это ужас которым надо пугать детей.

Зачем по-твоему нужен ООП?

>Зачем по-твоему нужен ООП?

Если в двух словах, то для абстракции и разделения данных.

>>Зачем по-твоему нужен ООП?

Если в двух словах, то для абстракции и разделения данных.

А зачем нужна абстракция, что такое «разделение данных» и зачем оно нужно?

>Я вообще-то думал что переменные это счетчики циклов

Которые не нужны чуть менее, чем всегда. Итераторы (в т.ч. указатели) быстрее, безопаснее и проще.

>Если какую-то структуру объявить как const, то лишишься возможности инициализировать ее поля иначе чем через параметры конструктора

...что означает лишиться ряда способов инициализировать структуру неправильно. А инкапсуляцией настоящие джедаи пренебрегают, я уже понял. Зачем? Они всегда знают как работает класс лучше, чем его автор.

>что при отсутствии key-параметров

Сахарку не доложииииилиии!

>Она может измениться при вызове любого метода из другой единицы компиляции (т.н pointer aliasing).

void changeme(int * var)
{
    ++(*var);
}
int main()
{
    const int var = 265;
    changeme(const_cast<int*>(&var)); //строчка написалась совершенно случайно, почти опечатка.
}

>Сonst фагготория - это локальный сиплюсплюсный культ

В одних языках const толком нет вообще, в других только константы и есть. А фагготория - в си++. Чудо-логика.

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

Ога. Обычно приходится писать «язык не предназначен для таких задач». Довольно коротко, действительно.

вот кстати на заметку ТС неплохое FAQ:

http://www.parashift.com/c++-faq-lite/const-correctness.html

и вот это
http://yosefk.com/c++fqa/const.html

спасибо за ссылку, комментатор местами несет полную чушь( т.к. видно задался целью придраться к каждому пункту - не важно есть в этом смысл или нет ), но здоровая критика также есть

>>Я вообще-то думал что переменные это счетчики циклов

Которые не нужны чуть менее, чем всегда. Итераторы (в т.ч. указатели) быстрее, безопаснее и проще.

Ну итераторы вообще-то тоже изменяются, то есть являют собой переменные. Или нет?

Если какую-то структуру объявить как const, то лишишься возможности инициализировать ее поля иначе чем через параметры конструктора

...что означает лишиться ряда способов инициализировать структуру неправильно.

К сожалению, из-за перегрузки конструкторов может случайно вызваться не тот конструктор. Или лишний параметр может быть неявно связан с самым левым опциональным параметром (для которого указано дефолтное значение). Это наверное сознательное отстреливание себе яиц, да?

что при отсутствии key-параметров

Сахарку не доложииииилиии!

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

Сonst фагготория - это локальный сиплюсплюсный культ

В одних языках const толком нет вообще, в других только константы и есть. А фагготория - в си++. Чудо-логика.

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

Сранный вы человек. То константные объекты вам не нравятся, то конструкторы. Язык по-вашему должен связывать по рукам и ногам?

Если какую-то структуру объявить как const, то лишишься возможности инициализировать ее поля иначе чем через параметры конструктора

Вам под страхом смерти запрещают что-то делать? Константную ссылку на объект нам тоже плохо передавать?

> Сранный вы человек

это пять :)

>Сранный вы человек. То константные объекты вам не нравятся, то конструкторы.

Ну это смежные темы вообще-то. Константный объект имеет то состояние которое было задано конструктором при его создании.

>Ну это смежные темы вообще-то. Константный объект имеет то состояние которое было задано конструктором при его создании.
Вас же никто не заставляет объявлять объект константным. Или вам не нравиться, что константный объект инициализируется только в конструкторе?

>>Ну это смежные темы вообще-то. Константный объект имеет то состояние которое было задано конструктором при его создании.

Вас же никто не заставляет объявлять объект константным.

В изначальном постинге вообще-то была произведена попытка классификации того какие переменные вообще бывают, и, отталкиваясь от этой классификации, был сделан вывод о приемлемости квалификатора const для самых мейнстримных случаев. Не первый взгляд const выглядит вменяемо для алиаса к результату промежуточных вычислений или для получения R/O среза состояния какого-нибудь объекта для безопасной передачи клиенту. К сожалению, первое - это паранойя по отношению к самому себе, а второе - запутанная игра в попытке избежать создания копии данных.

>К сожалению, первое - это паранойя по отношению к самому себе, а второе - запутанная игра в попытке избежать создания копии данных.
При чём здесь копия данных? Оптимизация возможна, но это побочный эффект. Я воспринимаю const именно как средсво документирования и дополнительного контроля со стороны компилятора. А оптимизация это дополнительный бонус, который никогда не помешает.