Не злоупотребляйте unset при разработке web-приложений!!! Дело в том что возврат управления из скрипта сильно затягивается и данные клиенту отправляются позже. Т.е. высвобождение ресурсов производится во время выполнения скрипта, а не после ( автоматическим сборщиком мусора ). Можно посоветовать связку unset и flush, либо полностью положиться на сборщик (что лучше). // KCacheGrid попробуй поюзать для общего развития, а потом говносоветы давай
либо пишите так чтобы unset надобился максимально редко. Я вот сейчас чисто из интереса пересмотрел немалую часть кода - не нашел ни одного случая, где я не уверен в содержимом переменной и одновременно оно имеет значение.
Как раз unset() надо пользовать...
NULL только приравнивает переменную нулю... (т е сама переменная остается в памяти), а ансет - удаляет переменную...
Кстати со времен доса, тот кто писал всегда переменные обьявляет и обязательно убивает... памяти тогды мало было, а сейчас с жиру все бесятся... :)
Не смешно что-то... Очень глупая ошибка, которую очень просто избежать в PHP, не отрубая E_WARNINGS. Там, где нужно, пишется @intval($var) или по ситуации.
Что касается инклудов скриптов - не случайно во всех хороших и не очень CMSках, состоящих из кучи файлов, первой строчкой стоит проверка, типа if ( ! defined( 'IN_IPB' ) ). Держите это в голове и будет вам щастъе. :)
Насчет Е_STRICT поддержу, единственная проблема - использование Библиотек, писаных как под 4-ку, так и под 5-ку. Кучу барахла выкидывает. А уж как косоворотит ненавидимую вами систему и без E_STRICT... Буэээ ;)
А вот тут ошибаетесь, просто надо грамотно использовать. Например в шаблоне "Друзей ". Но абсолютно точно нельзя использовать для @get_num($intUserID) или @require_once. P.S. У меня всегда E_STRICT + перехват ошибок и исключений singleton ErrorHandler.
Шаблонизатор хабра глючит. Имелось ввиду "Друзей: <=@(int)$num>". Или $db->squery('SELECT id,name FROM entity WHERE id = ?',(int)@$arRequest[0]);
@ + /dev/hands = красивый безопасный код
Никогда не видел чтобы (int) плевалась. Ни варнигом, ни даже нотисом. Проверил сейчас еще раз (5.1.4), посмотрел даже мануал. Так что, если это был единственный пример "умного" использования @, то можете смело больше ее не использовать :)
Ой, может вы так защищаетесь от неинициализированной $num? Ну тогда уже проще не показывать вообще все нотисы, чем плодить собачек. Может я просто не понял кто такие "друзья" которые вставляют разный бред?
class Database implements IDatabase
{
....
public function result($result, $row, $field)
{
if(!is_resource($result)) throw new DatabaseException($this->error());
return(mysql_result($result,$row, $field));
}
....
}
В контроллере:
$intUsersCount = @(int)$db->result($db->query('SELECT COUNT(id) FROM `users`'),0,0);
Догадываешься для чего тут "@" ?
P.S. Нормальные люди все ошибки и NOTICE напрваляют в журнал. И нихуя не одупляют когда
у них журнал засран NOTICE'ами для нормального поведения.
P.P.S я так понял вы обработку ошибок и журнализацию не используете. Это лечиться, но трудно
ППЦ, мы все отстали от жизни!!!! Позвони всем чтобы срочно переходили. Система по требованиям должна поддерживать mysql. У нас в т.ч. есть версия mysqli. Тока никому не говори.
Так вот если пользователя не существует, контроллер промапит $user = false;
Шаблон выведет:
Пользователь:
Друзей: 0
Если убрать @ то и int. То шаблон будет
завален NOTICE'aми.
Так что сдесь без @ нормульно не обойтись.
А насчет @require_once это еще не уникумы. У 30% проектов которые мне
приходилось видеть не закрыт FCKEditor Browser и у проц 60% SQL injecttion. Люди еще
не знают что такое placeholder'ы и прочая пофигистика.
Так вот если пользователя не существует, контроллер промапит $user = false;
Шаблон выведет:
Пользователь:
Друзей: 0
Если убрать @ то и int. То шаблон будет
завален NOTICE'aми.
Так что сдесь без @ нормульно не обойтись.
А насчет @require_once это еще не уникумы. У 30% проектов которые мне
приходилось видеть не закрыт FCKEditor Browser и у проц 60% SQL injecttion. Люди еще
не знают что такое placeholder'ы и прочая пофигистика.
Ну потомучто у тебя ( error_reporting(E_NOTICE)):
1 случай: Notice: Undefined variable: User
2 случай если не инициализировано $User['name']: будет NOTICE undefined index
3 не инициализировано $User['Friends'], то даже при приведении к типу int: будет NOTICE undefined index
Короче как бы не хотели NOTICE,"@" и читаемый код не разделимы. Главное не тыкать @ куда не надо
Если мне пришел вменяемый результат из вызова $db->fetchAll(), а не Object(DB_Error), то собаки тут нахрен не нужны. А если DB_Error, то тут и собаки не спасут.
Устал уже, сникерсни.
1) Object(DB_Error) к тебе в жизни не придет. Так как Exception ловиться catch, а не возвращается функцией.
2) mysql_fetchАра возвращает либо массив, либо фалсе. И там допустим забыли запросить поле friends и т.д.
День был тяжелый, пиво кончилось, пойду посплю и на завод. :D
Перед уходом:
Человек работает в комманде. Нужно разработать свой кусок с позиции что меня все хотят наебать. И мне всеравно как данные будут обработаны в контроллере. У меня задача написать стрессоусточиый кусок кода. Не полагаясь на то что контроллер не забудет инициализировать переменную.
Например: был пользователь, его удалили, пользователь переходит по ссылки с ID удаленного пользователя. Если программист писавший контроллер не отработал такую ситуацию, то я все равно должен вывести шаблон грамотно. У меня есть свой атомарный кусок кода в котором не должны выскакивать Notice.
Аналогия такая: С++ приложение работающее с внешним миром через сокеты. Я не верю тому что мне всегда буду приходить строки с длинной не привышаюшей длину 1024. Данные поступают из внешнего не контроллируемого мира => моя задача не допустить записать в буффер размером 1024 полученные 1028 байт. Иначе buffer overrun.
это из той же оперы, что указатели и множественное наследование использовать нужно, только осторожно... а вот кто-то с этим несогласен до такой степени, что придумал джаву
Не согласен ни разу. Попробуйте отключить ворны для большинства скриптов - сразу ошибки попрут (типа, "барахло"). Конечно, в 90% случаев на них можно положить, но оставшиеся 10% затрудняют отладку очень сильно - а в случае, когда ведется лог всех ошибок, всё становится гораздо проще.
Впрочем, и так ниже все за меня сказали. :)
Они самые. Тоже пишу под E_ALL, поэтому и использую @.
Скажем, в середине скрипта не вижу ничего плохого, если написать
if (!@$user) die(); :)
Чем это хуже if (!isset($user)) die(); ?
Нотайсом при разборе парсером.
Он все видит и вынужден утруждаться на подавление отклонения от нормы. Нагрузка, конечно, ерунда полная, но осадок остается.
Пора на питон :)
Там еще и числам можно методы ставить в соответствие. Представляете себе, у вас число - и объект!
Плюс - это минус, а минус - это плюс. И гениальная идея товарища - истина это ложь, а ложь это истина. Программист будет прямо Алиса в Зазеркалье :)
А если такую нотацию принять в команде и потом отдать проект на аутсорсинг... :)))
Не смешно конечно, жизненно. Но у меня получается либо инициализация и/или перезапись несуществующей ранее переменной, либо да - обнуление. Плюс фильтрация юзер-данных. В сложные ситуации по сабжу не попадал.
Если переменную объявить типа такого:
$a = 5;
то все в порядке, а если попытаться сделать ей без этого
$a++;
то получите Notice: Undefined variable in bla-bla-bla
1) unset делает переменную неинициализированной снова. При попытке обращения к ней - нотис.
2) удаляет элемент в массиве ($a[1]=null ничего не удалит)
...
ех... я ж еще паралельно филолог по образованию... украинский и английский... а русский учу самостоятельно, ибо приходитса последним временем... так что не судите строго... главное - семантика сообщения, которое я хочу донести...
Почитал про нотисы, вспомнил какие из-за них иногда бывают необычные ошибки, посмотрел серьезные и забавные примеры кода. Хотел сказать что-то умное, но оказывается, почти все уже сказано :)
На ум в результате пришел забавный "исходный код" windows. Надеюсь, он поднимет настроение и вам :)
#include
#include
#include /* Microsoft Network Connectivity library */ #include
/* For the court of law */
void main()
{
if (latest_window_version>one_month_old) {
if (there_are_still_bugs)
market(bugfix);
if (sales_drop_below_certain_point)
raise(RUMOURS_ABOUT_A_NEW_BUGLESS_VERSION); }
while(everyone_chats_about_new_version)
{
make_false_promise(it_will_be_multitasking); /* Standard Call, in
lie.h */
if (rumours_grow_wilder)
make_false_promise(it_will_be_plug_n_play); if (rumours_grow_even_wilder)
{
market_time=ripe;
say("It will be ready in one month);
order(programmers, stop_fixing_bugs_in_old_version); order(programmers,
start_brainstorm_about_new_version); order(marketingstaff,
permission_to_spread_nonsense); vapourware=TRUE;
break;
}
}
switch (nasty_questions_of_the_worldpress) {
case WHEN_WILL_IT_BE_READY:
say("It will be ready in", today+30_days," we're just testing"); break;
case WILL_THIS_PLUG_AND_PLAY_THING_WORK:
say("Yes it will work");
ask(programmers, why_does_it_not_work);
pretend(there_is_no_problem);
break;
case WHAT_ARE_MINIMAL_HARDWARE_REQUIREMENTS:
say("It will run on a 8086 with lightning speed due to"
" the 32 bits architecture");
inform(INTEL, "Pentium sales will rise skyhigh"); inform(SAMSUNG, "Start a
new memorychip plant"
"'cos all those customers will need at least 32 megs"); inform(QUANTUM,
"Thanks to our fatware your sales will triple"); get_big_bonus(INTEL,
SAMSUNG, QUANTUM);
break;
case DOES_MICROSOFT_GET_TOO_MUCH_INFLUENCE:
say("Oh no, we are just here to make a better world for
everyone");
register(journalist, Big_Bill_Book);
when(time_is_ripe)
{
arrest(journalist);
brainwash(journalist);
when(journalist_says_windows95_is_bugfree) {
order(journalist, "write a nice objective article"); release (journalist);
}
}
break;
}
while (vapourware)
{
introduction_date++; /* Delay */
if (no_one_believes_anymore_there_will_be_a_release)
break;
say("It will be ready in",today+ONE_MONTH); }
release(beta_version)
while (everyone_is_dumb_enough_to_buy_our_bugware) {
bills_bank_account += 150*megabucks;
release(new_and_even_better_beta_version); introduce(more_memory_requirements);
if (customers_report_installation_problems) {
say("that is a hardware problem, not a software problem"); if
(smart_customer_says_but_you_promised_plug_and_play) {
ignore(customer);
order(microsoft_intelligence_agency, "Keep an eye on this
bastard");
}
}
if (there_is_another_company)
{
steal(their_ideas);
accuse(company, stealing_our_ideas);
hire(a_lot_of_lawyers); /* in process.h */
wait(until_other_company_cannot_afford_another_lawsuit);
buy_out(other_company);
}
}
/* Now everyone realizes that we sell bugware and they are all angry at
us */
order(plastic_surgeon, make_bill_look_like_poor_bastard);
buy(nice_little_island); hire(harem);
laugh_at(everyone,
for_having_the_patience_year_after_year_for_another_unfinished_version); }
void bugfix(void)
{
charge (a_lot_of_money)
if (customer_says_he_does_not_want_to_pay_for_bugfix)
say("It is not a bugfix but a new version"); if (still_complaints)
{
ignore(customer);
register(customer, big_Bill_book);
/* We'll get him when everyone uses Billware!!*/ }
}
unset() использовал только в одном случае в жизни: когда делал анализатор логов и много мегов загнанных массив могли бы не дать скрипту нормально завершиться не вылетев с ошибкой allocated memory.
Но unset() по сравнению с жутко расточительными алгоритмами всяких подпольных cms смотрится как-то мелко :)
unset() и Буратино