-
Впрочем, если геморрой на собственный зад тебя не страшит, готовь данные и вызывай функции с использованием basm, тогда компилятор махнет на твои извращения рукой)
-
> С чего это?
Он мне по секрету на ушко шепнул)
-
Сергей М. © (04.04.08 9:48) [20]
О чем и говорилось в [5]: > кроме переписывания кода на ассемблере
Сергей М. © (04.04.08 9:49) [21]
Ну-ну...
-
> О чем и говорилось в [5]
В [5] не было конкретностей, они появились в [6]. А вот теперь измени декларацию своей ф-ции на следующую процедуру: procedure ExpandEnvironmentStrings2(var s:string);
Удивись - компилятор не заключил вызов процедуры в try-блок ! Теперь думай над происходящим)
-
Сергей М. © (04.04.08 9:56) [23]Честно удивлюсь, если не заключил. У меня заключил. Код: uses Windows;
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:string;
begin
s:='%PATH%';
ExpandEnvironmentStrings2(s);
Write_(s);
end.
-
> У меня заключил
Врешь и не моргаешь) Или не понимаешь в принципе, какому конкретно программному действию этот блок соответствует.
-
Сергей М. © (04.04.08 10:10) [25]>> У меня заключил > Врешь и не моргаешь) Смотрю в самое начало кода и вижу mov fs:[eax],esp . Кто врет? > Или не понимаешь в принципе, какому конкретно программному действию этот блок соответствует. Случай, > если возвращаемое значение есть LargeString мы убрали, в каких еще случаях генерируется этот блок? Не затруднит рассказать или хотя бы дать ссылку?
-
> Смотрю в самое начало кода и вижу mov fs:[eax],esp . Кто > врет?
ты, разумеется) Этот блок появился по факту присутствия строчки s:='%PATH%' но отнюдь не строчки ExpandEnvironmentStrings2(s); которую можно смело закомментировать, чтобы убедиться в том, что блок не исчез. > в каких еще случаях генерируется этот блок?
Во всех случаях когда компилятор берет на себя ответственность за безусловное освобождение ресурсов, распределенных под данные с управляемым временем жизни, при потенциальной возможности исключений.
-
Сергей М. © (04.04.08 10:28) [27]Нет, виновата строка с var: var s:string;
begin
end. Даже тут генерируется этот блок... Спасибо за объяснение. Итак, строку можно вернуть либо функцией, либо процедурой с var string. В обоих случаях будет генерироваться этот блок. Есть ли еще способы вернуть строку (AnsiString)?
-
> виновата строка с var
Далеко не всегда.
> В обоих случаях будет генерироваться этот блок
Вовсе не факт.
-
var s: string;
procedure TForm1.Button2Click(Sender: TObject); begin s := '%PATH%'; end;
Удивись - никаких блоков компилятор не сгенерировал.
-
Сергей М. © (04.04.08 10:54) [29]
Приведите пример, пожалуйста.
-
см. [30]
-
Сергей М. © (04.04.08 10:56) [30]Ну да, в функции TForm1.Button2Click не будет этого блока, а в главном begin end. все равно будет.
-
> в главном begin end. все равно будет
И чем он тебе помешал ? Этот блок "охватит" всю работу приложения, один раз за всю его жизнь, что никак не отразится на сквозной его производительности.
-
Сергей М. © (04.04.08 11:03) [34]
> И чем он тебе помешал ?
Давайте все-таки отвечать на заданный вопрос - "как избавиться от блока обработки исключений", а не такой вопрос - "чем тебе мешает X?" Если бы он мне не мешал, я бы не задавал свой вопрос, логично?
-
Отвечаю - не пользовать конструкции вида [28].
-
Нелогично другое - стремление к блохоловству, аргументированное лишь ничего не значащим "пишу на чистом ВинАПИ"
-
Ты объясни, на чем ты хочешь сэкономить, избавившись от сабжа ? На размере исп.модуля ? На локальной/сквозной производительности приложения ?
-
> [35] Тыщ (04.04.08 11:07)
уверен, что жонглирование нуль-терминированными строками, с постоянным перераспределением памяти компенсирует избавление от исключений? готов написать свой более оптимальный менеджер памяти, чем борландовый?
|