- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
fputs(fopen("ttext.txt", "w+"),"Мега текст!"); # создание файла и запись
fpassthru(fopen("ttext.txt", "w+")); # отображение
copy("ttext.txt", "ttext2.txt"); # копирование
fputs(fopen("ttext2.txt", "w+"), "скопированный Мега текст"); # запись
rename("ttext2.txt", "dctext.txt"); # переименование
fpassthru(fopen("dctext.txt", "w+")); # отображение
unlink("dctext.txt"); # удаление
fclose(fopen("ttext.txt", "w+")); # закрытие
вообще изначально 90% функций PHP было обертками вокруг Cных функций с такими же названиями
вообще изначально 90% функций PHP было обертками вокруг Cных функций с такими же названиями
почему тогда просто не использовать си?
Управление памятью - есть Boehm GC.
Это верно и для Java, которая считается for brain-damaged people не меньше php (в своей нише). Ничего, научиваются.
это не правда:)
В мире java есть разные люди: есть и вполне себе нормальные. В мире PHP таких нет.
Большинству PHP разработчиков до сих пор не очевидно зачем нужны юнит-тесты, почему не нужно выводить ошибки в браузер, а из всех паттернов они с трудом назовут синглтон:)
Я это уже проходил.
Кроме того пишущие на java хотя бы имеют представление о том, что такое куча и стек, и даже (бывает так) запускают йоркит, и смотрят -- кто загадил кучу.
В PHP же обычно о таких вещах не задумывються
>это не правда:)
Мопед не мой.
> В мире java есть разные люди: есть и вполне себе нормальные. В мире PHP таких нет.
Да что хоть. Везде примерно одинаковые соотношения.
> Кроме того пишущие на java хотя бы имеют представление о том, что такое куча и стек
С чего бы им знать что такое стек? В яве знание того, где хранятся объекты (в отличие, например, от C# с его struct'ами) не обязательно с точки зрения языка.
Традиция обсуждать такие моменты как куча, как мне кажется, шло/идёт с инициативы самого Sun'а. А так, простому ява-разрабу до лампочки это (никто его не принуждает понимать устройство, как напр. в си)... Как мне кажется, всё дело не в особенности ява-кодеров, а в разных политиках Sun и авторов PHP. (всё равно, знание того, что такое стек, не превращает говнокодера в хорошего программиста волшебным образом)
)))Вы возьмите какой-нибудь хорошо известный проект на PHP, и загляните внутрь. PHPBB например или PHPMyAdmin. Или drupal или jumla. И сравните, например, с magnolia cms на java.
Сразу и поймете в чем разница.
>>С чего бы им знать что такое стек? В яве знание того, где хранятся объекты (в отличие, например, от C# с его struct'ами) не обязательно с точки зрения языка.
Подобные вещи описываются в туториалах сана, и являются обязательными для scjp.
Возьмите любого джависта, который работает на джаве хотя бы год -- и спросите:)
>>А так, простому ява-разрабу до лампочки это
Без этих понятий -- здравствуй мемори лик.
Можно много еще привести примеров того, что у джавистов принято знать: java memory model например.
>> Как мне кажется, всё дело не в особенности ява-кодеров, а в разных политиках Sun и авторов PHP.
Вернее в отсутствии политики у PHP вообще. В отсутствии идеологии, код-стайла, JSR и прочего: потому язык похож на кучу мусора.
Вообще о чем мы говорим, если в PHP есть register_globals и magic_quotes? :))
Точными цифрами не обладаю. Во всяком случае я догадываюсь, где могут работать хорошие джависты (яндекс, джетбрейнс итд), а где могут работать PHPшники -- я не знаю.
А с мемори ликами вообще ситуация особая: так как PHP приложение начинается и заканчивается сразу же (в случае CGI) или довольно быстро (в случае модуля апача), то о мемори ликах "можно" не думать, а еще можно "забывать" закрывать файлы и коннекты к базам данных, что успешно делают многие PHPшники.
Очевидно что в мире сервлетов такая штука не прокатит.
А логи? log4j мастхев в у любого явиста, а много Вы видели PHP приложений с логами?
И кстати. Понимание стека и кучи важно так же и потому, что в жабе вполне себе есть примитивы, и в отличии от упомянутого Вами C# они автоматом не боксились до недавнего времени, так что понимание это все таки основопологающее. Хотя обратной стороной является ужасающая концепция врапперов, но тут уже ничего не поделаешь:)
Остается добавить к этому невнятный, кривой API PHP, частично объектный, частично процедурный, использование ассоциативных массивов вместо структур и/или объектов, и всякие плюшки о которых я уже говорил(регистер глобал, вывод ошибок в браузер, мэджик квотес) и становится понятно что джава все таки помогает учиться программированию, а PHP мешает)))
И нормально так:
Т.е., и там итам соотношения одинаковые плюс минус статистич. погрешность. Как мне кажется.
Смысл аналогии ясен, надеюсь.
Если юзать только стандартные либы - то сложно. Если заюзать некий фреймворк, который бы мимикрировал классы жабы иль дотнета (что-то наподобие glib/gobject'а), то - проще некуда. А так разница только в синтаксисе...
А вообще было бы любопытно изучить вопрос о том, нет ли уже такого готового фреймворка. Я, признаться, как-то не интересовался.
If C++ would have been used instead of PHP, then 22,500 servers could be powered down (assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code), or a reduction of 49,000 tons of CO2 per year. (это про Facebook)
Sure C++ would be faster running but not necessarily more efficient in terms of dollars (из обсуждения оттуда же)
И не забываем, что для си есть тоже сборщик мусора (куда более sophisticated, чем в говнореализации пхп).
в указателях ничего сложного нет, если не использовать арифметику (сложенние, вычитание) и какие-то аццкие хаки.
а так, нужно просто взять себе за правило, что у выделяемых на куче объектов после типа нужно ставить звёздочку - и, в принципе, всё )
в сишарпе есть ref -- передача по ссылке -- и это второе применение указателей в си (в стандартных функциях, например). как то же его освоили обезьянки-сишарписты.
Их, вроде, нельзя использовать без unsafe?
В любом случае оно там не нужно. Разве что для портирования сишного кода как-то использовал...
Это просто ключевое слово + ключ компилятору.
На уровне же рантайма указатели - полноправный элемент
Ну да, оно полезно в основном только для общения с сишным кодом (и то редко).
Хотя указатели в C# в некоторых местах быстрее стандартных средств. Ядровая библиотека (mscorlib) много где их использует, например очень много в реализации класса String.
Вкратце: оно останавливает потоки и сканирует кучу, стек и регистры на значения, которые "похожи на указатели". Поэтому у сишного коллектора два минуса 1) Если на стеке/в куче лежит число, похожее на указатель, то реальный объект не сможет удалться 2) дефрагментация, потому что теоретически нельзя компактировать кучу :(
А так если код не говнокод и не имеет хаки, то Boehm GC способен работать с любым уже написанным си-приложением, нужно только заменить malloc на gc_malloc
Я в свободное время ваяю велосипед по типу gobject, но с оглядкой на mono/java :\
Само использование такого псевдообъектного кода не сложное (синтаксис раздутее, может быть, в 1.3-1.5 раз), сложно то, что легко юзеркоду ошибиться, ибо язык не строгий...
О, синь.
Файлом посру