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

потому что const-correctness в C++ это бессмысленное говно, которое не работает

const int *

потому что это - указатель на константные данные. а это:

int *data

просто указатель. поскольку ссылка на константу - константный, однако изменять данные, на которые он указывает, никто не запрещает

потому что const-correctness в C++ это бессмысленное говно, которое не работает

ну, в общем-то +1

Черт, мне одному кажется смешным название темы?

[C++] член-указатель

мне одному кажется смешным название темы?

noone cares

что-то я ни хрена не понял почему foo1 компилируется. getData же возвращает const int*. Может у тебя там несколько разных getData?

что-то я ни хрена не понял почему foo1 компилируется

Почему foo1() не компилируется

Потому что у экземпляра const Q & переменная data имеет тип не const int *, а int * const. Другими словами изменить значение data, чтобы оно указывало на другую область памяти нельзя - запрещено квалификатором хоть как-то менять переменные класса. А вот поменять данные по указателю - никто не запрещает, потому как данные по указателю не являются членами класса Q. Это одна из причин, по которой константные квалификаторы и ацессоры к данным - наш друг, а публичные переменные - враг.

Почему мне C++ выносит мозг? Когда я программирую на нём,
время от времени начинают трястись руки, поднимается температура,
я ничего не понимаю, как будто попал в пространство со слишком большим
количеством измерений. Дискасс.

>запрещено квалификатором хоть как-то менять переменные класса
Да ну!

google://const_cast

разумное применение const_cast-а никто не отменял :)

если бы программисты разумно применяли свои мозги они бы не писали на c++
ну или менеджеры их

Знаешь, есть такие «законы Мерфи»?

мир несовершенен, что поделать

> Почему мне C++ выносит мозг? Когда я программирую на нём,
время от времени начинают трястись руки, поднимается температура

переходи на лисп

> google://const_cast

Причём здесь это. C/C++ - языки с прямым управлением памятью, при желании можно хоть весь стек прикастировать к указателю и рулить куском памяти. Но ведь речь совершенно про другое. К константным квалификаторам и разграничителям доступа private/protected это никак не относится, они - методы защиты от ошибок в коде при попытке доступа/изменения данных, к которым логически доступа быть не должно.

Стоит ли напоминать про первое правило программирования - что программы пишутся не для машины, а для человека. Добавление в начало функции const к переменной гарантирует, что нигде до конца функции случайно изменить её не выйдет. Код стаёт на порядок читабельней, не то что вермишель в C, с тележкой мутабельных переменных в начале функции и непонятной кашей внутри что когда инициализируется и изменяется. Более того, в книге Александреску и Саттера рекомендуется чуть-ли не все переменные в стеке делать константными, не обьявлять их аш до момента, когда они используются в функции и не ложить выше необходимой области видимости.

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

что вполне разумно

>разграничителям доступа private/protected это никак не относится,
О, кстати, да.
Еще одно бессмысленное говно, которое не работает.

Добавление в начало функции const к переменной гарантирует,

Ничего не гарантирует.

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

Это по моему рекомендуется сейчас чуть ли не во всех книгах, причём безотносительно С++.

>Еще одно бессмысленное говно, которое не работает.

Тогда расскажи нам почему? :)

> Добавление в начало функции const к переменной гарантирует, что нигде до конца функции случайно изменить её не выйдет.

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

> О, кстати, да.

Еще одно бессмысленное говно, которое не работает.

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

> Почему foo1() не компилируется, а foo() компилируется?

чую троллинг.

>C++ позволяет напрямую манипулировать памятью.

Какой памятью он позволяет манипулировать? Физической или С++-кучей? Ну дык Лисп тоже позволяет напрямую работать с кучей Лиспа.

У C++ есть проблемы, он не идеален.

Количество проблем в разработке конкретных приложений зависит от «отвратительных компромиссов» языка не линейно, а комбинаторно, то есть это некий факториал. То есть язык с N «отвратительных компромиссов» может быть вполне приемлемым, а с N + 1 - неприемлемым, т.к начиная с определенного рубежа N! и (N+1)! становятся числами принципиально разного порядка. Жаба вплотную приближается к этому N из-за своей невыразительности, С++ превосходит N процентов на десять.

Жаба не подходит по возможностям. Твоя альтернатива С++?

>Жаба не подходит по возможностям.

По каким возможностям Жаба не подходит?

Твоя альтернатива С++?

Ну на практике только один язык является совсем беспомощным и ни на что негодным - С++. Так что замен куча - чистый Си например.

чую троллинг.

слишком тонко чтобы быть правдой

>Так что замен куча - чистый Си например.

Что такое умеет чистый си, чего не умеет си++?

> Что такое умеет чистый си, чего не умеет си++?

Не путать код, не комлироваться часами?

>>Так что замен куча - чистый Си например.

Что такое умеет чистый си, чего не умеет си++?

На практике от интерфейсов на Си кариеса меньше на порядок.

Что такое умеет чистый си, чего не умеет си++?

к C у всех есть FFI. к C++ - только если повезёт

> к C у всех есть FFI. к C++ - только если повезёт

Дык проблему только темплейты, по идее, представляют, разве нет? В худшем случае придётся сначала сделать чисто сишную обёртку. С темплейтами в общем случае опа, да.

Дык проблему только темплейты

не только

> Какой памятью он позволяет манипулировать? Физической или С++-кучей?

Манипулировать физическими адресами памяти можно только средствами ядра и C++ тут немного сбоку. Я имел ввиду память, доступную процессу, будь то стек или куча. Установив указатель на начало области памяти, в которой расположена структура объекта, можно как угодно изменять его данные. Private они или protected, или может быть даже const - в этом случае значения не имеет. То, что за такое надо убивать с особым цинизмом - второй вопрос. Речь шла именно о том, что C++ не гарантирует защищенности данных объектов, так же как и их константности. Я и говорю, что если захотеть, можно и голову об стену разбить, но это не значит, что это правильно.

Жаба вплотную приближается к этому N из-за своей невыразительности, С++ превосходит N процентов на десять.

Ну и замечательно, никто вроде и не спорит, что плюсы маловыразительные. Только вот в настоящий момент реальных альтернатив пока нет. Может быть допилят D до вменяемого состояния, но пока что это далеко не факт. C#, Java и прочие management языки занимают свою нишу и полностью заменить плюсы не могут.

>Только вот в настоящий момент реальных альтернатив пока нет. Может быть допилят D до вменяемого состояния, но пока что это далеко не факт.

А Вам не приходило в голову, что C++ совершенно необязательно заменять _одним_ языком. Тем более во всех нишах. Зачем?

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

Это как раз теория, а практика показывает что на нём пишут большинтво приложений.

На чистом Си писать чтолибо кроме ядра?, либо чегото небольшого могут только эти.. как их.. «безумству храбрых поём мы песни» :))

>На практике от интерфейсов на Си кариеса меньше на порядок.

Интерфейсы на Си это что?

> А Вам не приходило в голову, что C++ совершенно необязательно заменять _одним_ языком. Тем более во всех нишах. Зачем?

Так я и не говорил вроде бы, что надо заменять одним языком. Но если мы говорим о замене C++, то нужен некий сферический язык в вакууме, применимость которого оправдана _примерно_ там же, где оправдана применимость C++, это вроде логично. Хотя конечно можно и несколько языков, покрывающих эту область.

>если мы говорим о замене C++, то нужен некий сферический язык в вакууме, применимость которого оправдана _примерно_ там же, где оправдана применимость C++

повторяю: зачем один язык?

это вроде логично.

нет

>Установив указатель на начало области памяти, в которой расположена структура объекта, можно как угодно изменять его данные.

Что это дает вообще? Я знаю одно применение - как с помощью адресной арифметики сделать массивчег. Но в жабе той же динамические массивы и без адресной арифметики делают.

Ну и замечательно, никто вроде и не спорит, что плюсы маловыразительные.

Ну какбе ООП должна облегчать построение надежных стабильных интерфейсов, а не усложнять наоборот. Практика однако что-то показывает что на С++ надо писать все сразу «набело», т.к потом хрен что переделаешь.

>повторяю: зачем один язык?

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

Хватит уже с вашей практикой, которая комуто показывает:))

Что это дает вообще? Я знаю одно применение - как с помощью адресной арифметики сделать массивчег. Но в жабе той же динамические массивы и без адресной арифметики делают.

Это даёт возможности ассемблера(точней Си). И это одно из главных, почему Ява не катит как замена С++.

>Практика однако что-то показывает что на С++ надо писать все сразу «набело», т.к потом хрен что переделаешь.

Мне искренне жаль, что у вас такая неудачная практика. Хотя нет, не искренне.

>Если один язык приемлимо справляется с задачей, то нелогично заменять его несколькими.

дык не справляется же.

Что это дает вообще?

Ничего хорошего это не дает. За такое надо отрывать руки по самые колени. Вот пример (не повторяйте этого дома, это опасно для психики):

#include <iostream>

class A {
public:
	A() : _value(0) { }
	int getValue() const { return _value; }

private:
	int _value;
};



int main()
{
	A object;
	std::cout << object.getValue() << std::endl;
	int *ptr = reinterpret_cast<int *>(&object);
	*ptr = 1;
	std::cout << object.getValue() << std::endl;

	return 0;
}

В результате выполнения получим

0
1

т.е. изменение закрытого члена.

>Это только всё усложнит, какие бы это другие языки небыли супер-пупер.

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

т.е. изменение закрытого члена.

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

>Это даёт возможности ассемблера(точней Си). И это одно из главных, почему Ява не катит как замена С++.

Что может помешать сделать хардверное API хоть в пистоне?

>т.е. изменение закрытого члена.

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

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