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

--Ins--, вот например смотри тут, как работает const_cast Ссылко, ткни мну

--Ins--, кстати. Я думаю, что большинство со мной не согласится, но я бы предпочел, чтобы const был по умолчанию, а изменяемые объекты нужно было бы указывать(каким-нибудь mutable или var).

Цитата D_KEY @ 27.01.11, 22:53

Я думаю, что большинство со мной не согласится, но я бы предпочел, чтобы const был по умолчанию, а изменяемые объекты нужно было бы указывать(каким-нибудь mutable или var).

Кстати, да. Как то не задумывался за это, но мысль мне нравиться. К сожалению, не мало программистов С++ - хотя таких правильней назвать программистами на Си с классами - плохо понимают всю мощь const.

Добавлено 27.01.11, 23:03

Цитата D_KEY @ 27.01.11, 22:49

может быть только в билдере можно смастерить что-то работающее средней сложности, не понимая С++

Да и там это будет не очень надёжно работающее, ну а чтение кода и сопровождение доступно только автору

Цитата D_KEY @ 27.01.11, 22:49

на С++ неаккуратно программировать нельзя

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

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

Итак:
Delphi - гарантия 0%
C++ - гарантия больше 0%

Но но! У нас такие ситуации решаются интерфейсами к классу и, что самое замечательное, без "уродства" интерфейса самого класса
А вот как в С++ разруливается такая ситуация? Есть класс с несколькими полями, экземпляр этого класса нужно передать одному клиенту с доступом к полям "read only", а другому клиенту с возможностью полного доступа, но только к одному полю.

type
  ISomeClass1 = interface
    function GetX: Integer;
    function GetY: string;
    property X: Integer read GetX;
    property Y: string read GetY;
  end;
 
  ISomeClass2 = interface
    function  GetY: string;
    procedure SetY(const AY: string);
    property  Y: string read GetY write SetY;
  end;
 
  TSomeClass = class(TInterfacedObject, ISomeClass1, ISomeClass2)
  strict private
    function  GetX: Integer;
    procedure SetX(const AX: Integer);
    function  GetY: string;
    procedure SetY(const AY: string);
  public
    property X: Integer read GetX write SetX;
    property Y: string read GetY write SetY;
  end;
 
 
function TSomeClass.GetX: Integer;
begin
  //
end;
 
procedure TSomeClass.SetX(const AX: Integer);
begin
  //
end;
 
function TSomeClass.GetY: string;
begin
  //
end;
 
procedure TSomeClass.SetY(const AY: string);
begin
  //
end;
 
 
procedure MyClient1(const SomeClass: ISomeClass1);
var
  X: Integer;
  Y: string;
begin
  X := SomeClass.X;
//SomeClass.X := X; Cannot assign to a read-only property
  Y := SomeClass.Y;
//SomeClass.Y := Y; Cannot assign to a read-only property
end;
 
procedure MyClient2(const SomeClass: ISomeClass2);
var
  X: Integer;
  Y: string;
begin
//X := SomeClass.X; Undeclared identifier: 'X'
//SomeClass.X := X; Undeclared identifier: 'X'
  Y := SomeClass.Y;
  SomeClass.Y := Y;
end;
 
...
 
var
  SomeClass: TSomeClass;
  X: Integer;
  Y: string;
begin
  SomeClass := TSomeClass.Create;
 
  X := SomeClass.X;
  SomeClass.X := X;
  Y := SomeClass.Y;
  SomeClass.Y := Y;
 
  MyClient1(SomeClass);
  MyClient2(SomeClass);

Цитата DesweR @ 28.01.11, 14:08

Но но! У нас такие ситуации решаются интерфейсами к классу и, что самое замечательное, без "уродства" интерфейса самого класса

Плодить и размножать наследников на все случаи жизни? Как это здорово.

Цитата DesweR @ 28.01.11, 14:08

А вот как в С++ разруливается такая ситуация? Есть класс с несколькими полями, экземпляр этого класса нужно передать одному клиенту с доступом к полям "read only", а другому клиенту с возможностью полного доступа, но только к одному полю.

Ответ не думая: как минимум так же само.

Цитата korvin @ 28.01.11, 04:48

Цитата D_KEY @ 27.01.11, 22:49

на С++ неаккуратно программировать нельзя

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

Да, часто именно так и бывает

Добавлено 28.01.11, 14:25

Цитата DesweR @ 28.01.11, 14:08

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

Итак:
Delphi - гарантия 0%
C++ - гарантия больше 0%

Но но! У нас такие ситуации решаются интерфейсами к классу и, что самое замечательное, без "уродства" интерфейса самого класса

Это не только у вас. Это везде так, в том числе и в С++. Только в отличие от, я и в интерфейсе явно указываю, что объект методы не меняют. Это удобно как клиентам, так и наследникам(наследники не смогут изменить состояние объекта и нарушить контракт).

Цитата

А вот как в С++ разруливается такая ситуация? Есть класс с несколькими полями, экземпляр этого класса нужно передать одному клиенту с доступом к полям "read only", а другому клиенту с возможностью полного доступа, но только к одному полю.

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

Добавлено 28.01.11, 14:31
Это как спецификации исключений. Вот мне, например, нравится проверяемые исключения в Java. В С++ же спецификации исключений проверяются только в рантайме , но тем не менее указывать спецификации исключений - дело хорошее, ибо позволяет делать код более документированным. Другое дело, что часто эти спецификации приходится писать в виде комментариев, чтобы избежать этой странной и практически бесполезной проверки во время выполнения А в яве компилятор берет на себя часть работы по устранению ошибок.
В этом, собственно, и заключается основное преимущество статической типизации... Вот и у вас константность является, максимум, "комментарием"...

Сообщение отредактировано: D_KEY - 28.01.11, 14:32

Цитата Повстанець @ 28.01.11, 14:17

Плодить и размножать наследников на все случаи жизни? Как это здорово.

Каких наследников? У меня там один единственный класс

Цитата Повстанець @ 28.01.11, 14:22

Ответ не думая: как минимум так же само.

Ну так покажите?

Цитата D_KEY @ 28.01.11, 14:22

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

А если для другого клиента необходим доступ методу, который значится константным? Что делать с const? Вообще его убирать?

Сообщение отредактировано: DesweR - 28.01.11, 14:49

Цитата DesweR @ 28.01.11, 14:47

Каких наследников? У меня там один единственный класс

Ну вот смотри пример, который мы рассматривали. Там поинты и ректы. Во всех гуёвых библиотеках они уже реализованы. Мне что, ещё наследоваться от них? Зачем?

Цитата Повстанець @ 28.01.11, 14:59

Ну вот смотри пример, который мы рассматривали. Там поинты и ректы. Во всех гуёвых библиотеках они уже реализованы. Мне что, ещё наследоваться от них? Зачем?

Не понял про наследование, о чём там речь была?

Добавлено 28.01.11, 15:02
И да, с вопроса не соскакиваем

Цитата DesweR @ 28.01.11, 14:47

А если для другого клиента необходим доступ методу, который значится константным? Что делать с const? Вообще его убирать?

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

Цитата Мяут-Настоящий @ 28.01.11, 15:08

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

Нет. Это разграничение прав доступа.

const не занимается разграничением прав доступа.

Цитата Мяут-Настоящий @ 28.01.11, 15:12

const не занимается разграничением прав доступа.

И какова тогда польза от него, помимо тривиальных ситуаций?

Цитата DesweR @ 28.01.11, 15:01

Не понял про наследование, о чём там речь была?

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

Цитата DesweR @ 28.01.11, 15:01

И да, с вопроса не соскакиваем

А вопрос такой занимательный-занимательный. Интересный-интересный:

class some_class_a
{
public:
    virtual int get_x() = 0;
    virtual int get_y() = 0;
    virtual void set_x(int) = 0;
    virtual void set_y(int) = 0;
};
 
class read_only : virtual public some_class_a
{
private:
    using some_class_a::set_x;
    using some_class_a::set_y;
 
};
 
class only_y : virtual public some_class_a
{
private:
    using some_class_a::set_x;
    using some_class_a::get_x;
 
};
 
class some_class : public read_only, public only_y
{
    //...
};
 
void read_only_f(read_only& ro)
{
    //...
}
 
void only_y_f(only_y& oy)
{
    //...
}
 
some_class sc;
read_only_f(sc);
only_y_f(oy);