• Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.
  
• Возможность написать класс "по кусочкам". Т.е. я сначала пишу определение самого класса, без определений его методов. А потом, ниже определяю все его методы. Очень удобно читать код. Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.
  
• То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.
  
• Считаю, что маленькая стандартная библиотека — преимущество. Она может быть реализована на обширнейшем количестве систем. Я бы еще ее подсократил, или расчленил на опциональные компоненты. Например, не везде существуют файлы и потоки ввода/вывода — взять те же микроконтроллеры. В оконных приложениях Windows, потоки cout/cin не имеют смысла. Я бы даже time.h сделал бы опциональным. Если у вас есть обширная стандартная библиотека, она влечет зависимости от наличия фич платформы, которые не везде присутствуют. Хотя опять же, опциональность компонентов библиотеки может спасти ситуацию.

clang++ -fsanitize=undefined main.cpp

test> ./a.out                              
0 : 0 : 27
1 : 1000000000 : 82
2 : 2000000000 : 41
main.cpp:8:38: runtime error: signed integer overflow: 3 * 1000000000 cannot be represented in type 'int'
3 : -1294967296 : 124
4 : -294967296 : 62
5 : 705032704 : 31
6 : 1705032704 : 94
7 : -1589934592 : 47
8 : -589934592 : 142
9 : 410065408 : 71

test> ./a.out                              
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==2982==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0001078c7ef1 bp 0x7ffee83389a0 sp 0x7ffee8338980 T298609)
==2982==The signal is caused by a READ memory access.
==2982==Hint: address points to the zero page.
    #0 0x1078c7ef0 in main (a.out:x86_64+0x100000ef0)

==2982==Register values:
rax = 0x0000000000000000  rbx = 0x0000000000000000  rcx = 0x0000000000000000  rdx = 0x00007ffee83389d0  
rdi = 0x0000000000000001  rsi = 0x00007ffee83389c0  rbp = 0x00007ffee83389a0  rsp = 0x00007ffee8338980  
 r8 = 0x0000000000000000   r9 = 0xffffffff00000000  r10 = 0x00007fff9828f0c8  r11 = 0x00007fff9828f0d0  
r12 = 0x0000000000000000  r13 = 0x0000000000000000  r14 = 0x0000000000000000  r15 = 0x0000000000000000  
UndefinedBehaviorSanitizer can not provide additional info.
==2982==ABORTING

f := createFile("/tmp/defer.txt")
defer closeFile(f)
writeFile(f)

KP>f := createFile("/tmp/defer.txt")
KP>defer closeFile(f)
KP>writeFile(f)
KP>

std::shared_ptr<HANDLE> createFile(const boost::file_system::path&);

        public static T Deserialize<T>(Stream input)
        {
            var textReader = new StreamReader(input);
            // че-то читаем из textReader

            using (var xmlReader = XmlReader.Create(textReader))
            {
                return Deserialize<T>(xmlReader);
            }
        }

        public static T Deserialize<T>(Stream input)
        {
            using (var textReader = new StreamReader(input))
            {
                // че-то читаем из textReader
                using (var xmlReader = XmlReader.Create(textReader))
                {
                    return Deserialize<T>(xmlReader);
                }
            }
        }

L>>Ага, берешь такой какую-нибудь Atmega 328 и запихиваешь

gcc based Ada compiler

The compiler generates AVR object code based on your Ada code.

Туда можно запихать Java Card и Аду...

    open(target, 'a').write(data)

    with open(target, 'a') as tg:
        tg.write(data)

W>>а не будут каталогизировать недостатки

Rather than answering the individual myself, I forwarded his letter to Steve Vinoski of Hewlett-Packard, with
whom I had previously corresponded regarding the efficiency of C++. Here is an excerpt from his response:

    I have heard a number of people over the years voice opinions similar to those of your
    colleagues. In every case, those opinions could be attributed to a lack of factual knowledge
    about the C++ language. Just last week I was chatting with an acquaintance who happens to
    work for an IC testing manufacturer, and he said they don't use C++ because "it does things
    behind your back." When I pressed him, he said that he understood that C++ calls malloc()
    and free() without the programmer knowing it. This is of course not true. It is this sort of
    "myth and legend" that leads to opinions such as those held by your colleagues….
    Finding the right balance [between abstraction and pragmatism] requires knowledge,
    experience, and above all, thought. Using C++ well requires effort, but in my experience the
    returns on the invested effort can be quite high.

I like to think of this book, then, as my answer to this individual, and, I hope, a repository of knowledge to
help put to rest many of the myths and legends surrounding C++.