" писал(а):не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве, галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм.
Это, смотря кто читает. Если комп, то проблемы будут. А человеку пофиг даже как текст расположен: нормально или перевёрнут - прочитать можно.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
" писал(а):лишь за счёт технологии визуальной связки имеющихся компонентов
Не согласен. Я, например, предпочитаю текстовую разработку и в той же делфе часто создаю объекты и размещаю их в объектах-контйнерах не с визуальной среды, а с кода. Время разработки всегда сокращается. Кто не согласен, попробуйте с визуала накидать четыреста объектов пяти разных типов и ещё выровнять их. Сколько на это нужно времени? Мне с кода - меньше десяти минут. А так, как у меня ещё проблемы одновременно со зрением и с координацией, то с визуала у меня же это займёт год даже при использовании команд визуала для автовыравнивания. У вас, возможно, много быстрее, но от кода отстанете. При этом я знаю и плюсплюс. И для одних задач предпочитаю делфу, а для других - плюсплюс. Кстати, в плюсплюсе есть болендовский интерпрайз - так это точно такой же визуал. Но я его юзю для воще третьих задач и тоже кидаю компоненты с кода. На вижелбейсике же вообще не поянтно, что ещё можно делать, кроме как кидать готовые компоненты вообще без обработчиков, чем он и проигрывает, так как без самостоятельной разработки кода с текста вообще нельзя сделать ничего толкового и хоть куда нибудь годного.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
" писал(а):Вовсе не бред, а нормальная ситуация. Длительность каждой команды (а точнее группы команд определенного вида) различна + задержки на занятость шины данных если операнд в памяти + задержки на выборку команды из кеша 1-го уровня и его обновление, если команда не выровнена по границам параграфа. А если брать в расчет многоконвеерное АЛУ, то..... Вообщем факторов достаточно много, на мой взгляд это настоящее искусство и отдельное направление в программировании - оптимизация кода.
Знаю комп у которого вообще
нет конвейеров, +
синхронная оперативка, +
кэшей нет за ненадобностью , но одна команда может выполняться дольше, чем
одиннацать. Это по неблочным командам. А для блочных команд толко долгое исполнение - норма, а быстрое - анамалия. Но они и делают больше.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
" писал(а):осторожно 2009 юникод
Я понимаю "осторожно ansi", но уникод? Раньше была куча проблем, для решения которых надо было каждый раз точно знать кодировку, а уникод решает их сам.
[quote="""]не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве, галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. [/quote]
Это, смотря кто читает. Если комп, то проблемы будут. А человеку пофиг даже как текст расположен: нормально или перевёрнут - прочитать можно.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
[quote="""]лишь за счёт технологии визуальной связки имеющихся компонентов[/quote]
Не согласен. Я, например, предпочитаю текстовую разработку и в той же делфе часто создаю объекты и размещаю их в объектах-контйнерах не с визуальной среды, а с кода. Время разработки всегда сокращается. Кто не согласен, попробуйте с визуала накидать четыреста объектов пяти разных типов и ещё выровнять их. Сколько на это нужно времени? Мне с кода - меньше десяти минут. А так, как у меня ещё проблемы одновременно со зрением и с координацией, то с визуала у меня же это займёт год даже при использовании команд визуала для автовыравнивания. У вас, возможно, много быстрее, но от кода отстанете. При этом я знаю и плюсплюс. И для одних задач предпочитаю делфу, а для других - плюсплюс. Кстати, в плюсплюсе есть болендовский интерпрайз - так это точно такой же визуал. Но я его юзю для воще третьих задач и тоже кидаю компоненты с кода. На вижелбейсике же вообще не поянтно, что ещё можно делать, кроме как кидать готовые компоненты вообще без обработчиков, чем он и проигрывает, так как без самостоятельной разработки кода с текста вообще нельзя сделать ничего толкового и хоть куда нибудь годного.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
[quote="""]Вовсе не бред, а нормальная ситуация. Длительность каждой команды (а точнее группы команд определенного вида) различна + задержки на занятость шины данных если операнд в памяти + задержки на выборку команды из кеша 1-го уровня и его обновление, если команда не выровнена по границам параграфа. А если брать в расчет многоконвеерное АЛУ, то..... Вообщем факторов достаточно много, на мой взгляд это настоящее искусство и отдельное направление в программировании - оптимизация кода. [/quote]
Знаю комп у которого вообще [b]нет конвейеров[/b], + [b]синхронная оперативка[/b], + [b]кэшей нет за ненадобностью[/b] , но одна команда может выполняться дольше, чем [b]одиннацать[/b]. Это по неблочным командам. А для блочных команд толко долгое исполнение - норма, а быстрое - анамалия. Но они и делают больше.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
[quote="""]осторожно 2009 юникод[/quote]
Я понимаю "осторожно ansi", но уникод? Раньше была куча проблем, для решения которых надо было каждый раз точно знать кодировку, а уникод решает их сам.