д0k все, что можно было написать на С/С++
давно написано до нас

haproxy написан на Pure C. Что-ж вы свой std::язык для <substandard coders> пытаетесь примазать где не попадя?

д0kна разработу приложений на С++ для веб
то его не нужно делать с нуля , а форкуть какой нибудь
готовый опенсор, или подключиться к проекту...

господи, какие вы смешные.

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

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

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

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

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

д0knojavaпропущено...


haproxy написан на Pure C. Что-ж вы свой std::язык для <substandard coders> пытаетесь примазать где не попадя?

Если вы хотите услышать мое мнение,
то С++ в своем развиии ушел не туда туда не знаю куда .

Единственное почему лично я использую С++ компилятор -
привязка кода к структуре , защита полей - класы ,
автоматический вызов деструкторов и обработка исключений.


вот тут пожалуй соглашусь, С with objects без намека на std:: звучит единственно разумным выбором.
у меня самого рука несколько раз срывалась на то, чтоб разрешить использовать class.

но каждый раз останавливала неизбежность линковки с libstdc++.

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

typedef struct my_struct_t my_struct_t;

и хитрый финт ушами с alloca()/vla, который позволяет объявить и инициализировать структуру на стеке (нужно лишь вернуть sizeof из "конструктора", это тоже скрывается).

и выглядит в итоге совсем не уродски:




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

Anatoly Moskovskynojavaда нельзя пускать гамнокодеров писать ни модули для апача, ни для нгинкса.
Судя по топикам которые вы создаете, с говнокодингом вы знакомы не понаслышке.
Поэтому поверим вам )))
Модератор: Отредактировано
стебелек 2.0 пишете?

Anatoly Moskovskyд0kА кто сказал что прикладника нужно запускать в С++ код ?
Нужно. С++ развивается именно в прикладном направлении.

угар. это последние-то изменения в C++14 и С++17 это для прикладника делаются?

что вы курите? какой нормальный прикладник будет изучать два кирпича по 900 страниц только стандартных библиотек, и это лишь чтоб понять, что в этой вашей STL нет вообще ничего для него пригодного?

чем прикладник вообще занимается обычно? наверное мается выбором перед std::string и string_view, или читает толмуд как правильно жить с SFINAE и move semantics, ну и не стрелять себе в голову через string aliasing?

да да. это все прикладные вопросы, они в любом прикладном ЯООП затрагиваются. да да да.

д0kАльтернативы автоматическому вызову деструкторов
и строго типизированному подстать языку
обработчику исключнний в С всеравно нет.

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

деструкторы для web программирования вообще не нужны.
жизненный цикл типового запроса очень мал - проще не деструктировать вообще ничего, и лишь по завершению обработки одним переприсвиванием поля hwm сбросить "аллокатор памяти" в нулевую позицию.
т.е. вместо тысяч безумно рандомных походов на деаллокацию и free() - просто делаем присваивание указателю. красота.

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

нужно только мозги прочистить от деструкторской шелухи, и наступит счастье.

ясен пончик, такой подход не канает для GUI, но для web обработчиков - на ура.

--

аналогично с исключениями - они вообще не нужны. мозг типового программиста засран напрочь этой извратной формой goto.
а все что нужно - это почитать про live-to-die в PHP и erlang, для прочистки мозгов, ну и внимательно посмотреть как реализована обработка ошибок в базах данных, тех-же oracle и mysql.

сразу наступит нешуточное прозрение.


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

ни разу не возникало необхходимости написать хоть какой-то иной код в обработчике исключений, ну а finally писал чисто как обезьянка - сказали писать так, писал, но в виду концепции live-to-die и управляемого освобождения ресурсов и этот код является абсолютно бесполезным.