Новая тема   Ответить

 Teacher-X
ШЕФФ писал:

Извини, но весь твой пост - ерунда. Так $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'ов. И ещё представь, что шаблон достаточно большой и в нем много символов #. Что получится, ессно ерунда.

 _s_[sov]
Во-первых я только учусь
Во-вторых про форич я в курсе, просто тут чет решил for заюзать.
В-третьих причем тут пробел? Как он на работу повлияет?
p.s. эт я отписал чтоб строго не судили!

 Cibtor
ШЕФФ писал: В РНР4 при использовании foreach создается копия массива в памяти.

 kot_murkin
xreload писал:
Пояснил бы где я не прав. Все продукты которые основаны на продукте под лицензией gpl должны быть тоже под лицензией gpl, так? GPL подразумивает предоставление исходного кода, так? А если ты предоставляешь исходный код, тогда какой же это коммерческий продукт, если каждый может его скомпилить у себя на сервере?

 Teacher-X
kot_murkin писал:

Вроде бы (я не уверен на 100%, т.е. это мои домыслы), если твоя прога, к примеру, использует возможности другой GPL-проги, но не является её модификацией и не включает в себя её код, то можно распространять свою прогу как угодно, но придется заставить юзера скачать необходимый для работы модуль.

Все сказанное является предположением, прямого подтверждения что-то нигде не могу найти (косвенные есть в тексте самой GPL), но и опровержения не видно

 Cibtor
ПЕРЕВОД НА РУССКИЙ ЯЗЫК GENERAL PUBLIC LICENSE (GNU)

 Sirgey
Цитата:
Ты не прав....
1. - 4 str_replace работают быстрее (нагрузка меньше) чем 1 preg_replace (не спорь).
2. foreach в php по определению не может работать быстрее чем for (ибо он ячейки меняет, а for только цифру инкрементирует)
3. foraech в php глючен, и если в цикле есть обращение с изменением массива по которому крутится forech, то есть вероятность что данные в памяти сломаются (опять - же не спорь, доверься моему опыту). Т.е. если вы пишите надёжный софт - foreach можно использовать только в циклах чтения / отображения, НЕ ПРИСВОЕНИЯ.
4. не буду про пробелы и точки

 xreload
Sirgey: батенька, когда страница отдается несколько секунд , то поверь абсолютно до жопы что ты там напишешь, серавно это займет времени много меньше чем время отдачи страницы, это гавно-оптимизация называется.

Хотя не спорю, что то, о чем ты выше сказал, сэкономят тебе пару миллисекунд, жалко что этого некто не оценит )

В PHP нужно научиться писать аккуратно и локанично и естественно безопасно, это самое главное имхо.

 Stek
Цитата:
пиздешь и провокация Всегда нормально форич работает, код грамотно просто писать надо.

 Sirgey
To xreload: при большом объёме текста разница во времени работы REGEXP и String функций КОЛОСАЛЬНА! Это не милисекунды, иногда это время сопоставимое с минутой или более! Согласен, что страницы по 400kb текста не бывают, но представь проект с нормальным загрузом. Строковая функция в среднем работает в 10 раз быстрее чем регулярка. Итого если ты не юзаешь медленные обращения к SQL ты теряешь 10x только на лаконичности, поверь - оно того не стоит. Не далее как позавчера ускорил работу не скажу какого скрипта раза в 4 заменив split (регулярка) на explode (строковая).
To Stek: я почти каждый день смешу весть кабинет нахождением интересных дыр в ядрах. Foreach очень часто затирает соседние ячейки массива с которым ты работаешь, особенно когда ты листаешь тот - же массив который изменяешь ( ветвишь текущую ячейку). Mysql, например, в некоторых версиях даёт разные результаты по групповым запросам в зависимости от регистра оператора GROUP (как только не пытались его переписывать, и GrOup и grOup - фишка не в регистре определённой буквы, он просто глючит...). Причём это именно ошибка его ядра, ибо ошибка не только при запросе из php, но и из консоли его собственой.

Итого: лаконичность - это классно, но на первом месте скорость работы кода и его надёжность => юзаем строковые функции и циклы типа for. А регулярки... суйте их в парсеры, там где скорость в общем - то не важна (основное время - запрос и сохранение в БД).

 Sirgey
А по теме топика - не изобретайте велосипед. Не забывайте что php - это в первую очередь именно шаблонизатор, а не язык програмирования (из своего названия). А следовательно именно его и надо юзать для построения шаблонов.
Смарти - удобно, есть конструкции удобные... но вы готовы отдавать 10-20% загруза за это? И не говорите что смарти работает при правильных руках так - же быстро как php, она не может так - же быстро работать, ибо после компиляции, даже если вы отключили оную на сервере, она гоняет обычный php код, только по объёму в раза 3 - 4 больший (посмотрите сорс скомпилированных шаблонов).
При умелых руках - php - мега удобный шаблонизатор, который ко всему прочему даёт вам всю полноту власти над шаблоном.
Трудитесь в радость!

 xreload
Sirgey: do you speak Russian ? Ты вообще понял о чем я говорю ? Прочитай еще раз и не смеши людей.

Повторяю что большинство времени уходит на коммуникационные проблемы, в результате пользователь ждет НЕСКОЛЬКО СЕКУНД, пока браузер загрузит html-код и отрендерит его, это время огромно по сравнению с работой скрипта, и поэтому смысла оно не имеет, я вообще не говорю про функции(!) , какая в жопу оптимизация в PHP, спустись с небес на землю.

 Sirgey
ты не прав. Время работы скрипта неважно когда у тебя сайт без нагрузки работает. Когда на него вешают хотя - бы 40k запросов в сутки - время имеет значение.
Да, можно купить железку с x2 памятью, и с x2 процессорами... но разве не проще код написать более быстроработающий?