XML C8 - не понял...

[Aragorn]

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

[Aragorn]

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

[Yufil]

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

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

[PavelNK]

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

Конвертация в 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)

[Aragorn]

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

[Дед Пахом]

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

[Aragorn]

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

[Дед Пахом]

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

[Aragorn]

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

[Aragorn]

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