NothingAnother
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
deus6666
Цитата:| зачем? Чем анси не устраивает? |
Вопрос так не стоИт - "не устраивает" (дарёному коню в зубы не смотрят!), здесь уместней "не устраивает по-сравнению с..." А данный топик как раз для того и создан, чтобы помочь автору в улучшении продукта всеми путями - развитие функционала, улучшение интерфейса, оптимизация работы... Надо признать - нам всем очень повезло, что mai62 не страдает манией величия и прислушивается к высказываемым здесь мнениям (а иначе зачем тогда всё?), разве что не всегда внимательно...
По сути твоего вопроса - это, конечно же оффтоп, но раз уж задан... Надеюсь, ни для кого не будет откровением, что ядро NT-систем (а это все форточки, за исключением 9x) - юникодовое, поддержка ANSI - тяжкое наследство, оставшееся лишь для совместимости с уже существующим софтом - софтом стремительно устаревающим, остановившемся в своём развитии. Оглядываться на этот анахронизм оправдано лишь в одном случае - поддержка юзеров по разным причинам остающихся на 9x. Но мировая практика софтостроения давно решила этот антагонизм - сценарий инсталлятора автоматически определяет тип системы, и в соответствии с этим разворачивает те или иные модули (Unicode or ANSI). В случаях, когда имеет значение размер дистриба - ещё проще,- создаются два варианта билдов на выбор пользователя.
Любое Win-приложение представляет из себя бесконечный (замкнутый) цикл выборки из очереди и обработки сообщений. Внутри этого цикла и находится основная логика, которая сводится к цепочкам вида "вызов ф-ии API->обработка результатов->модификация данных->передача данных другой ф-ии API->обработка результатов...". Это то, что создаёт компилятор из программы на языке высокого уровня. Теперь самое интересное - входы API-функций в модулях ядра NT-систем в случаях использования символьных данных всегда парны и различаются суффиксами - FunNameA и FunNameW (соотв. ANSI и Unicode варианты). При этом вызовы ф-й ANSI можно считать паразитными - вся их работа сводится к преобразованию данных в юникод и передачу управления уже "настоящей" ф-ии (с суффиксом W) для обработки. Этого паразитного этапа можно легко избежать, всего-то установкой неких (не знаю - каких в Делфи) опций компилятора (вернее - линкера). Просто раньше я не знал - возможно ли это в продукции Borland, но вот deus6666 сообщает, что возможно.
mai62, обрати внимание! Только что посмотрел HC линк-вьюером только для того, чтобы лишний раз полюбоваться на гигантское количество вызовов "паразитов", и тут же обнаружился глюк, но (внимание, сейчас вылетит птичка!  ) не HC, а компилятора!!! В модуле MPR.DLL вызывается вообще отсутствующая  в нём (во всяком случае в версии 5.1.2600.2180 из XP SP2) ф-я WNetRestoreConnectionA, зато есть WNetRestoreConnectionW, но Дельфи, походу, просто не может её слинковать в соотв. с приказом "делай ANSI!"  Это уже даже не аргумент, а бомба!  Прокомментируешь?
----------
Мы тоже не всего читали Шнитке!.. © В. Вишневский |
|
Что касается конкретно HC, то обработка строк - основная (по- времени) деятельность программы, а кратковременных (возможных!) "дёрганий" просто не видно... 
надо SFX делать