Список в конце поста написан Лавсаном 2 года назад. (2011-03-23 19:56:00) (источник)
Надеюсь, автор не подаст жалобу в Роспатент за перепечатку :-)
Кстати, sudo cast lovesan.

Чтобы проверить актуальность вопроса, всю последнюю неделю я долго и нудно использовал этот список в дискуссиях. Чтобы разобрать отдельные пункты отдельно.

Временное резюме: С++ всё еще актуален по историческим причинам. Еще есть мобилки (sudo cast mono), гиперкластеры для шиндовс 3.11 (sudo cast vromanov) и базы данных. Т.к. он актуален, но не предназначен ни для чего (см. выводы в конце списка) новых специалистов по нему должно быть мало. Маленькая конкуренция на огромной области применения — огромное лавэ $$$. Вот это и есть истинная причина использовать кресты — возможность срубить €€€.

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

Заодним, крестопоклонники смогут выйти на последний и решительный бой, т.к. сегодня пятница и вечером будет время пообщаться. Поклонникам мамкиного борща тоже наверняка есть что добавить, конструктивно и аргументированно.

Вот этот список:

1. Вырвиглазный синтаксис и контекстно-зависимая грамматика
   • медленная компиляция
   • частые «internal error» в компиляторах
   • код плохо читается и его сложно поддерживать
   • разбор кода различными инструментами, вроде IDE, и его генерация - сильно затруднены
2. ручное управление памятью
   • неудобства при работе с динамической памятью
   • утечки памяти
   • висячие ссылки
   • сегфолты
   • стандартные средства, как то malloc/new, работают медленно
   • фрагментация кучи
   • велосипедные аллокаторы на каждом шагу
     • которые далеко не факт что эффективнее malloc/new

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

   • отладка затруднена
   • написание GC, по факту, невозможно, отчасти из-за (5), (7) и (8)
3. Никакого ABI
4. Нестандартизированный и непредсказумый name mangling
5. Дублирование функционала Си
   • сами фичи из Си никуда не деваются при этом
     • отчасти из-за того, что по функционалу превосходят аналоги из C++

   • запутывает новичков
   • malloc - new/new[], free - delete/delete[]
   • препроцессор - шаблоны
   • указатели - ссылки
     • ссылка не может быть NULL, что способствует появлению висячих ссылок и сегфолтов

   • структуры - классы
   • stdio - iostream
6. Стандартная библиотека убога
   • Отсутствует даже такой функционал, как вменяемая работа со строками и многомерные массивы
     • Юникод?

7. Слабая типизация
   • способствует ошибкам
   • затрудняет отладку
   • const не дает абсолютно никаких гарантий
   • при этом система типов невероятно переусложенена
     • в основном из-за пунктов (2), (5) и (9)
     • медленная компиляция
     • частые внутренние ошибки в компиляторах

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

   • множественное наследование неудобно в использовании
     • проблема ромба по дефолту не разрешается никак

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

   • деструктор можно вызывать до выхода из блока кода, или до delete
     • гарантированная утечка ресурсов/сегфлот
     • это не предотвратить никак, деструктор обязан быть public

   • одиночная диспетчеризация
     • виртуальные методы в конструкторах не работают
     • реализована убого
       • pure virtual function call
       • сложности в случае с множественным наследованием
       • деструкторы обязаны быть виртуальными
         • по дефолту - не виртуальные

       • никаких интерфейсов, только классы

   • порядок инициализации статических членов классов не определен
   • private, public и protected не дают никаких гарантий сокрытия данных
     • к инкапсуляции же не относятся совершенно никак

   • отсутствие «свойств»
     • вынуждает городить getter'ы и setter'ы
       • раздувание кода
       • размывание интерфейса класса

   • неявно генерирумые конструкторы, деструкторы и операторы присваивания
   • «friend» нарушают инкапсуляцию
9. шаблоны
   • очень сильно замедляют компиляцию
   • раздувание кода
   • обфускация кода
   • результат раскрытия плохо предсказуем
   • сложности в отладке
     • километровые и плохо читаемые сообщения об ошибках при компиляции

   • нарушают инкапсуляцию
     • обязаны содержать реализацию в заголовочных файлах

   • позволяют генерировать некорректный код
10. исключения
    • отсутствие finally/unwind-protect
      • заставляет городить классы ради одних деструкторов
        • раздувание кода
        • медленная компиляция
        • медленная работа

    • конфликтуют с другими возможностями языка
      • конструкторы/деструкторы
      • ручное управление памятью

    • работают медленно
    • малофункциональны (ср. CL condition system)

По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 - и для прикладного.

У C++ нет области применения.

Всем привет, разрабатываю одну программу, и в будущем планирую продавать. Так-как половина уже написана, начал задумываться о будущем так сказать. Вот и возникла пара вопросов:
нужно ли регистрировать свою программу где-то, и подтверждать, что права на программу мои? У меня программа кроссплатформенная, собственно нужно ли мне приобрести лицензию на Windows чтобы все было легально?

Доброго дня. Допустим есть

message Message
{
   required string str = 1;
}

libprotobuf ERROR google/protobuf/wire_format.cc:1059] Encountered string containing invalid UTF-8 data while serializing protocol buffer. Strings must contain only UTF-8; use the 'bytes' type for raw bytes.

Вопрос: как в поле str ( оно должно оставаться string, т.к. туда помимо сериализованного Message может записываться любая строка) записать то, что требуется, не изменяя при этом Message?

P.S. Если кого-то заинтересует зачем надо так извращаться, или найдутся желающие сказать очередное «не нужно» - идите лесом.

Привет.
Есть 2 буфера, которые будут лежать в shared memory, в один из них будет производиться запись из 2-х процессов. Как только этот буфер заполнится, он отсылается по сети, в это время используется второй буфер. Timestamp'a в данных нет, порядок записи имеет значение.
Собственно, как это правильно синхронизировать, при условии, что мьютексов и семафоров нет. Есть только сообщения, которые процессы могут посылать друг другу.

Я пока надумал 2 возможных решения:
1. Посылать сообщения как механизм синхронизации. Решение простое, но кажется, что неэффективное, потому как сообщений будет чуть более, чем докуя.
2. Каждому процессу писать в свой буфер, а при заполнении синхронизировать (опять же сообщениями). Но тогда встаёт вопрос, как лучше синхронизировать, если timestamp'a нету. Его добавление влечёт собой 4(?) дополнительных байта.

Если у кого-нибудь есть дельные мысли, прошу поделиться. Спасибо.

В std::cout передаются какие-то левые указатели, не могу понять почему.

struct Aaa
{
	typedef std::vector < std::string > Vec;
	Aaa()
	{
		m_vec.push_back( "sobaka" );
		m_vec.push_back( "mendeley" );
	}
////
	Vec m_vec;
};

struct Bbb
{
	Aaa& get(){ return m_aaa; }
////
	Aaa m_aaa;
};


/////////// main() ////////
...
Bbb b_obj;
Aaa &ref_a = b_obj.get();
BOOST_FOREACH( const Aaa::Vec::value_type &_val, ref_a.m_vec )
{
	std::cout << _val << "\n";
}

Здравствуйте форумчане, Столкнулся с проблемой у моего Raspberry Pi(тип B), что когда к нему ничего не подключено по RCA, то не работает картинка по HDMI.

В каких областях программирования С++ незаменим? И почему?

Интересно, существует ли такой? Хочется сделать большую битовую карту. И выставлять/проверять статус «занятости» без блокировок. Вообще похоже, что можно будет обойтись обычный байтовым CAS. Нужно для реализации lockless множества чисел. Прогамма работает с сообщениями, если уже сейчас обрабатывается сообщение связанное с пользователем (точнее с IP), и приходит еще одно, то новое должно быть отложено пка не завершится обработка предидущего. Таких обработчиков ограниченое количество - 100-200, обычно 16. Нужна структура, где хранить те IP которые в обработке.

Привет. Какой наиболее правильный способ обработки EAGAIN ошибки send'a у неблокирующего сокета? Способ подождать n милисекунд кажется workaround'ом или обычно так и делают? Спасибо.
P.S.: Это embedded приложение, монстрообразный boost мне не нужен.

Оказывается, free или top при показе свободной памяти не показывает память занимаемую объектами sys v (семафоры, очередеи, shared memory). Если у вас есть какие-либо приложения, которые ее используют данные мониторинга могут окзаться сильно неправильными

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

• retcode_t push(void* data, int size);
• retcode_t pop(void* data, int max_size, int* size);

При том это все рабоатет на уровне сообщения. Т.е. если вставили тру кусочка по 100, 200, и 300 то и выберем 100, 200, 300 а не 600 одним куском.

Хотелось бы это сделать без блокировок. Писателей/читателей от 4 до 50

Добрый день! В приложении используется Shared Memory. Для того, чтобы разные процессы не меняли данные одновременно используется spinlock в виде переменной, лежащей в той-же Shared Memory. Проблема в том, что при большом количестве заблокированных процессов, они начинают слишком много времени тратить в цикле спинлока. Сейчас есть идея сделать счетчик процеесов, коорые ждут лока и если их больше количества ядер-1, то сразу вызвать sleep вместо цикла спинлока. Может есть другие решения? Где про это все хорошо написано?