forum.clarionlife.net

Так что же... классу Cstr таки до конца доверять нельзя? И можно ли конструкторы-деструкторы заменть так, как я описал выше?
Насчет 40 кб... ошибся буквой. вместо к читаем м. При формировании ДОМ документа и формировании очереди выделяется эдак около 250 мб, а после уничтожения ДОМ документа около 40 остается. Free(ListXML) эффекта не дает, пробовал сразу, как только обнаружил.
Кстати, такой обьем памяти для парсера ХМЛ я так понимаю, обычное дело. В Дельфи пользовали встроенный ХМЛДокумент для формирования файла, так тоже жрал примерно столько же. Но без утечек. Переделали на классы и stream'ы - выделение памяти сократилось раз в пять. Ну тут понятно - под конкретную структуру документа проще так сделать, а компонент видимо в порядке универсальности создает кучу ненужных для конкретной задачи вещей...
И все-таки, если есть возможность, прошу подбросить еще идеек!!!

Неужели ни у кого нет идей? Или советов? Может, можно перегонять utf-8 в windows-1251 и наоборот каким-то другим способом?.. неужели ни у кого не возникало такой задачи, кроме Yufil?..

Ну так посмотри cstr.clw, он краток и прост. Методы toUTF8 и ToAscii - там максимум десяток строк кода, где-то Dispose мог и пропустить.
Да и оформить конвертацию в виде отдельной процедуры ненапряжно, там три обращения к WinAPI - и всё.

Но у меня больше подозрений на CW8, я пытался перегнать одно приложение с CW6 и не достиг успеха, просто не компилируется. Может быть, более поздний релиз поможет. Судя по тому, что ссылка на &Cstr считается ошибкой - странно это...

Возьми Клашин класс, сделай от него наследника. Добавь методы конвертации и вставь где необходимо

Конвертация в 1251 из utf-8
Blength = MultiByteToWideChar (CP_UTF8, 0, address(S), -1, address(Buffer2), 0)
RetCode = MultiByteToWideChar (CP_UTF8, 0, address(S), -1, address(Buffer2), Blength)
RetCode = WideCharToMultiByte (CP_ACP0, 0, address(Buffer2),Blength, address(Buffer1), Slength, 0, 0)

Конвертация в utf-8 из 1251
RetCode = MultiByteToWideChar (CP_ACP0, 0, address(S), -1, address(Buffer2), Blength)
RetCode = WideCharToMultiByte (CP_UTF8, 0, address(Buffer2), Slength, address(Buffer1), Blength, 0, 0)

PavelNK, завтра попробую. Однако, чем меня зацепил класс CStr так это быстрой работой с текстовыми файлами и неким подобием TStringStream... те быстрой работой с текстом.
Юрий, к содержимому CStr.clw вопросов практически нет (если не считать неадекватные падения приложения при наличии в классе явных конструкторов и деструкторов и/или прямого обьявления экземпляра класса. Не пойму, в чем дело, может быть в новой thread-модели, организованной в 8рке?), в классе утечек нет. Утечка явно в работе ХМЛ модуля, а именно после работы с очередью типа DOMQueue...

скорее всего мешанина имён: у SV тоже есть класс CStr (svcom.inc)

Ну так я svcom.inc не подключал... Разве что где шаблоном подцепился? Но попробую переименовать, посмотрим, что получится...

Уж больно поведение (падение на стадии инициализации объекта) похоже на то, если используешь COM класс, но прагмы _SVLinkMode_ и _SVDllMode_ не определены.

В общем, как и предположил Дед, все дело оказалось в "волшебных пузырьках" ))) А точнее - в конфликте имен.
Переименовал все, что связано с CStr в FaStr - и проблема с классом исчезла:
- заработало нормальное обьявление экземпляра класса FS FaStr;
- возвращены конструктор и деструктор:
- все команды в конструкторе и деструкторе выполняются;
- класс полностью стал вести себя адекватно и выполнять свои функции.
Остался вопрос по выделению памяти в DOMQueue, ну да хрен с ним пока )))

Решил для своей задачи проблему с утечкой памяти - исключил из работы очередь DOMQueue, зная конечное число уровней вложенности элементов, получаю очередной список нодов и извлекаю его атрибуты и/или значения, в конце применяю метод Release() для всех NamedNodeMap, NodeList и самого DomDocument. Утечки нет. Тема исчерпана...?