Delphi vs C++ , Часть 1

Цитата Smike @ 18.10.07, 11:17

То есть класс может заимствовать реализацию интерфейса из другого класса.

Если бы речь шла только о реализации интерфейса...

Цитата Romkin @ 18.10.07, 10:47

концепция множественного наследования таит в себе немало «подводных камней», и ее полноценная реализация далеко не проста.

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

Цитата Romkin @ 18.10.07, 10:41

Недостаток множественного наследования, на мой взгляд - в его свободе. Код меньше инкапсулируется. В этом же и опасность.

елементарно инкапсулируется

Цитата Romkin @ 18.10.07, 10:54

Это всего лишь подтверждает мой тезис об ограниченности мышления сишников, которые просто не способны вообразить себе методики написания программ, отличные от имеющихся в С++.

множественное наследование в отличии от одинарного - это ограниченность мышления?

Цитата Flex Ferrum @ 18.10.07, 10:57

Для не-плюсовиков, например, такое понятие как "наследование свойств (traits)" - это, скорее, пустой звук, чем нечто осязаемое. Для программиста на С++ - вполне себе рабочий механизм. И как тут без МН?

Цитата Flex Ferrum @ 18.10.07, 11:19

Если бы речь шла только о реализации интерфейса...

ну на самом то деле преимущество С++ в этом вопрос то, что там вся настройка осуществляется во время компилярования. Что мешаеь тоже самое сделать в Delphi полиморфно во ремя выполнения. Ничего. Суть "настраемого поведеения" я могу получить.

Цитата

Это скорее про VB, который (насколько я знаю) вообще не позволяют создавать автономных экзешников (то есть работающих без msvbvwmX0.dll.

Это несущественно, да и к языку не относится.

Цитата

А Delphi — это скорее набор отверток. Да, гвозди ими не забъешь, но зато можно закрутить шуруп. А как известно шурупы держаться прочнее И на каждый шуруп в Delphi есть своя отвертка.

Smike, я давно не писал на паскале, быть может я не в теме, но всеже у вас уже есть возможность нормальных арифметических операций с указателями ( dec и inc - для меня мало).

Сообщение отредактировано: Alex Forth - 18.10.07, 11:27

Цитата Romkin @ 18.10.07, 11:19

И что? Изначально определяешь интерфейс, потом берешь его реализацию и имплементируешь. Вроде бы достаточно должно быть.
Или я не с того конца зашел? Можно конкретный пример, не связанный с C++?

Ну смотри. Предположим, мы реализуем объект, содержащий счетчик ссылок. При этом предполагаем, что объект может использоваться либо в однопоточном приложении, либо в многопоточном. А потому решаем, что если объект используется в однопоточном приложении, то тратить время на синхронизацию потоков при изменении счетчика нам нет необходимости. А если в многопоточном - то может потребоваться. А может и не потребоваться. По этому в С++ это может быть сделано так:

template<typename L> public RefCounter : public L
{
public:
   void AddRef()
   {
      Lock();
      m_Counter ++;
      Unlock();
   }
   void Release()
   {
      Lock();
      m_Counter --;
      Unlock();
   }
private:
   int m_Counter;
};
 
class STLocker
{
public:
   void Lock() {;}
   void Unlock() {;}
};
 
class MTLocker
{
public:
   void Lock() {m_Mutex.lock();}
   void Unlock() {m_Mutex.unlock();}
private:
   Mutex m_Mutex;
};
 
RefCounter<STLocker> SimpeRefCounter; // счетчик ссылок без синхронизации
RefCounter<MTLocker> MultiThreadRefCounter; // счетчик ссылок с синхронизацией

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

Цитата mo3r @ 18.10.07, 10:55

Ферзь ходит как слон и как ладья

Ну ОК. Вот реализация на Delphi:

type
  // interfaces
  IBasicMove = interface;
 
  IBishopMove = interface(IBasicMove);
  IRookMove = interface(IBasicMove);
 
  // classes
  TBasicMove = class(TInterfacedObject, IBasicMove);
 
  TBishopMove = class(TBasicMove, IBishopMove);
  TRookMove = class(TBasicMove, IRookMove);
 
  TQueenMove = class(TBasicMove, IBishopMove, IRookMove)
    property BishopMove: TBishopMove read GetBishopMove; implements IBishopMove;
    property RookMove: TRookMove read GetRookMove; implements IRookMove;
  end;

По-моему все просто, понятно и логично

Цитата archimed7592 @ 18.10.07, 10:59

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

Годится?

Добавлено 18.10.07, 11:29

Цитата Alex Forth @ 18.10.07, 11:26

Smike, я давно не писал на паскале, быть может я не в теме, но всеже у вас уже есть возможность нормальных арифметических операций с указателями ( dec и inc - для меня мало).

А что под этим подразумевается?

Цитата Flex Ferrum @ 18.10.07, 11:27

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

Даже в приведенном ранее коде (в исходниках калькулятора - моего и Смайка), Смайк вынужден сначала строить дерево разбора, а потом по нему бежать вычислителем. В моей реализации все арифметические операции выполняются сразу же, как только была распознана соответствующая грамматическая конструкция. При этом в коде Смайка имеет место еще один оверхед - дерево разбора строится даже в том случае, если требуется простая проверка выражения на соответствие грамматике.

Цитата Орион @ 18.10.07, 11:20

Сдругой стороны - вот как сделать красиво наследование нескольких поведений без множественно наследования?

Через имплементацию интерфейса.

Цитата Flex Ferrum @ 18.10.07, 11:27

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

Сенькс. Более-менее понял. Да, в Delphi это во время выполнения делается.

да.. если добавляем переменные.. то надо определится что выводим на экран?
сделать функцию println?

Цитата archimed7592 @ 18.10.07, 11:33

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

Я говорил не именно об умных указателях А там проблема в "многа букаф" по больешй части.

Цитата Romkin @ 18.10.07, 11:39

Да, в Delphi это во время выполнения делается.

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

Цитата

А что под этим подразумевается?

  int *a;
  int b;
  a+=375-b;

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

Цитата Romkin @ 18.10.07, 11:39

Через имплементацию интерфейса.

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

Цитата Alex Forth @ 18.10.07, 11:51

int *a;
int b;
a+=375-b;
Если я правильно помню, то такое вычисление значения указателя в делфи невозможно без костылей

  inc(LongInt(a), 375-b);

Это не костыль, просто ты объясняешь компилятору, что тебе нужно именно это.

Цитата Alex Forth @ 18.10.07, 11:51

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

var
  A: Pointer;
  B: Integer;
begin
  A := PChar(A) + B - 375;
end;

Костыль-не костыль, но задача реализуема.

Добавлено 18.10.07, 12:07

Цитата Flex Ferrum @ 18.10.07, 11:55

Expr ::= ...
Term ::= ...
Frac ::= ...

А правила построения этих схем есть?