Значения возвращаемые include при подключении файла

По умолчанию, если файл не может быть включен через include, возвращается FALSE и возникает и выводится сообщение E_WARNING. Если файл успешно включен через include, возвращается 1.

Из описания include на php.net. Оператор include возвращает значение FALSE при ошибке и выдает предупреждение. При успешном включении, если это не переопределено во включаемом файле оператором return, оператор include возвращает значение 1. Если во включаемом файле прописан оператор возврата return с возвращаемой переменной, то при успешном включении оператор include возвращает значение этой переменной. То есть, при записи оператора возврата return с перемен-ной во включаемом файле, можно получить значение возвращаемой переменной таким же образом, как получают значение возвращаемой оператором return переменной из обычной функции.

Из описания return на php.net. Если включаемый файл скрипта был подключен с помощью include, тогда значение переданное return во включаемом файле будет возвращено в качестве значения вызова include.

Включение файла в переменную через include

Включение файла inp.php в переменную происходит посредством записи во включающем файле res.php инструкции включения включаемого файла в переменную

$input = include ‘inp.php’; // инструкция включения файла в переменную

При этом во включаемом файле, в конце скрипта файла, должна быть прописана инструкция возврата значения

return $output // инструкция возврата

При таком подходе также удобно осуществлять проверку успешности включения файла

// Проверка успешности включения файла
if(!$input){
echo 'Ошибка включения файла';
var_dump($input); // отладка, выводит FALSE
// Обработчик
}else{
echo 'Включение файла успешное';
var_dump($input); // отладка, выводит 1 (если без return) или содержимое $input
// Рабочий код
}

Кому интересен такой подход и связанная с ним практика – пишите в эту тему. Есть отдельные моменты работы, не вполне оче-видные, и практика в этом плане очень кстати.

Я лично вообще такие проверки не делаю, ну не загрузился какой нибудь баннер да и плевать на него с большой колокольни

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

Еще один момент. Есть включаемые файлы-скрипты, от которых нужен только результат их работы - итоговая выходная переменная. А при инклюде в подключаемый файл тащатся все переменные подключающего файла, включая массу ненужных промежуточных. Я их удаляю через unset, пока ничего лучше не придумал, хотя, может, есть способ получше.

sadex13
Делай функции и подключай их, все переменные объявленные в функции автоматом удалятся после исполнения

<?php
    function foo($a){
        $c = 'Привет '.$a.'!<br>';
        return $c;
    }
    $name = 'Вася';
    echo foo($name);
    var_dump($c);// Убеждаемся что $c больше нет
?>

zelenuy, с функциями понятно, но они не всегда удобны. В определенных случаях можно очистить память и через unset.

sadex13
Не знаю у меня вообще одни объекты да функции все раскидано по папочкам, есть главный файл который при запуске все эти куски собирает в единое целое

sadex13
Ну это экономия на спичках, самое критичное что действительно влияет на скорость это плохо спроэктированая под конкретную задачу база данных (имхо)

Насчет спичек - это не всегда. Конкретный пример. Я вот весьма интересуюсь форумным движком FluxBB и сделал общую (для форума и сайта) систему учета юзеров для своей мини CMS на базе таблиц БД и скриптов FluxBB. При этом мне понадобилось проинклюдить файл с функциями флакса, кб где-то за 70 и прочие скрипты флакса. Мои скрипты (CMS) после такого подхода стали работать в 9 раз медленнее. Тогда я вынул из общего файла функций флакса - это файл functions.php на 76 кб только несколько укороченных модифицированных функций идентификации юзера по кукам и распределил их по своим скриптам. При этом работа скриптов замедлилась всего в 2 раза (за счет выполнения процедуры распознавания юзеров по кукам). Но не в 9 раз, если бы просто инклюдить то что было изначально.

Насчет плохой структуры БД - согласен, сильно влияет на скорость.

sadex13
Ну так там много лишнего скорей всего, так сказать под каждый чих есть свой метод, да еще там наверно система учета реализована через СуБД

Причин много разных. Но согласись, то как распределяются скрипты и функции по файлам и сколько чего инклюдится имеет важное значение. В итоге я из скриптов самого флакса стал инклюдить только маленький config.php, а остальные необходимые процедуры и функции распределил по скриптам-файлам своей CMS. Скорость в разы возросла.

Если вернуться к исходной теме, инклюдить файл в переменную бывает удобнее, чем просто его инклюдить. Тут еще важно понять, как правильно сконфигурировать включаемый файл, чтобы там поменьше всякого лишнего и промежуточного было. Это когда функции неудобно использовать. Именование переменных тоже важно, можно многократно использовать переменные с одним и тем же именем для промежуточных операций, и все будет работать.

Например, у меня в CMS несколько файлов разных скриптов включают файл-скрипт цепочки навигации (breadcrumbs). Так вот, входные переменные, по которым строится цепочка, я сделал с одинаковыми именами в разных файлах, чтобы лишних процедур не писать... . Все работает.

sadex13
С тобой соглашусь что объект в пхп много занимает места, тем более можно засунуть сто методов что не есть айс, да и объект в пхп это не то что он из себя представляет в том же с++, это совсем разные вещи, но в принципе пхп и не создан для супер пупер порталов типа гугла, он просто для принял строку посчитал 2+2 и отдал результат, от него из начально не требовалось раз считывать троекторию движения планет даже тот же фейс-бук он вроде на пхп но не совсем так, они придумали свою технологию как бы доработав пхп, мораль хочешь скорости пиши на Си как гугл сделал)

Провел простой эксперимент. Файл с небольшим скриптом (включаемый в переменную инклюдом) обернул в оболочку функции, на вход которой пришлось подавать 4 параметра.

Итог. Время работы скрипта чуть-чуть увеличилось, а вот объем потребляемой памяти вырос более чем в 1.5 раза. Это по сравнению со скриптом без функции, в котором я 9 промежуточных переменных вычищал через unset. Тот же unset делал и в файле с функцией, но он ничего особо не менял.

Я не сторонник процедурного программирования как принципа, функции активно применяю. Но делать на функциях все что попало, наверное, неправильно. Надо смотреть, где функции действительно необходимы, а не делать все на функциях ради красоты кода только.

Пока не понимаю, почему функция отъела в 1.5 раза больше памяти - может параметры, может вызов и обработка функции в памяти - не врублюсь пока, а особо думать лень.

Пхп реально работает на выделенном сервере) А на хостере просто по сто сайтов на один пк, плюс одна точка интернета, и все это на прямую влияет на производительность, причем одного досят все сайты страдают