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

#include <stdio.h>
 
class x
{
    public:
        x() { printf("x()\n"); }
        ~x() { printf("~x()\n"); }
};
 
class e
{
    public:
        e() { printf("e()\n"); }
        e(const e& src) { printf("e(src)\n"); }
        ~e() { printf("~e()\n"); }
};
 
void g(void)
{
    throw e();
}
 
void f(void)
{
    x* ptr = new x();
    g();
    delete ptr;
}
 
int main(void)
{
    try
    {
        f();
    }
    catch (e)
    {
        printf("Caught exception e\n");
    }
}

Казалось бы, достаточно простой код, но он таит в себе Memory leak: объект класса x создаётся, но никогда не уничтожается. Это очень вырожденный пример, но он передаёт очень важную суть: если вы не ожидаете от функции g(), что она будет генерировать исключение, и пишете код, то когда функция g() начинает генерировать исключения, код становится работающим некорректно, в чём вы и можете убедиться, запустив программу:

x()
e()
e(src)
Caught exception e
~e()
~e()

Обойти это можно, сделав класс-обвязку (а-ля smart ptr):

template <class ptr>
    class p
    {
        private:
            ptr *m_ptr;
 
        public:
            p(): m_ptr(0) {}
            p(ptr *pp): m_ptr(pp) {}
            ~p() { if (m_ptr!=0) delete m_ptr; }
 
            ptr *drop()
            {
                ptr *res = m_ptr;
                if(m_ptr!=0)
                {
                    delete m_ptr;
                    m_ptr = 0;
                }
                return res;
            }
 
            ptr &operator *() { return *m_ptr; }
            ptr &operator ->() { return *m_ptr; }
 
            bool validate() { return m_ptr != 0; }
            operator bool() { return m_ptr != 0; }
    };

И переписав функцию f():

void f(void)
{
    p<x> ptr(new x());
    if (ptr)
        printf("OK, validated\n");
    g();
}

Получаем вполне нормальное поведение:

x()
OK, validated
e()
~x()
e(src)
Caught exception e
~e()
~e()

Но… Если функция g() была использована во многих местах, это же получается тотальный рефакторинг кода! И не надо меня убеждать в том, что изначально надо было пользоваться штуками типа smart ptr!

Решить проблему можно, сделав сеппуку для функции g() и разбив её на две функции: враппер и, собственно, саму реализацию, то есть:

void _g(void)
{
    throw e();
}
 
void g(void)
{
    try
    {
        _g();
    }
    catch (e)
    {
        printf("Caught exception e\n");
    }
}
 
void f(void)
{
    x *ptr = new x();
    g();
    delete ptr;
}
 
int main(void)
{
    f();
}

То есть, мы избежим тотального рефакторинга, но при этом сможем пользоваться новой функцией _g(), которая будет кидать исключения. С другой стороны, это не всегда корректно. Представим себе ситуацию, что генерация исключения e() требует обязательного освобождения какого-либо ресурса, о котором функция _g() не знает (и ввиду её специфичной реализации не должна знать). Тогда если код, который будет отлавливать исключение e(), будет неявно пользоваться и g(), и _g(), то он рискует не освободить ресурс, когда это надо. Характерный пример:

class x
{
    public:
        x() { printf("x()\n"); }
        ~x() { printf("~x()\n"); }
        void alarm() { printf("alarm!\n"); }
};
 
void _g(void)
{
    throw e();
}
 
void g(void)
{
    try
    {
        _g();
    }
    catch (e)
    {
        printf("Caught exception e\n");
    }
}
 
void z(bool r)
{
    if (r) g();
    else _g();
}
 
void f(bool r)
{
    x *ptr = new x();
    try
    {
        z(r);
    }
    catch (e)
    {
        ptr->alarm();
    }
 
    delete ptr;
}
 
int main(void)
{
    f(true);
    f(false);
}

В результате выполнения получаем:

x()
e()
e(src)
Caught exception e
~e()
~e()
~x()
x()
e()
e(src)
alarm!
~e()
~e()
~x()

То есть, «Caught exception e» для нас — это неожиданная ситуация, так как мы ожидаем, что если _g() не отработала, то мы должны сами словить исключение и получить «alarm!».

Таким образом, исключения в C++ таят достаточно большую опасность, если их использовать неаккуратно. Попытка обойти подобную ситуацию есть в java — это специальная директива throws у метода, которая вынуждает разработчика либо ловить исключение, либо передавать его дальше, что, хоть, и не спасает от генерации Runtime Exception, но помогает сразу найти места, где вызывается метод, который генерирует исключение (потому что иначе просто ничего не скомпилится).

В общем, на этом пока мысли останавливаются.

В современном программистском мире появилась тенденция к изучению функциональных языков программирования. И на них сейчас пытаются выразить всё, что только под руку попадётся. Я называю это никак иначе как мозговым онанизмом.

Сразу оговорюсь: я не знаю парадигмы функционального программирования. И вряд ли её буду изучать до тех пор, пока мне это не понадобится. Но то, что, извините, вытворяют функциональщики, порой меня шокирует: решать элементарные задачи через, простите меня, жопу — это выше моих сил и нервов. Зато это повышает ЧСВ аффтаров до уровня over 9000, что очень настораживает и порой порождает сомнения в их адекватности.
Вот характерный разговор с товарищем ivansorokin (осторожно, русский мат).

ivansorokin:
void char_count_2(string s)
{
std::sort(s.begin(), s.end());

auto i = s.begin();
while (i != s.end())
{
auto j = find_if(next(i), s.end(), _1 != *i);
cout << *i << ": " << (j - i) << endl;
i = j;
}
}
SadKo: изврат?
ivansorokin: порно
SadKo: согласен
ivansorokin: обрати внимание что под find_if написано. _1 != *i. ищем элемент не равный *i
SadKo: мда
ivansorokin: а что?
SadKo: быдлокод
ivansorokin: ты ничего не понимаешь в функциональном программировании boost/lambda епть
SadKo: ну его нахер, это функциональное программирование, если оно позволяет плодить ЭТО.
ivansorokin: быдло пишет всякое дерьмо с указателями
int cnt[256];
char *p;
int i;

// str is pointer to input zero-terminated string;

for(p = str; *p; ++cnt[*p++]);
for(i = 0; i < 256; i++) {
if(cnt[i]) printf("%c = %d\n", i, cnt[i]);
}
такое дерьмо лучше?
SadKo: оно быстрее
ivansorokin: о госпади
SadKo: а вы любите ездить в Лондон через Нью-Йорк
ivansorokin: а тех кто пишет на Питоне, тогда вообще расстрелять
SadKo: Я к тому, что простую задачу превратили в какую-то хуйню. Или меряться функциональными пиписьками ща модно?
ivansorokin: модно, трендово...
SadKo: Так вот, послушай меня. То, что модно, диктуют всякие мудаки. Надо использовать не то, что модно, а то, что работает.
ivansorokin: var q = from a in array group a by a into g select new {a, g.Count()}
SadKo: буээээ

Я не отрицаю тот факт, что, возможно, функциональные языки нужны и ряд задач при помощи функциональных языков решается легче, быстрее и проще, нежели через привычные нам объектные языки. Тем не менее, это не означает, что абсолютно всё можно решить быстро, элегантно и красиво с помощью функционального программирования. И фанаты Python, Haskell, BOOST/C++ и иже с ним должны это понимать и, как говорится, «знать меру».

Забавно, но стал в последнее время замечать, что на мой сайт регулярно заходят в поисках алгоритмов сжатия по Хаффману. Да, будучи студентом второго курса, я изучал этот метод кодирования и даже написал демонстрационные программы для сжатия/распаковки файлов (от реальных их отличают некоторые ограничения в использовании). И даже написал три статьи (по теории, кодированию и декодированию) в набиравшем в своё время обороты журнале eXcode eZine, который, к сожалению, скончался.

Тем не менее, статьи у меня остались, и две я уже выложил у себя на вики в разделе «Статьи». Третью всё пока не соберусь перевести из html в wiki-формат.

Тем не менее, мой сервер регулярно штурмуют вопросами вроде «Пример реализации алгоритма Хаффмана на языке C++». Что ж, мне приятно, что труд мой не пропал для кого-то даром. Тем не менее, также берёт обида за то, что такие вещи можно и самостоятельно реализовать, благо алгоритм кодирования/декодирования очень прост.

Вот, почитал статью:

http://www.xakep.ru/post/38388/default.asp

Такое ощущение, что автор только всю жизнь и программировал на паскале.
Он пытается сравнить системные языки программирования с чисто прикладными.
Возникновение монструозно сложного языка C++, сочиненного путем тупого добавления к C без исправления его многочисленных дефектов модных конструкций объектно-ориентированного программирования
Ну уж извольте. Если бы не было потребности, то язык не возник бы. Язык не сложный, просто нужно иметь пару извилин и помнить, что можно делать, а что нельзя.
Отсюда понятно, почему серьезные специалисты употребляют такие сильные выражения как «развращение малолетних», «интеллектуальная зараза» и т.п., говоря о языках C/C++.
Нет, не понятно. Это понятно автору статьи, который не в состоянии часок-другой посидеть с языком и разобраться в его тонкостях. Я понимаю «развращение малолетних» как тот факт, что С++ новичкам освоить сложно. Хотя бы потому, что в нём много тонкостей.
Подчеркнем, что BlackBox, хотя и аналогичен виртуальным машинам Java и .NET, но работает с эффективным компилируемым кодом. Благодаря этому программы, написанные на Компонентном Паскале в Блэкбоксе, качественно более эффективны, чем программы на Java и С#.
Бред. Откровенный бред. И меня больше всего добило это:
При создании C была проигнорирована вся накопленная к тому времени мудрость создания высоконадежных языков программирования. В результате на C легко написать совершенно нечитаемые конструкции.
А зачем эти конструкции писать? Чтобы выпендриться перед кем-то? А про искусство оформления кода мы вообще забыли, да? Про то, что надо писать программы понятно, чтобы любой другой человек с минимумом усилий их понимал.

Итог: намешали в кучу Pascal, C, C++, C#, Java, Oberon, Blackbox. При этом не было сказано, для какой конкретной задачи используется тот или иной язык. C++ не подойдёт для написания всяких веб-систем, работающих через браузеры — имхо очень сложно. В то время, как Java или тот же C# не подойдут для написания операционной системы. Из-за их прикладного характера.