kami

На Android штатный менеджер памяти не отслеживает утечки.

Некрасиво обзывать описание интерфейса с префиксом T. Если уж используете объект как интерфейс - так и работайте с интерфейсом для нормальной работы подсчета ссылок: var Obj: IInterface; Obj:=TInterfacedObject.Create; В том случае, если ссылку на Obj никто не держит при выходе из метода - да, объект будет уничтожен.

Думаю, причина проще и сложнее одновременно. Просто что-то портит память.

С днем рождения!!!

Нет, я этого не говорил. MSSQL - "исторически сложилось" в моей компании. И вся серверная работа построена на Win. И PHP тоже развернут на WinServer Без виртуалок с линухом, прямо на Win. Предупреждая дальнейший спор - да, я стормозил в предыдущем сообщении, написав "linux + php". Прошу прощения, голова другим была забита. Ну, это так - небольшое ответвление от основной темы и в ответ на

Имел дело с комбинацией linux+php+MSSQL. Не могу пожаловаться на квалификацию наших php-девелоперов, но в итоге написал аналог сам на Delphi + mORMot + MSSQL. Аптайм сервиса - около года. Про то, как работало php-решение (как по скорости, так и по качеству) промолчу. Кроссплатформенность - да, с этим не поспоришь.

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

С этим никто и не спорит. Немного утрируя - вы предлагаете сказать разработчикам Embarcadero "ребята, поживите годик без зарплаты, зато мы восстановим популярность и вот тогда всё выплатим"? Простите за резкие высказывания, но я со своего дивана тоже могу говорить, как надо управлять государством. Еще раз повторюсь, в управлении Embarcadero сидят не дураки. Там люди, умеющие считать деньги. Как "деньги сейчас" так и "что у нас будет с деньгами в перспективе". И очень может быть, что снизить цену просто не позволяет текущее финансовое состояние компании. Вот за такие факторы я и говорил. Ни вы, ни я, и никто кроме руководства компании не видит полной картины. Поэтому говорить "снизьте цену и через полгода все станет классно, это единственный выход" с вашей стороны как минимум опрометчиво. О, да. Как кодер по вашей классификации - снимаю шляпу перед вами, настоящим разработчиком. Увы - у меня их нет. Я просто не могу и не буду ничего советовать, если не имею всех исходных данных и соответственно - не могу просчитать влияние планируемых шагов на дальнейшую жизнь компании. И вам не советую.

Я не думаю, что маркетологи и финансисты в Embarcadero настолько глупы, что не в состоянии просчитать прибыль/убытки от снижения стоимости. И думаю, это просчитывалось неоднократно. Мы судим, в основном, по рынку РФ (а если быть более точным - по себе, как НАМ было бы лучше). Я бы вот хотел бы, чтобы Architect раздавали бесплатно Не имея исходных данных по клиентуре Embarcadero по всему миру, динамике продаж и т.п. (думаю, эти акции по бесплатной раздаче более чем анализируются, как и последующие обновления со starter до более полных версий) - говорить "снизьте цену на всё и продажи пойдут и Delphi восстановит популярность моментально", имхо, не есть правильно. И потом - а на кой вам Архитект? Для подавляющего большинства задач более чем хватает Про с аддонами.

Может, проблема в том, что там Intel Atom?

Потому что программер должен понимать разность между хранением чисел и их представлением.

Тогда уж "есть массив ЦЕЛЫХ чисел". 16-ричное, двоичное, восьмиричное, десятичное - это всего лишь строковые human-readable представления этих чисел.

Ну а что вы хотели услышать? Даже в Windows, где действительно можно явно "прибить" поток, это приведет к тому что самого потока не станет, но вся память, которую он забрал в ходе работы останется помеченной как "в использовании". Несколько раз так создаем/прибиваем потоки и получаем OutOfMemory в любом случайном месте программного кода. Поэтому убивать поток не надо, его надо корректно завершать.

1. Смотря где. В Мск и СПб - это не "очень хорошая" 2. Смотря для какого состава семьи. Если один - да, зарплата хорошая. Если 3-4 человека - то уже маленькая.

Использую GIT и SVN Но не встроенные средства, а черепашку (Tortoise), консоль для меня слишком круто

Уточнение: интерфейс не должен работать с данными с управляемым временем жизни. К примеру, вы не можете передать между exe и dll IXMLDocument и его составляющие, поскольку этот интерфейс работает с типом string.

LibreOffice совместим? Бо, емнип, OpenOffice малость совсем заброшен...

Простите, но фраза про тонны кода, как мне показалось, была написана именно в скептически-отрицающем-не-принимающем-аргументы тоне. Зачем? Вполне достаточно передавать HBITMAP, т.е TBitmap.Handle (если мы говорим про VCL). Сеттер TBitmap.SetHandle сделает всё необходимое.

Скорее с помощью RTL и WinAPI. Собственно, ищем: 1. как работать с LibreOffice (подключение/отключение) 2. Как открыть существующий документ 3. Как сохранить его в нужном формате. Соединяем эти кусочки воедино и имеем нужный результат на выходе.

Потому что по счастливой случайности адресация методов в VMT для TBitmap.exe и TBitmap.dll оказалась идентичной. абсолютно. То, что что-то работает, еще не значит что это работает правильно. И всякие "тонны кода", которые "ну они же работают, значит все я написал правильно" вываливаются с ошибками в самых непредсказуемых местах как раз из-за порчи памяти. И отловить это (и тем более воспроизвести) нереально. Никак. Если вам так удобнее - можете продолжать использовать свой текущий подход, ваше право. Пытайтесь отловить несуществующие ошибки, когда проблема в неправильном API

Так сделайте метод, который будет принимать в качестве параметра грид и "запихивать" туда содержимое лога. И после этого хоть 10 гридов заводите.

Вы не поверите, но передавать экземпляры классов между различными независимыми модулями (будь то exe и dll или две разных длл) нельзя даже если версии IDE абсолютно идентичны. Потому что TBitmap в одном модуле - это не то же самое, что TBitmap в другом модуле. У каждого модуля СВОЙ менеджер памяти, своя таблица виртуальных методов (VMT), свои структуры описания классов и т.д. и т.п. Модуль будет пытаться работать с экземпляром класса, как со своим, обращаясь к своим методам вместо методов, реализация которых находится в другом модуле. И память при работе с методами и свойствами объекта он будет выделять и пытаться освободить СВОЮ, а надо было бы - память, выделенную менеджером памяти другого модуля. Вот вам и первопричина для глюков. Из dll в exe и наоборот в случае с битмапом вы можете передать максимум hbitmap, поскольку это хендл на ресурс ОС. А классы, их экземпляры, строки и другие типы с управляемым временем жизни передавать нельзя, это табу. Для изучения: http://www.gunsmoker.ru/2011/12/delphi.html#n5 сразу можно переходить к правилу 6

вы случайно не объекты и/или дельфовые типы (а-ля string) передавали между exe и dll?

http://forum.vingrad.ru/forum/topic-60076.html

Мы используем кошерные TCriticalSection, TMutex, TEvent и остальные классы из System.SyncObjs