нет, скобок как раз достаточно. они визуально разбивают наше условие на две логически равноправные части.
Горбунов Олег дело не в "попробывать" и в удобстве, а в производительности. Этим страдает .НЕТ, понавешали ООП всюду, а потом спрашиваю, почему так медленно... dark-demon честно? мне удобнее strlen(переменная), или там sizeof(переменная). Вообще не поддерживаю идею про скобки (точнее их упразднение), ибо только скобками формируется выражение, которое нельзя понять двусмысленно (и даже тени сомнений не появляется).
> честно? мне удобнее strlen(переменная), или там sizeof(переменная). strlen( 'а если вы захотите перевести приложение на использование юникода, то извольте везде поменять strlen на mb_strlen' ); > Вообще не поддерживаю идею про скобки (точнее их упразднение) скобки никто не упразняет. не знаю где ты такое вычитал.
dark-demon Ну, это вообще не аргумент. mb_strlen(str) vs. strlen(str) ничуть не хуже str.length vs. str.mb_length вопрос в том, есть в языке нативная поддержка Уникода или нет. В хорошем ЯП она конечно же должна быть
Эт недостаток реализации конкретных модулей/библиотек, а не языка как такового. Без string функций PHP будет спокойно работать, просто вам реализовывать их придётся ручками своими - только и всего.
> Ну, это вообще не аргумент. mb_strlen(str) vs. strlen(str) ничуть не хуже str.length vs. str.mb_length (0o._.o0) при объектном подходе в обоих случаях будет str.length фишка не в том, что язык не поддерживает юникод, а в том, что его нельзя безболезненно расширить для его поддержки.
armadillo именно, идет вызов конструктора, выделение памяти, а после отработки - free. Банальный random() в цикле, следуя правилам ООП будет создавать себя (если функция тоже объект), переменные в себе (если они объекты), возвращаться результат (неее, не в EAX, а тоже обектом, который нужно создать, у нас ведь супер-мега отречение от асма ), а потом заставить менеджер памяти почистить dark-demon не понял перекрыть strlen() нельзя? это должно быть в true-языке программирования по скобкам - извиняюсь, не понял кашу про приоритеты операторов в посте от "Вт Ноя 27, 2007 21:36" (блин, а разве нумерации постов в теме нету?)
извини за грубость, узнал много буков и выкладываешь. ПРи чем тут асм и причем тут rand ? Конкретный вменяемый пример и насколько медленнее?
armadillo http://delphimaster.ru/cgi-bin/forum.pl ... 1194091269 ЗЫ есть пример и с ВинАПИ, конкретно с Getpixels/Setpixels (точку на hdc можно раскрасить,грубо говоря), очень универсально и просто в использовании. При другом подходе (получение прямого адреса точки в памяти, учитывая заголовки и формат), обычным процедурным программированием дсотигается впечатлительных результатов (число под циклами - время выполнения в секундах): Код (Text): //======= запрос пикселя =============== { for i:=0 to 99999 do dds:=btte.Canvas.Pixels[10,10]; //winapi //0,13651316 } // for i:=0 to 99999 do // dds:=bt3.GD_GetPixel(10,10); //0,000983365 { for i:=0 to 99999 do dds:=bt3.GD_GetPixel_unsafe(10,10); //0,000810717 } //======= установка пикселя =============== { for i:=0 to 99999 do btte.Canvas.Pixels[10,10]:=clred; //winapi //0,045453821 } {for i:=0 to 99999 do bt3.GD_SetPixel(10,10,clred); //0,001177803 } { for i:=0 to 99999 do bt3.GD_SetPixel_unsafe(10,10,clred); //0,00103616 } ЗЗЫ ну а уж что такое WinApi наверное знаете, везде трезвонят, что так можно писать маленькие и быстрые прогрыммы. Вот только местами там перегружено все... ЗЗЗЫ кстати, потому и игры в последнее время тормозные выпускают - языки высокого уровня значительно облегчают разработку, скорость написания выше и командная работа более налаженная получается. Однако как результат - из-за всех этих ООП не к месту падает производительность
dark-demon Щазз! Как реализуешь, так и будет. Что, если нужна функция для определения длины строки в байтах?
antonn проблема у аффтора в голове. А закрашивать матрицу хотя бы по строкам ему в голову не приходило? Там кость? вы бы еще вместо pow(int a, int b) писали while () { while () { while (i<a) a++; а потом кричали что тормозит что-то внешнее.
+1 к antonn, отрицать, что ООП тормозит выполнение программы - глупо. Руби именно поэтому поначалу так настороженно воспринимали - существующая реализация дико тормозила.
armadillo код то смотрел? а спроси там, узнаешь много язвительных выражений, и почему нельзя во блин .net+производительность gui приложений - http://delphimaster.ru/cgi-bin/forum.pl ... 257475&n=3 кстати, просто вспомнилось - DirectX - это ООП, интерфейсная модель и все такое (если честно - ваще жуть по внешнему виду, хочется убежать куда нибудь), а OpenGL - процедурная модель. Многие предпочитают ОГЛ, потому что в некоторых моментах он быстрее, сделать проще некоторые вещи, но ДХ берет расширяемостью (ну и тем, что он то дальше развивается - хозяин есть, а у ОГЛ довольно туманное будущее).
armadillo При чем здесь "хорошо" или "плохо" - antonn сказал "медленнее", а не "хуже". У ООП, кроме тормозов, есть и другие преимущества
посмотрел, увидел что он попытался использовать что-то чужое (пусть и встроенное) Вопрос - при чем тут ООП? Ты сам хоть какие-то классы писал? процедурно нельзя загнать стек в даун или перегрузить что угодно вызовами и выделениями памяти? Проблема в головах, а не методах. Лечится усекновением головы. С тобой спорить я не буду, у тебя аргументы "Вася разбил жигуль, значит жигуль сакс."
Поясняю свои слова - кода ООП с тормозами я так и не увидел. Увидел его вызов, и заявления о тормозах. А какой индус его писал - неизвестно. Зато увидел непонимание у antonn что такое вообще ООП и зачем оно надо.
armadillo он использовал системную функцию (gdi+ - это улучшеная версия gdi, + прошитая вдоль и поперек ООП, именно через нее в висте рисуется Аеро, через gdi можно, но просто руками многое нужно делать), она оказалась медленной, написал свой велосипед и он оказался гораздо быстрее. Потому у него и вопрос возник, какого фига системная функция оказывается настолько медленней. нет, я только языком треплюсь классы написать не проблема, вопрос наверное - перегружал ли я методы класса, переопределял ли я их? тоже да дельфи и пхп имеют неплохие срадства ООП может я не так выразился, я против (хотя "против" как то странно звучит, тут просто дисскусия) представления типов как объектов. Т.е. число - это указатель на область памяти, в которой лежит значение. А не объект с методами типа length(), такие функции просто и быстро реализуются через процедурные методы - обычная procedure length(); объявленная глобально. ЗЗЫ хотя если этот труе-язык будет применяться в образовательных целях, или там странички хтмл генерить, где скорость глубоко по барабану (ну в пределах разумного, 0.1 сек или 0.5 - не важно) - делайте что хотите
armadillo Сочувствую. Для меня рассуждения о маразматических переливаниях из пустого в порожнее при работе с теми же целыми числами, обернутыми в классы, выглядели достаточно понятно. И именно так в том же Руби все и происходит.
antonn а, виста - уже пример быстрого кода? )))) с этим вопросом я совершенно согласен. При чем тут ООП? Dagdamor function getx() { return $this->$x*$this->multiplier; } предложи процедурный аналог (не полный, то есть function getx, а по "процедурной" логике) даже если multiplier меняется раз в год. Разумеется, стоит обсудить как оптимизировать и при необходимости написать пакетную обертку. У Борланда как пример TStringList смотрели? Но при чем тут ВСЕ ООП, которое
Сбавьте слегка обороты и не переходите на личности. Иначе буду вынужден прикрыть тему и забанить некоторых особо агрессивных особей. Хочу отметить, что агрументация "опытом" вместо фактов - показатель пустозвонства для меня. Поэтому прекратите флейм. Хотите аргументировать - сделайте тесты, замеры. Или если ссылетесь, то ссылайтесь не на авторитетных личностей, а не соседа Васю. Я придерживаюсь мнения Джоэля Спольски, который считает что "в наше время компьютеры удваивают мощность за 18 месяцев - потратьте это время на реализацию новых возможностей, вместо переписывания процедур на ассемблере"
armadillo учитывая, что рисование происходит не только по маске, но и постобработкой - довольно быстро должно быть по идее потому что пиксель там объект. Не указатель на массив, по котороум можно просто взять значение и изменить его, а объект, позволяющих переводить в разные цветовые модели (смук, хуе, ргб), делать всякие озвещения/затемнения и тп. Короче все то, что можно сделать обычной процедурой, и это будет жрать намного меньше памяти. наследник Tstrngs, добавлены методы сортировки, к примеру. В общем нормальный класс. вижу в дельфи есть понятие, попробую нарисовать, против чего я тут бурлю добавляя строку в Лист(Tstringlist) происходит - addtring('text'); при этом сама строка не хранится непосредственно в Листе, в лист добавляется указатель (тип pointer) на первый элемент string в памяти, при удалении указатель в nil, первый элемент строки в nil (хотя там более сложное, зато нет ошибки переполнения буфера). Если строку представить в виде объекта, со своими методами и тп, то нужно будет создать пустой объект, поместить указатель на него в Лист (более дурацкую идею поместить сам объект в Лист я отметаю), возможно заполнить поле text самим текстом. А после удаления строки из Листа, нужно высвободить память из под объекта. Накладные расходы, при "обычных" операциях они не видны, но вот при многократных повторениях (в циклах, вот захотели мы пузырьком отсортировать Лист) они выплывают. короче я про то, зачем числа и строки представлять объектами? наверное так надо было сразу спросить %)