» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

kaz_av

Цитата:

В смысле, между ARC и GC?

Да, не вижу особой разницы. Будь это даже удаление записей в базе по ID на которых каунтер или подсчитываемое хранимое поле = 0. Разницы особой нет.


Цитата:

Я пишу на дельфях уже 16 лет

Похвально


Цитата:

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

AV указывающего на мусор, так понимаю ошибки памяти, я никогда не видел - там свой собственный экзепшен (и вылавливал я их легко собственным менеджером памяти, могу запостить - удобно мемори лики ловить). Но "уже 16 лет", тута я сильно засомневался. Если компилим проект с Debug DCU -optimization, до всех исходников указан путь, то любой AV, совершенно любой, тут же покажет где он случился, а далее - дело 10-и минут. Если 16 лет, то Вы должны знать про AV всё.


Цитата:

или твоя софтина не умеет восстанавливать иконку после падения эксплорера?

Когда падает Explorer - это визуально заметно, этого не было.


Цитата:

GC не может убить объект на который есть ссылки. Может у твоего юзера винда скрыла иконку,

Так если бы это было один раз, так это было постоянно. Посмотрите в ILSpy или ILdasm, там она (иконка), как раз с GC общается по поводу того что у неё внутри системный ресурс.


Добавлено:

Цитата:

Может у твоего юзера винда скрыла иконку,

Скрывать - не скрывала. А вот чтобы убить, надо знать имя процесса и уметь вычислить именно её хэндл в систрее, в чём я сильно сомневаюсь, что кто-то бы заморочился. Убивалась именно моя иконка постоянно, и думаю что GC успевал понять что системный ресурс ссылками не одолеть, но не успевал её пометить как не убиваемую, - при старте системы процессорного времени для дотнета маловато, так что и процессы GC рубятся. Запускали после загрузки - всегда иконка есть.

xpin2013

Цитата:

AV указывающего на мусор, так понимаю ошибки памяти, я никогда не видел

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


Цитата:

Так если бы это было один раз, так это было постоянно.

GC не может убить объект на который имеются ссылки. Это аксиома.

Цитата:

мой собственнй код, который я пишу и о котором знаю всё до самой последней мелочи

Интересно было бы посмотреть.

Цитата:

При порче стека

Цитата:

дважды финализировал интерфейсную переменную

На сколько знаю в стеке только ссылка на интерфейс, а счётчик интерфейса явно за рамками стека. Или мы о других интерфейсах? Что такое интерфейсная переменная?

Цитата:

Я на D2010 попадал с ошибкой компилятора, который при определенных условиях

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

Цитата:

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

Так как Вы встретились с проблемой впервые, то потратили много времени, с аналогичной проблемой в чужом коде теперь Вы разберётесь гораздо быстрее.

Цитата:

дважды финализировал

При финализации, все ссылки заполняются nil, так что хоть 10 финализаций, все пройдут успешно, интерфейсы же вызывают деструктор памяти объекта, но это не есть финализация, это _Release.

kaz_av

Цитата:

Цитата:
Покажи мне пример, когда, проблема фрагментации стала для натива стала критичной.

Гуглиться на раз.

там чел коммитит 6-7 блоков по 380 мегабайт, это идет в обход MM. А потом освобождает.
В 32-битном режиме!
идиот..

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

Он сам виноват. Не такая и проблема: следить чтобы 6-7 блоков не фрагментировались. Это и ежу понятно.

У тебя все примеры такие дурацкие??

Цитата:

Что работает быстрее: последовательный просмотр памяти или прыжки по разным участкам? Так вот первый сценарий это GC, второй - подсчет ссылок.

В плане кэша, ведь ты говоришь о нем: если участок больше 64 байт, линейки кеша, то разницы нет.
Конечно есть префетч, и накладные расходы на стороне RAM для пересылки и вычисления адреса: там, действительно, несколько последовательных чтений или записей выгоднее (DRAM burst).
Но это не поможет : выигрыш невелик по сравнению с ценой кэшевого промаха.

Другими словами, рандомные адреса, не влияют на обработку длинных в массивах(так как там все последовательно), ни на локальные переменные(то все последовательно).

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

Что же до остального, типа строк, то не даст последовательное размещение особых преимуществ, если объекты больше 64-байт.
Ручное управление памятью тоже не серебряная пуля, но там намного больше контроля. Больше возможностей.

А крохотные объекты обходятся дорого везде: причем GC с ними работает хуже: приходится вычислять достижимость каждого из целой тучи.


Цитата:

А чего не на 4 или 8?

а того, что при вычислении размера буфера, программисты чаще всего ошибаются на 1 элемент, как в том случае, который ты упоминал.
Опыт, батенька

Цитата:

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

мы далее рассмотрим время GC, только поскольку ты использовал JVM в своем примере, то о ней и будем говорить.


Цитата:

Кроме того, что не пригоден для использования в продакшене? Ничем.

Кто сказал? Форк ScaleMM включен даже в дистрибуцию mORMot. Он вполне юзабелен.


Цитата:

Сравнивать iOS и Android, для поисков истины в споре ARC vs. GC, вообще глупо т.к. iOS является оптимизированным решением для железа единственного вендора, а Android универсальная ОС работающая на диком зоопарке разношерстного говна. У меня аппарат далеко не флагман, скорее середнячек. .

iOs приложения тоже вынуждены работать с разными версиями iPhone, которые различаются железом.


Цитата:

Памяти там 2Gb, но свободной почти гигабайт

вот тебе и ответ. GC может быть хорош, когда памяти вдвое более требуемой.
в покое есть половина, а как начинается нагрузка, GC забирает эту память своим оверхедом.
---------
теперь по примеру.
У меня нет оксиджена, да и вообще писать на нем, таргетируя под JVM, -- имхо извращение, так что я написал аналогичный код на жабе.
Прежде всего скажу, что в твоем коде в итерации забирает не более 30 мегабайт=(12букв*2*10+48(размер объекта) )*100'000. Так не пойдет. Нужно создать близкую к предельной нагрузку.
Второе, нужно условиться, сколько же памяти мы разрешаем JVM. Как раз для того, чтобы рассчитать нагрузку.

И третье, код , который ты привел на оксиджене, ужасен. Ну зачем пересоздавать StringBuilder? Это замедляет код почти в два раза! За такое нужно увольнять с формулировкой "нахер".

JVM, которую я использовал

Код:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode, sharing)

xpin2013

Цитата:

Интересно было бы посмотреть.

Там нечего смотреть, это был элементарный энумератор реализованый в виде записи с единственным полем интерфейсного типа. Ошибка была в невкорректной кодогенерации при возвращении этого энумератора функцией GetEnumerator. Я, когда выяснил причину ошибки, не стал писать в QC т.к. на XE она уже не воспроизводилась, а старые версии абракадабра не правит.


Цитата:

На сколько знаю в стеке только ссылка на интерфейс, а счётчик интерфейса явно за рамками стека. Или мы о других интерфейсах? Что такое интерфейсная переменная?

Порча стэка и двойная финализация это были разные примеры.


Цитата:

Компилятор ошибаться не может

Ты такие глупости больше никому не рассказывай, хорошо?


Цитата:

с аналогичной проблемой в чужом коде теперь Вы разберётесь гораздо быстрее.

Проблема была не в коде, он был корректен, ошибка была в кодогенерации.

AlekXL

Цитата:

У тебя все примеры такие дурацкие??

Ты убедился, что проблема фрагментации памяти не надумана? Вот и ладушки.


Цитата:

Другими словами, рандомные адреса, не влияют на обработку длинных в массивах(так как там все последовательно), ни на локальные переменные(то все последовательно).

Последовательно у тебя расположены ссылки, а счетчики находятся где? Вот-вот... В объектах, которые лежать могут где угодно.


Цитата:

программисты чаще всего ошибаются на 1 элемент, как в том случае, который ты упоминал.
Опыт, батенька

Детский сад какой-то. А элемент массива не может быть 32 или 64 байта, нет?


Цитата:

Кто сказал?

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


Цитата:

iOs приложения тоже вынуждены работать с разными версиями iPhone, которые различаются железом.

Только iOS пилиться именно под это конкретное железо, а ведроид работает вообще на любой ноунеймовой китайщине. Разница немного очевидна, не считаешь?


Цитата:

вот тебе и ответ. GC может быть хорош, когда памяти вдвое более требуемой.

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


Цитата:

Второе, нужно условиться, сколько же памяти мы разрешаем JVM

Это с чего вдруг? Никаких разговоров об ограничении небыло.


Цитата:

код который ты привел на оксиджене, ужасен.

Я на красоту не претендовал. Ты хотел пример, я тебе его дал.


Цитата:

---------
теперь по примеру.

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

kaz_av

Цитата:

Ошибка была в невкорректной кодогенерации при возвращении этого энумератора функцией GetEnumerator.

Цитата:

Цитата:
>Компилятор ошибаться не может
Ты такие глупости больше никому не рассказывай, хорошо?

Компилятор ошибаться не может - это Вы ошибаетесь когда не берёте на себя ответственность за использование только что появившихся новинок языка, компонентов, алгоритмов, технологий. Это касается всего, компилятор тут ни чем не лучше он умеет только то чему успел научиться. Я использую новинки строго с изучением CPU. Иначе не пойму.
Компилятор ошибаться не может - Это не глупости это истина, когда ты начинаешь использовать его как инструмент. Ещё раз говорю интересно было бы посмотреть Ваш код, так как я не смог написать ошибочные GetEnumerator для d2010. Тут компилятор не ошибается, он только вставляет то' чему его недавно научили. Енумераторы так же как inline были бажными вплоть до XE2. Это неизвестно только Вам. Дело даже не в бажности кода. У моего товарища стояли сторонние расширения для разрисовки редактора кода и сама среда разработки падала - так как плагины разрисовки не знали енумераторы, либо ToolsAPI связанный с ними. я обернул их в добровольную директиву, а директиву запретил по дефолту. Это мне позволило сформировать демки удобоваримые для всех версий.

Ещё раз говорю интересно было бы посмотреть Ваш код пусть даже в ПМ. Очень люблю по изучать баги Delphi, они их фиксят по 300 штук от версии к версии, а те снова появляются.

Добавлено:

Цитата:

Ещё раз говорю интересно было бы посмотреть Ваш код

В замен могу предложить посмотреть мою ADH (Automatic Date's in Header and source code). Это дизайн там пакетик без компонентов, ничего лишнего. Совместимость D6-XE7 (исключение D7, не удалось победить). Что он делает? - Вставляет имя исходника, дату, автора в хидер комментария. Вставляет время в Double и TTimeStamp формате в исходник. Происходит это при нажатии Ctrl+S в Delphi. Вставка идёт не в файл, а прямо в редактор перед сохранением. Вот примерчик:


Код: [no]{*******************************************************}
{ Project }
{ Original Code: $Id: 123.pas $ }
{ Modified: $Date: 2015/01/07 14:44:44 $autor }
{*******************************************************}
...
const
sDate_123 = 42011.56789XXXXX;
[/no]

Цитата:

Если GC не будет хватать памяти, ведроид тупо скинет в кэш фоновые приложения. Т.е. для пользователя вообще не имеет значения сколько свободной памяти доступно на устройстве т.к. для работы активного приложения она есть всегда.

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

SuPriTo, аппаратное решение софтовых проблем - обычно самое простое и дешевое
ASUS ZenFone 2 - первый в мире смартфон с 4 ГБ ОЗУ стоимостью $199

landy
1. XE не поддерживает процессоры Intel под андроид. Для меня это важно, в планах софтину писать под андроид для личного пользования.
2. Этот аппарат уже не такой дешевый в рублях из-за курса.
3. Мой текущий аппарат меня устраивает. Если что на подхвате планшет на винде.
4. Я написал предыдущее сообщение, чтобы обозначить проблему с памятью.

xpin2013

Цитата:

Компилятор ошибаться не может - это Вы ошибаетесь когда не берёте на себя ответственность за использование только что появившихся новинок языка

Цитата:

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

OMG.

SuPriTo

Цитата:

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

Так он тебе не про ОЗУ, пишет, а про внутреннюю память. Разные же вещи.

kaz_av

Цитата:

OMG.

Ладно, считаем за отмазку. Но в свете отмазки Ваши заявления о преимуществах GC тоже OMG, так как ещё до того как я начал просить, за подозревал, что пример, как Вы долго искали ошибку - выдуманный. Вы этим примером пытались опровергнуть моё заявление:

Цитата:

Добавлено:
Цитата:
>Да, он очень быстро падает.
У дровосеков одной и той же квалификации - реже падает. Там гораздо больше экзепшенов прописано - труднее заблудиться в вариациях на тему. (xpin)

Цитата:

Цитата:
>труднее заблудиться в вариациях на тему.
AV указывающий на мусор мало чем тебе поможет, а это очень распространенная ситуация. (kaz_av)

Цитата:

Я её вылавливал несколько часов. И это мой собственнй код, который я пишу и о котором знаю всё до самой последней мелочи. (kaz_av)

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

Зы:
OMG

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

kaz_av
Я же сказал, - Вы отмазались, бог с Вами, зачем продолжать?
Не в святости калькулятора я убеждён, а в том что ошибки надо искать в себе, а не в бездушных творениях. А коли виновны не Вы, так приведите доказательство, чего стесняться то?

Добавлено:
Да наконец обидно, я тут хук IUnknown интерфейсов Delphi ToolsAPI выкладываю, чтобы показаться интересным собеседником, оказывается я недалёкий человек. А Вы хоть знаете сколь тернистый путь перехватить BorlandIDEServices, отдать вместо него свой IModuleServices, отдать свои IModule, добраться до юникодного редактора, потом вернуть все счётчики интерфейсов на место и проделать это же во всех версиях Delphi. Уж не в святости компилятора я уверен, а в безалаберности разработчиков IDE делфи и их не понимании идеологии IUnknown - то есть об интерфейсе мы не должны знать ничего.

xpin2013

Цитата:

Не в святости калькулятора я убеждён, а в том что ошибки надо искать в себе, а не в бездушных творениях

Код этот (библиотека большая) писался под версии 2006-по самую последнюю, которой тогда была XE. Писался на 2006, проверялся на 2009 и XE. Когда начал делать полную проверку - а библиотека обложена тестами вдоль и поперек - на 2010 обнаружился AV, который не воспроизводился ни на одной другой версии. Поиски показали, что имеется проблема в кодогенераторе, который дважды финализирует интерфейс. Т.к. смысла постить баг в QC небыло - на XE он уже не воспроизводился - был найден воркараунд и о проблеме благополучно забыли.


Цитата:

А коли виновны не Вы, так приведите доказательство, чего стесняться то?

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


Цитата:

А Вы хоть знаете сколь тернистый путь...

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

kaz_av

Цитата:

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

Для меня никогда ничего полезнее не было, чем забраться под самую кожу Delphi, иметь над ней абсолютную власть, взломать её не взламывая, покорить её в самое сердце (я считаю var BorlandIDEServices сердцем или сердцевиной как хотите). Я публиковал только замену дат, но я перехватывал хинты редактора, генерил их самостоятельно, много чего, в общем проверял возможности делать с ней что угодно. Так что неправильно предъявлять авторам EhLib-ов, типа "что могут ваши демонстрашные exe - что полезного в этих готовых проектах"?

Однако я же заметил, а Все пропустили:

Цитата:

xpin2013
Кстати, кто не в курсе, то напоминаю - тип TDataTime легко конвертируется в Double. По сути это один и тот же тип, поддерживающий ту же арифметику на уровне процессора. Так вот прикол - обратите внимание на первую цифру перед точкой.
'2014/12/31 11:42:28' = 42004.4878240741
'2015/01/01 13:34:36' = 42005.5656944444
Так понимаю через 10 дней будет 42014 - 42015, может перенесём Новый Год?

42014 - это 10.01.2015
42015 - это 11.01.2015
Очень редчайшее совпадение. Так
52042 - это 25.06.2042 - явно под новый год не катит, хотя прошло уже 27 лет
62069 - это 10.11.2069 - тоже не новый год. и так далее.

А вот с 10.01.2015 по 11.01.2015 будет самый что нинаесть Бинарный Новый Год! Всех поздравляю заранее, не пропустите. Дату можно проверить следующим кодом:

Showmessage(DateToStr(42014.0))



Добавлено:
зы
Да кстати что может быть полезного, что я заметил редчайшее совпадение в компьютерной индустрии, которое не предвидится в ближайшие 50 лет, которые проживут компьютеры. Что полезного например в воздушных шариках и мыльных пузырях ? Может быть только радость от ещё одного праздника. Всем радости и веселья!!!

Кратко о времени:

Timestamp к нам пришёл из UNIX. Он занимает 4 байта, 1 равна секунде, отсчёт идёт 1970 года. В FFFF:FFFF влазит около 138 лет.
TTimestamp в Delphi это 8 байт:
TTimeStamp = record
Time: Integer; { Number of milliseconds since midnight } //4 byte
Date: Integer; { One plus number of days since 1/1/0001 } //4 byte
end;
Так что его мы пока не отмечаем, есть ещё TSQLTimespamp (вроде около 16ти байт).
DateTime стандартный у всех, однако что касается баз данных.
В FireBird (у меня 2.5.0.26074) типа Datetime нет, есть Date и Time отдельно и есть Timestamp.
В MSSQL есть Datetime, но есть ещё и Datetime2 - более точное время с более широким диапазоном.
В Delphi 2010 появилось поле TSQLTimeStampOffsetField, выглядит оно как время плюс смещение по Гринвичу - 01.01.2011 11:22:05 +03:00.
В FAT32 время хранилось в 4х байтах, подозреваю, что это Timestamp, но в документациях пишут что это "the OS time stamp", в чём разница не поясняют. Про DOS "the OS time stamp" так же известно, что он хранится в ZIP файле и при разархивировании на NTFS из-за округлений для преобразования набегает 2 секунды. Значит, это не совсем Timestamp как у UNIX.

Из всех конкурентов более по душе Datetime (IMHO).

xpin2013

Цитата:

Так что неправильно предъявлять авторам EhLib-ов, типа "что могут ваши демонстрашные exe - что полезного в этих готовых проектах"?

С "EhLib'ами", как раз, всё понятно. А вот полезность хрени вставляющей дату в исходник весьма сомнительна. Особенно если учесть, что сделать это можно менее черезжопным способом - используя pre-build events, которые будут работать даже при сборке из командной строки.

kaz_av
1) Естественно, но это же обман. Мы запоминаем дату, вставляем в файл, потом восстанавливаем. То есть дата исходника одна, а дата изменения файла другая, какая из них логичнее?
2) pre-build events. Ну да хорошо, но он вставит дату только в тех каталогах которые ему настроят, он должен запоминать даты которые были до этого, чтобы быть эргономичнее а не перезаписывать всегда все файлы настроенных каталогов. Он ничем не поможет если я нахожусь в проекте EXE, открываю файл библиотеки package, исправляю там ошибку, и забываю про пакет. EXE будет компилиться с неверной датой в окне About. Тут я обязан прописывать каталоги, помнить кучу нюансов, что обязательно нужен билд.
3) pre-build events. Их в Delphi6 не было, но можно было назначить INotificationModue ToolsAPI. Чтобы сделать это Рей Лишнер (секреты Delphi2) предлагал класть на такую форму свой компонент, который при создании в Design-Time вешает нотификатор, но это не касается тех юнитов которые не имеют форму. Задача была одна - создать свой объект при создании любой закладки любого модуля. Стандартных способов ToolsAPI сделать такое не было даже в d2006. Хотя не то что недокументированным способом, отыскать его изучая ToolsAPI.pas практически невозможно, но GExpert умудряются встраивать свой тулбар в редактор, однако это опять же видимые компоненты как у Рея Лишнера.
4) EhLib понятен так как он уравнивает программиста со стажем 1 год с программистом со стажем 16 лет. Но должна же быть какая то инфраструктурная этика. EhLib это один инструмент, а технология позволяющая заменить любой внутренний интерфейс самой Delphi это другой инструмент, он для высшей касты как бы проще сказать. Сделать такой инструмент, свернуть горы, добраться до золотого берега, ради чего? Конечно же чтобы поправить циферку у даты немного.
5) Что он мне дал? Разработка таких инструментов как GExpert для меня стала в 100 раз проще, то что я накручивал, я никому не даю. Код приобретал почти абсолютную независимость от версий Delphi. По технологии ничего не менялось с 2006 го года. Только благодаря ему я узнал, что внутри Delphi существуют препоны на объявленный ToolsAPI, то есть если в хидере написаны определённые последовательности символов, то объявленный интерфейс для чтения исходника останавливается на них и ничего больше не возвращает. Приходилось схитрить. Мне открылся особенный мир не доступный тем кто не писал GExpert или подобный проект.

В итоге - мой инструментик весьма простенький 3 pas файлика, одно отличие - Вы редактируете не компонент а исходник. Конкретно Вас kaz_av, я не призываю писать инструменты ToolsAPI, но про pre-builds не пишите пожалуйста, я рассматривал и такие варианты, но все они были ужасны, гораздо ужаснее чем Ctrl+S.


Цитата:

А вот полезность хрени вставляющей дату в исходник весьма сомнительна.

Я вот сравнительно уже стар. У нас программисты отмечают свои версии последней цифрой билда. Я с трудом понимаю как они запоминают что было в 124 а что было в 136 билде. Но они же это для чего-то делают, типа мне сказали ошибку я спросил билд и понял что ошибка была исправлена позже. Я вот хочу посмотреть на них когда 2.9.5.124 сменится 3.0.0.136, потом 3.0.1.. 3.0.15, 3.1.0..3.1.4, 3.2.0 и так далее. Я уже обычно не помню чем отличается 3.1 от 3.1.3. Когда мне говорят вместо версии дату моего исходника, который я записывал и смотрел чтобы там в датах не было цифры 666, я конечно сразу вспоминаю, ага это до, а это после. То есть для меня это без сомнений полезная хрень... Закроем.

Я напоминаю - Вы же отмазались. То что:


Цитата:

Поиски показали, что имеется проблема в кодогенераторе, который дважды финализирует интерфейс. Т.к. смысла постить баг в QC не было - на XE он уже не воспроизводился - был найден воркараунд и о проблеме благополучно забыли.
И вот теперь, спустя несколько лет, ты предлагаешь мне привести для тебя воспроизводимый пример? А ты понимаешь, что баг может элементарно не воспроизвестись на голом проекте? А понимаешь, что спустя такое количество времени, я могу просто не вспомнить всех деталей?

Это никак не вяжется с Вашим же утверждением о том, что такие случаи сплошь и рядом и они происходят чаще чем в средах которые используют GC. Вы же сказали - случай распространённый, я Вас за язык не тянул. Теперь Вы боитесь что мол на голом проекте кодогенератор текст исходника поймёт по другому, чем тот же текст но не на голом проекте, тут что-то у меня вообще не укладывается. Все Ваши объекты не на голом проекте появляются только после того как кодогенератор (win32/win64) отработает и выдаст программу, как они у Вас связаны? Это же не дотнет! Просто приходится наблюдать много мути, ничего доказывающего, что Ваш случай по Вашим словам распространённый. В каком месте?


Код:
SUPPORTS_INLINE Compiler supports the inline directive (D9+/FPC)
SUPPORTS_FOR_IN Compiler supports for in loops (D9+)
SUPPORTS_GENERICS Compiler supports generic implementations (D11.NET, D12+)

kaz_av

Цитата:

Ты убедился, что
Цитата: Цитата:
Это 5 процентов овехеда -- чудовищное замедление?

Из ничего - не то слово.

проблема фрагментации памяти не надумана? Вот и ладушки.

xpin2013
Я весь твой поток сознания комментировать не осилю, потому выборочно:

Цитата:

Естественно, но это же обман. Мы запоминаем дату, вставляем в файл, потом восстанавливаем. То есть дата исходника одна, а дата изменения файла другая, какая из них логичнее?

Пишешь в своем исходнике {$I blah_blah_last_modified_datetime.inc}, настраиваешь событие на генерацию соответствующего файла. Всё.


Цитата:

pre-build events. Их в Delphi6 не было

Кто в 2015 использует D6 тот сам себе злобный буратино. Некрофилы должны страдать.


Цитата:

Я с трудом понимаю как они запоминают что было в 124 а что было в 136 билде.

Им VCS помогает.


Цитата:

Это никак не вяжется с Вашим же утверждением о том, что такие случаи сплошь и рядом и они происходят чаще чем в средах которые используют GC

Я тебе уже говорил, но повторю, и надеюсь, последний раз: проблема с затиранием стека и описанный случай неверной кодогенерации это разные ситации. Так вот слова о частой проблеме относятся к первой ситуации, а вторая была приведена, как демонстрация, когда даже в собственном коде ошибку найти крайнне не просто, особенно если учесть, что её там нет, тогда как про затирание стека разговор был в контексте использования стороннего кода.


Цитата:

А Вы, в 2005 появились енумераторы в 2006 их используете и жалуетесь на распространённость недопонимания Вас компилятором

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

kaz_av

Цитата:

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

А он там не рассказал, чего они не взяли нативные плюсы?

Обычная мантра: C++ сложен, нужна огромная команда, "жесточайшая" дисциплина, а критичное по производительности ядро -- лишь небольшая часть продукта: обвязку легче делать на Java.

Про C++ во многом правда, но Delphi они даже не рассматривали, вероятно. Ибо не владели.


Цитата:

А о том, что GC не требователен к количеству памяти никто не говорил.

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

AlekXL

Цитата:

..при двукратном превосходстве ресурсов

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

Добавлено:

Цитата:

Обычная мантра: C++ сложен, нужна огромная команда, "жесточайшая" дисциплина

Т.е. когда он говорит о переписывании GC, он умудренный опытом джавист. А когда говорит о проблеме с нативом то это мантра

52042 - это 25.06.2042 - не новый год!
62069 - это 10.11.2069 - не новый год!
72097 - это 22.05.2097 - не новый год!
82124 - это 04.11.2124 - не новый год!
92152 - это 19.04.2152 - не новый год!
102179 - это 02.10.2179 - не новый год!
поздравляю, начиная с нашего дня мы перешли рубеж Timestamp (~138 лет)
112207 - это 18.03.2207 - не новый год!
122234 - это 30.08.2234 - не новый год!
прошло более двух столетий, такой же случай не повторился.
132262 - это 12.02.2262 - не новый год!
142289 - это 27.07.2289 - не новый год!
152317 - это 10.01.2317 - не новый год!

Такого же совпадения как с 10-го по 11-ое не предвидится ближайшие 300 лет. Программу расчёта можете написать сами, но цифра 300 уже поражает воображение.

У кого будут предложения как назвать этот Новый Год. Я пока называю бинарный - туго у меня с воображением. Как будет правильнее?

Цитата:

Вот это и проблема, ты распространяешь ложь

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

kaz_av

Цитата:

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

"... дам памяти" и ядро процессора, не забывай.
Угу, если работа маленькая и нересурсоемкая, то конечно. Из 2 секунд на дельфи, ты выиграешь 1, -- может быть.
Выиграешь в скорости там, где скорость не важна.

А на сложном ресурсоемком проекте -- проиграешь во всем : и в производительности, и в User Exprerience.

Java -- зачетный инструмент для мелкотравчатого девелопмента. Но не для сложных вычислений.


Цитата:

Т.е. когда он говорит о переписывании GC, он умудренный опытом джавист. А когда говорит о проблеме с нативом то это мантра

так он джавист, а не нативщик. Он умудрен в своей джаве, но боязлив, когда дело доходит до натива, тем более Delphi.
Он полон решимости, борясь с языком, выстроить свой образ Delphi на JVM, поскольку первообраз обладает "фатальным недостатком".


Цитата:

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

ну прости, я то думал, что сравнение будет честным.
Я думал о тебе лучше, чем следовало, хотя меня и предупреждали.

Цитата:

Я показал, как жаба таки рвет дельфу (и где тут ложь?), а ты написать быстрый код ниасилил.

твой изначальный код медленнее моего, на Delphi, за счет пересоздающихся StringBuilder'ов


Цитата:

У тебя хватило ума лишь на то чтобы зарезать жабе память

Что значить "зарезать"?
Всегда есть потолок.
Я ограничил память и Delphi приложению, в равном объеме, и показал, что в этом случае java сливает.

Цитата:

Да ты ваще герой.

на личности переходишь?
Повторюсь:
kaz_av, ты распространяешь ложь, говоря
1) GC потребляет доли процента процессорного времени, тогда как легко может 50 или более
2) Java быстрее Delphi на строках, не упоминая, что Java имеет преимущество только при наличии двукраного объема памяти, и процессорного времени на работу сборщика
3) Что накладные расходы на подсчет ссылок велики, хотя расходы на GC могут быть на порядок, в 10 раз больше
4) Что GC существенно оптимальнее по CPU кэшу, не упоминая, что сама работа GC забивает кэш служебными структурами сборщика
5) Что боятся проблем нативного кода, вроде порчи буферов памяти -- это нормально

kaz_av

Цитата:

Пишешь в своем исходнике {$I blah_blah_last_modified_datetime.inc}, настраиваешь событие на генерацию соответствующего файла. Всё.

В каждом исходнике свой? А у меня их явно более двух сотен важных.


Цитата:

Некрофилы должны страдать.

О! Вот тут я Вам пожму руку даже, Ваши бы слова да кому-то в уши.


Цитата:

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

Я же писал историческую справку. В D2010 повезло тем счастливчикам, которые с D7 ждали, когда можно будет увидеть нестандартную (не Ansi) букву в приложении. Им повезло, а вот Вам видимо не очень, думаю много сил ушло именно в правильный юникод.


Цитата:

Что боятся проблем нативного кода, вроде порчи буферов памяти -- это нормально

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

xpin2013


Цитата:

В D2010 повезло тем счастливчикам, которые с D7 ждали, когда можно будет увидеть нестандартную (не Ansi) букву в приложении.

нестандартную букву можно увидеть и в классических Delphi, только это не так просто.
Я сам этим занимался, и небезуспешно.
Тем, кто "ждал" юникода аж до D2010, она не очень то поможет, поскольку из готового библиотечного кода приложение с полноценной поддержкой юникода все одно не построишь.
Есть суррогаты, есть диакритика, есть проблема с подходящими шрифтами и покрытием, есть проблема с поиском и сравнением строк, где эквивалентные FormD и FormC побайтово неравны.

AlekXL
Ой, да я тут со всем с Вами соглашусь.

Цитата:

полноценной поддержкой юникода все одно не построишь.

У меня то всё проще. Меня интересовало примерно Edit1.Text := WField.AsVariant. Я имею ввиду, что я нарочно, на имплицитных преобразованиях не потеряю букву если постараюсь. Тут ведь иногда я прямо со смеху падаю
Функция только для Delphi 2006

Код: [no]procedure GetFieldNamesList(Table: TDataSet; List: TStrings);
{$IFDEF COMPILER10}
var
WL: TWideStrings;
{$ENDIF}
begin
{$IFDEF COMPILER10}
WL := TWideStringList.Create;
try
Table.GetFieldNames(WL);
List.Assign(WL);
finally
WL.Free;
end;
{$ELSE}
Table.GetFieldNames(List);
{$ENDIF}
end;[/no]

AlekXL

Цитата:

ну прости, я то думал, что сравнение будет честным.

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


Цитата:

твой изначальный код медленнее моего, на Delphi, за счет пересоздающихся StringBuilder'ов

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


Цитата:

Я ограничил память и Delphi приложению

Ты её не ограничил, а дал столько, чтоб при таком количестве данных система тебя в своп не загнала. А вот потребность GC ты ограничил. Это читерство в чистом виде.


Цитата:

на личности переходишь?

Ты же перешел от любезностей к обвинениям, с чего мне себя сдерживать?


Цитата:

1) GC потребляет доли процента процессорного времени, тогда как легко может 50 или более

Ты перевираешь мои слова от невнимательности или просто очень хочется быть правым? Я-то написал:

Цитата:

Всё от ситуации зависит, когда я мониторил одну софтину там GC кушал сотые доли процента.

Если ты не понял, это совсем не означает, что GC всегда будет кушать сотые доли процента.


Цитата:

2) Java быстрее Delphi на строках, не упоминая, что Java имеет преимущество только при наличии двукраного объема памяти, и процессорного времени на работу сборщика

Я ни разу не сказал, что GC не требователен к памяти. Речь была о скорости работы.


Цитата:

3) Что накладные расходы на подсчет ссылок велики, хотя расходы на GC могут быть на порядок, в 10 раз больше

Эти выводы сделаны тобой из некорректных тестов. В нормальных условиях GC безусловно быстрей.


Цитата:

4) Что GC существенно оптимальнее по CPU кэшу, не упоминая, что сама работа GC забивает кэш служебными структурами сборщика

Опять вранье. Я говорил, что "GC более cache friendly", ты мне приписываешь "существенно оптимальнее". С такими методами ведения дискуссий, проследуй-ка ты родной в пень, и захвати туда книжку рихтера по GC, авось поможет.


Цитата:

5) Что боятся проблем нативного кода, вроде порчи буферов памяти -- это нормально

И снова вранье. Я сказал, что порча буферов, да и не только буферов, это обычная ситуация для натива.

Итого, поздравляю вас, гражданин соврамши.

xpin2013

Цитата:

В каждом исходнике свой? А у меня их явно более двух сотен важных.

Ну пусть бы даже и свой, в чем проблема? А зачем тебе в каждом исходнике дата? Ну и даже если она тебе действительно нужна, макросами VCS решить проблему куда проще.


Цитата:

В D2010 повезло тем счастливчикам, которые с D7 ждали, когда можно будет увидеть нестандартную (не Ansi) букву в приложении.

Это те кому не рассказали о TNT? Бедняги.


Цитата:

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

Так может все таки ошибаться компилятор, или божественность все же не отменяется?


Цитата:

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

У тебя и в дельфях от твоего датавставлятеля, по твоим же словам, эксепшен вываливается при закрытии среды. Видимо в прокладке дело.

Цитата:

У тебя и в дельфях от твоего датавставлятеля, по твоим же словам, эксепшен вываливается при закрытии среды. Видимо в прокладке дело.

Дело в том что BorlandIDEServices - это переменная, стало быть её можно заменить, но чудо писаки - пользователи интерфейсов рождённых от IUnknown считаю что BorlandIDEServices никогда никто не меняет и если запросить тот же интерфейс то это будет тот же объект. Значит можно смело кешировать переменные, складывать эти интерфейсы IUnknown себе запазуху (И плевать на всех гуру которые пишут тонны книг и очень популярны).
1) Добиться исправления этой ситуации невозможно.
2) Кто сказал что сторонний пакет компонентов не будет вести себя точно так же?
3) Мой перехватчик абсолютно точно считает количество какое должно быть на счётчике, когда выгужают мой пакет из памяти и я обязан вернуть родной BorlandIDEServices. Очень частенько ошибки не возникает, но при определённых событиях, нерадивые программисты кешируют интерфейсы в своих переменных и тогда из-за некорректной работы со счётчиком вылазит один чудо Exception не затраеный до сих пор.
4) Если бы всегда когда нужен интерфейс повторялся бы путь от BorlandIDEServices до исполнения и потом освобождение интерфейса, то всё было бы корректно, а Delphi давно был бы более развит чем Excel. Разработчики IDE, пользователи ToolsAPI даже не предполагают что объекта обрабатывающего интерфейс, который они хранят нет и в помине, его выгрузили с пакетом. Так программировать нельзя, разувать глаза надо на реадонли проперти или переменную, разница всё же есть, и не спроста. Так и подмывает посоветовать - не плохо бы видеть куда прёте.
5) Один экзепшен против полной свободы добраться во все участки Delphi даже те где не реализован ToolsAPI. Тут под силу гораздо больше чем умеют GExpert.

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

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

Добавлено:
Ну и если Экзепшен при выходе, то это Delphi говорит мне до свидания или пока, зависит он настроения.

Добавлено:

Следующий точный Новый Год найден!!!!!!!!!!!!!
Это Datetime(122358) то есть 01.01.2235 год! Мой предыдущий расчёт вручную не учитывал совпадения цифр по середине. Следующий Новый Год будет ровно через 220-ть лет!