C++14 имеет достаточно фич, что бы забыть о PHP?

Question

[Offenso]

Я давно уже грею мысль о создании сайтов на C++, на моем родном языке. Но раньше это было не рационально.
На днях я ознакомился с черновиком С++14, и хотелось бы узнать у тех, кто ознакомился более подробно, а так же уже освоил C++11, там достаточно возможностей, что бы так же быстро клепать дерьмо-сайты, только на нормальном языке, с адекватным распределением памяти?

(Для злящихся php-шников, дополню, меня не устраивает вот это. Этим испещрен весь язык. )
$a = «2d9»; $a++; $a++; echo $a; → 3
$a = «2d9»; $a+=2; echo $a; → 4
$a = «2d9»; $a++; echo $a; → 2e0

Comments

[Offenso]

На всякий случай, что бы не плодить апологеты интерпретируемых языков:
Меня интересует именно готовность(в плане удобства) конкретного языка (С++) с вводом следующего стандарта(2014), для решения указанных задач(работа с СУБД, с строками, ассоциативными массивами, управление http заголовками и тп.), я не ищу замену PHP.
Для простоты усвоения сего факта скажем у меня академический интерес.

Answer 1

[galaxy]

C++14 имеет достаточно фич, что бы забыть о C++

Comments

[Offenso]

Вы имели в виду C++98? Не думаю что стоит решать все принципиально на делегатах и Си коде.

[Nerazumovskiy]

Думаю имелось виду что С++, с его новыми фичами, из невероятно сложного превращается в язык который единицы способны использовать по полной. Как результат теряется контроль над происходящим, а в С++ такое допускать нельзя.

Answer 2

[AxisPod]

Ну если хотите много геморойчика себе на сидячее место, то на здоровье.

Профит от C++ возможен только в случае, если необходимы очень сложные расчеты и многопоточность. А для всякой мелочи у которой в основном работа с бд и файлами, подойдет абсолютно любой интерпритируемый язык. Если хотите уйти с PHP, глядите на Python к примеру. Но подводные камни есть абсолютно везде.

Comments

[Offenso]

Т.е вы утверждаете что С++14 еще не готов, для того что бы сделать сайт без гемороя? Жаль.
А чего конкретно не хватает? В сторонних библиотеках типа boost это не реализовано?

Я не хочу уйти от php, я хочу забыть про интерпретируемые языки. Про большинство из них. (К примеру я люблю Lua)

[AxisPod]

Да тут дело даже не в самом C++, и не в самом C++14. По сути уже C++11 дал очень много. Основная проблема, это поддержка стандарта, приходится общаться как с gcc (использую 4.8.1 и 4.9), msvc (2012, 2013). О заявленной полной поддержке C++11 в gcc говорят, но от этого поддержка полной не становится. Регулярки до сих пор не работают, очень много багов, недоработок. Лямбды не захватывают variadic аргументы. Баги с вложенными лямбдами. У msvc всё еще хуже. clang увы не щупал. Вменяемая поддержка C++11 вряд ли появится раньше 2015 года, с пофиксинными багами и со всеми необходимыми доработками. А C++14 не стоит ждать раньше года 2016.

Опять же это почти полное отсутствие фреймворков для web. Существующие ныне это полутрупы, а то и полные трупы. Которые в принципе никак не развиваются.

На C++ сделать множно многое, но рационально ли это. У нас сейчас основная разработка для веб ведется на C++, честно скажу, очень хочется перевезти всё на PHP, уж очень много времени уходит на отлов багов и утечек памяти. Да и написание самого кода совсем не быстрое.

[Offenso]

Вопрос рационализации действительно стоит отложить. Мне повезло не терять память, поэтому в сравнении с С++ и PHP я вижу только меньшее количество возможностей, и более опасное дно(читай: больше подводных камней).
По статистике — в С++, я сам дурак, недоглядел, недосмотрел. В PHP неочевидное(неожиданное, здравым рассудком не предполагаемое), но хорошо документированное поведение(о котором я не знал, потому что не нашел книгу: неожиданности в PHP), или же расход в понятиях между С++ и PHP(и тогда я сам дурак).

Я говорю о стандарте, я здраво понимаю, что завтра перепрыгнуть не удастся. Просто на днях была хорошая статья о IPv6, и я подумал что сейчас так же по полочкам расскажут, что вложенные массивы от разных типов теперь можно упаковать вот так, а это вот так. А это невозможно, и будет, как вы сказали «геморой».

Мне, выращенному на DOS и ASMx86, нравится контроль. Максимально возможный. Создавая long-polling приложение, я хочу терять только столько памяти, сколько необходимо. Надеюсь больше мотивировать мое желание не придется. Примите пожалуйста за данность — хочу на С++. И теперь узнаю — удобно ли в 2016-2018-2020 году это будет делать? Ибо PHP уже совсем развития не получает.

[Никита Гусаков]

И теперь узнаю — удобно ли в 2016-2018-2020 году это будет делать? Ибо PHP уже совсем развития не получает.

Я совсем немного знаю плюсы и по больше знаю PHP. Но по моему ясно, что добавить фич в любой скриптовый язык — гораздо быстрее, чем это сделать под компилируемый, тем более такого монстра, как плюсы)

[AxisPod]

Я сам занимался разработкой 2х разных независимых веб фреймворков для C++, задача очень непростая. В итоге я остановился для себя на том, что проще взять boost::asio и делать конкретно то что нужно, от силы сделав несколько классов, например для полноценного парсинга HTTP запросов.

Если бы компиляторы работали идеально, то большинство проблем отпало бы, но увы, идеально работать они никогда не будут. Дальнейшая проблема, это в их старости, да, есть gcc 4.8-4.9, но далеко не везде возможно завести эти версии на продакшене, у нас местами болтается еще 4.2.1. Тогда как с тем же PHP в этом плане проблем меньше.

[Offenso]

hell0w0rd, но насколько я вижу прогресс С++ идет за последние 10 лет быстрее чем в PHP.

AxisPod, я и не говорил про чистый С++, без сторонних библиотек.

[AxisPod]

Offenso, проблема в том, что сторонние библиотеки либо дохлые, либо их нет.

[Никита Гусаков]

Offenso ну как сказать) под php совсем недавно появился phalcon(фреймвор написанный на си). Приложения написанные на нем по скорости сравнимы с приложениями на Go, памяти кушает совсем не много. Сейчас занимаются написанием транслятора с php-подобного языка в си-расширения. Это я о чем все говорю — если вам хочется писать логику на компилируемом языке — возьмите ядро скриптового языка и представьте что это ваш фреймворк. В каждом скриптовом языке есть возможность расширять через си/с++ расширения.

[Offenso]

hell0w0rd Блин, доколе люди будут думать что С++ выбирают только изза скорости. Мне он кажется просто нереально удобным, я мыслю этим языком. Я могу сравнить это разве что с PostgreSQL — все что не хочешь, написано.
Мне хочется пользоваться всей мощью C++98, без гемороя. Вот я и задался мыслью, а может в частично совместимом, но более удобном C++14 это получится?
Я и пхп могу скомпилировать в байткод, исключая парсинг при выполнении. Я же программист. Просто хотелось бы С++.

[AxisPod]

Меня лично C++ привлекает за шаблонное метапрограммирование. Для web применение находится, в этом есть реальное удобство. Потихоньку делаю свой IoC контейнер для C++11, для web опять же он очень даже применим. Но это требует ну уж очень много времени, далеко не всегда это выгодно. Или например делал свою обертку для шаблонизатора ClearSilver, подключать callback'и стало очень удобно, хоть и потерялась возможность произвольного кол-ва аргументов для них. Точнее просто и не делал их. Но теперь в функциях пишется только их контентная часть и не требуется вообще никакого кода для разбора типов данных из ClearSilver, уж очень неудобно это из коробки. Но опять, это съедает много времени.

Answer 3

[Sergey Lerg]

А вы смотрели в сторону Go? Я забыл о PHP с приходом Go в мою жизнь. Правда я не сайты делаю, а сервисы, но одно не сильно от другого отличается. Go как C компилируемый (скорость, низкое потребление памяти), но при этом на нём очень комфортно писать, почти как на PHP или Python.
Можно подружить с nginx.

Вот подборка веб фреймворков на этом языке
robfig.github.io/revel/
www.gorillatoolkit.org/
webgo.io/
code.google.com/p/gorest/

Я использую этот — github.com/stretchr/goweb
Простой и лёгкий.

Книжка по Go — www.golang-book.com/

Comments

[Offenso]

Спасибо, но не хотелось бы из лоно C++ вырываться совсем далеко. Мне нравится когда синтаксис близок.

Answer 4

[96467840]

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

Answer 5

[gro]

Нет, сначало нужно написать какую-то херню, намекнуть, что php-г.но и php'шники талпайопы, а потом рассказывать, что «я не хотел никого оскорбить», «я здесь вообще не о php»…

Comments

[Николай Турнавиотов]

php то нормальный, а вот от г-но кодеров, написавших три программы и мнящих себя суровыми сеньорами в 20 лет знакомые HRы и PM с тимлидами, этих сеньоров собеседующие, находятся в глубоком трансе

[Offenso]

Вы вольны видеть то что захотели. Я написал свое мнение развернуто, только когда спросили. Мне не понравилось личное общение с dev-team PHP, поэтому я так предвзято рассуждаю.
Между тем даже этого обьяснения не хватило, что бы ваши коллеги стали отвечать по ссуществу, а не предлагать другие интерпретируемые языки.
Не обижайтесь, но я правда не люблю PHP. Примите это.

[gro]

Я много чего не люблю и мне всё равно примут ли это или нет. Но если я решаю вынести свою нелюбовь на публику, то не занимаю позицию, что я ничего этого не говорил и вообще не ваше дело.
По опыту самые снобы и ненавистники PHP, это бывшие php-говнокодеры, которые стараются перейти говнокодить на другой язык.

И не знаю, как там в C-14, но раньше помнится, char и byte было одно и тоже. Так что int a = '0'; a++; — вау, '1'!, а вот '0' + '1' — уже хрен знает что. А арифметические операции над строками вообще, кажется, к операциям над указателями сводились.

[Offenso]

У вас каша в голове, и вы говорите про С89-С99, я же отталкиваюсь от С++95.
Суть простая, не спрашивайте моего мнения, и я не буду его публиковать. Вам бы лишь бы на холиварную почву вопрос свести.
Что конкретно вас, конкретно в вопросе задело? Где я там высказал свое мнение от которого потом отказался?? Я написал что это поведение неадекватное, разве это не так?

В C89 нет встроенного типа byte, близжайший появился в майкрософте, BYTE, и они действительно, частично сходны.
И мне кажется в условиях таблицы ASCII то что вы написали совершенно верно, попробуйте как в физике добавить размерности. В пхп же типы теряются. Меня это не устраивает.

Дак вот, строк как типа в С89 не существует, вы опперируете с указателями. В С++ же сложение строк не определено в библиотеке, но вы вольны написать свою конкатенацию.
Более того, если меня не устраивает чертов ассерт(а в php он меня не устраивает), я могу просто переопределить.

Может уже хватить тратить наше время, будем концентрироваться на сути вопроса?

Answer 6

[bak]

На плюсах есть всё чтоб пилить сайты. Берёте батарейки (boost), веб-сервер (мой выбор — mongoose с самопальной обёрткой), шаблонизатор (например, cpptemplate), базу данных (в простых случаях — хранить всё в памяти и дампить на диск. В средних — заюзать любую из кучи бд, как внешних, так и легко встраиваемых прям внутрь проги. В сложных — держать часть данных в памяти, часть на диске, подгружать когда надо, и не забыть ещё журналирование). Затем берёте бутстрап & jquery (или любые другие фреймворки по вкусу) и запиливате обмен json-ами. Можно ещё websocket-ы прикрутить.
По скорости разработки — когда приноровитесь — будете не слишком сильно сливать интерпретирщикам. Для удобной разработки нужно иметь настроенную систему сборки с библиотеками, ide, умеющую работать с данными на удаленной машинке (например, QtCreator) ну и саму машинку, которая будет не сильно долго всё это пересобирать.
Сливать будете всё равно, потому что:
— компиляция (быстрей 5-10 секунд для проекта с набором библиотек наврятли разгонитесь. хотя..)
— библиотеки (есть инфа что воткнуть в систему сборки либу и написать для неё обёртку несколько медленней, чем заюзать готовую для популярных в вебе языков)
— велосипеды (не знаю на плюсах нормально реализованных веб компонент, т. е. cms, веб фреймворки, etc). В итоге у вас будет свой собственный фреймворк с блекджеком и шлюхами утечками памяти и багами, на фикс которых вам придётся тратить время, превышающее время разработки продукта
— скорость мозга. Есть инфа, что если мозг часть времени думает о том, какой объект кем владет и кто кого когда убивает, ещё часть, как бы завернуть первую часть в удобо-юзабельные абстракции и какой-бы паттерн тут применить, ещё часть о том, что за странное сообщение об ошибки в какой-то сторонней библиотеки, вступившей в странную связь со свеженаписанным говнокодом, не забывая про статическую типизацию а так же извращённый интерфейс разработчиков типовых решений (да тот-же split) — его производительность несколько ниже чем у мозга, думающего по большей части о продуктовой логике.
— ошибки компиляции, линковки, segfault-ы, ошибки многопоточности, утечки памяти — вообщем полный набор удовольствий для истинных ценителей :)

Comments

[Offenso]

Спасибо, а можете посоветовать что нибудь с ассоциативными массивами?

Библиотеку так я и не нашел, под свой выбор, либо слишком малый, либо нагибающий MVC, без возможности расширения. (Всем сочувствующим, я не нашел на данный момент, и не стоит эту несправедливость исправлять советами). Так и так на своих велосипедах катаюсь.
Проблемы с потерей памяти меня не пугают, я искренне удивлен почему все так ругаются на это, хендлить одно из самых простых в с++, вот к примеру потоки(conditional race) для меня сложнее. отсюда про скорость мозга, благодарю, но не актуально.
===
Вообще я рад за просвечивание минусов, но хотелось бы больший акцент на том чем пользоваться.

[bak]

std::unordered_map — стандартная хеш таблица. Ну и если чё обычный map всегда в плюсах был.
Ну так а что мешает начать использовать прямо сейчас? Чего не хватает?

[Offenso]

Я без дерьмокода затрудняюсь поддерживать ассоциативный массив от разных типов.
Ведь не редки ситуации, когда в одном массиве(а в последствии json), нужно передать строку, число, и вложенный массив.
Так же до выхода это должны быть отдельные классы — цвет, картинка, и еще что то, что потом сериализуется в строку, и ссылку на картинку. К примеру

[bak]

Плюсы — это статическая типизация. Если у вас в массиве может лежать строка, число и вложенный массив — значит вы что-то делаете не так. В плюсах для этого есть классы.
Чтоб не быть голословным — приведите конкретный пример когда вам этого хочется. Ну и кстати, если уж очень хочется — используйте boost any. Ну или можно использовать json объекты, например из jsoncpp — в них как раз можно хранить всё что угодно — но я не рекомендую их использовать для чего-либо кроме серилизации.

[Offenso]

bak, ничего хитрого придумать я не собираюсь. Результат выборки из базы, содержащий произвольные данные, в числе прочего, одно моле является двумерным массивом.

Answer 7

[Николай Турнавиотов]

Честно, для себя лично я оценил простоту web-разработки на C# + Asp.Net MVC + jquery/twitter bootstrap.

Answer 8

[Алексей Акулович]

Про объективность использования C++ это вам уже и так понаписали. Давайте растолкую про не устраивающую вас логику PHP. Правда в другом порядке.

<?php $a = "2d9"; $a++; echo $a; → 2e0

a — строка. Инкремент строки (которая не является записью в 10чной СЧ) выполняется по принципу Perl: «A»++ = «B», «Z»++ = «AA», «AA»++ = «AB». Вот и получаем «2e0».

<?php $a = "2d9"; $a++; $a++; echo $a; → 3

Если же строка содержит нечто, похожее на 10чную СЧ, то приводим к целому и инкрементируем. Второй инкремент дает «2e0» = 2*10^0 = 2. 2++ = 3.

<?php $a = "2d9"; $a+=2; echo $a; → 4

Арифметика без инкремента сразу приводит строку к числу, и мы просто считаем 2+2.

Нормальная логика, если учесть, как PHP используется. Это как удивляться, почему инкремент short* увеличивает значение указателя на 2, а не «как должно быть» на 1 :)

Answer 9

[Vitold S]

Я вообще не понимаю Вашу проблему? Если Вы пишите на C++, то не составляет труда просто сделать свою ветку PHP выпилить сложение строк и получить интерпретируемый язык с тем поведением, которое Вам нужно.

И я уверен Вы найдете последователей и любителей писать long-pool приложений. А если дописать PHP и снабдить его Threading и допилить до хорошего уровня ООП-шный Runtime, то цены вам не будет…

Comments

[Offenso]

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

[Vitold S]

1. Рекомендую побороть свои негативные чувства к любой информационной системе. Чувства не помогут в разработке (только мешать будут) и избавить сообщества от Ваших чувственных суждений — свойственные малолетним джунам (я о «еще одного дерьмоязыка»). Вам верно заметили, что писать можно как плохо, так и имея хороший опыт — не плохо (главное понять откуда руки растут).

2, Недостаток, который указан: приведение строчных типов в PHP к численным действительно место для совершения массы ошибок. А еще наличие нескольких сравнений (конкретно == и ===). Можно сознательно избегать таких ситуаций используя костыли методы для приведения типов (пример, в Joomla были методы на подобии getInteger, getString, getBoolean, ...)

2. Если Вам надо срочно реализовать, то очевидно использовать опыт предков. Именно вам уже советовали PHP / Ruby / Perl / Python…

3. Если есть время, желание «рыть каналы» и уверенность в своих силах, то очевидно надо пилить джедайский WEB Framework под C++… Я думаю, что найдутся единомышленники среди крупных компаний (D-Link, ASUS, ...) а то сейчас они творят что хотят (я про CGI скрипты в роутерах)…

4. Опять же возвращаюсь к негативу (скорее всего рожденный к криворуким программистам приходящим в программирование через PHP) по улучшению PHP. Выглядит как не любовь к набору шестигранных ключей (аналогия с инструментом). Исправляйте тогда уж, а не морду воротите…

[Offenso]

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

Answer 10

[SBKarr]

Если сильно интересно - писать сайты можно и на C, и на С++

В моих проектах используется Apache HTTPD + интересующие модули + контентный модуль, написанный на C++ (правда, от ++ там только объекты с наследованием, никаких шаблонов, а тем более stl и boost, просто объектная семантика удобнее структур от C)

Apache HTTPD уже имеет на борту солидный набор полезных вещей (гуглить Apache Portable Runtime), недостатки исправляются тоннами хороших и доступных библиотек (curl, imagemagick, openssl, да что угодно из мира C/C++, хоть V8 + toc++ для генерации биндингов и у вас свой скриптуемый жабаскриптом сервер)

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

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

Сборка построена на makefile, которые замечательно понимает любая IDE, что есть на линуксе. Сборка инкрементальная, как положено, компиляция при активной работе над фичей меньше секунды. Отладка через GDB (тоже замечательно воспринимается IDE). Компиляция + деплой + запуск с одного сочетания клавиш занимает меньше секунды.

Рабочие версии выкатываются через примитивный CI (gitolite + hooks), сервер сам собирает, сам устанавливает. Выкатывание так же занимает от 5 до 10 секунд (на сервере всё пересобирается полностью, ну и качеству связи не последняя роль отведена).

Веб-морды собираются на бутстрапе (хотя недавно верстальщики распробовали SemanticUI и порадовались), сердце веб-морды - AngularJS.

А как же индексация, спросят знакомые с SEO люди? PhantomJS + простейший скрипт решают эту проблему. Когда приходит робот за полным индексом, сервера конечно не очень довольны, но вполне себе стоят и работают без заметных тормозов (0.1 мс против 1.5 мс, при среднем пинге пользователей в 150мс)

В общем, хотите писать сайты на Си - это более чем реально, а порой и более чем эффективно. Строгая типизация и отсутствие интерпретируемого в Runtime кода решают целую гору проблем со стабильностью и безопасностью. И дело тут не в уровне стандарта, а в подходе.

Answer 11

[polifill]

1% времени мощь С++ используется.
99% процентов времени ты с С++ борешься

Сказал человек, разрабатывающий языки и среды и компиляторы уже почти 40 лет.
https://habrahabr.ru/post/314616/