Конференция "KOL" » Будет ли работать сайт KolMck.net?
 
  • Dimaxx © (09.11.16 13:53) [20]
    Дело не в этом, это все лирика. Но ясно одно - нужно отказываться от асма полностью, и, желательно, от объектов.
  • DKOL (09.11.16 14:38) [21]

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

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


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

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


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

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


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

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

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

    И немного лирики насчет отказа от объектов в пользу классов:
    1) Просто поменять object -> class - это вряд ли много работы будет.. Хотя уже от привычных List: PStrList/NewStrList надо будет отказаться в пользу List: TStrList/TStrList.Create
    2) Или же полностью менять архитектуру на использование виртуальных методов
  • HelperCode (09.11.16 15:51) [22]
    > А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..

    Смысл в следующем. Если кто-нибудь решит исправить или дополнить версию на Паскале, то кто будет вносить изменения (дополнения) на Ассемблере.
  • Awkward © (09.11.16 16:45) [23]
    Использовал объекты у себя через FPC без KOL,  создаются один раз, никаких утечек. Так что не думаю, что имеет смысл отказываться от объектов.
  • Dimaxx © (09.11.16 17:19) [24]

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

    Проявляется, когда в пошаговом режиме наводишь, допустим, на используемый 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

    Ключевое слово "без".
  • Awkward © (10.11.16 08:47) [25]
    > Ключевое слово "без".
    Я имею в виду, что проблема, если и есть, то в KOL, а не в object как таковых
  • DKOL (10.11.16 08:55) [26]

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


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


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

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


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

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


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


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

    Если затевать какие то глобальные переходы, то нужно это делать поэтапно. Сначала одно, потом другое и т.д..
    Вопрос кто будет это делать? Кому это реально надо? И что Владимир думает поэтому поводу..?
  • Dimaxx © (10.11.16 11:34) [27]

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

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


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

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


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

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


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

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


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

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


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

    Владимира, видимо, давно не волнует судьба КОЛ. Емнип, он его отдал на откуп общественности. Весной не отвечал даже на письма. Тут не появляется давно.
  • DTy (22.11.16 12:03) [28]
    мне нужен КОЛ, но только для моего древнего навигатора. То есть размер поменьше и под 6-ой арм (кросскомпилятор Лазаруса умеет 4-ый). Для остального уже 5 лет есть C#
  • L`Autour (23.11.16 13:32) [29]
    C# - это идеологически антипод KOL.
  • Dimaxx © (27.11.16 17:47) [30]
    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;


    старый участок памяти не освобождается, после выхода из функции переменная станет недоступной и вот вам утечка. Кто там говорил, что все проверял и нет утечек? Выкиньте свои устаревшие инструменты :).
  • Dimaxx © (27.11.16 18:10) [31]
    procedure TBitmap.ClearData;
    begin
     fDetachCanvas( @Self );
     if fHandle <> 0 then
     begin
       DeleteObject( fHandle );
       fHandle := 0;
       fDIBBits := nil; ЗАЧЕМ???
       // Память выделена, а мы ее просто забываем!!! Убрать!
       // Если она еще не освобождена, то в следующих строках будет освобождена.
     end;
     if fDIBBits <> nil then
     begin
       if not fDIBAutoFree then
         GlobalFree( THandle( fDIBBits ) );
       fDIBBits := nil;
     end;
     if fDIBHeader <> nil then
     begin
       FreeMem( fDIBHeader );
       fDIBHeader := nil;
     end;
     fScanLineSize := 0;
     fGetDIBPixels := nil;
     fSetDIBPixels := nil;
     ClearTransImage;
    end;
  • Гость (27.11.16 23:59) [32]
    В который раз...
    Есть архив сайта kolmck.net (не помню, раньше его выкладывал или нет) от 12.01.2014 года.
    Посмотрю еще были еще архивы сайтов Тедди и как мне кажется более поздние архивы kolmck.net.
  • L`Autour (28.11.16 11:13) [33]
    Dimaxx
    По TBitmap.ReleaseHandle:

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

    По TBitmap.ClearData:

    под fDIBBits память выделяется при NewDIBBitmap, при этом fHandle равно 0.
    Если потом присвоить fHandle, то судя по  TBitmap.SetHandle вроде последующая очистка памяти будет уже через fDIBHeader.
  • Dimaxx © (29.11.16 21:08) [34]
    DeleteObject удаляет все связанное с хэндлом. Так что ClearData оправдана - там все верно.
  • An a Student (29.11.16 23:45) [35]
    Читал что не удаляет, а помечает как освобождённое. То есть после DeleteObject оно ещё лежит в памяти неопределённое время.
  • An a Student (29.11.16 23:47) [36]
    Забыл, для тех кто не заметил соседнюю тему (или на случай если она потеряется):

    "Поднято зеркало прежнего сайта по адресу http://kolmck.ru" © Vladimir Kladov
  • L`Autour (30.11.16 06:30) [37]
    Dimaxx
    из KOLBook по TBitmap


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



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


    поэтому и там все верно.
  • L`Autour (30.11.16 06:37) [38]
    сорри за форматирование.
  • RusSun © (30.11.16 19:02) [39]

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

    Доброе время суток.
    Напишите мне или выложите ссылку в этой теме.
    Особенно интересны архивы сайтов Тедди так сейчас их не найти. Спасибо.
 
Конференция "KOL" » Будет ли работать сайт KolMck.net?
Есть новые Нет новых   [85495   +13][b:0.001][p:0.002]