LINUX.ORG.RU

const int *

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

int *data

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

jtootf ★★★★★ ()
Ответ на: комментарий от Love5an

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

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

jtootf ★★★★★ ()
Ответ на: комментарий от anonymous

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

noone cares

jtootf ★★★★★ ()

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

dilmah ★★★★★ ()
Ответ на: комментарий от dilmah

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

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

jtootf ★★★★★ ()

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

Dendy ★★★★★ ()

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

Sphinx ★★☆☆ ()
Ответ на: комментарий от vvviperrr

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

Love5an ()
Ответ на: комментарий от Sphinx

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

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

lester ★★★★ ()
Ответ на: комментарий от Love5an

> google://const_cast

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

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

Dendy ★★★★★ ()
Ответ на: комментарий от Dendy

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

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

jtootf ★★★★★ ()
Ответ на: комментарий от Dendy

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

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

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

Love5an ()
Ответ на: комментарий от Dendy

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Love5an

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Dendy

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Love5an

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

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


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

m0rph ★★★★★ ()
Ответ на: комментарий от m0rph

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

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

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

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

Absurd ★★★ ()
Ответ на: комментарий от golodranez

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

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

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

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

Absurd ★★★ ()
Ответ на: комментарий от name_no

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

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

jtootf ★★★★★ ()
Ответ на: комментарий от legolegs

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

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

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

Absurd ★★★ ()
Ответ на: комментарий от jtootf

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

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

kemm ()
Ответ на: комментарий от Absurd

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

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

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


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

m0rph ★★★★★ ()
Ответ на: комментарий от m0rph

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

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

Sectoid ★★★★★ ()
Ответ на: комментарий от Absurd

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

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Absurd

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Sectoid

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

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

m0rph ★★★★★ ()
Ответ на: комментарий от m0rph

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

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

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

нет

Sectoid ★★★★★ ()
Ответ на: комментарий от m0rph

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

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

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

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

Absurd ★★★ ()
Ответ на: комментарий от Sectoid

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Absurd

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

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

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

golodranez ★★★★ ()
Ответ на: комментарий от Absurd

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

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

staseg ★★★★★ ()
Ответ на: комментарий от golodranez

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

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

Sectoid ★★★★★ ()
Ответ на: комментарий от Absurd

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

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

#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

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

m0rph ★★★★★ ()
Ответ на: комментарий от golodranez

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

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

Sectoid ★★★★★ ()
Ответ на: комментарий от golodranez

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

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

Absurd ★★★ ()
Ответ на: комментарий от m0rph

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

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

Absurd ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.