Здравствуйте !
Попробовала сделать так:
В Builder выбираем File --> New --> VCL Forms Application.
Выбрасываем из проекта Unit1 и res.
В оставшемся Project1 чуть меняем код на:
Сохраняем и "билдим": все OK.

Теперь пытаемся тоже проделать с консольным проектом:
Выбираем File --> New --> Other --> Console Application
Опять чуть меняем код на:
и пытаемся "билдить".
И нам выдаются следующие ошибки:
[Linker Error] Error: Unresolved external 'System::__linkproc__ __fastcall LStrClr(void *)' referenced from C:\PROGRAM FILES\BORLAND\BDS\4.0\LIB\DEBUG\VCLE.LIB|dstring
[Linker Error] Error: Unresolved external '__fastcall Sysutils::IntToStr(int)' referenced from E:\DELETE FILES\CONSOL\DEBUG_BUILD\UNIT1.OBJ
[Linker Error] Error: Unresolved external 'System::__linkproc__ __fastcall LStrFromPChar(System::AnsiString&, char *)' referenced from C:\PROGRAM FILES\BORLAND\BDS\4.0\LIB\DEBUG\VCLE.LIB|dstring
[Linker Error] Error: Unresolved external 'System::__linkproc__ __fastcall LStrCmp()' referenced from C:\PROGRAM FILES\BORLAND\BDS\4.0\LIB\DEBUG\VCLE.LIB|dstring
Объясните мне, пожалуйста, в чем разница
и как консольный проект научить принимать, например, sysutils.hpp без ругани 

означает что есть вызов функции(класса) у которого нет тела. 
В вашем случае надо добавить нужные библиотеки к проекту. 

Поставить галку Project->Options->Packages->Build with runtime packages = True; 
Разница в том, что эта галка для VCL-приложений стоит автоматом...    

Спасибо всем !



А ведь ни за что бы сама не догадалась   

А как можно аналогичное проделать "вручную" ? Или это довольно сложно ?

P.S.
 На самом деле мне нужен не sysutils.hpp, а system.hpp
 Хочу поробовать "достать" из него MemoryManagerEx и сопутствующие ф-ии.

Riply, может стоит воспользоваться Win32API напрямую?
Кстати, этот MemoryManagerEx упоминается только на этом форуме - больше нигде гугл не нашел. Может это неспроста?   

Это сообщение отредактировал(а) bsa - 24.6.2008, 10:26

Что значит "вручную"? Вроде бы и так ручнее некуда 
Насчет MemoryManagerEx - соглашусь с bsa, не понимаю, зачем этот геморрой и откуда он взялся  У меня билдер не знает такую функцию...

Может потому что искал именно MemoryManagerEx ?
На запрос TMemoryManagerEx что-то выдает  Можно еще посмотреть TMemoryManager, но он устарел.



Не поняла, что имеется ввиду ? 
Я то просто хотела попробовать использовать вкусности от Borland-овского менеджера памяти в Builder`е 

Добавлено через 3 минуты и 38 секунд


Из Delphi 

Все равно не понимаю, что мешает... Ну вот я накидал код (смысла в нем я правда не вижу, но как пример)...Вроде работает. Но в чем его вкусность - не вкурил 

Спасибо. Попробую.





А ее (вкусности) в Builder`е может и не быть.
Я ведь в С++, сейчас нахожусь на уровне "обучения ставить точку с запятой перед else",
что мне дается с большим трудом, после Delphi 

С чего-то же надо было начинать изучать язык. 
Вот я и решила начать с различных способов работы с памятью, ибо без нее (памяти) никуда 

Только, IMHO, надо чуть чуть не так.


Вроде работает.
Теперь можно попробовать сравнить с "настоящими" GetMem, AllocMem... e.t.c. 

Riply, кошмар. Зачем такие сложности?
чем тебя malloc/calloc/free или new/delete не устраивают?
Я уж не говорю про такие вкусности C++, как стандартные контейнеры (string, vector, list, set, map и пр.).
Твой код с их использованием можно написать так:

Это сообщение отредактировал(а) bsa - 24.6.2008, 12:24

Вполне устраивают 
Но надо же посмотреть и альтернативные варианты (если они конечно есть),
уяснить разницу и понять что с чем едят 

Riply, вот есть типичная тривиальная задача - выделить память под N элементов типа int. N на этапе компиляции неизвестна.
Как мы делаем в стандартном Си:Сложно и малопонятно с первого взгляда.
Как мы делаем под C++:Наглядней, но все равно надо следить за памятью.
Теперь тоже самое, но с использованием вектора:Просто и понятно, да и память сам за собой подчистит...

Все эти AllocMem'ы и пр. пришли из дельфи, который не имеет ничего подобного (если не ошибаюсь). Ну и зачем спрашивается пытаться заставить себя научиться работать с тем, что как минимум неудобно и небезопасно, а как максимум еще и медленней работает.

Это сообщение отредактировал(а) bsa - 24.6.2008, 13:22

Одна из причин, почему все это затеяно -  подтверждение или опровержение этой фразы 

P.S. 
 Пока нет доказательств, будем считать ее спорной 

Добавлено через 4 минуты и 2 секунды


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

Редко можно встретить женщину-программиста (женщину-программиста вообще сложно встретить) с подобной дотошностью...
Ну что ж, вперед - доказывай или опровергай.

Есть способы форсировать "чистку" (например, reserve(0) у вектора). С другой стороны, у тебя в голове много лишнего места, чтобы хранить информацию о том, что где-то что-то надо освободить?

Попробую. О результатах будет доложено 

Раз уж пошло такое дело, еще вопрос:
Под VS 2005, вроде, мне удается более-менее контролировать утечки памяти с помощью _Crt функций.
А вот из под Builder`а не получается до них добраться. Они в нем вообще есть ?
Если нет, то как можно контролировать в нем утечки памяти ?

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

Какие-то странные результаты. 
Имеем код:


Получаем такие сообщения:
malloc/free:               203854
new/delete:              268167
MemoryManagerEx:  160868

Либо я чего-то не понимаю, либо где-то партачу,
либо Борландовский менеджер опять на коне 

Добавлено через 1 минуту и 56 секунд

Как-то код неправильно отформатировался. Sorry.

видимо его специально оптимизировали.

Может кому будет интересно:
Один мой знакомый заинтересовался механизмом работы с памятью и быстродействием.
Вот что он пишет:
"..............
В результате исследований выяснилось, что занимает больше памяти совсем не 
строки, вопреки моим ожиданиям, а некоторые структуры. Переупорядочил поля 
тех структур - получил в одном случае более 10% экономии, другие проверить 
не могу пока, но думаю там сэкономлено больше. Надеюсь дадут ещё время на 
это, есть ещё как и более глубокие идеи оптимизации, так и идеи насчёт 
улучшения средства исследования (которое пока то ли работает то ли не 
работает - об этом ниже).

Детоуринг RtlAllocateHeap/RtlReAllocateHeap/RtlFreeHeap - идея правильная. 
C++овский new  сводится к сишонму malloc, оттуда вызывается HeapAlloc, 
оттуда уже RtlAllocateHeap. Внутри кое-каких майкрософтовских библиотек 
вызываются Heap* функции напрямую, всё равно попадаем туда же. WinAPI 
функции типа CreateWindow вызывают функции вроде LocalAlloc или HeapAlloc, 
всё равно идём в RtlAllocateHeap. Разумеется, не факт что malloc и 
GlobalAlloc будут _всегда_ сводится к RtlAllocateHeap, но похоже что в моём 
случае все существенные объёмы проходят через RtlAllocateHeap.

Detours заинтересовала как она работает. Например, т.к. задача перехвата 
этим путём может быть разной сложности и в общем случае не решаема (функцию 
чисто из ret так не перехватишь), интересно как далеко она ушла в обработке 
сложных ситуаций. Также интересно насколько транзакция detours действительно 
транзакция. И если настолько, насколько я надеюсь, то как оно работает.

Спуск по коллстеку через StackWalk или StackWalk64 - не всегда работает. На 
самом деле перед этой функцией стоит тоже в общем случае не решаемая задача. 
Реально получается интересный факт - с winapi до ехе спускается вседа, но со 
спуском из кода CRT до прикладного кода иногда проблемы. У StackWalk есть 
параметр ContextRecord. Глянь что про него в MSDN пишут. Оказывается, что 
если передать туда эту структуру, то StackWalk в состоянии обработать спуск 
с malloc до new, иначе - нет. Причём, заполнение структуры не влияет. Видимо 
влияет то заполнение, которое делается самой StackWalk в предыущих вызовах. 
Пока что самые существенные объёмы уже успешно обрабатываются, но будет 
время - попытаюсь добиться чтобы всё обрабатывалось.

Анализ - прост как валенок. Начиная с начала профилируемого интервала при 
Alloc запоминаем в hash_map указатель как ключ, размер и стек вызовов в виде 
адресов возврата как значение. при Free удаляем. В конце профилируемого 
интервала для каждого оставшегося в hash_map адреса ищем адрес возврата 
своего кода: получаем файл исходников из адреса возрата, и функцией strstr 
проверяем его на принадлежность своему коду. Из всего этого составляем 
другой hash_map, здесь уже ключ - адрес_возврата_в_свой_код, значение - 
сумма выделенной памяти ( /* интересная тонкость STL: */ std::map<int,int> 
m; m[3] += 2; m[3] += 2; /* чему равно теперь m[3] ? думаешь неизвестно ? а 
вот и нет, оно будет равно 4. */ ). Теперь перекладываем содержимое этого 
мэпа в контейнер, соритрованый по получившемуся там размеру (я взял map), 
дополняем результат файлом и срокой и именем метода из адреса своего кода - 
вот и результат. Конечно, это не будет "максимально полная картина". Но уже 
представления что надо оптимизировать, а что нет - даёт.

Теперь почему это "то ли работает то ли не работает". Разумеется мы должны 
защититься от повторного вхождения в перехваченные функции, кроме того т.к. 
хешмэпы не потокобезопасны, их нужно защитить. Казалось бы - критическая 
секция, а потом флаг уже вошли мы в перехваченую функцию или нет, если уже 
вошли - выходим. Но это приводит к дедлоку, т.к. Sym* и StackWalk выделяют 
что-то в другом потоке. Сейчас работает хитрая система из TLS и крит. 
секций, но я не уверен, что там всё ок.
.........."