Недостатки чистого функционального программирования

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

Недостатки чистого функционального программирования

Статья скорее пытается сказать «в функциональных ЯП плохо организованы базовые алгоритмы». Аля «из гнилых бревен хорошей бани не построишь»

Недостатки чистого функционального программирования

Это круто если в итоге эта строчка не отработает на тысячи часов больше её многострочного, но оптимизированного аналога.

QtQuick/QML в качестве игрового UI

Qt Quick Compiler планируют добавить в публичную лицензию в Qt 5.8

QtQuick/QML в качестве игрового UI

намного проще настроить алгоритм сборки/деплоя, чем каждый раз тянуть костыль из-за отсутствия MOC. Например, qmake определяет переменную $$[QT_INSTALL_LIBS] — директория с библиотеками Qt. Добавляем все нужные библиотеки в INSTALLS, определяем и добавляем шаг сборки make install. Запускаешь билд и всё лежит на своих местах. Архивируй и распространяй.

QtQuick/QML в качестве игрового UI

сложно сказать насколько будет выигрыш в большом проекте, использующем (около) полный набор API, но на одной из своих утилит получил 8 мб вместо 40 (и то потому, что не смог статически прилинковать libmysql и libwinpthread)

QtQuick/QML в качестве игрового UI

Жить с Qt без MOC'a может быть и можно, но зачем? Неужели QtCreator — единственный IDE, поддерживающий компиляцию в несколько этапов?

Предлагаю обратить внимание на статическую линковку. Всё равно лицензия нужна для любого более-менее серьезного проекта

Компилятор С/С++ на базе LLVM для мультиклеточных процессоров: быть или не быть?

потому что там, где есть C/C++, есть как минимум линукс и половина других яп. А там, где есть Rust, есть амбиции и, собственно, Rust

Коммуникации в программировании — во сне и наяву

«кто в опенспейсе сидел тот в цирке не смеется?»

C++ без new и delete

а через пару лет, когда все компиляторы научатся генерировать для оберток столь же эффективный код, что и для new/delete, вы будете заставлять джуниоров переписывать new/delete на shared_ptr/unique_ptr?

C++ без new и delete

но это писал не я

C++ без new и delete

моя изначальная мысль заключалась в том, что с годами в коде на плюсах не должно ничего ломаться…

C++ без new и delete

вот когда я прознал о том, что using namespace вполне делается внутри фунции, жить действительно стало чуточку проще

C++ без new и delete

Ну, лично я готов злоупотребить плохой практикой если увижу, что блок кода наполовину состоит из std:: (в хедер, однако, ни-ни). И рассчитывать на то, что 15 лет назад рандомный коллега не зафигачил в проект using namespace std я бы точно не стал

C++ без new и delete

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

C++ без new и delete

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

C++ без new и delete

только не надо именовать функции с большой буквы, пожалуйста… )
Что до deleteLater — его можно и в стандартные смартпоинтеры сунуть. Через лямбду в deleter'е

C++ без new и delete

так в итоге внутри unique_ptr есть проверка на nullptr и внутри delete есть вторая такая же проверка. Компилятор по идее должен просто выкинуть одну из них из-за её тождественности.

C++ без new и delete

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

Почему я больше не использую современный C++

а зачем писать целый аллокатор, если можно перед push_back написать if (v.capacity() == v.size()) v.reserve(v.capacity()*1.2 /*+100*/) или любой другой закон увеличения объема?