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

Цитата

Пишущему на паскале сипипи всегда будет китайской грамотой, равно как и наоборот

Не надо вот так необдуманно кванторы всеобщности применять. Паскаль учила после с++, в универе. Китайской грамотой не показался ни разу --- просто слабым по возможностям языком.(преподавали стандарт паскаля).Понять тот же with было несложно, просто непонятно особо было на кой он нужен. Зашла сейчас в пару тем в дельфях -- вроде в коде все понятно.Некрасиво, на мой вкус, но понятно.

Цитата archimed7592 @ 11.04.07, 18:03

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

Похоже ты просто Дельфи, как говорится, не осилил

На мой взгляд, у каждого языка есть достоинства и недостатки. Мне, например, очень не хватает сишных ?:, декларации переменных в любом месте кода (даже в Борландовском опросе просил о такой фиче ), сишного for и дефайнов с макросами.

Но с другой стороны я терпеть не могу сишный case, где нужно в каждом варианте писать return/break, декларации интерфейсов, от которых пухнет голова (а ActiveX без интерфейсов — не ActiveX), отсутствие вложенных функций.

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

Добавлено 11.04.07, 18:35

Цитата mo3r @ 11.04.07, 18:20

PopupMenu.Popup(ClientToScreen(Point(X,Y)));

Не пройдет Потому что ClientToScreen возвращает TPoint, а метод Popup принимает X и Y отдельно.

Цитата mo3r @ 11.04.07, 18:20

Use the reference

УмнО. With и так использует ссылку на класс

Добавлено 11.04.07, 18:40

Цитата Smike @ 11.04.07, 18:32

Не пройдет Потому что ClientToScreen возвращает TPoint, а метод Popup принимает X и Y отдельно.

И это правильно, потому что обилие скобок тоже не к добру.

А это вообще жесть. Чувствительным сишникам не смотреть

procedure TForm2.Panel1MouseMove(Sender: TObject; Shift: TShiftState; X,
  Y: Integer);
begin
  with ScreenToClient(Panel1.ClientToScreen(Point(X, Y))) do
    Caption := Format('x: %d, y: %d', [X, Y]);
end;

Цитата Smike @ 11.04.07, 18:18

Hryak почему-то упирает на проблему с распознаванием методов класса и обычных процедур внутри блока with. Я же в упор не вижу здесь проблемы.

Ну, и Бог с тобой, не видь.

Цитата

Вот еще пару примеров использования with. Это в классе, отрисовывающем нестандартное окно, в процедуре, где вычисляется клиентская область:

  with Rect do
  begin
    Inc(Left, Border);
    Inc(Top, Border + CaptionHeight);
    Dec(Right, Border);
    Dec(Bottom, Border);
  end;

with тут пришелся как нельзя лучше. Или тоже предложите переписать с дополнительной функцией? Не вижу никакого смысла.

Скока буковок...

rect += Rect(border, border + captionHeight, -border, -border);

Цитата

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

Ну вот так, и даже со столь любимыми вложенными функциями - вернее, эмуляцией этого (сам так не пишу, считаю достаточным написать в анонимном неймспейсе функцию)
Вместо

Цитата

    with RGB do
    begin
      if R > 0 then
        R := Power(R, Gamma)
      else
        R := 0;
      if G > 0 then
        G := Power(G, Gamma)
      else
        G := 0;
      if B > 0 then
        B := Power(B, Gamma)
      else
        B := 0;
    end;

пишем

struct In {
  void SpecPow(double& x, double y)  {
     x = x > 0. ? pow(x, y) : 0.;
  }
};
In::SpecPow(rgb.R, gamma);
In::SpecPow(rgb.G, gamma);
In::SpecPow(rgb.B, gamma);

Цитата

А это вообще жесть. Чувствительным сишникам не смотреть

procedure TForm2.Panel1MouseMove(Sender: TObject; Shift: TShiftState; X,
  Y: Integer);
begin
  with ScreenToClient(Panel1.ClientToScreen(Point(X, Y))) do
    Caption := Format('x: %d, y: %d', [X, Y]);
end;

Действительно, чего тут смотреть?

const Point& pt = ScreenToClient(Panel1.ClientToScreen(Point(X, Y)));
caption = Format("x: %d, y: %d", pt.X, pt.Y);

Сообщение отредактировано: Hryak - 11.04.07, 19:49

Цитата Hryak @ 11.04.07, 19:00

rect += Rect(border, border + captionHeight, -border, -border);

Красиво, но добавляет лишнюю операцию и трубует, чтобы оператор сложения был перегружен.

Цитата Hryak @ 11.04.07, 19:00

Ну вот так, и даже со столь любимыми вложенными функциями - вернее, эмуляцией этого (сам так не пишу, считаю достаточным написать в анонимном неймспейсе функцию)

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

Цитата Hryak @ 11.04.07, 19:00

Действительно, чего тут смотреть?

Лишняя переменная... ну да ладно, с сишной декларацией переменных это не столь неудобно

По поводу же одного моего примера ты умолчал. Значит согласен с целессобразностью применения with?

Smike, а что по поводу моего поста с делегатами?

Добавлено 11.04.07, 19:27
Вот этого вот: Delphi vs C++ (сообщение #1519380)

Цитата Pourtous @ 11.04.07, 18:27

Не надо вот так необдуманно кванторы всеобщности применять.
<...>
Понять тот же with было несложно, просто непонятно особо было на кой он нужен. Зашла сейчас в пару тем в дельфях -- вроде в коде все понятно.Некрасиво, на мой вкус, но понятно.

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

Цитата Smike @ 11.04.07, 19:24

Красиво, но добавляет лишнюю операцию

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

Цитата

Лишний вызов функции.

Размещение тела метода прямо в определении класса - автоматом подразумевает inline.

Цитата

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

Если тело функции, где дело происходит, не с километр - то не сильно как и пострадает..

Цитата

Лишняя переменная... ну да ладно, с сишной декларацией переменных это не столь неудобно

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

Цитата

По поводу же одного моего примера ты умолчал. Значит согласен с целессобразностью применения with?

Это где много-много строчек инициализации свойств у объекта?
Дык, уже же сказали:
"Use the reference, Smike" ©

Цитата Smike @ 11.04.07, 19:24

Лишняя переменная... ну да ладно, с сишной декларацией переменных это не столь неудобно

это ссылка вообще-то

Отдельные Delphi'сты скатились до аргументации "Да что вы понимаете в конной авиации?". Забавно.

Цитата Hryak @ 11.04.07, 17:10

Ага, не скакать дак комментарии писать. Я, знаешь ли, предпочитаю самодокументированный код.

А что, самодокументируемый код уже заменяет комментарии? Ну, ладно, раз так.

Цитата archimed7592 @ 11.04.07, 18:03

типа коментарий написать проще, чем имя объекта перед именем члена?

Комментарий нужен всего один, рядом с with, а вот писать каждый раз имя объекта, которое может быть жуть каким длинным, это и правда неприятно. В общем-то именно для сокращения времени набора with, наверное, и был сделан, не более того. О чем и говорил, если подозреваешь с ним проблем - не юзай, и все тут. Главный-то цимес в том, что он есть, а пользовать или нет на усмотрение прогера А в си он есть? Нету. Так что усматривай уже, не усматривай, а ничего не изменится.

Цитата Астарот @ 12.04.07, 06:10

А что, самодокументируемый код уже заменяет комментарии? Ну, ладно, раз так.

Цитата

Комментарий нужен всего один, рядом с with

И какой будет текст у комментария?

Цитата

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

Для сколь угодно длинного имени можно ссылкой ввести короткий псевдоним.

Цитата archimed7592 @ 11.04.07, 18:03

кстати, а что с namespace'ами в ОПаскале?

У каждого unit'а свое пространство имен и если два модуля содержат сущности с одинаковыми названиями, можно явно сослаться на сущность. Чуть-чуть похоже на import в Java.

Цитата Hryak @ 12.04.07, 06:24

Не удивительно, чт ты путаешься

Цитата Hryak @ 12.04.07, 06:24

И какой будет текст у комментария?

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

Цитата Hryak @ 12.04.07, 06:24

Для сколь угодно длинного имени можно ссылкой ввести короткий псевдоним.

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

Цитата Астарот @ 12.04.07, 06:41

Не удивительно, чт ты путаешься

Я не путаюсь, потому что with не использую и проблем не возникает. Зачем писать комментарий к коду, если и так всё понятно?

Цитата

Цитата Hryak @ 12.04.07, 06:24

Для сколь угодно длинного имени можно ссылкой ввести короткий псевдоним.

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

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

Цитата Hryak @ 11.04.07, 10:16

Ты не понял. Пишешь wc. и получаешь список только имен из WINDOWCLASS. А если через with делать, то получишь список из всех идентификаторов, видимых в данном месте.

Ну, что с Delphi взять-то? Я ж про идею говорю, а не о её кривом воплощении в Delphi. Посмотри ещё раз на такой синтаксис

with (wndclassex)
{
    .cbSize = sizeof wndclassex;
    .style  = CS_DBLCLKS;
    /* ... */
}

Все перечисленные тобой проблемы отпадают.

Цитата Hryak @ 11.04.07, 10:16

Чем меньше область видимости, тем меньше длина имени.

Длина в 5 - 6 символов - вполне нормальное имя для локальной области видимости (кто-то там говорил про самодокументируемый код?). Однако при множественном обращении к членам теряется и удобство написания, и читаемость по сравнению с возможным решением с помощью with.

Цитата Hryak @ 11.04.07, 10:16

А несколькостраничный with - это вообще малочитаемо, имхо.

Цитата Flex Ferrum @ 11.04.07, 10:17

Если нравится писать километровые идентификаторы для локальных переменных

Не надо передёргивать.
И, кстати, вместо идентификатора может быть выражение. Предвижу, что вы тут же скажете про ссылки. Однако ж auto объявления в C++ пока нет, так что тип ссылки придётся указывать явно, а это уже минус, особенно если наименование типа длинное (вспоминаем про итераторы). И вообще, чем меньше имён, тем лучше.

Цитата Hryak @ 11.04.07, 10:16

ПРи чем тут конструктор?

В течение конструирования объект не считается существующим. Или ты опять хотел сказать что-то другое?

Цитата Мяут @ 11.04.07, 12:50

вообще-то не могут являться его челнами не-POD-типы.

Неправда. Структура, унаследованная от какого-либо класса, не является POD типом, но её объекты могут быть членами non-POD объединения.

Цитата Smike @ 11.04.07, 18:32

Но с другой стороны я терпеть не могу сишный case

В C++ case не особо-то и нужен, ибо обычно есть альтернативы получше: полиморфизм или ассоциативные массивы.

Цитата Smike @ 11.04.07, 18:32

отсутствие вложенных функций.

Можно использовать вложенные классы

int main()
{
    struct A {
        static int func()
        {
            /* ... */
        }
    };
}

Менее удобно, но всё же.

Сообщение отредактировано: Dantes - 12.04.07, 07:03