История изменений

Речь идет о модуле для ALSA, чем мне еще ограничивать этот разговор?

Речь идет о том, что Erlang+C — это реальная альтернатива C++.

В качестве подкрепления этого тезиса вы приводите C-шный код. В котором вам указывают на ваши ошибки.

В оправдание вы начинаете говорить, что в вашем конкретном случае это не проблема.

Ну OK, за свою жизнь я столько наслушался этих самых «в моем конкретном случае», что уже не воспринимаю их всерьез. Посему вы просто в очередной раз продемонстрировали, что как только речь идет о C-шном коде, так все оказывается работоспособным в очень узком диапазоне ограничений.

Вот точно так же и ваш совет «Erlang+C» можно всерьез воспринимать только если очень и очень сильно ограничить контекст.

Разве это не валидный C++ код?

В нем есть синтаксические ошибки. Причем, судя по тому, что ошибка в декларации метода класса у вас повторяется несколько раз, вы C++ не видели очень давно.

Про то что с С++11 это deprecated я знаю.

Обсуждаемый здесь SO5 требует C++11, под C++03 он не собирается.

Ну и вообще, что за экивоки. Вот пример кода когда эксепшен на верхнем уровне не поймать. Либа чужая и сорцев у вас нет.

Это просто вы не понимаете, как писать на C++ не заморачиваясь на типы выбрасываемых исключений. Ключевые слова вам обозначили — exception safety. Если ваш код обеспечивает exception safety хотя бы на уровне basic guarantee, то вам без разницы, бросается ли bad_alloc, bad_cast, bad_exception, invalid_argument или еще что-то. Поэтому вы имеете возможность просто писать new или make_unique, или make_shared и не заморачиваться на проверки кодов возврата (*).

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

* если только речь не идет о специфических условиях, в которых C++ные исключения запрещены ключиками компилятора, например, жесткий real-time.

Речь идет о модуле для ALSA, чем мне еще ограничивать этот разговор?

Речь идет о том, что Erlang+C — это реальная альтернатива C++.

В качестве подкрепления этого тезиса вы приводите C-шный код. В котором вам указывают на ваши ошибки.

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

Ну OK, за свою жизнь я столько наслушался этих самых «в моем конкретном случае», что уже не воспринимаю их всерьез. Посему вы просто в очередной раз продемонстрировали, что как только речь идет о C-шном коде, так все оказывается работоспособным в очень узком диапазоне ограничений.

Вот точно так же и ваш совет «Erlang+C» можно всерьез воспринимать только если очень и очень сильно ограничить контекст.

Разве это не валидный C++ код?

В нем есть синтаксические ошибки. Причем, судя по тому, что ошибка в декларации метода класса у вас повторяется несколько раз, вы C++ не видели очень давно.

Про то что с С++11 это deprecated я знаю.

Обсуждаемый здесь SO5 требует C++11, под C++03 он не собирается.

Ну и вообще, что за экивоки. Вот пример кода когда эксепшен на верхнем уровне не поймать. Либа чужая и сорцев у вас нет.

Это просто вы не понимаете, как писать на C++ не заморачиваясь на типы выбрасываемых исключений. Ключевые слова вам обозначили — exception safety. Если ваш код обеспечивает exception safety хотя бы на уровне basic guarantee, то вам без разницы, бросается ли bad_alloc, bad_cast, bad_exception, invalid_argument или еще что-то. Поэтому вы имеете возможность просто писать new или make_unique, или make_shared и не заморачиваться на проверки кодов возврата (*).

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

* если только речь не идет о специфических условиях, в которых C++ные исключения запрещены ключиками компилятора, например, жесткий real-time.