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

О как.

Цитата korvin @ 21.09.11, 18:23

...в хаскелле, и я считаю...

Одна запятая, а как меняет смысл...

Сообщение отредактировано: Qraizer - 21.09.11, 18:25

Цитата D_KEY @ 21.09.11, 18:21

Класс известен(поэтому виртуальные классовые методы вызывать можно), а вот объекта еще нет.

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

Добавлено 21.09.11, 18:28

Цитата Qraizer @ 21.09.11, 18:25

О как.

Цитата korvin @ 21.09.11, 18:23

...в хаскелле, и я считаю...

Одна запятая, а как меняет смысл...

зачем ты искажаешь смысл моих слов?

Сообщение отредактировано: korvin - 21.09.11, 18:36

Не, я понял правильно. Но вдруг ошибся ты? Я проверил, не ошибся.

Какой то неинтересный холивар. Дельфи язык какой то.. в общем, мне оно не нравится. Не знаю почему. С++ хорош. C# тоже хороший язык, но он зелёный. Не знаю почему он такой, но он зелёный. Objective-C, кстати, оранжевый. Дельфи синий, а С++ белый. Джаву пробовал - тоже не воткнула. Именно на таком уровне "нравится-не нравится" нужно вести дискуссию. Я так считаю, вот.
А ещё можно на таком уровне - "в мире ежесекундно выполняется примерно 500 моих строчек, написанных на С++, 5 на C# и ни одной на Дельфи". Поэтому С++ - самый хороший.

Сообщение отредактировано: Бобёр - 21.09.11, 18:49

korvin, ты повторяешься. За полгода, или сколько там, твоего участия в холиварах, мог бы и уяснить, что под объектом и его конструированием C++-сники понимают не то же, что дельфисты. В Дельфи объект это всего лишь место в памяти, которое еще нужно наполнить содержимым. А в C++ объект это готовая к работе сущность, не требующая дополнительных инициализаций

Если сравнивать с автомобилем, то в Дельфи автомобиль это кузов, в который еще нужно поместить двигатель, и остальное оборудование, прикрутить колеса и провести испытания.
В С++ автомобиль - это полностью собранное и прошедшее испытания средство передвижения.

Методы инициализации в Дельфи создают инварианты. В C++ этим занимается конструктор. Тем же чем занимается конструктор Дельфи, в C++ занимается operator new.

Цитата korvin @ 21.09.11, 18:23

Цитата D_KEY @ 21.09.11, 18:21

Про инварианты слышал?

про методы инициализации слышал? при чем тут инварианты? они (методы инициализации) их не нарушают

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

Добавлено 21.09.11, 18:50

Цитата Бобёр @ 21.09.11, 18:47

Дельфи язык какой то.. в общем, мне оно не нравится.

Цитата Qraizer @ 21.09.11, 18:38

Не, я понял правильно. Но вдруг ошибся ты? Я проверил, не ошибся.

ну как-то нелогично говорить, что что-то тебе не нравится, но при этом считать это нормальным =)

D_KEY, давай не будем продолжать спор, ты просил объяснить логику, я объяснил, а хорошо такое поведение или плохо вы уже с делфистами обсудили на стопицот постов в другом холиваре =)

Цитата

В С++ автомобиль - это полностью собранное и прошедшее испытания средство передвижения.

Не факт. Если пользователь не написал конструктор, то даже "сконструированный" объект будет хуже запорожца.

Цитата D_KEY @ 21.09.11, 18:48

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

дык наследование на то и существует, чтоб в потомке конкретизировать/изменять поведение предка, а инициализация, тоже часть поведения.

Добавлено 21.09.11, 18:55

Цитата amk @ 21.09.11, 18:47

korvin, ты повторяешься. За полгода, или сколько там, твоего участия в холиварах, мог бы и уяснить, что под объектом и его конструированием C++-сники понимают не то же, что дельфисты. В Дельфи объект это всего лишь место в памяти, которое еще нужно наполнить содержимым. А в C++ объект это готовая к работе сущность, не требующая дополнительных инициализаций

программист != язык программирования, так-то

Добавлено 21.09.11, 18:56

Цитата Бобёр @ 21.09.11, 18:52

Не факт. Если пользователь не написал конструктор, то даже "сконструированный" объект будет хуже запорожца.

на это тебе ответят "значит так объект задуман"

Добавлено 21.09.11, 18:57

Цитата amk @ 21.09.11, 18:47

korvin, ты повторяешься. За полгода, или сколько там, твоего участия в холиварах, мог бы и уяснить, что под объектом и его конструированием C++-сники понимают...

и да, мы тут как бы сейчас джаву обсуждаем...

Цитата korvin @ 21.09.11, 18:26

с точки зрения языка объект уже есть

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

Добавлено 21.09.11, 19:01

Цитата Бобёр @ 21.09.11, 18:52

Если пользователь не написал конструктор, то даже "сконструированный" объект будет хуже запорожца.

Почему же. Это просто будет объект в дефолтной комплектации

Добавлено 21.09.11, 19:26

Цитата korvin @ 21.09.11, 18:53

Цитата amk @ 21.09.11, 18:47

korvin, ты повторяешься. За полгода, или сколько там, твоего участия в холиварах, мог бы и уяснить, что под объектом и его конструированием C++-сники понимают...

и да, мы тут как бы сейчас джаву обсуждаем...

В java в данном случае тоже самое. Только вот поведение конструкторов у них не продуманно в этом плане.

Цитата Бобёр @ 21.09.11, 18:52

Если пользователь не написал конструктор, то даже "сконструированный" объект будет хуже запорожца.

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

Цитата D_KEY @ 21.09.11, 18:59

Почему же. Это просто будет объект в дефолтной комплектации

Именно. Нормальная практика в случаях, когда объект сборки не требует. Но при этом готовы к работе все составляющие объекта.

Цитата D_KEY @ 21.09.11, 17:41

Цитата DesweR @ 21.09.11, 16:20

Цитата D_KEY @ 21.09.11, 16:15

DesweR, я не понимаю, что тебя не устраивает, поясни мысль. Или тебе перевести нужно?

Ну там же по русс чёрному по белому написано что "finally is necessary when you need to set something other than memory back to its original state", т.е. вернуть самому в исходное состояние то, что сам GC не способен.

А я о чем писал?

Опять о своём, о "ресурсах" и RAII. Давай в 100500-ый раз не будем поднимать эту тему.

Цитата Qraizer @ 21.09.11, 17:50

Цитата DesweR @ 21.09.11, 16:17

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

Здрассссти-пжалста. Это ты их просто 328 (триста двадцать восемь прописью) раз не увидел.

Я не видел решений удовлетворяющие ТЗ.

Цитата amk @ 21.09.11, 18:47

В Дельфи объект это всего лишь место в памяти, которое еще нужно наполнить содержимым. А в C++ объект это готовая к работе сущность, не требующая дополнительных инициализаций

В С++ объект пошагово досоздаётся в каждом конструкторе производного класса, а в Delphi на момент вызова конструкторов производных классов - объект уже полностью создан.

Цитата D_KEY @ 21.09.11, 18:48

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

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

Цитата D_KEY @ 21.09.11, 18:59

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

"С точки зрения языка С++" fixed.

Цитата korvin @ 21.09.11, 16:33

кстати по поводу отлова исключений, допустим есть такой код:

try {
    throwSpecificException();
} catch (GeneralException exn) {
    doSomething();
} catch (SpecificException exn) {
    doSomethingElse();
}

где SpecificException -- наследник GeneralException

...

Можно и так, к услугам классовые ссылки.

program Project1;
 
{$APPTYPE CONSOLE}
 
uses
  SysUtils,
  Generics.Defaults,
  Generics.Collections;
 
type
  TGeneralException = class(Exception);
  TSpecificException  = class(TGeneralException);
  TMoreSpecificException  = class(TSpecificException);
  TVeryMoreSpecificException  = class(TMoreSpecificException);
 
  TExceptionsComparer = class(TComparer<TPair<ExceptClass, TProc>>)
    function Compare(const A, B: TPair<ExceptClass, TProc>): Integer; override;
  end;                            
 
 
function TExceptionsComparer.Compare(const A, B: TPair<ExceptClass, TProc>): Integer;
begin
  if A.Key = B.Key then
    Exit(0);
 
  if A.Key.InheritsFrom(B.Key) then
    Exit(-1);
 
  if B.Key.InheritsFrom(A.Key) then
    Exit(1);
 
  raise Exception.Create('');
end;
 
 
procedure SortExceptions(const AE: Exception; AExcepts: array of TPair<ExceptClass, TProc>; const AIsAllExcept: Boolean);
var
  LExcept: TPair<ExceptClass, TProc>;
begin
  TArray.Sort<TPair<ExceptClass, TProc>>(AExcepts, TExceptionsComparer.Create);
 
  for LExcept in AExcepts do
    if AE is LExcept.Key then
    begin
      LExcept.Value.Invoke;
 
      if not AIsAllExcept then
        Break;
    end;
end;
 
 
begin
  try
    raise TMoreSpecificException.Create('');
  except
    on E: TGeneralException do
      SortExceptions(E,
                     [TPair<ExceptClass, TProc>.Create(TVeryMoreSpecificException,
                                                       procedure begin WriteLn('TVeryMoreSpecificException'); end),
                      TPair<ExceptClass, TProc>.Create(TGeneralException,
                                                       procedure begin WriteLn('TGeneralException'); end),
                      TPair<ExceptClass, TProc>.Create(TMoreSpecificException,
                                                       procedure begin WriteLn('TMoreSpecificException'); end),
                      TPair<ExceptClass, TProc>.Create(TSpecificException,
                                                       procedure begin WriteLn('TSpecificException'); end)],
                     False);
  end;
 
  WriteLn('');
 
  try
    raise TMoreSpecificException.Create('');
  except
    on E: TGeneralException do
      SortExceptions(E,
                     [TPair<ExceptClass, TProc>.Create(TVeryMoreSpecificException,
                                                       procedure begin WriteLn('TVeryMoreSpecificException'); end),
                      TPair<ExceptClass, TProc>.Create(TGeneralException,
                                                       procedure begin WriteLn('TGeneralException'); end),
                      TPair<ExceptClass, TProc>.Create(TMoreSpecificException,
                                                       procedure begin WriteLn('TMoreSpecificException'); end),
                      TPair<ExceptClass, TProc>.Create(TSpecificException,
                                                       procedure begin WriteLn('TSpecificException'); end)],
                     True);
  end;
 
  ReadLn;
end.

TMoreSpecificException
 
TMoreSpecificException
TSpecificException
TGeneralException

Добавлено 22.09.11, 05:34
К слову, в DelphiPrism вроде можно как-то так:

  try
    raise TMoreSpecificException.Create('');
  except
    on E: TGeneralException do
      case E of
        TVeryMoreSpecificException:
          WriteLn('TVeryMoreSpecificException');
 
        TGeneralException:
          WriteLn('TGeneralException');
 
        TMoreSpecificException:
          WriteLn('TMoreSpecificException');
 
        TSpecificException:
          WriteLn('TSpecificException');
      end;
  end;

Сообщение отредактировано: DesweR - 22.09.11, 05:34

какой ужасный ужас

Цитата DesweR @ 22.09.11, 01:55

Цитата D_KEY @ 21.09.11, 17:41

Цитата DesweR @ 21.09.11, 16:20

Цитата D_KEY @ 21.09.11, 16:15

DesweR, я не понимаю, что тебя не устраивает, поясни мысль. Или тебе перевести нужно?

Ну там же по русс чёрному по белому написано что "finally is necessary when you need to set something other than memory back to its original state", т.е. вернуть самому в исходное состояние то, что сам GC не способен.

А я о чем писал?

Опять о своём, о "ресурсах" и RAII.

Да? Давай посмотрим, в чем ты меня обвинил:

Цитата DesweR @ 21.09.11, 15:32

Цитата D_KEY @ 21.09.11, 15:25

Правильная книжка. В ней, например, автор пишет, что в С++ лучше продумано поведение конструкторов Еще пишет, что finally необходим при работе с другими(не памятью) ресурсами

Ой врать-то

Собственно, на это обвинение мне и пришлось сейчас ответить. И я показал соответствующие цитаты.

Цитата

а в Delphi на момент вызова конструкторов производных классов - объект уже полностью создан.

Как же он может быть создан, если конструктор еще не отработал

Цитата

Цитата D_KEY @ 21.09.11, 18:48

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

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

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

Цитата

Цитата D_KEY @ 21.09.11, 18:59

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

"С точки зрения языка С++" fixed.

В обсуждаемой Java такая же стратегия конструирования объектов.

Добавлено 22.09.11, 06:30

Цитата korvin @ 22.09.11, 05:50

какой ужасный ужас

+100500

Сообщение отредактировано: D_KEY - 22.09.11, 06:31