LINUX.ORG.RU

Разница между +1 и ++ в PHP


0

2

Не пойму в чем разница, вроде одно и тоже, но результат с массивами разный.
Например, если написать:

<?php
$img = array("0.png","1.png","2.png","3.png");
print_r($img);
$count = count($img);
$nextimg = $count++;
echo "<br>".$nextimg.".png"."<br>";
?>
То вывод будет верным и имя следующего изображения 4.png, но если написать так:
<?php
$img = array("0.png","1.png","2.png","3.png");
print_r($img);
$count = count($img);
$nextimg = $count+1;
echo "<br>".$nextimg.".png"."<br>";
?>
То вывод неверен, следующее изображение 5.png
В чем причина?

Вот всегда хотелось оторвать руки за строчки типа
nextimg = count++;

count++;
nextimg = count;

чего вот так вот не пишется, никаких разночтений

ilovewindows ★★★★★
()
Ответ на: комментарий от ilovewindows

Вот всегда хотелось оторвать руки за строчки типа...

Это ещё почему?! Если правильно юзать, ничего плохого не случается.

erfea ★★★★★
()
Ответ на: комментарий от erfea

Потому как постоянный источник ошибок, все равно как под крышей с сосульками гулять и думать про свою внимательность и ловкость.

ilovewindows ★★★★★
()
Ответ на: комментарий от ilovewindows

Потому как постоянный источник ошибок, все равно как под крышей с сосульками гулять и думать про свою внимательность и ловкость.

Вообще-то здесь источником ошибок выступает криворукость быдлокодера. Если кодер понимает что делает оператор, ошибок он не допустит. Пример с сосульками не в тему.

erfea ★★★★★
()
Ответ на: комментарий от erfea

Это ещё почему?!

Это сишная боязнь. Там есть поведение, неопределённое по стандарту :)

a = a++ + ++a; — это стандартно работает во всех известных мне языках, проме Си/Си++ :)

И хотя конструкции, типа nextimg = count++; совершенно безопасны, стандартны и много лет используются на практике, у обжёгшихся на предыдущем варианте возникает баттхёрт :)

KRoN73 ★★★★★
()
Ответ на: комментарий от ilovewindows

В первом случае тоже никаких разночтений быть не может. Как еще это можно прочитать кроме как «count -> nextimg, count + 1 -> count»? Руки нужно отрывать когда count с обеих сторон оператора присваивания.

urxvt ★★★★★
()
Ответ на: комментарий от Deleted

но пихать хитрожопость в код не стоит.

Что хитрого в простейшей операции, характерной для языка, строго описанной в стандарте?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

В стандарте много чего описано, но когда для простого чтения нужно туда заглядывать «на всякий случай»… не. Это сейчас, пока пишешь, всё понятно, а потом, когда будешь баги искать, сиди гадай «что хотел сказать автор». Может он ошибся и хотел другое?

Это как с {} в if(). С одной командой можно их не ставить, но если пишешь в несколько строк, то лучше поставить во избежание.

Deleted
()
Ответ на: комментарий от KRoN73

a = a++ + ++a; — это стандартно работает во всех известных мне языках, проме Си/Си++ :)

А с чего бы это вдруг порядок вычисления слагаемых должен был бы совпадать с их порядком следования?

Как по мне, так логичней было бы сначала (++a) сделать, потом (a++) и потом сложить результаты.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Deleted

но когда для простого чтения нужно туда заглядывать «на всякий случай»

Ну какое ещё «на всякий случай» для var++??

KRoN73 ★★★★★
()
Последнее исправление: KRoN73 (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

А с чего бы это вдруг порядок вычисления слагаемых должен был бы совпадать с их порядком следования?

Потому что это в стандарте оговорено. Порядок вычислений там явно оговорён. Он, извини, нужен обязательно, так как вызываться могут функции. А в функциях, что характерно для Си, могут быть сайд-эффекты.

Как по мне, так логичней было бы сначала (++a) сделать, потом (a++) и потом сложить результаты.

Пиши свой язык, со своими стандартами.

KRoN73 ★★★★★
()
Ответ на: комментарий от Deleted

Это как с {} в if(). С одной командой можно их не ставить, но если пишешь в несколько строк, то лучше поставить во избежание.

Меня удручает уровень современных программистов. И эти люди ещё что-то про PHP говорят.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Ты помнишь все случаи, описанные в стандарте? Уверен, что помнишь их все и правильно? Зачем создавать себе проблемы?

Deleted
()
Ответ на: комментарий от KRoN73

Что сказать то хотел? Если ты привык писать код, который выглядит как говно, это одно, но других заставлять не надо.

Deleted
()
Ответ на: комментарий от Deleted

Ты помнишь все случаи, описанные в стандарте?

Ещё раз. Если такие банальные вещи вызывают у народа проблемы памяти, то мне печально за будущее программирования. Следующий этап — не помнить, что у умножения приоритет выше сложения и считать, что 2+2*2 == 8. На самом деле таких уже много, но программирование на Си, всё же, требует хотя бы минимального уровня знаний.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Ещё раз. Для чего ты так пишешь? Экономишь на переводе строки или хочется показать, что стандарт знаешь?

Deleted
()
Ответ на: комментарий от Deleted

Если ты привык писать код, который выглядит как говно, это одно, но других заставлять не надо.

Чую я, для вас скоро вызов тригонометрии какой-нибудь или работа с указателями «говном» будет скоро. OMFG...

«Как говно» пишут в массе неявных конструкций на Perl или Ruby. Но работа с инкрементами никогда не считалась write-only кодом.

Я очень глубоко скорблю.

KRoN73 ★★★★★
()
Ответ на: комментарий от Deleted

Для чего ты так пишешь?

Потому что это удобно, очевидно и однозначно. Соответствующая конструкция языка именно для такого использования и вводилась. Кстати, for ты тоже пишешь как (for int i = 0; i < 10; i = i + 1)?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Отлично. Чем

if (x)
    blahblah();
лучше
if (x) {
    blahblah();
}
? Когда настигнет человеческий фактор и кто-нибудь ошибётся вставив команду, будет очень интересно.

Deleted
()
Ответ на: комментарий от KRoN73

Пример некорректен. Там одно действие и хоть так, хоть сяк запиши. В nextimg = count++ их два.

Deleted
()
Ответ на: комментарий от KRoN73

Для человека, не видящего семантического мусора — ничем.

Готов не согласиться!

«Мне кажется что знаки препинания не нужны там где и так всё понятно».

obinos
()
Ответ на: комментарий от Deleted

вопрос скорее в общем падении того уровня который считают мастерством.

живи быстро и избегай нюансов и на выходе получаем JAVA c её разумной бюрократией.

qulinxao ★★☆
()
Ответ на: комментарий от obinos

Аналогия некорректна, так как в данном случае «знаки препинания» избыточны. Они не требуются ни по грамматике языка, ни по его семантике.

KRoN73 ★★★★★
()
Ответ на: комментарий от qulinxao

В том примере только один. Обычно их пишут в строку, но предположим оно длинное, да и условие тоже. Ставить {} не обязательно, но может избавить от лишних телодвижений и усилий в будущем.

Deleted
()
Ответ на: комментарий от Deleted

да блин. ясно понятно что есть составные VS простные стэйтмент ( операторы при не точном переводе на великий и могучий)

можно и один оператор для удобства разнести в несколько строк - что не делает появление операторных скобок необходимым.

может . и да рекомендовано . и да язык успел вырватся из лаборатории так , что оставили как есть :)

qulinxao ★★☆
()
Ответ на: комментарий от KRoN73

Аналогия некорректна, так как в данном случае «знаки препинания» избыточны. Они не требуются ни по грамматике языка, ни по его семантике.

Вполне корректна. Отсутствие знаков препинания не меняет смысл приведённого предложения. Просто, русский язык имеет более строгие требования к пунктуации, чем языки программирования. И, как мне кажется, именно по той же причине, по которой в coding standarts часто присутствует обязательное требование заключать в фигурные скобки даже тела циклов и условных ветвлений, состоящих из одного утверждения.

obinos
()
Ответ на: комментарий от obinos

Вполне корректна. Отсутствие знаков препинания не меняет смысл приведённого предложения.

Некорректна. Отсутствие знаков препинания в русском смысл не всегда меняет, но делает фразу невалидной.

KRoN73 ★★★★★
()
Ответ на: комментарий от obinos

Отсутствие знаков препинания не меняет смысл приведённого предложения.

Что за глупость? Очень часто меняет. Хотя-бы вопросительный знак в конце предложения кардинально меняет его смысл, отсутствующая запятая тоже часто выворачивает смысл предложения наизнанку. Про набившее оскомину «казнить нельзя поминовать» вообще молчу.

Kalashnikov ★★★
()
Ответ на: комментарий от obinos

ха?

естественный язык по определению более либерален в соблюдения синтаксиса чем машиный :)

появление coding standards скорее связано с тем что у законодателя стиля нет власти перекорёжить под себя определение языка программирования.

qulinxao ★★☆
()
Ответ на: комментарий от KRoN73

Отсутствие знаков препинания в русском смысл не всегда меняет, но делает фразу невалидной.

В определённых кругах людей очень даже валидная.

Но кроме прочего, отсутствие знаков в привычных местах заставляет перечитывать код (текст) и замедляет понимание. Это не вопрос валидности, это вопрос удобства чтения и общего единообразия. Так что, «ненужные» фигурные скобки это порой не «синтаксический мусор», а более строгие требования к языку поверх существующих, облечающих совместную работу над текстом.

obinos
()
Ответ на: комментарий от Kalashnikov

Что за глупость? Очень часто меняет

А в чём смысл игнорировать часть слов в посте? Я лишь говорил про определённое предложение, приведённое мною несколькими постами выше.

И уж тем более, я не брал на себя ответственность говорить за все возможные случаи.

obinos
()
Ответ на: комментарий от qulinxao

естественный язык по определению более либерален в соблюдения синтаксиса чем машиный :)

Для большинства естественный язык либерален, соглашусь.

А у некоторых людей отсутствие запятой в нужном месте может вызвать полное отторжение всего дальнейшего текста и самого автора (см. «grammar nazi»).

obinos
()
Ответ на: комментарий от obinos

В определённых кругах людей очень даже валидная.

Ну, в Питоне тоже фигурных скобок нет :)

KRoN73 ★★★★★
()
Ответ на: комментарий от PolarFox

А в go {} вроде как ставить обязательно, даже если оператор внутри один.

Можно ещё причуды Перла вспомнить :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Deleted

Стандарт ,кстати, менялся. Сначала префиксной формы вообще не было,
Потом i++ и ++i было одним и тем же, по какому-то стандарту или это просто была «фича» конкретного компилятора не знаю, но такую фигню видел.

зы. В паскале ++ нет, есть процедура Inc , её в выражение не вставишь.
У «двуязычных» поневоле вырабатывается стиль написания i++; отдельной строкой.
Все эти приколы , инкремент в сложном выражении или a=b=c; , тащатся со времен перехода с ассемблера на С, типа С считался медленным и надо руками «оптимизировать» . В выражении a=a+1; будут задействованы два регистра и несколько инструкций , а a++; транслируется в inc ax; Но соревноваться с современными компиляторами в оптимизации на фоне тормознутой навороченности библиотек, имхо, без шансов.

Скобки {}, даже пустые вызывают какое-то шаманство с регистрами sp и bp , типа отводят в stack место под переменные и фанатами «быстрого» кода на си тоже не приветствуются,ну или знатоками стандартов и фич, но опять же рано или поздно вляпываешься при вставке строки в for без { } со 100% вероятностью.

ilovewindows ★★★★★
()
Ответ на: комментарий от ilovewindows

о каком языке речь?

можно по подробней?

это(не отличимость ш++ и ш++ как составной части выражения ) была фича недокомпилятора.

пустые скобки {} - не обязаны гарантировать шаманство с sp и bp ибо их(sp и bp) в стандарте нет :)

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Про C, Borland Turbo C 1.0 или Borland Turbo C++ 1.0 где-то так ,как уж он там назывался. И не утверждаю что есть в стандарте, может это и убиралось оптимизатором или только для asm файла генерилось.

ilovewindows ★★★★★
()
Ответ на: комментарий от qulinxao

пустые скобки {} - не обязаны гарантировать шаманство с sp и bp ибо их(sp и bp) в стандарте нет :)

Да и не будут. Тут путаница между пустыми скобками и скобками без управляющих конструкций, создание новой области видимости. Совершенно разные сущности :)

...

Вообще, тема забавный индикатор каши в голове многих нынешних сишников. Что-то мне кажется, что всего лет 5 назад на ЛОРе такого не могло быть. Что-то поменялось?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

ну ежель вспоминать предков то операторные скобки могут быть как у именнованой сущьности (блок исполнения у procedure-routen-function) , так и анонимного составного оператора.

под {} подразумевал операторные скобки содержащие некое действие.

тема - забавный индикатор изменения и сепарации по мере жизни того или иного комьюнити

осень юзенета она такая.

qulinxao ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.