Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Мяут-Настоящий @ 27.01.11, 21:38

Дык как быть, если модуль реализует всего один класс? :-)

а что, это означает, что их нужно называть одинаково? кто этому обязал?

Цитата D_KEY @ 27.01.11, 21:38

--Ins--, покажи пример, в котором бы "легально"(без грязных хаков) компилятор давал изменять константные объекты?

Скрытый текст

mutable

Цитата Мяут-Настоящий @ 27.01.11, 21:43

Цитата D_KEY @ 27.01.11, 21:38

--Ins--, покажи пример, в котором бы "легально"(без грязных хаков) компилятор давал изменять константные объекты?

Скрытый текст

mutable

Я уже "намекал" на него. Но это - решение самого объекта, для специальных случаев, вроде кэширования или лени.

Цитата korvin @ 27.01.11, 21:43

а что, это означает, что их нужно называть одинаково? кто этому обязал?

А как ты предлагаешь называть? ConfigurationParser, чтоб никто не догадался?
В С++ я могу сделать так:

#include <OptionParser.h>
 
...
 
auto op = OptionParser();

Цитата --Ins-- @ 27.01.11, 21:40

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

Ты говоришь, что уже показал нам, что "защита" не работает. Я прошу показать.

Цитата Мяут-Настоящий @ 27.01.11, 21:43

Цитата D_KEY @ 27.01.11, 21:38

--Ins--, покажи пример, в котором бы "легально"(без грязных хаков) компилятор давал изменять константные объекты?

Скрытый текст

mutable

т.е. можно гарантировать, что объект будет изменяем, даже если его передали как const? если да, то есть ли способ гарантировать, что объект не будет изменен, даже если он mutable? если да то, есть ли способ изменить объект, даже если он гарантировано защищен от изменений? если да, то... =)

Цитата --Ins-- @ 27.01.11, 21:38

Заметь, я на уровень указателей и ассемблерных вставок не опускался, я остался на уровне абстракции объектов И нарушил, нет, не инкапсуляцию, она тут ни причем... А вашу "гарантию"

Ничего ты не нарушил, ты просто вообще не понял о чем тебе D_KEY говорит!

Цитата korvin @ 27.01.11, 21:48

т.е. можно гарантировать, что объект будет изменяем, даже если его передали как const? если да, то есть ли способ гарантировать, что объект не будет изменен, даже если он mutable?

mutable все же для описанимя не логики объекта, а ее физики. Например блокировку, очевидно нужно мочь менять и в случае константности объекта

Добавлено 27.01.11, 21:50
На всякий случай замечу, что mutable прописывается полям.

Цитата --Ins-- @ 27.01.11, 21:34

D_KEY, идея константных объектов может и замечательная, но реализовать ее так, увы, невозможно Никто тебе не гарантирует ничего, ты можешь только надеяться. Так и говори "я надеюсь", а не "мне гарантировано". Я же говорю, никто не гарантирует неизменность объекта - это исключительно на совести программиста. Если нужно чтобы объект не изменялся - не передавай ссылку на него, передай значения нужных параметров

На совести какого программиста? Если ты хочешь, чтобы возвращённый по ссылке объект никто не менял, его никто не изменит независимо от совести. Вот как код D_KEYя:

      class Rect
      {
      public:
         //...
         void SetRect(const Rect &rect);
         const Rect & GetRect() const;
      };

Состояние возвращённого из GetRect объекта не изменится. Это гарантия. В делфи, в аналогичной ситуации действительно стоит надеяться только на совесть программиста.

Цитата D_KEY @ 27.01.11, 21:46

Я прошу показать.

Речь идет о том, что объект переданный со словом const в методе не может быть изменен, так? Но вы же говорите что в этом методе можно дергать методы других объектов. А они то откуда знают, что менять объект нельзя? Допустим, мы вызвали какой-то метод, который, казалось бы, никакого отношения к константному объекту не имеет. А он - имел. Либо явно в своем коде, либо через каллбэк поменял значение изначального объекта. Это возможно?

Цитата Мяут-Настоящий @ 27.01.11, 21:45

А как ты предлагаешь называть? ConfigurationParser, чтоб никто не догадался?
В С++ я могу сделать так:

#include <OptionParser.h>
 
...
 
auto op = OptionParser();

и если тут же подключишь какой-нибудь "../OptionParser.h", который тоже экспортирует класс OptionParser, как быть?

но вообще меня вопрос натолкнул на другую мысль: в какой модуль поместить этот OptionParser, в Parser, где все парсеры или в Options, где все классы для работы с опциями? =) может неплохо было бы иметь тегированные пространства имен?

Цитата --Ins-- @ 27.01.11, 21:52

Речь идет о том, что объект переданный со словом const в методе не может быть изменен, так? Но вы же говорите что в этом методе можно дергать методы других объектов. А они то откуда знают, что менять объект нельзя?

Так ты можешь дергать только те методы, которые по такой же гарантии не имеют права изменять объект, иначе ошибка компиляции, тебе уже 3 раза это написали, я в четвертый пишу

Добавлено 27.01.11, 21:58

Цитата --Ins-- @ 27.01.11, 21:52

Допустим, мы вызвали какой-то метод, который, казалось бы, никакого отношения к константному объекту не имеет. А он - имел.

не прокатят такие финты

Цитата korvin @ 27.01.11, 21:52

может неплохо было бы иметь тегированные пространства имен?

т.е. например пишешь что-то типа

[Option, My, Parser, Class]

-- получаешь свой класс парсера опций

соответственно

import [Option, My, Class]

-- получаешь все свои классы для работы с опциями

import [Parser, My]

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

по-моему прикольно было б =)
вроде для перла есть пакет, позволяющий тегировать функции

Сообщение отредактировано: korvin - 27.01.11, 22:00

Цитата KILLER @ 27.01.11, 21:54

Так ты можешь дергать только те методы, которые по такой же гарантии не имеют права изменять объект, иначе ошибка компиляции, тебе уже 3 раза это написали

Мне три раза написали, что методы других объектов, которые параметрами нас не принимают, МОЖНО вызывать.

Цитата --Ins-- @ 27.01.11, 21:59

Мне три раза написали, что методы других объектов, которые параметрами нас не принимают, МОЖНО вызывать.

Параметр - это лишь один из способов поиметь объект, еще можно напрямую присвоить...