Здравствуйте, Cyberax, Вы писали:

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

Про управление памятью я уже говорил. Отсуствие ЖЦ — это конечно недостаток, но управление памятью в Дельфи отнимало не бьльше чем при пронраммировании на С++. Умные указатели и т.п. — это все костыли.

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

Лямбды там действительно нет. Но есть вложенные методы и замыкания. Дельфи, кстати, один из немногих языков в которых замыкания называются замыканиями.

C>Поэтому как язык особо Дельфи никому и не нужна.

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

C>А "компонентые технологии" обычно нигде кроме простого GUI и не нужны....

Так оно и есть... если добавить одну оговорку — лично тобой.

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

C>И при этом требует кардинального изменения в организации окружения.

Отнюдь.

C>Чего-то сложнее формочек с несколькими таблицами на VB нормально не
C>пишется, так как метод "drag-and-drop контролов на форму" становится
C>неприменим, зато становится необходимой нормаль.

Опять же тобой. VB6- с успехом использовался для создания компонентов в трехзвенке, а об АСП я вообще молчу.

>> 1. Откровенно слабоватый маркетинг связанный с размерами и богатством
>> Борланда.
>> 2. Качество. Я не раз слышал нарекания на качетсво дельфи. МС сейчас
>> вылизывает свои прдукты очень серьезно. И Борланду тоже прийдется
>> очень постараться.

C>3. Отсутствие целевого рынка (VB.NET/C#+WinForms делают те же задачи,
C>что и Дельфи.NET).

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

C>4. Непонятная позиция Borland'а в отношении Дельфи.

Да позиция более чем понятна. Просто пп. 1-2 мешает.

Здравствуйте, c-smile, Вы писали:

CS>А не оставляй ссылки.

Это не серьзно. Главное что даем мне ЖЦ — это снимает с меня заботу об управлении памятью. Ты же предлагаешь мне вернуться обратно в каменный век.

CS>Не надо никакого контроля особого.
CS>Контроль он "денег стоит".

Тогда уж лучше не нужно таких оптимизаций. Не намного медленее будет и с ЖЦ если профиль приложения под него подогнать. Деревья на одну секунуд не создаются. Обычно они после построения продвигаются в 1-2 поколение и каши не просят (на скорость сборки нулевого не влияют).

CS>В Apache для того чтобы удалить весь
CS>пул скопом делается одно простое движение.
CS>Запрос выполнился — страница клиенту отдана — все, можно закрывать.
CS>В PHP вообще никакого GC нет — он не нужен.

И что я выигрываю используя Апач? В дотнете всей этой трахомудии нет, но ASP.Net работает не медлненее JSP под апачем. К тому же ты говоришь об оптимизации фрэймворка. А их пишут более отвественные люди и отлаживают тщетельнее чем прикладной код. Ты же предлагаешь отдать такие опасные оптимизации именно прикладникам. Опять же согласен, что где-то внутри ОС где скорость критична я лекго пошел бы на подобную оптимизацию. Но вот уже в компиляторе я бы предпочел пользоваться автоматикой. Те сотые доли секунды которые нужны на полный ЖЫ никак меня не спасут. А вот время на отладке я точно сэкономлю.

CS>Т.е. наличие пулов — это еще один инструмент.
CS>И как любой интсрумент при неправильном его использовании
CS>может доставить неприятности.

Изивин, но инструмент инструменту рознь. Бывают, например, бриты опасные, а бывают безопасные. Может опасная бреет чуть лучше, но вот почему-то почти все перестали ими пользоваться.

CS>Но опять же за все приходится платить.
CS>Есть задачаи где платежи на code management оправданы и есть прямо противоположные.

Согласен. Только 90% задачь более чем пригодна для решения их управляемыми средсвами. Расплат в основном идет за счет памяти. А ее что-то все больше и больше.

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, FR, Вы писали:

FR>>Еще насчет этих тестов, сильно сомнительные результаты, например тест sum-file benchmark, у них такие результаты:

CS>Ты прав. На самом деле всякого рода бенчмарки это всегда палка о двух концах.
CS>Очень много всяких но. Какой процессор, какая ось и т.д.

CS>Т.е. все очень приблизительно.

Только вряд ли все это может дать разницу в разы или даже на порядки.
Например у них C++ g++ почти в 9 раз медленее чем D (У меня gcc3.2 и D v0.122 дают практически одинаковый результат). Ничем кроме ошибок замера это не объяснить. И таких мест в этих тестах полно.

CS>А ты D компилировал с -release -inline -O ?

да

CS>На моей машине (Pentium4)
CS>D идет "ноздря в ноздрю" с C++
CS>где-то отстает но в основном на уровне
CS>и лучше чем VC++ из VS6

у меня(P3) VC7.1+STLPort4.6 обычно чуть быстрее чем D.

CS>Напомню обсуждение:
CS>http://rsdn.ru/Forum/?mid=1022965

Автор: c-smile
Дата: 12.02.05

да там по ссылкам долго читать

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, IT, Вы писали:

CS>>>Вот по тестам в разбивку:
CS>>>http://shootout.alioth.debian.org/great/index.php?sort=fullcpu

IT>>Я не понял только как делались замеры времени.

VD>Машейничают. Измеряют время работы ЕХЕ-шника, а не чистого кода. Ну, и пишут там, что измеряют подсчет слов, а на деле измеряют скорость чтения файла с диска.

Угу, но даже повторяя все по их методике почему-то у меня d, си и с++ показывают практически одинаковые результаты, тогда как у них разница в разы.

Здравствуйте, FR, Вы писали:

FR>Угу, но даже повторяя все по их методике почему-то у меня d, си и с++ показывают практически одинаковые результаты, тогда как у них разница в разы.

Значит многократно мошейничают.

ЗЫ

На что только не способено человеческое вожделение.

Здравствуйте, VladD2, Вы писали:

VD>К выходу второго фрэймворка нужно будет сделать новых Шустриков и включить туда Ди, Питон и Окамл. Да проверить на вшивость как следует. Вот тогда можно будет что-то утверждать.

Оберон ещё не забудь. Судя по тестам кульный язык.

Здравствуйте, IT, Вы писали:

IT>Оберон ещё не забудь. Судя по тестам кульный язык.

Не. Делать тесты ради одного человека — это уже пребор.

Здравствуйте, L.C.R., Вы писали:

LCR>finally. В случае Дельфи мы пишем:
LCR>

LCR>try
LCR>   res.acquire();
LCR>   obj.explode(random(2)); // рванёт - не рванёт
LCR>finally
LCR>   res.release(); // do not forget!
LCR>end;
LCR>

LCR>В случае C++ мы пишем:
LCR>

LCR>{
LCR>   ResGuard guard(res);
LCR>   obj.explode(random(2));
LCR>   // free your mind and be happy.
LCR>}
LCR>

1) "try finally end" является конструкцией структурного программирования, такая же как все остальные структурные конструкции while, if, case и т.д. и не имеет ни какого отношения к ООП. Язык имеющий ее не обязан быть ОО языком, он должен быть просто структурным. Катить бочку на нее — все равно что катить бочку на структурное программирование. В то время как конструкция автоматического вызова деструктора статического объекта — есть всего лишь специфическое свойство отдельно взятого языка.

2) Не замучаетесь на каждый чих писать все новые и новые аналоги классов ResGuard (лишние сущности)? Использование структурной конструкции finally избавляет от этой лишней писанины и структурирует программу.

Сергей Губанов wrote:

> 1) "try finally end" является конструкцией структурного
> программирования, такая же как все остальные структурные конструкции
> while, if, case и т.д. и не имеет ни какого отношения к ООП.

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

Так что можно сказать, что конструкции типа ScopeGuard — это тоже пример
структурного программирования, причем более удобный чем try..finally.
ООП для реализации ScopeGuard'ов действительно не нужен.

> Язык имеющий ее не обязан быть ОО языком, он должен быть просто
> структурным. Катить бочку на нее — все равно что катить бочку на
> структурное программирование. В то время как конструкция
> автоматического вызова деструктора статического объекта — есть всего
> лишь специфическое свойство отдельно взятого языка.

Так же как и try..finally — специфическое свойство нескольких языков.

> 2) Не замучаетесь на каждый чих писать все новые и новые аналоги
> классов ResGuard (лишние сущности)?

Шаблоны (template'ы) и boost::bind спасут отца советской демократи.

> Использование структурной конструкции finally избавляет от этой лишней
> писанины и структурирует программу.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote

> C>Как язык Дельфи не блещет особыми достижениями, в ней нет нормальных
> C>средств для ручного управления памятью (умные указатели, автоматические
> C>классы и т.п.), нет автоматического управления памятью, нет каких-лиюо
> C>средств метапрограммирования, нет продвинутых средств типа лямбды и
> C>замыканий.
> Про управление памятью я уже говорил. Отсуствие ЖЦ — это конечно
> недостаток, но управление памятью в Дельфи отнимало не бьльше чем при
> пронраммировании на С++.

У кого как, я писал как-то на Дельфи визуальный генератор MSI-файлов (ну
заказали нам очередной велосипед...). В GUIшной части действительно все
было нормально — время жизни компонентов точно ограничено временем жизни
формы, поэтому проблем не было.

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

> Умные указатели и т.п. — это все костыли.

Нет, умные укзатели — это формализация политики владения (и
использования) объекта auto_ptr — эстафетное владение, scoped_ptr —
эксклюзивное владение, shared_ptr — разделяемое владение. Почти любую
программу можно описать в этих терминах, лишь в очень редких случаях
необходимо циклическое владение, которое не описывается нормально на С++.

Кстати, в Дельфи как раз реализована только политика эксклюзивного
владения для компонентов.

> Что касается метапрограммирования. Да его там нет. Но за то там есть
> компоненты, компонентная модель

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

> метаинформация оплностью отсутсвующая в плюсах.

В С++ есть метаинформация, только она доступна только на этапе компиляции.

> C>Поэтому как язык особо Дельфи никому и не нужна.
> На дельфи писали, пишут и еще очень долго будут писать приложения. Во
> всем мире популярность его конечно не так что у плюсов, но у нас
> дельфи более чем поеулярен.

Потому что только им умеют пользоваться учителя в школах и универах, к
сожалению.

> C>А "компонентые технологии" обычно нигде кроме простого GUI и не
> нужны....
> Так оно и есть... если добавить одну оговорку — лично тобой.

Могу пофлеймить на эту тему, если хочешь.

>>> В Делфьи научились обходить проблемы, но наличие ЖЦ дает
>>> дополнительную свободу программисту и делает язык более высокоуровневым.
> C>И при этом требует кардинального изменения в организации окружения.
> Отнюдь.

Не "отнюдь", если GC — нормальный, а не консервативный.

> C>Чего-то сложнее формочек с несколькими таблицами на VB нормально не
> C>пишется, так как метод "drag-and-drop контролов на форму" становится
> C>неприменим, зато становится необходимой нормаль.
> Опять же тобой. VB6 — с успехом использовался для создания компонентов
> в трехзвенке, а об АСП я вообще молчу.

VB6 использовался (да и сейчас используется) для простых
GUI-интерфейсов. В бизнес-логике VB6 я чего-то не встречал.

Кстати, под "сложными интерфейсами" я имею в виду чего-нибудь уровня
интерфейса в MS Office.

> C>3. Отсутствие целевого рынка (VB.NET/C#+WinForms делают те же задачи,
> C>что и Дельфи.NET).
> Старный ты человек. На ранке могут, а вренее должны, соусуществовать
> разные решения. Только одино решение приведет к застою и ушудшению
> ситуации.

Да, но обычно более дешовое и качественное вытесняет со временем другие.
Чего у нас было до .NET?
1. VC6+VB6 = около $1500 (не помню уже точно).
2. Delphi в стандартной редакции = около $300.
При этом объективно Delphi проще VB+VC для многих приложений.
Соответственно, и популярность у Дельфи была немалой.

Сейчас имеем:
1. Eclipse для Java = $0
2. VS Express = $0
3. Delphi 2005, Professional = $1000
И при этом Delphi уже не имеет особых преимуществ перед той же VSE. Что
в этих условиях выберет покупатель?

<http://shop.borland.com/dr/sat4/ec_MAIN.Entry10?V1=663031&amp;PN=1&amp;SP=10023&amp;xid=39696&amp;CID=0&gt;


> C>4. Непонятная позиция Borland'а в отношении Дельфи.
> Да позиция более чем понятна. Просто пп. 1-2 мешает.

Мне не очень понятна, например, в отношении C++Builder'а.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>2) Не замучаетесь на каждый чих писать все новые и новые аналоги классов ResGuard (лишние сущности)? Использование структурной конструкции finally избавляет от этой лишней писанины и структурирует программу.

Ну, если использовать что-то типа: Generic&lt;Programming&gt;: Change the Way You Write Exception-Safe Code — Forever, то не замучаемся -- будет очень похоже на написание функторов для std::for_each, std::transform, ...

Здравствуйте, Cyberax, Вы писали:

C>Как помнится мне, в конструкции структурного программирования входят
C>только циклы и ветвления. Про исключения там нет ничего.

Извините, конечно, но помнить этого не надо — это надо понимать. Естественно, когда структурное программирование только начинало формироваться инструкции finally еще не было. Но мир-то на месте не стоит. Структурное программирование развивается. Finally — появляется как естественное развитие структурного программирования. И кто знает, быть может, в будущем в структурное программирование добавится еще не одна инструкция.

Кстати, finally и исключения хоть и взаимосвязаны по происхождению, но на самом деле могут преспокойно быть отделены друг от друга: finally можно использовать даже тогда, когда нет никаких исключений:

  PROCEDURE Do()
  BEGIN

    ...

    BEGIN
      ...
      IF condition1 THEN f(); RETURN END;
      ...
      IF condition2 THEN g(); RETURN END; 
      ...
    FINALLY
      h()
    END;

    ...

  END Do;

Пример BEGIN-FINALLY-END блока на только что вымышленном мной языке программирования

Сергей Губанов wrote:

> C>Как помнится мне, в конструкции структурного программирования входят
> C>только циклы и ветвления. Про исключения там нет ничего.
> Извините, конечно, но помнить этого не надо — это надо понимать.
> Естественно, когда структурное программирование только начинало
> формироваться инструкции finally еще не было.

Замечательно, потому что под стр. программированием я понимаю то, что
написано у Кнута.

> Но мир-то на месте не стоит. Структурное программирование развивается.
> Finally — появляется как естественное развитие структурного
> программирования.

ScopeGuard'ы — тоже. Да и вообще, забудьте наконец-то про "структурное
программирование" — оно давно уже перестало быть чем-то особенным.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, IT, Вы писали:

IT>>Оберон ещё не забудь. Судя по тестам кульный язык.

VD>Не. Делать тесты ради одного человека — это уже пребор.

Дык, а если тесты для оберонов попросить написать того человека, разьве-ж он откажется...

Здравствуйте, Cyberax, Вы писали:

C>Да и вообще, забудьте наконец-то про "структурное
C>программирование" — оно давно уже перестало быть чем-то особенным.

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>1) "try finally end" является конструкцией структурного программирования, такая же как все остальные структурные конструкции while, if, case и т.д. и не имеет ни какого отношения к ООП. Язык имеющий ее не обязан быть ОО языком, он должен быть просто структурным. Катить бочку на нее — все равно что катить бочку на структурное программирование. В то время как конструкция автоматического вызова деструктора статического объекта — есть всего лишь специфическое свойство отдельно взятого языка.

Тут Киберакс уже ответил про новые аналоги ResGuard. Я же вставлю свои 5 копеек в отношении "try finally end". Что это такое? Это объектно-ориентированный аналог такой штуки, которая называется longjump. Грязный хак в чистом виде!

Разумеется в структурном программировании (которое всеми своими ветвлениями старается отбрыкаться от бедного goto) введение и легализация подобной концепции — это нонсенс. Поэтому лонгджампа нет и у Кнута, и у Дейкстры и у других авторов.

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

Здравствуйте, IT, Вы писали:

IT>

IT>class A
IT>{
IT>  B _b = new B(this);
    
IT>  public A()
IT>  {
IT>  }
IT>}
IT>

IT>Какой в этом смысл я не очень понимаю. Скорее всего чтобы не дать наделать лишних глупостей.

Что интересно, для джавы вполне легальная конструкция:

class B
{
    A a;
    public B(A a) { this.a = a; }
}

class A
{
    B _b = new B(this);
}

Ограничение языка (на которое указал AVK) мне представляется разумным, потому что иначе найдётся перец, который напишет

public class Node
{
    private Node _parent;
    
    public Node(Node parent)
    {
        _parent = parent;
        _parent.method();
    }
    public Node getParent()
    { 
        return _parent;
    }

    public void method()
    {
       // usual actions
    }

}
public RootNode : Node
{
    public RootNode()
    {
        base(this);
    }
[/b]
    public void method()
    {
       // terrible actions
    }
[/b]
}

Хотя этих перцев можно отсеять, введя правило "донт юз производные классы бефо отработают их конструкторы", но это вероятно усложнит компиляторы.

Здравствуйте, Сергей Губанов, Вы писали:

VD>>Не. Делать тесты ради одного человека — это уже пребор.

СГ>Дык, а если тесты для оберонов попросить написать того человека, разьве-ж он откажется...

Если попросить его, то оберон несомненно победит.

Сергей Губанов wrote:

> C>Да и вообще, забудьте наконец-то про "структурное
> C>программирование" — оно давно уже перестало быть чем-то особенным.
> Боюсь что нет, например, в C# есть *goto*, т.е. один из самых
> современных языков программирования имеет средство нарушения
> структурности

И что? В С++ных программах еще и ассемблерные вставки бывают Никто же
палкой не заставляет использовать goto.

ЗЫ: в Java, кстати, goto нет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Боюсь что нет, например, в C# есть goto, т.е. один из самых современных языков программирования имеет средство нарушения структурности
Ну имеет и дальше то что? goto может быть практически незаменим при генерации кода.
Да и в редких случаях его можно довольно красиво использовать значительно упрощая код.
Например

Автор: WolfHound
Дата: 02.12.04

попробуй переписать merge_list без goto и с одной точкой выхода из функции.