Borland продал подразделение CodeGear компании Embarcadero T

[Mirage]

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

Думаете они это будут осмысливать уже после того как отстегнули 23 лимона?

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

Надеюсь, что нет (ну или очень осторожно), ибо это "слабое место" - единственная причина, почему я на Delphi/FPC (с БД не работаю).

Отчасти и то только со стороны C++ -
...
От .NET народ шарахается как от чумы ( хрень какая-то высосанная из пальца ), на

Тут только один вопрос - откуда Вы о существовании .NET знаете?
Просто такое ощущение от поста, что последние лет 10 Вы не имели связи с миром (реальностью?).

Кстати, кто знает - почему в FPC не хотят добавить множественное наследование ?

Потому что не идиоты.

[Сергей Смирнов]

Думаете они это будут осмысливать уже после того как отстегнули 23 лимона?

Вполне возможно. Тут один пиар чего стоит... я думаю, что аналогичная по эффекту рекламная кампания обошлась бы им чуть ли не в ту же сумму . Кроме того, я уже писал, что врядли их интересует весь "багаж" CodeGear, соответственно надо решать, что делать с "балластом". Может быть уже и решили, но может быть и нет. А может быть, этот "балласт" всё же не дельфи, а приблуды для явы и пхп .

Надеюсь, что нет (ну или очень осторожно), ибо это "слабое место" - единственная причина, почему я на Delphi/FPC (с БД не работаю).

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

[zub]

срок выхода delphi 2008 уже сдвинули... был - first half, стал - Second Half of 2008. http://dn.codegear.com/article/36620
по сабжу нет цензурных слов. готовлюсь морально к переходу на спп

[debi12345]

2. Скрытые поля(не методы!) можно повыносить через протектед проперти. Рядом с фриендом обьявляется класс наследуемый от требуемого, в котором в паблике вкратце прописываются все нужные проперти (перенос из протектед в паблик)

Вам самому такое "решение" ( workaround = изврат ) нравится ? Это добавляет языку стройности?
По мне - нет, почему и всплыло это FRIEND.

[alexs]

Вам самому такое "решение" ( workaround = изврат ) нравится ? Это добавляет языку стройности?

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

[debi12345]

Тот же Мартин просит об FRIEND-фиче неоднократно... А уж он MSE* перетряхивал и перепроектировал не один раз.

[sts]

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

Совершенно с этим согласен, в том смысле что с D1 по D6 был реальный прогресс в языка, IDE и в VCL, D7 можно назвать расширенным обновлением к D6, т.е. всегда были серьезные основания для перехода на новую версию которые перевешивали затраты на корректировку кода и рост результирующего бинарника. D8 пропускаем. И что далее? да ничего! версии 200X только добавляли лишних затрат без отдачи, естествено это касается "клаcсических" задач для дельфи а не всякий маразм типа аппсервера генерирующего HTML по TForm или сдохшей в мучениях корбы.
Далее мат по поводу стратегии борланд убившей дельфи...

[bw]

Это всего-лишь бизнес.

..bw

[vital]

sts

Совершенно с этим согласен, в том смысле что с D1 по D6 был реальный прогресс в языка, IDE и в VCL, D7 можно назвать расширенным обновлением к D6, т.е. всегда были серьезные основания для перехода на новую версию которые перевешивали затраты на корректировку кода и рост результирующего бинарника. D8 пропускаем. И что далее? да ничего! версии 200X только добавляли лишних затрат без отдачи, естествено это касается "клаcсических" задач для дельфи а не всякий маразм типа аппсервера генерирующего HTML по TForm или сдохшей в мучениях корбы.
Далее мат по поводу стратегии борланд убившей дельфи...

Ничем необоснованные мифы. Вы хоть с D2006/2007 сами работали? Или сосед напел?
Новшеств там целый вагон:
http://www.codegear.com/products/delphi ... whats-new/
http://www.interface.ru/home.asp?artId=6763
Вообще продуктивность работы в новой среде на порядок выше - одна отладка чего стОит. D7 теперь смотрится жуткой архаикой.
Добавлю также, что стандартной теперь является одна из версий Fast Memory Manager'а, позволяющая в т.ч. отлавливать утечки памяти. Благодаря этому, кстати, были обнаружены протечки в датасете Алекса:)

P.S. Кстати, теперь ещё есть бесплатная Турба:) С отсутствием каких-либо ограничений на коммерческое использование:)

[*vmr]

В D2006/2007 действительно много нововведений, да.

Добавлю также, что стандартной теперь является одна из версий Fast Memory Manager'а, позволяющая в т.ч. отлавливать утечки памяти.

Вроде ж в D2006/2007 "урезанная" версия FastMM, не позволяющая следить за утечками...
А так респект разработчикам FastMM - реально мощная штука, как по перформенсу так и по отладке

[vital]

В D2006/2007 действительно много нововведений, да.

Добавлю также, что стандартной теперь является одна из версий Fast Memory Manager'а, позволяющая в т.ч. отлавливать утечки памяти.

Вроде ж в D2006/2007 "урезанная" версия FastMM, не позволяющая следить за утечками...
А так респект разработчикам FastMM - реально мощная штука, как по перформенсу так и по отладке

Урезанная, урезанная:) Но утечки ловить позволяет(урезанно, наверное):

Код: Выделить всё

program Project8;

{$APPTYPE CONSOLE}

uses
  Classes, Contnrs;

var
  MyList1, MyList2: TObjectList;
  StrList: TStringList;

begin
  ReportMemoryLeaksOnShutDown:= DebugHook<>0; //работает при выполнении по F9
  MyList1:= TObjectList.Create;
  MyList2:= TObjectList.Create;
  StrList:= TStringList.Create;
end.


Подспорье весьма и весьма неплохое:)))

[alexs]

По хорошему для fcl такую вещь бы сделать. было-бы круто

[vital]

По хорошему для fcl такую вещь бы сделать. было-бы круто

Это, по ходу, надо менеджер памяти фрипаскалевский ковырять. Кстати, кто-нибудь пробовал использовать FastMM с Фри Паскалем? Под Win, понятное дело:))

[*vmr]

Это, по ходу, надо менеджер памяти фрипаскалевский ковырять. Кстати, кто-нибудь пробовал использовать FastMM с Фри Паскалем? Под Win, понятное дело:))

Ну под ФПЦ не пробовал, на насчет виндоувз-онли могу возразить:

Код: Выделить всё

{Some features not currently supported under Kylix}
{$ifdef Linux}
  {$undef FullDebugMode}
  {$undef LogErrorsToFile}
  {$undef LogMemoryLeakDetailToFile}
  {$undef ShareMM}
  {$undef AttemptToUseSharedMM}
  {$undef EnableSharingWithDefaultMM}
  {$undef RequireIDEPresenceForLeakReporting}
  {$undef UseOutputDebugString}
{$endif}

[Sergei I. Gorelkin]

По хорошему для fcl такую вещь бы сделать. было-бы круто

Сделать что, поиск утечек памяти? Он в FPC с самого начала есть, только в отдельном модуле heaptrc. Подключается ключом командной строки -gh.
Зато у Борланда - "революционные нововведения"...

Это, по ходу, надо менеджер памяти фрипаскалевский ковырять. Кстати, кто-нибудь пробовал использовать FastMM с Фри Паскалем? Под Win, понятное дело:))

Фрипаскалевский менеджер памяти как минимум не уступает FastMM. А если учесть где-то в три раза меньший объем исходников и работу на всех платформах, то можно сказать, что превосходит.
По своей архитектуре этот менеджер очень близок к QuickHeap (который был написан специально для тестирования того, насколько быстрым может быть менеджер памяти). Разница состоит в том, что он все же освобождает память (QuickHeap ввиду своего назначения этого не делает) и поддерживает многопоточность.

Многое зависит от модели использования памяти. Например, при загрузке чего-то, когда память только выделяется (освобождаемых фрагментов нет), разницу между всеми тремя менеджерами (Дельфи, FPC и FastMM) практически невозможно заметить. Когда же доходит до выделения/освобождения фрагмента одинакового размера в цикле, то FPC просто рвет Дельфи на британский флаг, и даже немного опережает FastMM.
Кроме того, в многопоточном приложении менеджер памяти FPC входит в критическую секцию только тогда, когда один поток пытается освободить память, выделенную другим потоком (что не есть большинство случаев).