С нами с 27.06.07
Сообщения: 289
Рейтинг: 247
|
Добавлено: 07/07/07 в 23:57 |
ШЕФФ писал: | $data = str_replace("#title#", $up , $file);
$data = str_replace("#body#", $body, $data);
$data = str_replace("#url#", $lin, $data);
$data = str_replace("#footer#", $foot, $data);
все это меняешь на только имена переменых должны совпадать с тем что в решетках.
$data= preg_replace("/#(\w+)#/ee", "$\\1",$data);
да и вобще логика програмы через жопу. для масивов всегда используй foreach она гораздо быстрей for
$lin.= "<a href='http://$arr[$i]'>$arr[$i]</a><br>"; проще так написать, да и пробел $lin.= между точкой и именем переменой нельзя ставить. |
Извини, но весь твой пост - ерунда. Так $lin .= писать можно, это раз.
Так $lin.= "<a href='http://$arr[$i]'>$arr[$i]</a><br>"; писать можно, но не нужно, это два. Если только $lin.= "<a href='http://{$arr[$i]}'>{$arr[$i]}</a><br>";.
Ну и в третьих, вот это $data= preg_replace("/#(\w+)#/ee", "$\\1",$data); вообще что? Откуда уверенность, что все куски текста между ## являются макросами? Где проверка их существования? Твой код вызывает появление Notice'ов. И ещё представь, что шаблон достаточно большой и в нем много символов #. Что получится, ессно ерунда.
|
|
|
|
php
С нами с 09.10.06
Сообщения: 3706
Рейтинг: 2410
|
Добавлено: 08/07/07 в 07:52 |
Во-первых я только учусь
Во-вторых про форич я в курсе, просто тут чет решил for заюзать.
В-третьих причем тут пробел? Как он на работу повлияет?
p.s. эт я отписал чтоб строго не судили!
|
|
|
|
С нами с 26.02.03
Сообщения: 2366
Рейтинг: 987
|
Добавлено: 08/07/07 в 13:24 |
ШЕФФ писал: | да и вобще логика програмы через жопу. для масивов всегда используй foreach она гораздо быстрей for |
В РНР4 при использовании foreach создается копия массива в памяти.
|
|
|
|
С нами с 26.02.06
Сообщения: 55
Рейтинг: 37
|
Добавлено: 12/07/07 в 12:25 |
xreload писал: | прочитай лицензию и не пиши бред... |
Пояснил бы где я не прав. Все продукты которые основаны на продукте под лицензией gpl должны быть тоже под лицензией gpl, так? GPL подразумивает предоставление исходного кода, так? А если ты предоставляешь исходный код, тогда какой же это коммерческий продукт, если каждый может его скомпилить у себя на сервере?
|
|
|
|
С нами с 27.06.07
Сообщения: 289
Рейтинг: 247
|
Добавлено: 14/07/07 в 23:05 |
kot_murkin писал: | Пояснил бы где я не прав. Все продукты которые основаны на продукте под лицензией gpl должны быть тоже под лицензией gpl, так? GPL подразумивает предоставление исходного кода, так? А если ты предоставляешь исходный код, тогда какой же это коммерческий продукт, если каждый может его скомпилить у себя на сервере? |
Вроде бы (я не уверен на 100%, т.е. это мои домыслы), если твоя прога, к примеру, использует возможности другой GPL-проги, но не является её модификацией и не включает в себя её код, то можно распространять свою прогу как угодно, но придется заставить юзера скачать необходимый для работы модуль.
Все сказанное является предположением, прямого подтверждения что-то нигде не могу найти (косвенные есть в тексте самой GPL), но и опровержения не видно
|
|
|
|
С нами с 26.02.03
Сообщения: 2366
Рейтинг: 987
|
Добавлено: 14/07/07 в 23:55 |
|
|
|
|
С нами с 16.04.05
Сообщения: 754
Рейтинг: 352
|
Добавлено: 15/07/07 в 05:08 |
Цитата: | $data = str_replace("#title#", $up , $file);
$data = str_replace("#body#", $body, $data);
$data = str_replace("#url#", $lin, $data);
$data = str_replace("#footer#", $foot, $data);
все это меняешь на только имена переменых должны совпадать с тем что в решетках.
$data= preg_replace("/#(\w+)#/ee", "$\\1",$data);
да и вобще логика програмы через жопу. для масивов всегда используй foreach она гораздо быстрей for
$lin.= "<a href='http://$arr[$i]'>$arr[$i]</a><br>"; проще так написать, да и пробел $lin.= между точкой и именем переменой нельзя ставить. |
Ты не прав....
1. - 4 str_replace работают быстрее (нагрузка меньше) чем 1 preg_replace (не спорь).
2. foreach в php по определению не может работать быстрее чем for (ибо он ячейки меняет, а for только цифру инкрементирует)
3. foraech в php глючен, и если в цикле есть обращение с изменением массива по которому крутится forech, то есть вероятность что данные в памяти сломаются (опять - же не спорь, доверься моему опыту). Т.е. если вы пишите надёжный софт - foreach можно использовать только в циклах чтения / отображения, НЕ ПРИСВОЕНИЯ.
4. не буду про пробелы и точки
|
|
|
|
С нами с 19.11.03
Сообщения: 3973
Рейтинг: 2362
|
Добавлено: 15/07/07 в 08:30 |
Sirgey: батенька, когда страница отдается несколько секунд , то поверь абсолютно до жопы что ты там напишешь, серавно это займет времени много меньше чем время отдачи страницы, это гавно-оптимизация называется.
Хотя не спорю, что то, о чем ты выше сказал, сэкономят тебе пару миллисекунд, жалко что этого некто не оценит )
В PHP нужно научиться писать аккуратно и локанично и естественно безопасно, это самое главное имхо.
|
|
|
|
www.phpdevs.com
С нами с 24.10.02
Сообщения: 16633
Рейтинг: 16105
|
Добавлено: 15/07/07 в 12:08 |
Цитата: | foraech в php глючен, и если в цикле есть обращение с изменением массива по которому крутится forech, то есть вероятность что данные в памяти сломаются (опять - же не спорь, доверься моему опыту). |
пиздешь и провокация ![icon_smile.gif](/template/images/smiles/icon_smile.gif) Всегда нормально форич работает, код грамотно просто писать надо.
|
|
Пишу на php/mysql/django за вменяемые деньги.
Обращаться в личку.
|
0
|
|
|
С нами с 16.04.05
Сообщения: 754
Рейтинг: 352
|
Добавлено: 15/07/07 в 14:35 |
To xreload: при большом объёме текста разница во времени работы REGEXP и String функций КОЛОСАЛЬНА! Это не милисекунды, иногда это время сопоставимое с минутой или более! Согласен, что страницы по 400kb текста не бывают, но представь проект с нормальным загрузом. Строковая функция в среднем работает в 10 раз быстрее чем регулярка. Итого если ты не юзаешь медленные обращения к SQL ты теряешь 10x только на лаконичности, поверь - оно того не стоит. Не далее как позавчера ускорил работу не скажу какого скрипта раза в 4 заменив split (регулярка) на explode (строковая).
To Stek: я почти каждый день смешу весть кабинет нахождением интересных дыр в ядрах. Foreach очень часто затирает соседние ячейки массива с которым ты работаешь, особенно когда ты листаешь тот - же массив который изменяешь ( ветвишь текущую ячейку). Mysql, например, в некоторых версиях даёт разные результаты по групповым запросам в зависимости от регистра оператора GROUP (как только не пытались его переписывать, и GrOup и grOup - фишка не в регистре определённой буквы, он просто глючит...). Причём это именно ошибка его ядра, ибо ошибка не только при запросе из php, но и из консоли его собственой.
Итого: лаконичность - это классно, но на первом месте скорость работы кода и его надёжность => юзаем строковые функции и циклы типа for. А регулярки... суйте их в парсеры, там где скорость в общем - то не важна (основное время - запрос и сохранение в БД).
|
|
|
|
С нами с 16.04.05
Сообщения: 754
Рейтинг: 352
|
Добавлено: 15/07/07 в 14:53 |
А по теме топика - не изобретайте велосипед. Не забывайте что php - это в первую очередь именно шаблонизатор, а не язык програмирования (из своего названия). А следовательно именно его и надо юзать для построения шаблонов.
Смарти - удобно, есть конструкции удобные... но вы готовы отдавать 10-20% загруза за это? И не говорите что смарти работает при правильных руках так - же быстро как php, она не может так - же быстро работать, ибо после компиляции, даже если вы отключили оную на сервере, она гоняет обычный php код, только по объёму в раза 3 - 4 больший (посмотрите сорс скомпилированных шаблонов).
При умелых руках - php - мега удобный шаблонизатор, который ко всему прочему даёт вам всю полноту власти над шаблоном.
Трудитесь в радость!
|
|
|
|
С нами с 19.11.03
Сообщения: 3973
Рейтинг: 2362
|
Добавлено: 15/07/07 в 15:35 |
Sirgey: do you speak Russian ? Ты вообще понял о чем я говорю ? Прочитай еще раз и не смеши людей.
Повторяю что большинство времени уходит на коммуникационные проблемы, в результате пользователь ждет НЕСКОЛЬКО СЕКУНД, пока браузер загрузит html-код и отрендерит его, это время огромно по сравнению с работой скрипта, и поэтому смысла оно не имеет, я вообще не говорю про функции(!) , какая в жопу оптимизация в PHP, спустись с небес на землю.
|
|
|
|
С нами с 16.04.05
Сообщения: 754
Рейтинг: 352
|
Добавлено: 15/07/07 в 15:45 |
ты не прав. Время работы скрипта неважно когда у тебя сайт без нагрузки работает. Когда на него вешают хотя - бы 40k запросов в сутки - время имеет значение.
Да, можно купить железку с x2 памятью, и с x2 процессорами... но разве не проще код написать более быстроработающий?
|
|
|
|