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

> Выяснилось, что объекты создаются дважды(!!)

Интересная штука.. но у меня подозрение, что это происходит только в fpc.
А как воспроизвести? Только в формами\контролами такая штука или достаточно создать простой PStrList их будет два?


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

На самом деле классная штука, объект может лежать просто на стеке... но увы..


> В итоге отладчик ни в одной версии (новее бесплатного Turbo
> Explorer'а не проверял) не работает с ними корректно.

А как проявляется? Просто о некоторых особенностях в курсе, например нельзя юзать default параметры или криво помощник кода отрабатывает, но это не про отладчик..


> Но ясно одно - нужно отказываться от асма полностью, и,
> желательно, от объектов.

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

А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..

И немного лирики насчет отказа от объектов в пользу классов:
1) Просто поменять object -> class - это вряд ли много работы будет.. Хотя уже от привычных List: PStrList/NewStrList надо будет отказаться в пользу List: TStrList/TStrList.Create
2) Или же полностью менять архитектуру на использование виртуальных методов

> А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..

Смысл в следующем. Если кто-нибудь решит исправить или дополнить версию на Паскале, то кто будет вносить изменения (дополнения) на Ассемблере.

Использовал объекты у себя через FPC без KOL,  создаются один раз, никаких утечек. Так что не думаю, что имеет смысл отказываться от объектов.

> А как проявляется?

Проявляется, когда в пошаговом режиме наводишь, допустим, на используемый Form.Width и в подсказке вместо значения появляется либо Illegal value, либо AV (хотя значение там есть и верное). С классами такого нет. Д5-Д7 точно, про турбо не помню - мало юзал.


> или достаточно создать простой PStrList их будет два?

Не проверял. Проверял тока с контролами. Дальше проверять не было желания.


> но кода будет больше

По сравнению с VCL - прибавка мизерная. От VCL приложение пухнет активнее. Если правильно помню, то просто +1 юнит в приложении это уже +8...10кб лишнего кода, помимо кода самого юнита.


> Если есть желание юзать х64 - то тут только PAS_VERSION

В коде много кода на асме без версий на паскале - для 64 бит такой фокус не прокатит.


> Просто поменять object -> class - это вряд ли много работы будет

Ничего не получится. Придется переписывать. В одном тока TControl черт ногу сломит. Если TList еще просто переписать, то TControl просто так не сдастся.


> Хотя уже от привычных List: PStrList/NewStrList

Зачем? Никто не мешает писать:

function NewStrList: TStrList;
begin
 Result:=TStrList.Create; // вместо New
 Result.<параметр>:=<значение>;
end;


> Использовал объекты у себя через FPC без KOL

Ключевое слово "без".

> Ключевое слово "без".
Я имею в виду, что проблема, если и есть, то в KOL, а не в object как таковых

> Form.Width и в подсказке вместо значения появляется либо
> Illegal value, либо AV (хотя значение там есть и верное).
>  С классами такого нет. Д5-Д7 точно, про турбо не помню
> - мало юзал.


Конкретно данный пример отрабатывает в турбе нормально. А вот тот же проперти TStrList.Count показывает бред.. надо смотреть саму переменную fCount. Вообще не сильно удивлюсь если в новых версиях object выпилят полностью..


> По сравнению с VCL - прибавка мизерная. От VCL приложение
> пухнет активнее. Если правильно помню, то просто +1 юнит
> в приложении это уже +8...10кб лишнего кода, помимо кода
> самого юнита.

В том то и дело, что там цепляется sysutils, который тащит еще модули за собой.


> Зачем? Никто не мешает писать:

Так у меня такой же вопрос возникает, а зачем так писать?)
Когда уже перешли на классы и привычное написание будет как раз через "TClass.Create;"


> В коде много кода на асме без версий на паскале - для 64
> бит такой фокус не прокатит.


Когда собирал последний SVN, то насколько помню там компилировалось все в х64.. Да и не замечал, что есть кода чисто на асме без пас версии.

Если затевать какие то глобальные переходы, то нужно это делать поэтапно. Сначала одно, потом другое и т.д..
Вопрос кто будет это делать? Кому это реально надо? И что Владимир думает поэтому поводу..?

> там цепляется sysutils, который тащит еще модули за собой.

Он дает прибавку 40-50кб и ничего лишнего не тащит за собой. Основная масса кода - Classes, Forms, контролы. Вот там тащится все беспорядочно. Один Classes, емнип, таращит код на 200+ кб.


> привычное написание

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


> делать поэтапно

Поэтапно не получится - там все завязано на всем.


> Вопрос кто будет это делать?

Вопрос открытый. Могу я, но мне, к примеру, нафик не нужен линух. Значит я выкину все к нему относящееся. Мне не нужна совместимость с тонной разных версий (меня интересует D5-D7 и FPC) - соответственно тоже выкину. Всяческие нагромождения под CommandActions и USE_FLAG также полетят в помойку. И т.д. и т.п.


> Кому это реально надо?

Вопрос также открытый. А надо ли это вообще? Меня не парит в D7 писать на VCL - размер exe там приемлемый. А вот если понадобится написать что-то коммерческое - у FPC exe жирнючий как свинья, но за полным отсутствием аналогов сойдет. Explorer - обрезок (сторонние компоненты поставить можно, но только в подписанный сигнатурой дефолтный пакет). Дельфи не подходит из-за отсутствия лицензии.


> И что Владимир думает поэтому поводу

Владимира, видимо, давно не волнует судьба КОЛ. Емнип, он его отдал на откуп общественности. Весной не отвечал даже на письма. Тут не появляется давно.

мне нужен КОЛ, но только для моего древнего навигатора. То есть размер поменьше и под 6-ой арм (кросскомпилятор Лазаруса умеет 4-ый). Для остального уже 5 лет есть C#

C# - это идеологически антипод KOL.

function TBitmap.ReleaseHandle: HBitmap;
var OldBits: Pointer;
begin
 HandleType := bmDIB;
 Result := GetHandle;
 if Result = 0 then Exit; // only when bitmap is empty
 if fDIBAutoFree then
 begin
   OldBits := fDIBBits;
   fDIBBits := Pointer( GlobalAlloc( GMEM_FIXED {or GMEM_ZEROINIT}, fDIBSize ) );
   Move( OldBits^, fDIBBits^, fDIBSize );
   GlobalFree(THandle(OldBits));  <-- ДОБАВИТЬ
   fDIBAutoFree := FALSE;
 end;
 fHandle := 0;
end;

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

В который раз...
Есть архив сайта kolmck.net (не помню, раньше его выкладывал или нет) от 12.01.2014 года.
Посмотрю еще были еще архивы сайтов Тедди и как мне кажется более поздние архивы kolmck.net.

Dimaxx
По TBitmap.ReleaseHandle:

Там развязывание объектов (без удаления отвязываемого). DDB, при обнулении (отвязки) fHandle превращается в DIB с независимым fDIBBits (копией ранее привязанного объекта). А старый участок памяти остается с отвязанным объектом и удалеятся при необходимости вместе с ним.

По TBitmap.ClearData:

под fDIBBits память выделяется при NewDIBBitmap, при этом fHandle равно 0.
Если потом присвоить fHandle, то судя по  TBitmap.SetHandle вроде последующая очистка памяти будет уже через fDIBHeader.

DeleteObject удаляет все связанное с хэндлом. Так что ClearData оправдана - там все верно.

Забыл, для тех кто не заметил соседнюю тему (или на случай если она потеряется):

"Поднято зеркало прежнего сайта по адресу http://kolmck.ru" © Vladimir Kladov

Dimaxx
из KOLBook по TBitmap


числе, для изображений, зависящих от устройства);
Handle - дескриптор системного графического объекта типа hBitmap. Независимые от устройства изображения не нуждаются в наличии такого дескриптора, и вообще всю работу потенциально могут выполнять без выделения такого дескриптора. Однако, если идет работа с изображением через канву, дескриптор для изображения создается автоматически. Допускается присваивать этому свойству в качестве значения дескриптор битового изображения (типа hBitmap), полученный любым способом, в том числе из API-функций - при этом прежнее изображение теряется и замещается присвоенным, а объект становится "владельцем" присвоенного дескриптора (т.е. дескриптор будет автоматически разрушаться вместе с объектом в его деструкторе);



> ReleaseHandle - отделяет дескриптор от изображения, освобождая
> его (независимое от устройства изображение продолжает при
> этом существовать в памяти, и при необходимости выполнения
> каких-либо операций, требующих наличия дескриптора, тот
> будет выделен снова). Отделенный в результате такой операции
> дескриптор освобождается в том смысле, что с этого момента
> он не известен (и не интересен) объекту TBitmap. И тогда
> уже вызывающий код отвечает за его дальнейшую судьбу. Например,
>  он может быть удален API-функцией DeleteObject, или использован
> каким-либо еще способом. Важно лишь обеспечить отсутствие
> утечек таких ресурсов: все выделенные ресурсы GDI, к которым
> относится и hBitmap, должны быть обязательно удалены, когда
> надобность в них отпадает;


поэтому и там все верно.

сорри за форматирование.

> В который раз...
> Есть архив сайта kolmck.net (не помню, раньше его выкладывал
> или нет) от 12.01.2014 года.
> Посмотрю еще были еще архивы сайтов Тедди и как мне кажется
> более поздние архивы kolmck.net.

Доброе время суток.
Напишите мне или выложите ссылку в этой теме.
Особенно интересны архивы сайтов Тедди так сейчас их не найти. Спасибо.