[PHP] а какие реальные пролемы появлялись у Вас при работе с PHP ?

> Есть в 5.3 Но ублюдочный, да. Хотя меня эта проблема не беспокоит, я для себя давно сделал очень удобный workaround этой проблемы :)

я написал оператор include, типа такого:

include('phpx.GUI.layouts.BorderLayout')

и придумал систему конвеншенов для этого.

Например: в одном php-файле может находиться только заголовки вызова фреймворка, потом вызовы include (и других функций, не нарушающих инвариант), потом класс названный так же как имя файла - именно в этом порядке.

но всё это жутко-жутко неприятно, прямо физически чувствуешь, что пишешь тонны костылей

>нет полиморфизма по методам классов, т.к. неизвестны типы параметров

Это не проблема.

никакая инкапсуляция

А точнее?

нет годной системы пакетов

У меня этот вопрос решён структурой фреймворка, мне как-то не актуально :)

анализ наследования - ад

А точнее?

Реурсивные скрипты!!11

А это что такое?

юнит-тестирование быдлокода (который у PHP - стандарт) - жесть.

Хм. Я использую phpunit - вроде, никаких проблем :)

многопоточность для объектов не раскрыта

В Web-программировании не актуально. А на десктоп PHP особо и не позиционируется...

ООП? Где ООП?

А что не так? :) У меня, вот, фреймворк во многом даже «ООП головного мозга» демонстрирует :D Вроде бы, проблем не было. Я бы сказал, что их намного меньше, чем в той же Java.

>Что за «Штатные средства создания шаблонов»? В каком языке есть такое? :)

<title><?=$page_title;?></title>

>>Неинициализированные переменные. Ворнинги всплывают не всегда.

>Всегда, кроме присванивания

А при передаче в функцию? А если в функции используется не инициализированная глобальная переменная?

>Ну и чем объект хуже структуры? Даже в Си++ это практически одно и то же.

В си++ объекты и структуры имеют размер равный сумме размеров их данных. И создание экземпляра гласса, содержащего, к примеру, инты будет бесплатным в плане CPU.

>>Юникод, ага.

>А точнее?

Ну вот есть форум, надо чтоб теперь он заумел юникод.

>Не стоит свои проблемы проецировать на весь мир :)

Ну правда же. Вон, на жумлу посмотри.

> Ой, не надо... :D Django - это ужасно :D Там, где у меня всё делается одной строчкой, в Django часто требует пять, если не 10...

на чем пишешь?

вопрос практический: надо напилить интерфейс к БД с кучей аякса и свистелок. На Жаве нельзя ибо заказчик - нищеброд (с другой стороны, на его хостинге есть бетка PHP6 и Python через FastCGI). Пока хочу Джангу (там хотя бы биндинги для ORMа пишутся быстро, не надо часами сочинять километры XMLя).

>даже элементарное foo(bar()['zagzag']) нельзя сделать.

Это достаточно редкое исключение. Да, это недостаток. Но уж больно редко встречающийся в практике :) Да и обычно демонстрирует ошибки в концепции структуры API :)

Ты ООП нормальное видел?

Я не просто виде, а много лет практиковал ООП на Си++ и Java. Сам делал разного вида ООП под Forth. Работал с ООП в Perl, Python и JavaScript. Вот чего нет, того нет, со Smalltalk не работал. Видел я нормальное ООП или нет? ;)

>Пока сам пишешь - норм, но влезут ламера и привет.

Это в любом языке так :) Но - согласен, PHP тут позволяет зевнуть больше ошибок, чем та же Java.

>Не стоило таки смешивать hash и array.

Ну да, это тот момент, где хоть немного нужно знать язык, прежде чем писать на нём :D

>Функциями PHP нельзя правильно узнать размер файла.

Так не в одном только PHP :)

>впилили вроде уже, в 5.3

Удивительно. Я, вот, 6,5 лет назад на Юникод переехал: http://balancer.ru/support/2004/02/t25205--perevod-forumov-aviabazy-na-utf-8....

> У меня, вот, фреймворк во многом даже «ООП головного мозга» демонстрирует :D

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

многопоточность для объектов не раскрыта

В Web-программировании не актуально.

Задача на следующий месяц. Планирую на Жаве, в т.ч. из-за пресловутой многопоточности.

Надо сделать сайтик фирме, которая занимается поставкой каких-то конских предметов быта (кажется, штукатурка и обои).

В задачи сайтика входит давать продавцам и клиентам интерфейс до БД их сети магазинов, и вычислять оптимальный способ производить махинации с продуктами. Например, есть десять филиалов и 15 перевалочных станций, по которым идут конские обои до целевого города, вычислить самый дешевый/быстрый/здесь-набор-разных-критериев из путей.

Вычисления не обязательно доводить до конца, должна быть кнопочка «стоп». Результаты должны аякситься на экран, и после нажатия кнопочки «стоп» оставаться на экране.

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

как сделать это на PHP по-человечески - вообще ни одной идеи.

>Какие? Например, switch может выдавать варнинги, если не перечислены все элементы enum'а? Ах да, енумов же нет.

А какие языки такое выдают? Java, вот, варнинги не выдаёт... Да и Python, полагаю, тоже. А зачем, вообще, в switch'е все варианты enum'а?

>Даже на ассемблере это проще.

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

Я, вот, практиковал только 8080, x86 (x от 80 до 804), PDP. Знакомился с ARM, 68K и 8048/8051. Может, я, конечно, что-то ещё другое упустил, но я даже не представляю, в чём но «проще» может быть, чем PHP :)

>при наличии мозга в голове можно писать надежный код и на PHP.

все равно PHP течет %)

>т.е. чтобы делать конкурентные вещи нужно писать модули для веб-сервера? о_О

Э... Если речь о многопоточной обработке запросов и отсутствии утечек памяти, то это всё много лет, как реализовано. От mod_php до fast-cgi.

Если речь о синхронизации и транзакционной целостности для параллельной обработки, то это уже другой вопрос, но и тут всё давно решено. От тех же mutex'ов до gearman'ов :)

> все равно PHP течет %)

а можно пример?

>Что-то не разберусь, что это значит. Пояснишь?

Это пример списка привязок properties классов к fields таблицы БД в ORM фреймворка BORS. Если имя свойства и поля БД совпадают, достаточно просто указать это имя. Если не совпадают, то можно указать ассоциативное присваивание property => field. Можно также, например, задать более сложное описание, если тип поля не автоопределяется, если нужны комментарии для полей в автоадминке и т.п.

>Ну, ты уж про себя разберись. Если это массив, то по for прекрасно проходится. Но зачем for, когда есть foreach?

Иногда хочется очень по индексу таки попасть. Да и foreach считается медленнее for, впрочем это неважно.

А вот была у меня задача - надо было проходить по трём массивам - в них были элементы для одного «объекта» на одинаковых «местах». Я не виноват - такая была кривая архитектура, не я писал. И вот там жутко неприятно было, что по индексам никак, а через методы next у массива - мутно.

Как это? Есть индекс - есть доступ.

Я имел в виду цифровой индекс. Вон, пример в треде про «42» и порядок заполнения массива есть. По сути в пхп массив - хэш с хитрым порядком. А массива, как такового, в языке нет.

Это в _любом_ языке так.

Но в пхп таки больше :)

Гы. Лучше такой костыль, чем полное его отсутствие, как в том же Си ;)

Ну для высокоуровневого веб-языка это плохо. Си вообще с другой оперы.

Ну так я, например, их часто использую :) create_function() замечательно работает, если нужно ехать, а не шашечки.

Неудобно:) Нет, правда. И таки create_function не полноценная замена настоящим функциям.

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

Ой, не надо... :D Django - это ужасно :D Там, где у меня всё делается одной строчкой, в Django часто требует пять, если не 10...

Ты просто не умеешь его готовить. Джанго имеет кучу недостатков, но огромное количество удобных вещей. В отличие от того же pylons, он местами сложноизменяем, т.е. это не конструктор, а готовый продукт, в котором многое сделано за тебя, и некоторые вещи сложно поменять. Потому если хочется чего-то очень своего, то надо либо брать что-то другое (pylons, web.py итд), либо сильно курочить джангу, но получить в результате кучу затрат при не самом лучшем результате.

И вообще, сравнивать твой самописный фреймворк с чем-то готовым не стоит. У авторов джанги тоже всё в одну строчку делалось, что на твоём бы делалось в 10.

А, кстати, форум авиабазы целиком на твоём, или что-то от punBB там осталось?

я написал оператор include, типа такого

Вот, беда, я очень-очень редко и только на самом низком уровне использую include/require ;)

но всё это жутко-жутко неприятно, прямо физически чувствуешь, что пишешь тонны костылей

Не знаю. Возможно, моё кунгфу^W^W мои конвеншны круче ;)

...

Я же писал про «ООП головного мозга» у себя. У меня почти все задачи решаются через принцип «всё есть класс/объект». И есть удобная система автозагрузки классов.

Так что, обычно, если мне нужно получить название места проживания пользователя по его IP, то я пишу не

require_once('inc/users/geoip.php');
$place = geoip_place($user_ip);

$place = users_geoip::place($user_ip)

Это если подобное значение используется только раз. А то я могу его прямо в классе юзера описать один раз в виде:

function auto_objects()
{
    return array(
        // ...
        'place' => 'user_place(user_ip)'
        // ...
    );
}

$place = $user->place();

><title><?=$page_title;?></title>

Во-первых, не «<?=», а «<?php echo» :) Во-вторых, такой код никакую валидацию не пройдёт, синтаксическую раскраску часто загубит и громоздок. Но, да, имеет право на жизнь. Иногда пользуюсь в тех нечастых местах, где это даёт реальный выигрышь, благо в BORS любой шаблонизатор подключается одной строчкой класса :)

А при передаче в функцию?

Если ты в функцию попытаешься передать неинициализированную переменную - будет тебе NOTICE.

А если в функции используется не инициализированная глобальная переменная?

А я не использую глобальные переменные. Это зло. Ну и, да, неинициализированная переменная через $_GLOBALS[] тоже даст NOTICE.

>>Опять же, если всё знаешь, то всё ок, но сам подход нехорош - надо много запоминать того, что к программированию имеет косвенное отношение.

Это в _любом_ языке так.

В не которых меньше, в некоторых больше, а некоторые вообще php. Серьёзно, зубрить нюансы надо дольше даже, чем в си++.

Ну вот, опять же, ===. Костыль абсолютный, неужели нельзя было придумать что-нибудь получше.

Гы. Лучше такой костыль, чем полное его отсутствие, как в том же Си ;)

В си для строк и чисел разные операторы сравнения.

create_function() замечательно работает, если нужно ехать, а не шашечки.

Ну да, раз компиляции нет и даже объявления переменных не требуется, то задание имён аргументов как строки на этом фоне - пустяк.

PHP тут позволяет зевнуть больше ошибок, чем та же Java.

Для меня невозможность зевнуть ошибку входит в функцию оценки языка с самым большим коэффициентом.

А какие языки такое выдают? Java, вот, варнинги не выдаёт... Да и Python, полагаю, тоже. А зачем, вообще, в switch'е все варианты enum'а?

си и си++ выдают. А затем, чтоб быть уверенным, что ничего не забыл. Если в свиче не весь enum, то либо с дизайном косяк, либо обработка ошибок недостаточная.

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

Я немного сутрировал, но вообще типизация у асма и пхп одинаково хреновая.

на чем пишешь?

В Django? Как обычно, в mcedit :) Но уже больше не пишу. Я только в одном проекте поучаствовал и понял, что оно мне не интересно. Хотя несколько идей оттуда почерпнул :)

вопрос практический: надо напилить интерфейс к БД с кучей аякса и свистелок. На Жаве нельзя ибо заказчик - нищеброд (с другой стороны, на его хостинге есть бетка PHP6 и Python через FastCGI). Пока хочу Джангу (там хотя бы биндинги для ORMа пишутся быстро, не надо часами сочинять километры XMLя).

Э... Если заказчик нищеброд, то разницы между Java и Python нет. Всё одно резко ограничивается выбор хостингов.

там хотя бы биндинги для ORMа пишутся быстро, не надо часами сочинять километры XMLя

На мой BORS посмотри :) Биндинги для ORM пишутся как я указал в [PHP] а какие реальные пролемы появлялись у Вас при работе с PHP ? (комментарий)

При чём есть, хоть и корявый (для себя на коленке писанный), кодогенератор. Скармливаешь БД и таблицу, получаешь готовый класс и, опционально, все нужные классы для админки. Полной автоадминки, правда, у меня нет, опять же, из-за отсутствия востребованности, хотя написать можно быстро.

Есть обратная генерация - из файла описания класса (синтаксис примерно такой):

class: bors_external_content

external_content:
    int id++!
    uint create_time!

    url             // Ссылка на источник
    text content    // Полное содержание источника
    title           // Извлечённый заголовок

получить как SQL:

CREATE TABLE IF NOT EXISTS `external_content` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `create_time` INT UNSIGNED NOT NULL,
    `url` VARCHAR(255) NOT NULL COMMENT 'Ссылка на источник. ',
    `content` TEXT NOT NULL COMMENT 'Полное содержание источника. ',
    `title` VARCHAR(255) NOT NULL COMMENT 'Извлечённый заголовок. ',

    PRIMARY KEY (`id`),
    KEY `create_time` (`create_time`)
)

class bors_external_content extends base_object_db
{
    function title() { return ec('Объект external_content'); }
    function nav_name() { return ec('объект external_content'); }
    function table_name() { return 'external_content'; }
    function table_fields()
    {
        return array(
            'id',
            'create_time' => array('type' => 'uint', 'title' => ec('')),
            'url' => array('title' => ec('Ссылка на источник')),
            'content' => array('title' => ec('Полное содержание источника'), 'type' => 'text'),
            'title' => array('title' => ec('Извлечённый заголовок')),
        );
    }


    function url() { return config('main_host_url').'/bors/external/content/'.$this->id().'/'; }
}

(понятно, все «лишние» методы в классе снести проще, чем вписывать при их отсутствии, поэтому они генерятся на всякий случай).

> Не знаю. Возможно, моё кунгфу^W^W мои конвеншны круче ;)

стопудов )
Мои конвеншены - это всего лишь попытка написать жабосишарп на пхп, и симулировать статическую типизацию везде где можно.

Вплоть до классов IntegerObject и StringObject (хотя с этой вершиной мысли пришлось расстаться из-за нечеловечески низкой производительности - я почти плакал :( Если сделать «всё как надо» для полной эмуляции статики, то потеря производительности позволит использовать это чудо только для сайтов-визиток из трех страниц...

> Э... Если заказчик нищеброд, то разницы между Java и Python нет. Всё одно резко ограничивается выбор хостингов.

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

> На мой BORS посмотри :)

http://bors.balancer.ru/ ? Рекомендуешь? :) Задавать вопросы можно?

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

Так это в любом языке так... Не было у меня ещё языка, где бы не приходилось что-нибудь чем-нибудь симулировать :)

Планирую на Жаве, в т.ч. из-за пресловутой многопоточности.

На Жаве хорошо писать самостоятельные сервера с отдельным внутренним миром объектов. Собственно, с такими системами я и ковырялся обычно (самое жирное - эмулятор Lineage II сервера L2Fortress). Если это актуально, то Java тут почти без альтернативы. А вот если не актуально - то она уже не лучший выбор. Цикл отладки получается очень утомительным и писанины лишней слишком много.

В задачи сайтика входит давать продавцам и клиентам интерфейс до БД их сети магазинов, и вычислять оптимальный способ производить махинации с продуктами. Например, есть десять филиалов и 15 перевалочных станций, по которым идут конские обои до целевого города, вычислить самый дешевый/быстрый/здесь-набор-разных-критериев из путей.

Ну, это же на любом языке легко решается :)

Вычисления не обязательно доводить до конца

10 филиалов, 15 промежуточных узлов - это же на доли секунды расчёт, по идее. Та же обратная волна, например. Или там хитрости какие-то?

как сделать это на PHP по-человечески - вообще ни одной идеи.

Например, совать задачи в gearman :) Это если параллельность (отложенная) реально требуется. Но, да, если там без таких извращений никак, то PHP будет не лучшим вариантом. Никто ж не говорит, что PHP - это серебряная пуля :D

> 10 филиалов, 15 промежуточных узлов - это же на доли секунды расчёт, по идее. Та же обратная волна, например. Или там хитрости какие-то?

у каждого филиала своя база данных с продуктами (отдельный веб-сервер, отдельный mysql, отдельный комп... отдельный город в чуркистане). База данных открыта для других узлов в сети, кстати, не вся, а только та часть, которой руководство магазина решило поделиться. Когда один из узлов сети хочет получить что-то, он опрашивает все остальные и каким-то образом перемалывает полученные данные. Есть тормоза каждого узла в отдельности (сиране селероны 700 мегагерц), плюс задержки и потери при передаче, плюс синхронизация на узле.

Крон, я же быдло :) Может это и решается каким-то алгоритмом в одну строчку, да я их знаю от силы пару штук. Как там, "- вы какие книги читали? - Красную, синюю, и толстенькую такую, с картинками."

http://www.linux.org.ru/forum/development/5260740?lastmod=1282742548107#comme...

Ох щи-

php > echo intval ( (0.1+0.7) * 10 );

7

>>1) Юникод

А что с ним не так?

Его нет.

2) Многопоточность

Это задачу берёт на себя web-сервер. И на практике она не всплывает.

Из-за этого PHP никак не может воспользоваться преимуществами современных многоядерных процессоров.

3) Никакущее управление памятью

Кстати, в 5.3, вроде бы, с 3-м пунктом сильно переиграли. Но пока не щупал.

Чето как-то слабо верится.

ИМХО, эту проблему выправят к 6-ке если не раньше. И то, как бы не получилась пародия на яву.

>Иногда хочется очень по индексу таки попасть.

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

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

Вообще, раз ты про скорость заговорил, ЕМНИП, через each() - самый быстрый вариант. Опять же, с итераторами никаких проблем :)

А массива, как такового, в языке нет.

Да. И это хорошо - см. мои примеры про описание :) Но, да, повторюсь, прострелить себе ногу тут можно.

Но в пхп таки больше :)

Он достаточно далёк от идеала. Но это и далеко не худший язык из тех, с которыми доводится работать :D

Неудобно:) Нет, правда. И таки create_function не полноценная замена настоящим функциям.

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

Старый код уже, естественно, переписывать не стоит, но и привязываться в пхп намертво не надо.

Как только у меня серьёзные заказы появятся на чём-то отличном от PHP - займусь переносом наработок на новый язык. Как когда-то переносил наработки сперва с Форта на Perl, а потом с Perl'а на PHP :) Но пока - не актуально :)

Ты просто не умеешь его готовить.

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

Джанго имеет кучу недостатков, но огромное количество удобных вещей.

Я увидел в нём массу недостатков, которых нет у меня, ряд удобных вещей, которые у меня есть, и немного удобных вещей, которых у меня нет. Последнее не перевесило первое :D

т.е. это не конструктор, а готовый продукт

Мне, как раз, показалось, что Django ближе не к фреймворку, а к набору библиотек. Для комфортной работы в качестве фреймворка, там нужно много пилить и пилить. Это мне и не понравилось. Просто влом делать раз за разом ручками то, что в своём продукте давно автоматизировал :)

И вообще, сравнивать твой самописный фреймворк с чем-то готовым не стоит. У авторов джанги тоже всё в одну строчку делалось, что на твоём бы делалось в 10.

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

А, кстати, форум авиабазы целиком на твоём, или что-то от punBB там осталось?

От punBB там обломки кода для просмотра форумов, обновлений. Формы новых сообщений/ответов. Там от 2/3 до 90% исходного кода ещё. Назрело уже переписывание кода форумов, но всё руки не доходят. Предпочитаю пока всякие фенечки и фишки делать. Вчера, вот, наконец, избранное добавил. И несколько вариантов просмотра юзеров на гуглекарте :) Например, так: http://balancer.ru/users/gmapd/

int main()
{
cout << int((0.1+0.7)*10) << endl;
}
Скомпилировалось, запуск...
7

>В не которых меньше, в некоторых больше

Ну да. Но PHP тут, всё же, не выглядит чем-то демоническим :D На мой взгляд...

В си для строк и чисел разные операторы сравнения.

В Си есть оператор для сравнения строк? ;)

си и си++ выдают.

Значит, стали это делать уже после того, как я с них слез :) Но мне такой подход не нравится. Ибо очень часто в switch'е нужны не все возможные варианты enum'а.

Я немного сутрировал, но вообще типизация у асма и пхп одинаково хреновая.

Ну да. В асме её нет вообще, а в PHP хоть можно на тождественность типов проверить ;) Или на сами типы.

>Скомпилировалось, запуск... 7

Да, но при этом в пхп echo(0.1 + 0.7) выводит честные 0.8, а не 0.79999, так что эт обман какой-то.

int main() { cout <<(0.1+0.7)<< endl; } Скомпилировалось, запуск... 0.8

>и симулировать статическую типизацию везде где можно.

У меня делалось как-то. Но в итоге забил :) До сих пор закомментирован соответствующий код в обёртке присваиваний.

Вплоть до классов IntegerObject и StringObject

Чёрт. Я думал - у меня ООП головного мозга ;) Нет, это уже перебор :D

то потеря производительности позволит использовать это чудо только для сайтов-визиток из трех страниц...

Но если это так критично, то можно юзать, вообще, статическое кеширование на сайте :) У меня, вон, пока железка совсем старая была, даже на форуме топики были статическими.

...

Но, прикидываю, что если у меня в BORS сделать все свойства объектов строго типизированными, то потери производительности большой всё равно не должно быть. Но не вижу смысла в таком извращении :)

>У заказчика уже есть PHP+Python-хостинг

А, тогда вопросов нет :)

>Рекомендуешь? :)

Сложный вопрос :D Сам-то использую, и в достаточно толстых проектах, но кроме меня на нём никто ещё ничего не выпускал. Так что мне сложно судить, насколько он подходит другим :D

Задавать вопросы можно?

Безусловно :)

>у каждого филиала своя база данных с продуктами (отдельный веб-сервер, отдельный mysql, отдельный комп

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

Крон, я же быдло :)

Не-не, прибедняться только не надо :D

Может это и решается каким-то алгоритмом в одну строчку, да я их знаю от силы пару штук.

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

Да ну вас, ваш с++ тоже кривой.

Тот же питон не врёт:

Python 2.6.5 (r265:79063, Apr  1 2010, 05:22:20) 
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.7 + 0.1)*10
7.9999999999999991
>>> int((0.7 + 0.1)*10)
7

>Ох щи-

php > echo intval ( (0.1+0.7) * 10 );

7

[code]
$ python
Python 2.6.5 (release26-maint, May 23 2010, 12:17:59)
[GCC 4.3.4] on linux2
Type «help», «copyright», «credits» or «license» for more information.

print 1/3;

0

[/code]

тоже щи? :) Или борщ? ;)

>Его нет.

А почему у меня юникод с 2004-го работает? :) Я ссылку выше кидал, все ходы записаны :)

Из-за этого PHP никак не может воспользоваться преимуществами современных многоядерных процессоров.

Хм. А почему у меня все четыре ядра легко загружаются? :D

ИМХО, эту проблему выправят к 6-ке если не раньше. И то, как бы не получилась пародия на яву.

В любом случае это не принципиально :)

>тоже щи? :) Или борщ? ;)

Тут нюанс в том, что про мерзкое целочисленное деление в каждой книге по питону говорят столько, что не запомнить это может только совсем странный человек. Да и от него наконец отказались в третьей версии.

А вот пхп нагло врёт что там 0.8, а округляет как 0.79, а это слишком нелогично.

>Тот же питон не врёт:

Походу, просто в тех ВУЗах, где программирование преподают, перестали обращать внимание на потери при переводах двоичиной плавучки в десятичную и обратно. И, вообще, тонкости округления плавучки :) А когда-то это был весьма фундаментальный вопрос...

>А вот пхп нагло врёт что там 0.8, а округляет как 0.79

А кто тебе сказал, что intval - это округление? Это _отбрасывание дробной части_. Со всеми вытекающими.

Округление - это round.

Или intval($val + 0.5), как раньше в любом институте учили... Ещё скажи спасибо, что не int($val + 4/9), как на программируемых калькуляторах на 130x серии :)

Дело просто в настройках по умолчанию. Т.к. си делался для людей, а не грузунов, то и числа в нём выводятся читаемо. А пхп просто частично слизан с си.

int main(){
cout << setprecision(90);
cout <<(0.1+0.7)*10<< endl;}
Скомпилировалось, запуск...
7.99999999999999911182158029987476766109466552734375

>А кто тебе сказал, что intval - это округление? Это _отбрасывание дробной части_. Со всеми вытекающими.

Ну я и имел это в виду под «округлением». Вечер, усталость, ошибаюсь, с кем не бывает.

Я к тому, что если у тебя 7.(9), то и выводи 7.9, а не 8. Т.е. пхп именно округляет при echo, смущая пользователя. Пока не напорешься, не поймёшь, среди кучи вычислений не заметишь. Такие мелочи и есть недоработка языка. Лучше бы сделали 7.9 и заставляли бы программиста силой делать округление по-честному.

Причем не отличить, целое там 8 или такое вот «округлённое».

В высокоуровневых языках не стоит так жестоко уходить в машинные нюансы с этими плавающими точками. А то вся высокоуровневость пропадает.

> си

cout

ниасилил float

(0.1+0.7)*10

журналист износиловал ученого

лор снова торт

1. php хорош для маленьких проектов. Что-то больше на нем написать - это извращение. Те же joomla и drupal настолько монстрообразны, что даже не хочется в них ковыряться.
2. Та техника работы с sql, которая используется почти всегда, допускает хакерские атаки. В итоге мы имеем огромное количество уязвимых ресурсов.
3. Порог вхождения - н у л е в о й. Это приводит к тому, что существует огромное количество кода, такого, что - оторвать и выкинуть.
Инклюды по переменным и тд...
4. Я дофига писал на пхп в свое время. Даже имея богатый опыт, бывает что обнаруживаешь уязвимость в неожиданном месте. Да, это ошибки программиста, но во-многом это вина языка.

Для веба - Java. Пхп - для хомепаг и говносайтов. ИМХО.

Что? Я просто иллюстрирую, что php копирует си. Ну да, а показываю на примере плюсов, но с сишным принтф та-же история, просто его шаманские закорючки вокруг %f я не помню.

>2. Та техника работы с sql, которая используется почти всегда, допускает хакерские атаки. В итоге мы имеем огромное количество уязвимых ресурсов.

Хоть я в это треде и против пхп, но не могу не заметить, что есть вполне приятный PDO, про который, увы, никто не знает. А он вполне себе защищённый, экранирует запросы и вообще хорош. Просто про него не в курсе многие.

Нормально если учить, то никаких проблем не будет. По сабжу, таковых не было