За последние 24 часа нас посетили 43820 программистов и 1814 роботов. Сейчас ищут 890 программистов ...

Одинарные и двойные кавычки

Тема в разделе "Прочие вопросы по PHP", создана пользователем Psih, 31 май 2007.

  1. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Меня вот всё интересует вопрос, почему народ пишет HTML код в двойных кавычках, при этом упорно бекслеша все двойные кавычки (это ад, такое даже править не берусь - переписать с 0, либо отказаться вообще), предназначенные для обрамления значений атрибутов HTML тегов. Да и не только HTML, просто подстановка значений в строку (особенно удивляет когда это делаеться в SQL запросах - привет SQL Injection), пихают многомерные масивы в { } конструкции и.т.д.
    Я уж не придираюсь к тому, что двойные кавычки сами по себе медленее работают, а когда ещё приходиться разбирать всякие подстановки многомерных масивов, результатов работы функций и.т.д., то быстродействие ещё больше снижаеться.
     
  2. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Psih
    Одинарными кавычками не сделать перевод строки никак ;)
    Я пользуюсь двойными, привык еще со времен программирования на C.
    Насчет скорости работы: PHP, перед тем как выполнять код, сначала парсит его и превращает в последовательность команд на своем псевдоязыке, байт-код. С этой точки зрения фрагменты

    'строка1,' . $var . ',строка2'

    и

    "строка1,$var,строка2"

    ничем не отличаются - они превратятся в одну и ту же последовательность команд. А распарсится быстрее второй фрагмент - он синтаксически проще.
     
  3. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Dagdamor
    Дык, а вот тут ты не прав - парсинг кода - это одно. А ты во время выполнения посмотри что будет :)
    http://forums.overclockers.ru/viewtopic.php?p=1852433#1852433 моё, тестил конечно довольно давно, но всё-же реальность оно отображает. Исходник там-же.
    На то время даже для меня тесты были не очень актуальны эти. На сегодня - актуально, ибо каждый выжатый % улучшает ситуацию, потому что работать надо с проэктами 1-2 миллиона запросов в сутки и более.
     
  4. Vladson

    Vladson Старожил

    С нами с:
    4 фев 2006
    Сообщения:
    4.040
    Симпатии:
    26
    Адрес:
    Estonia, Tallinn
    Я когда такой код вижу сразу возникает непреодолимая тяга нажать на Delete :D
     
  5. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Psih
    Вот мои результаты: http://img159.imageshack.us/img159/7427/quoteson2.gif
    Разница минимальная, хотя двойные кавычки все-таки чуть медленнее.
    НО: у меня установлен опкод кеш, скорее всего дело в этом.
     
  6. nimistar

    nimistar Активный пользователь

    С нами с:
    30 май 2007
    Сообщения:
    919
    Симпатии:
    0
    Vladson и Psih - согласен ... правда сам иногда всетаки пишу и в двойных ... но тупо отучиваю себя от этого! с другом сами мерели .... тупо встовляли большой текст один раз с ', второй - "! выигрыш абалденный!!!!!

    всем советую переучится!
     
  7. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Dagdamor
    Ну в 5-й версии разница уже поменьше, видно соптимизировали. Такие вещи надо тестить на более-менее законченных скриптах, которые генерируют всю страницу сразу, ибо на одной строчке с одной переменной, сами понимаете, тест получаеться практически академическим...
     
  8. Vladson

    Vladson Старожил

    С нами с:
    4 фев 2006
    Сообщения:
    4.040
    Симпатии:
    26
    Адрес:
    Estonia, Tallinn
    В принципе разница в кавычках очень маленькая и иногда её не стоит принимать во внимание (т.е только в качестве "косвенного" фактора) но есть несколько основных факторов

    Например фактор циклы.
    Многие настолько мало знакомы с основами программирования что не учитывают тот фактор что в цикле где идут тысячи операций даже такие мелочи как кавычки могут стать большим тормозом

    Или например человечекий фактор.
    Многие исключают возможность будующей модернизации скрипта и пишут в стиле ROM (Read only Memory) забывая что редактировать потом все эти вещи будет сложно (местами очень сложно) между тем в 99% редактировать приходится (исправляя баги, и.т.д.) никто не застрахован от багов и ошибок.
     
  9. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    Запустил твой код под PHP 5.2.0 разница большая ;)
    Сам всё время использую одинарные кавычки, а когда надо добавить перевод строки то:
    Код (Text):
    1. 'Hello world!' . "\n"
    :)
     
  10. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    интересно, а что быстрее "\n" или chr(13)? :)
     
  11. Vladson

    Vladson Старожил

    С нами с:
    4 фев 2006
    Сообщения:
    4.040
    Симпатии:
    26
    Адрес:
    Estonia, Tallinn
    dark-demon
    Не знаю, но местами мне chr(13) нравится больше (хотя в теории он тормознутее должен быть)
     
  12. Hight

    Hight Старожил
    Команда форума Модератор

    С нами с:
    5 мар 2006
    Сообщения:
    7.153
    Симпатии:
    0
    Адрес:
    из злой параллельной вселенной
    PHP:
    1. <?php
    2. $pages[] = "<td class="link_cell"><a href="".HTTP."://".DOMAIN."/".PATH."/".$file."&page=".$i."".SID."" class="link_cell">".$i."</a></td><td>&nbsp;</td>";
    об этом речь?! дык.
    значит на такое предлагаете заменить
    PHP:
    1. <?php
    2. $pages[] = '<td class="link_cell"><a href="'.HTTP.'://'.DOMAIN.'/'.PATH.'/'.$file.'&page='.$i.''.SID.'" class="link_cell">'.$i.'</a></td><td>&nbsp;</td>';
    один фиг, одинакого читается. а вот про скорость - это интересно.
     
  13. Vitas

    Vitas Активный пользователь

    С нами с:
    7 фев 2006
    Сообщения:
    595
    Симпатии:
    0
    Адрес:
    Новосибирск, Академгородок
    +1
     
  14. AlexGousev

    AlexGousev Активный пользователь

    С нами с:
    25 мар 2006
    Сообщения:
    1.505
    Симпатии:
    0
    Адрес:
    Москва
    Да ничего интересного в скорости - копейки.

    Пишу одинарные кавычки всегда, потому что:
    1. в строке
    PHP:
    1. <?php echo '<a href="/fullimage'.$id.'_1.php" target="_blank"><img src="/'.$iname.'" '.$isize[3].' alt="'.$alt.'" title="Щелкните левой кнопкой мыши чтобы увеличить изображение"></a>'; ?>
    я четко вижу в редакторе (с подсветкой синтаксиса) где у меня переменные, а где просто строка;
    2. апостроф нажимается без шифта :)
     
  15. korchasa

    korchasa Активный пользователь

    С нами с:
    4 май 2006
    Сообщения:
    12
    Симпатии:
    0
    Ничего загадочного, просто для двойных запускается парсер для замены всяких \t \n \r и прочих заслешенных радостей.
     
  16. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    korchasa
    Не в этом дело. Парсер обрабатывает строку один раз, и переводит ее в байт-код один раз. Есть там спецсимволы, нет - парсеру один фиг, как и у любого клеточного автомата, его скорость зависит не столько от сложности выражения, сколько от длины исходного текста. Причины того, что "" строки медленнее '', несколько хитрее. ;)

    AlexGousev
    У меня, как ни странно, переменные отображаются другим цветом и внутри строк в двойных кавычках тоже. :)
     
  17. Anonymous

    Anonymous Guest

    ИМХО, Оффтоп. Сам пишу одинарные ковычки, по единственной причине, коей часто руководствуюсь — однозначность выполнения кода. Просто буду знать, что 100% переменная не слипнется с текстом в строке и не вычислится/отобразится случайно другое значение, а если опечатаюсь — увижу ошибку.
    Полу-аргумент 2 — Иногда, хоть и нечасто, приходится определять HTML/JavaScript внутри строковой переменной, и легко обломится в слешировании этого всего.
     
  18. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    И не только заслешенных радостей, а так-же всех $bla, {$this->bla('blabla')}, {date("Y-m-d")}, {$array[0]}, {$array['hahaha']} и.т.д. Чем больше такой мути в строке, тем медленнее работает парсер, потому что обрабатывать строку надо во время выполнения, а не во время парсинга скрипта. Если у кому не лень - выше я давал ссылку, ам есть скрипт. Модифицируйте его так, что бы приблизить к реалньости ближе и посмотрим на резалты.
     
  19. Vladson

    Vladson Старожил

    С нами с:
    4 фев 2006
    Сообщения:
    4.040
    Симпатии:
    26
    Адрес:
    Estonia, Tallinn
    точно также считаю (хотя иногда в коротких конструкциях типа include "тра-ля-ля.рнр"; бывает ставлю двойные чисто случайно)
    "слеширование" очень важный аргумент кстати.
     
  20. Luge

    Luge Старожил

    С нами с:
    2 фев 2007
    Сообщения:
    4.680
    Симпатии:
    1
    Адрес:
    Минск
    +1

    даже в мануале в разных примерах где ", а где и ' стоит
     
  21. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Psih
    В смысле, обрабатывать? Ты думаешь, что кроме парсинга строки, там еще есть какая-то дополнительная обработка?
     
  22. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Dagdamor
    А как потвоему он подставляет в строку значения переменных, элементов масивов, результаты работ функций и методов объектов?
    Конструкция вида
    Код (Text):
    1. $str = 'blabla'.func('ha').' blah '.$someint;
    Обрабатываеться парсером PHP, преобразовыветься в байткод и просто исполняеться - функция вернёт значение, оно приклееться к строке, приклееться блах и потом значение переменной $someint.

    А конструкция типа
    Код (Text):
    1.  
    2. $str = "blabla{func('ha')} blah $someint";
    Обрабатываеться парсером как переменная равно строке. И когда до этого места доходит, то запускаеться парсер обрабоки строк в " " кавычках. Он находит там вызов функции, вызывает её, получает результат и заменяет {func('ha')} на значение функции. Потом находит в строке $someint и заменяеть $someint на её значение.

    Я не знаю внутреннего устройства конечно, но здравый смылс говорит, что примерно так и должно это работать. Согласитесь, парсинг и замена в строке явно медленее чем прямое выполнение байткода. И чем больше будет переменных/функций в " " кавычках, тем больше будет осуществляться поиск и подстановка данных.
     
  23. Vitas

    Vitas Активный пользователь

    С нами с:
    7 фев 2006
    Сообщения:
    595
    Симпатии:
    0
    Адрес:
    Новосибирск, Академгородок
    Редкое извращение ИМХО, в таких случаях я использую конкатенацию:
    PHP:
    1. <? $str = "blabla" . func("ha") . " blah $someint"; ?>
    А сам я используй двойные кавычки чтобы спец. символы использовать и не использовать конкатенацию.
     
  24. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Psih
    Мне здравый смысл подсказывает наоборот: конструкция вида

    "blabla{func('ha')} blah $someint"

    после завершения парсинга выглядит как

    "blabla" . func('ha') . " blah " . $someint,

    то есть примерно так же, как и аналогичное выражение в одинарных кавычках (откуда идут тормоза - это другой вопрос), и никакой дополнительный парсинг во время выполнения не требуется. Доказать это можно на таком примере:

    PHP:
    1. $str1="okay";
    2. echo "str1 parsed<br>";
    3. $str2="parse error: {$.}";
    4. echo "str2 parsed<br>";
    Если бы PHP использовал "отложенный" парсинг, как ты утверждаешь, то парсер нормально пропустил бы третью строку, так как синтаксис в ней нарушается только выражением "{$.}", и ошибка парсинга выявилась бы только на этапе выполнения, после того, как появится надпись "str1 parsed". Поскольку надпись не появляется (проверь сам), делаем вывод, что строка парсится полностью и никакого дополнительного парсинга во время выполнения не требуется. Еще одно доказательство - тесты с установленным опкод оптимизатором. Там скорость одинарных и двойных кавычек почти не различается.
     
  25. korchasa

    korchasa Активный пользователь

    С нами с:
    4 май 2006
    Сообщения:
    12
    Симпатии:
    0
    Я не говорю про опкоды. Строка туда попадает одинаковой, и при одинарных, и при двойных кавычках. Дизассемблер так показывает по крайней мере. А скорость конечного автомата пропорциональная как длине строки, так и размеру словаря. В случае двойных кавычек словарь гораздо длиннее.