сколько в памяти занимает объект класса ... var x,y:integer; ... ? Начнем с того, что TStringList выделяет память по 4 объекта сразу. И вообще ЗАНИМАЕТСЯ этим и вполне грамотно. Я не зря его привел как пример. Сортировать его похоже не пробовал )) Создавать, удалять и т.п. при операциях с объектами, в том числе при сортировке, не надо - не понимаю откуда эти идеи. Сортироваться вобще-то должны указатели. ну с числами вряд ли что-то можно сделать - хотя тоже можно добавлять новые команды процессора для ускорения, а строки явно могут обновляться по методам обработки, при этом не требуя обновления всего кода, написанного на планете. При первом же взгляде на AnsiString этот вопрос отпадает.
Придерживаюсь абсолютно обратной точки зрения, считаю что писать "Hello World" на каком нибудь сверх-кросс-босс-гусь-платформенном Зю#-/+.NET который после компиляции будет занимать 10Мб и тормозить на компах ниже 3GHz это эгоизм, сегодня компьютеры многозадачные и стоит учитывать что помимо вашей программы на фоне будут запущены десятки других программ которым так-же нужны процессорные такты и оперативные мегабайты... А по философии Джоеля надо ядро винды на PHP писать Начинающие PHP программеры готовы работать за копейки, а если их набрать 1000 человек и сделать новый "выньдос", потом вложить в рекламму оставшиеся 99% от бюджета разработки и распродать (а с таким бюджетом в рекламу успех практически гарантирован) то будет здорово. К тому моменту как ОСь будет готова компьютеры будут достаточно быстрыми чтоб тормозов не было...
Vladson писать самому без явных тормозов надо. уклоняться от заведомо тормозящих сред - тоже. Но тратить время и усилия на хелловорд, который делается в три с половиной клика и будет запускаться раз в день блондинкой, которой нужна БОЛЬШАЯ кнопка - не стоит. Но тут не об этом. Писать надо и быстро, и грамотно по структуре. Это возможно, если не биться заранее головой об стену "только ООП" или "ООП сакс". Именно для того, чтобы продукт был готов не к моменту написания ядер на ПХП. Изменение параметров точки (скажем разрядность) должны изменяться без изменения пользовательского кода. примеры аналогичных безумных "процедурных оптимизаций" тут приводились.
armadillo Вывод: на языке, который проектирует дарк-демон, можно будет писать только программы для блондинок.
Есть полно программ (сервисов/процедур/итд) которые не сильно сложнее "хелловорд" а тормозят как будто на 286-м работают. Простой пример FTP-клиент, его можно реализовать полностью в десяток килобайт (не считая GUI) если его написать на супер-пупер языке то он тормозить тоже не будет, просто будет требовать гиг оперативы и сам занимать пол гига. Да к моменту выхода продукта по 5-10 гигов оперативы будет стоять у всех, и HDD уже сейчас у многих по 500 гигов и выше, и экономически возможно выгоднее его таким сделать. Но разве если мы программисты и делаем программы ради денег, мы перестаём быть людьми ? Мы сами не будем пользоваться программами которые мы пишем ?
Vladson что ж ты не укладываешь свои программы в 64к? (com-файлы) )) да, надо соображать что творишь, и по выделению памяти и по ресурсам. Что такое пупер-язык - я не знаю. FTP-клиент должен писаться на С++. ПХП и прочие - это размен представления логики приложения на скорость, когда это выгодно (а выгодно чаще всего). Кой-чего можно и на прологе написать. И новый сервак стоит дешевле нового программиста. Мы живем в информационном обществе, производство инфы превосходит производство материальных вещей.
Что касается WEB сектора я вообще молчу. На какой сайт не зайди одни тормоза, и всё потому что писать новостную ленту в 10 строчек было дороже чем поставить нюку и исправить шаблон. В итоге десятки запросов к базе, а для генерации страницы достаточно было одного. В Win95 для просмотра папки (в режиме деталей, т.е имя/разрешение/размер/время) достаточно было 1 секунду на 486-м c 8MB оперативы, в Vista на P4-2.0 с 512MB по 5-10 секунд отображается тоже самое (я не говорю про случаи где отображаются все детали типа длительность MP3-треков, разрешение JPG файлов и.т.д. нет точно такой-же список не больше) Ощущение что весь GUI в WinXP и более поздних на JavaScript написан
armadillo без понятия сколько он будет занимать в труе-языке... я лишь образно показать, чего мне не понравилось итак, мы подошли к тому, чего мне небыло понятно с самого начала только что там за команды новые для ускорения? и причем тут процессор и труе-язык (да еще весь такой высокоуровневый)
Vladson в висте всякие thumbs создаются налет, плюс индексация, загрузка всяких рейтингов и прочей ерунды, что меня, в общем то, не радует...
в ТРУЪ - тоже не знаю, а в любом должен занимать 2*sizeof(int)+возможно что-то типа parent измени обработку кодировок в строке прозрачно для пользователя. или любой другой пример. Стандарт усложнился. и? Менять весь код планеты или как? Если уж писать "ТРУЪ" язык, то чтобы он работал в 2100 году в нанороботе в твоем кишечнике и не требовалось размораживать программиста по КОБОЛу. ))) да, это плохо. Хотя такова селява, серверы нынче дешевы. )) При чем тут ООП? )) Вот тебе пример: http://php.ru/forum/viewtopic.php?t=8703 стоит ли тратить время на это "ускорение"?
Об этом и речь. Философия что деньги важнее здравого смысла давно устоялась. Чем сделать нужный функционал на (образно говоря) ассемблере, лучше понапихать ненужных фишек которыми от силы 20% людей будут пользоваться. За то продать продукт можно будет не на 20% дороже а на 80%, а интересы большинства клиентов не интересуют, важно бабки с лохов срубить, и глюки раз в месяц затыкать. Ну а каждые 3-4 года собирать апдейты в сервис-паки менять название и продавать по двойной цене. Я с этой философией несогласен (считаю что клиент всегда прав) но похоже я такой один остался... Это к вопросу о росте скорости компов и мнении что скорость ПО дело второстепенное.
извиняюсь за банальный вопрос, но причём тут ооп??? нюка написана целиком на функциях. что лишний раз доказывает, что проблема в головах, а не в языке или в парадигме. число является объектом на уровне языка ( на высоком уровне ). на уровне интерпретатора (на низком уровне ) число является некоторым количеством подряд идущих байт. также замечу, что вы неправильно понимаете понятие "объект". объект - это сущность обладающая состоянием и поведением. так, например, числа в цпп являются объектами, ибо с помощью перегрузки операторов для разных типов чисел можно реализовать различое поведение. но они не являются экземплярами класса и хэш-таблицами. не надо путать понятие "объект" с понятием "хэш-таблица". первое - это абстракция, а второе - способ организации данных. объект не обязан быть хэш-таблицей, а хеш-таблица не обязательно является объектом. как мне видится низкоуровневая реализация примитивных объектов: каждое значение имеет идентификатор прототипа (бары байт более чем достаточно), который является хэш-таблицей и полностью определяет поведение своих наследников. итого - 64-битное целое будет занимать в памяти 10 байт, 32-хбитное - 6. вещественное двойной точности - 12. в языках типа пхп, идентификатор типа скорее всего занимает 1 байт, то есть разница незначительна. в языках со статической типизацией в идентификаторе типа вообще нет необходимости. также рекомендую ознакомиться с релизацией ооп в яваскрипте: http://darkodemon.blogspot.com/2007/10/ ... st_27.html любителям опускать руби предлагаю найти более адэкватного соперника, например, питон. ибо руби тормозит потому, что не компилируется в байткод и уж тем более не использует jit-компиляцию.
В том то и дело что не причём, не языки программирования нужны другие, и не концепции всяких типа ООП ООБ ООВ ИТД Любой язык из существующих прекрасно выполняет возложенные на него задачи, любой подход идеально подходит под свой круг задачь. Всё остальное (глюки/баги/дыры/итд) это человеческий фактор и не более, его никакими патчами не заделать... Так что труъ-язык программирования это тот где человеческий фактор не влияет на работу кода, но реализовать такой компилятор нереально в силу именно человеческого фактора, так что замкнутый круг. Такого языка не будет никогда (точнее будет, но глючный в силу опять таки человеческого фактора)
)) Концепции как писать не нужны? ))) Например, есть такие, у которых "свой круг задач" уже стремится к нулю. ))) У любого подхода есть свои специфичные варианты ляпов. Что этот подход не дискредитирует нисколько. Иногда полезно сокращать варианты выбора даже с ущербом в других местах, чтобы исключить часть ляпов. Скажем ту же перегрузку функций я бы трижды подумал, включать ли код к себе, если бы ее там обнаружил. больше 50% делают это ради себя лично не задумываясь о последствиях.
> Щазз! Как реализуешь, так и будет. Что, если нужна функция для определения длины строки в байтах? и зачем для строки определять длину в байтах? если очень приспичело, то любой объект можно конвертнуть в bytestream соответствующим методом > Любой язык из существующих прекрасно выполняет возложенные на него задачи если бы это было так, никто бы и не думал изобретать новые языки. например, если язык допускает случайное присваивание вместо сравнения - это плохой язык. в питоне, например, нельзя написать if( a = false ) и не словить исключение. казалось бы мелочь, а вот когда их много написание программы и её отладка превращается в каторгу.
нет, это проблемный программист. Есть синтаксис, который нужно выполнять, чего еще надо? схватили ексепшн - круто, пхп так вообще промолчит %) +1 точнее любую задачу (в пределах разумного, ИИ писать никто не будет) можно решить выбором уже существующего инструмента. Даже брайнфак нужен - чтоб могз парить и фигней страдать )
> нет, это проблемный программист. Есть синтаксис, который нужно выполнять, чего еще надо? тогда бери в руки асм и вперёд строгать программы. позови, когда что-нибудь получится...
dark-demon билет на самолет в Росиия/Приморье сам достанешь? Покажу цех с обновленными ФП-37 да и вообще, причем тут асм, это касается всех языков.
Знаете что я думаю? Что вы страдаете фигнёй. Что такое язык? Это основа, по правилам которой пишется код с определённым набором операторов и конструкций. Всё остальное это библиотеки, наборы классов и.т.д. (пусть и стандартных, идущих в комплекте). Если эти наборы сделаны через заднее место - то даже идиальный язык превратится в занозу, не, даже не занозу, а огромное шило в заднем проходе. Я сказал.
если бы кто-то в своё время не "пострадал от фигни", то все бы до сих пор писали бы на ассме. и библиотеки. и некоторое подобие классов. и тд.