-
> Например?
Дык тот же TObject и иже с ним потроха занимают немало места ! Некузяво как-то) .. Выбрей и его тож)
-
Сергей М. © (04.04.08 14:20) [79]
> На момент, когда я упомянул _IntfClear, предполагалось что ты пользуешь штатный system.dcu, а не выбритый лоскутами)
Странно, добавил _IntfClear в System.pas, а он все равно не прикомпилировался.
Сергей М. © (04.04.08 14:22) [80]
> Дык тот же TObject и иже с ним потроха занимают немало места !
Только в system.pas, не в конечной программе, если не используется.
-
> Странно, добавил _IntfClear в System.pas, а он все равно > не прикомпилировался
Странно, я заведомо использую блоки try..finally c заведомо штатным system.dcu, а в map'е процедурой идентификатором _HandleFinally даже не пахнет.
Наверно тоже не "прикомпилировался")
Вот ведь чудеса в решете - кода нет, а он успешно работает)
-
Сергей М. © (04.04.08 14:41) [82]
> в map'е процедурой идентификатором _HandleFinally даже не пахнет.
@HandleFinally там есть.
-
Во, обработку исключений победил! uses Windows;
procedure LStrFromPCharLen(Dest: PAnsiString; Source: PAnsiChar; Length: Integer);
asm
jmp System.@LStrFromPCharLen
end;
procedure LStrClr(S:PAnsiString);
asm
jmp System.@LStrClr
end;
procedure ExpandEnvironmentStrings2(var s:string);
var Buffer:pchar;
Size:cardinal;
begin
Size:=ExpandEnvironmentStrings(pchar(s),nil,0);
GetMem(Buffer,Size);
Size:=ExpandEnvironmentStrings(pchar(s),Buffer,Size);
SetString(s,Buffer,Size-1);
FreeMem(Buffer);
end;
procedure Write_(var s:string);
var Temp:dword;
begin
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE),s[1],Length(s),Temp,nil);
end;
var
s:pstring;
s_holder:integer;
begin
s:=@s_holder;
LStrFromPCharLen(s,'%PATH%',6);
ExpandEnvironmentStrings2(s^);
Write_(s^);
LStrClr(s);
end.
-
> @HandleFinally там есть.
Согласен, есть.
Но точно также там не будет никакого кода, касаемого обработки исключений, если ты не спровоцируешь его появление.
-
Если такого "красивого" исх.кода будет эдак мегабайт на 10..20 и там вкрадется лог.ошибка, тот, кто будет вынужденно изучать твой код с целью исправления этой ошибки, обязательно поймайт и поколотит тебя)
А ошибка там обязательно будет)
-
Ничего, с pchar'ами не лучше.
-
Дети Ивана Кулибина.
-
> Ничего, с pchar'ами не лучше
Угу. Лучше, наверно, нарваться на исключение и игнорировать этот факт (как и саму обработку), пребывая в святой уверенности, что операция прошла успешно)
> procedure ExpandEnvironmentStrings2(var s:string); > var Buffer:pchar; > Size:cardinal; > begin > Size:=ExpandEnvironmentStrings(pchar(s),nil,0); > GetMem(Buffer,Size); //а если память по каким-то причинам не была выделена ? > Size:=ExpandEnvironmentStrings(pchar(s),Buffer,Size); //в buffer'е мусор, это спровоцирует иск.ситуацию > SetString(s,Buffer,Size-1); //даже если GetMem выполнена успешно, аллокация памяти под строку и копирование туда данных из буфера тоже может завершиться неуспехом ? > FreeMem(Buffer); //если в buffer'е не мусор, то произойдет утечка памяти, поскольку при обработке искл-я у тебя происходит банальный выход по RETN > end; >
-
> Дети Ивана Кулибина
Да уж ... SEH для них - просто ненужный мусор)
-
Сергей М. © (04.04.08 15:34) [89]
Если системе будет настолько нехватать памяти, что моя программа не сможет выделить сотню-другую байт, то система при этом явно уже будет рушиться и без моей программы.
-
Сергей М. © (04.04.08 15:36) [90]
SEH на каждый чих - мусор, вот :)
-
> Если системе будет настолько нехватать памяти
А с чего ты взял, что операция аллокации может вызвать искл-е только по этой причине ?)
> SEH на каждый чих - мусор
Зачем на каждый ? Вовсе не обязательно)
Но обернуть весь код хотя бы в один блок, чтобы пощадить глаза и мозг юзера от тарабарщины в системных сообщениях о необработанных тобой исключениях - разве это не истинная "красота" программы ?
Я уже не говорю о ситуации, когда бедный юзер материт такого вот горе-разработчика, чья программа после запуска тут же тихо умирает, не подав никакие признаки рождения)
-
Сергей М. © (04.04.08 15:48) [93]> с чего ты взял, что операция аллокации может вызвать искл-е только по этой причине ?) По какой же еще? > программа после запуска тут же тихо умирает Так получается именно из-за "насильной" вставки обработки исключений, от которой и так мало что осталось. Если ее нет совсем, то получим стандартное и вполне приличное The instruction at "0x00401080" referenced memory at "0x00000000". The memory could not be "read".
Click on OK to terminate the program
Click on CANCEL to debug the program
-
> По какой же еще?
Ну, например, некая твоя логическая ошибка привела к загаживанию управляющих стуктур менеджера памяти.
Да мало ли в бразилии Педро !)
> получим стандартное и вполне приличное
Очень прилично, нечего сказать) Для какой-нить главбухши, знающий только "дебеты-кредиты-сальды-сторны" - самое то)
-
Сергей М. © (04.04.08 16:10) [95]
> например, некая твоя логическая ошибка привела к загаживанию управляющих стуктур менеджера памяти
Да уж, это надо постараться...
> Для какой-нить главбухши, знающий только "дебеты-кредиты-сальды-сторны" - самое то)
Для "какой-нить главбухши" я не пишу... пока что.
-
> Во, обработку исключений победил!
При работе со строками большую часть ресурсов заберет не несколько ассемблерных инструкций + 12 байт стека + обращение к TEB, а использование динамической памяти. И победа далась тебе дорогой ценой: вставлено несколько дополнительных вызовов CALL и JMP. Можешь сравнить эти два фрагмента по скорости ;)
-
> Mystic © (07.04.08 18:24) [97]
Красота требует жертв) Автору все это фиолетово - главное чтобы было "красиво")
-
> Тыщ (04.04.08 14:58) [84] > Во, обработку исключений победил!
Кто? Где?
|