ХГД>От записи штоле защищено?
Кеп подсказывает что инициализирующий конструктор не вызывается.

ХГД>И на выяснение этого факта надо много часов с отладчиком и дизассемблером?
В том случае, про который я рассказываю, компилятор сгенерировал инициализирующий конструктор для таблицы замен знаменитого госта (что такое таблица замен и гост я расказывать не буду — ты все равно не поймеш), сгенерировал он его потому что мудрила, набивший эти таблицы сделал это с нарушением сишного синтаксиса, а сам код — это был как раз тот случай когда модуль к ядру был написан на С++ и собирался как С++ код. Как ты догадываешся, все внешние юнит-тесты прекрасно проходили. Но связь с другой стороной пропала — пакеты вроде ходят, но расшифроваться не могут.
А теперь, умник, обозначь свои действия в этой ситуации.

ХГД>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?

IID>Ну, справедливости ради, GDB та еще какашка
Нормальный отладчик, ты просто им пользоваться не умееш.

IID>А может автор живую отладку не осиливает, и пользуется исключительно sprintf-ом в файл/компорт/etc.
Автор вообще програмирует на счетах.

Здравствуйте, eskimo82, Вы писали:

C>>В виде intrinsinc'ов — ровно наоборот, если речь идёт о gcc.
E>Вот и напиши здесь даты появления стандарта C11 и дату появления __sync_xxx функций в gcc.
А в PCC их до сих пор нет.

E>>>Итак, какая функция в WinAPI возвращает POINT ?
C>>Лень искать.
E>Поищи и приведи ссылку, иначе твоё заевление не соответсвует действительности.
Мне совсем лень искать. Да и не важно, если я даже ошибаюсь.

E>>>Вот и начни с себя. Потрать доллары на своё образование.
C>>Ну так готов спорить?
E>Лень спорить с балбесом.
Ну так ты признаёшь, что:
1) В C89 структуры могут возвращаться из функций.
2) В С++ абсолютно аналогичное поведение.

Или как?

C>>Что такое "агрегатный обьект"?
E>Ты не знаеш принципы ООП ?
Ну так что это такое? Я не знаю термина "агрегатный объект".

E>>>1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
C>>Это автоматическая переменная.
E>Кто сказал ?
Я сказал. Ещё вопросы про вменяемое поведение в С будут?

C>>За глобальные переменные вообще расстрел сразу.
E>Это категогричное заявление сразу выдает дилетанта наслушавшегося страшилок про глобальные переменные.
Я их не наслушался, а наиспытвался на себе.

E>Глобальные переменные могут быть очень полезны, а могут нести вред — это зависит от того как и для чего они используются.
Нет, пользы от глобальных переменных нет совсем.

E>Ты ведь не будеш тут брызгать слюной по поводу синглетонов ?, а ведь их реализация строится как раз на основе глобальных переменных, может и обьявленых как локально статические, но сути это не меняет.
Синглтоны — это те же глобальные переменные и точно так же идут в морг.

C>>Да, всего лишь молчаливо даст доступ к файлу. Тут если посмотреть, то в CVE от uninitialized access примерно процентов так 10% багов.
E>Или не даст доступ к файлу.
Да, в зависимости от фазы Луны.

C>>Ну так тут кто-то утверждает, что в Java всякие странные проблемы с вызовом super. В чём в Java проблемы с вызовом super?
E>В Java вообще возникает много странных проблем по сравнению с C++.
Ну то есть, Java ты не знаешь, и привести примеры реальных источников ошибок оттуда не можешь.

C>>Ну вот видишь.
E>Что тут видеть, если человек вообще не написал конструктор ? Согласись — это разные немного вещи: 1. не написать конструктор вообще, 2. в процесе модификации обьекта добавить коллекцию и забыть написать её создание в конструкторе.
А ещё можно забыть вообще код написать.

E>Второй случай как раз однозначно соответсвует потенциальным Сишным самострелам. В этом варианте С++, в отличии от Java, оказывается языком где нету такого замечательного шанса пострелять себе в ноги. Так что о том что Java — это безопасный язык ты можеш лечить молодых школьников.
В Java я уже показал как пишется подобный код. В С++ тоже точно так же можно написать:

class test_t
{
    std::map<std::string, int> *m_;
};

А потом плакаться про забытую инициализацию m_.

C>>Не надо указывать явный static.
E>А теперь ответь на следующие вопросы:
E>1. Как будут инстанцироваться методы add_to_list ?
При использовании.

E>2. Сколько копий их будет ?
Ровно одна, за исключением случаев inline'а, даже если шаблон инстанцируется из нескольких единиц компиляции.

E>3. Есть ли разница в количестве копий с Сишным вариантом ?
Есть. В С количество инстанцирований зависит от умности линкера.

CC>Дайте мне в С:
CC>классы с конструкторами, деструкторами, операторами и наследованием
За исключением операторов всё реализуемо.

CC>перегрузка функций
По указателю. Получается даже гибче чем в С++.

CC>templates (variadics included)
Некоторая часть реализуема на основе макросов, в том числе variadic-макросов.

CC>и я уже буду счастлив.
Ты счаслив ?

AWW>>Ну дык эти как СИ с классами. Это не С++.
CC>Даже С с классами уже помогает сократить объём кода раза эдак в 2-3 и облегчить жизнь разработчику за счёт автоматизации.


Что кассается драйверов и прочих модулей ядра — как я уже говорил отмена исключений и RTTI выпиливает практически весь С++ со почти всей стандартной библиотекой. Остается Си с классами и темплейтами и немного алгоритмов которые не бросают исключений.

Что осталось:
1. Наследование, полиморфизм из ООП.
2. Автоматический контроль за временем жизни переменных, RAII
3. Темплейты и обобщеное програмирование.


А теперь, можно задасться вопросом, насколько оставшийся функционал отличается от Сишного:
1. Наследование, полиморфизм из ООП.
— Элементы ООП прекрасно реализуются средствами Си.

2. Автоматический контроль за временем жизни переменных, RAII
— Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно. Следовательно, всё что можем — это тривиальные конструкторы и двухступенчатая инициализация аля как в MFC (после тривиального конструктора руками вызывать Init-функцию, которая и сделает всю реальную работу по конструированию и вернет ошибку). Это сводит на нет весь этот пункт — какая разница, что забывать вызвать руками, какой-ть free или какой-нибудь init.

3. Темплейты и обобщенное програмирование.
Некоторая часть может быть реализована на основе макросов препроцессора, возможно эта часть даже перекрывает все потребности.


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

Вам такой С++ вообще нужен ?

C>>>В виде intrinsinc'ов — ровно наоборот, если речь идёт о gcc.
E>>Вот и напиши здесь даты появления стандарта C11 и дату появления __sync_xxx функций в gcc.
C>А в PCC их до сих пор нет.
И що ?

E>>>>Итак, какая функция в WinAPI возвращает POINT ?
C>>>Лень искать.
E>>Поищи и приведи ссылку, иначе твоё заевление не соответсвует действительности.
C>Мне совсем лень искать. Да и не важно, если я даже ошибаюсь.
Это как раз важно, их нет потому что WinAPI родилось тогда когда возврата структурных типов в Си еще не было.

E>>>>Вот и начни с себя. Потрать доллары на своё образование.
C>>>Ну так готов спорить?
E>>Лень спорить с балбесом.
C>Ну так ты признаёшь, что:
C>1) В C89 структуры могут возвращаться из функций.
C>2) В С++ абсолютно аналогичное поведение.
C>Или как?
Возврат структурных типов в Си появился не сразу, довольно долгое время его не было.

C>>>Что такое "агрегатный обьект"?
E>>Ты не знаеш принципы ООП ?
C>Ну так что это такое? Я не знаю термина "агрегатный объект".
Значит учи матчасть.

E>>>>1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
C>>>Это автоматическая переменная.
E>>Кто сказал ?
C>Я сказал. Ещё вопросы про вменяемое поведение в С будут?
Отлично, а теперь покажи кодом, что это автоматическая переменная.

C>>>За глобальные переменные вообще расстрел сразу.
E>>Это категогричное заявление сразу выдает дилетанта наслушавшегося страшилок про глобальные переменные.
C>Я их не наслушался, а наиспытвался на себе.
Если ты разбирал говнокод — это еще не повод для категоричных обобщений. Все говнокод разбирали.
Ты же делаеш обобщение, аналогичное: был избит неграми — значит всех негров под расстрел. Надеюсь ты осознаеш, что твоё обобщение неверно ?

E>>Глобальные переменные могут быть очень полезны, а могут нести вред — это зависит от того как и для чего они используются.
C>Нет, пользы от глобальных переменных нет совсем.
E>>Ты ведь не будеш тут брызгать слюной по поводу синглетонов ?, а ведь их реализация строится как раз на основе глобальных переменных, может и обьявленых как локально статические, но сути это не меняет.
C>Синглтоны — это те же глобальные переменные и точно так же идут в морг.
Тем не менее это один из архитектурных паттернов ООП. Ты противник ООП ?

C>>>Да, всего лишь молчаливо даст доступ к файлу. Тут если посмотреть, то в CVE от uninitialized access примерно процентов так 10% багов.
E>>Или не даст доступ к файлу.
C>Да, в зависимости от фазы Луны.
Но виноват то не язык, а человек написавший код.

C>>>Ну так тут кто-то утверждает, что в Java всякие странные проблемы с вызовом super. В чём в Java проблемы с вызовом super?
E>>В Java вообще возникает много странных проблем по сравнению с C++.
C>Ну то есть, Java ты не знаешь, и привести примеры реальных источников ошибок оттуда не можешь.
Ну да, Java я не знаю. Предпочитаю писать на С++ и С. Как истиный валенок, поддавшить на маркетинговые лозунги об безопасном языке, первыми же строчками на Java выстрелил себе в ногу. Вот такой вот "безопасный язык".

C>>>Ну вот видишь.
E>>Что тут видеть, если человек вообще не написал конструктор ? Согласись — это разные немного вещи: 1. не написать конструктор вообще, 2. в процесе модификации обьекта добавить коллекцию и забыть написать её создание в конструкторе.
C>А ещё можно забыть вообще код написать.
Можно. Но одно дело код ненаписать, а другое — в процесе его модификации сделать опасным. Или по твоему нет никакой разницы ?

E>>Второй случай как раз однозначно соответсвует потенциальным Сишным самострелам. В этом варианте С++, в отличии от Java, оказывается языком где нету такого замечательного шанса пострелять себе в ноги. Так что о том что Java — это безопасный язык ты можеш лечить молодых школьников.
C>В Java я уже показал как пишется подобный код. В С++ тоже точно так же можно написать:
C>

C>class test_t
C>{
C>    std::map<std::string, int> *m_;
C>};
C>

C>А потом плакаться про забытую инициализацию m_.
Ты любитель гемороя ? Зачем тебе лишний указатель ?

C>>>Не надо указывать явный static.
E>>А теперь ответь на следующие вопросы:
E>>1. Как будут инстанцироваться методы add_to_list ?
C>При использовании.
Правильно.

E>>2. Сколько копий их будет ?
C>Ровно одна, за исключением случаев inline'а, даже если шаблон инстанцируется из нескольких единиц компиляции.
Ровна одна для каждого варианта T.

E>>3. Есть ли разница в количестве копий с Сишным вариантом ?
C>Есть. В С количество инстанцирований зависит от умности линкера.
В С++ тоже вообще-то. Кол-во копий в обоих вариантах будет одинаковым. Внезапно, да ?

Здравствуйте, Abyx, Вы писали:

A>можно писать на подмножестве С++, которое не требует рантайма и каких-то фич которые плохо работают в ядре.
A>это будет очень большое подмножество со многими полезными фичами.

Где про это можно узнать поподробнее применительно к Linux kernel? Я помню, давным давно где-то кто-то что-то пытался сделать, но был съеден Линусом заживо

Здравствуйте, uncommon, Вы писали:

A>>можно писать на подмножестве С++, которое не требует рантайма и каких-то фич которые плохо работают в ядре.
A>>это будет очень большое подмножество со многими полезными фичами.
U>Где про это можно узнать поподробнее применительно к Linux kernel?
Я видел проект, где ядро на С++, разделяемое между Linux и Windows. Работало через тонкую прослойку на С.

Здравствуйте, eskimo82, Вы писали:

C>>А в PCC их до сих пор нет.
E>И що ?
То что С отстаёт от С++ !!!!11111!!!

C>>Или как?
E>Возврат структурных типов в Си появился не сразу, довольно долгое время его не было.
Ну так он был в C89 или нет?

C>>Ну так что это такое? Я не знаю термина "агрегатный объект".
E>Значит учи матчасть.
Гугл со мной согласен. Этот термин упоминается в контексте программирования на 1С.

C>>Я сказал. Ещё вопросы про вменяемое поведение в С будут?
E>Отлично, а теперь покажи кодом, что это автоматическая переменная.

int set_mode(const char *path)
{
   int mode;
   return chmod(path, mode);
}

C>>Я их не наслушался, а наиспытвался на себе.
E>Если ты разбирал говнокод — это еще не повод для категоричных обобщений. Все говнокод разбирали.
E>Ты же делаеш обобщение, аналогичное: был избит неграми — значит всех негров под расстрел. Надеюсь ты осознаеш, что твоё обобщение неверно ?
Синглтоны — это Гитлеры.

C>>Синглтоны — это те же глобальные переменные и точно так же идут в морг.
E>Тем не менее это один из архитектурных паттернов ООП. Ты противник ООП ?
Нет, я противник глобальных переменных. Оборачивание глобальной переменной в объект её менее отстойной не делает.

C>>Да, в зависимости от фазы Луны.
E>Но виноват то не язык, а человек написавший код.
Или тот, кто проектировал язык.

E>Ну да, Java я не знаю. Предпочитаю писать на С++ и С. Как истиный валенок, поддавшить на маркетинговые лозунги об безопасном языке, первыми же строчками на Java выстрелил себе в ногу. Вот такой вот "безопасный язык".
Да, безопасный. Так как не имеет undefined behavior в этом случае.

C>>А потом плакаться про забытую инициализацию m_.
E>Ты любитель гемороя ? Зачем тебе лишний указатель ?
Ну так сам же любитель геморроя. Любой программист на Java написал бы:

public class Test
{
    private final IdentityHashMap map=new IdentityHashMap();
}

А не занимался бы созданием лишнего геморроя.

E>>>2. Сколько копий их будет ?
C>>Ровно одна, за исключением случаев inline'а, даже если шаблон инстанцируется из нескольких единиц компиляции.
E>Ровна одна для каждого варианта T.
Конечно.

E>>>3. Есть ли разница в количестве копий с Сишным вариантом ?
C>>Есть. В С количество инстанцирований зависит от умности линкера.
E>В С++ тоже вообще-то. Кол-во копий в обоих вариантах будет одинаковым. Внезапно, да ?
Нет, неверно. В С++ линкер удалит лишние копии. В С это не гарантируется, хотя часто работает.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Здравствуйте, andyag, Вы писали:

AWW>>>То есть для того что бы не делать ошибок на СИ нужна выскокая квалификация програмиста, а на С++ можно избежать ошибок и используя менее квалифицированную рабсилу.

A>>Это заблуждение. В мире СИ нужно делать много специфической работы, которой нет в других ЯП. Безусловно, минусом это является только когда речь заходит о вполне конкретных задачах, типа "сделать за 2 часа и чтоб работало".

AWW>Ну никакое это не заблуждение )).
AWW>В СИ очень много работы на прямую с памятью, в С++ это постарались убрать, точнее дали возможность этого избежать.
AWW>Прямая работа с помятью, (выделение, освобождение, инициализация ) всегда генерирует множество ошибок. То есть на СИ писать сложнее, но когда это необходимо то нужна более квалифицирванная рабсила.

Я не могу согласиться про квалификацию. Для программиста на Си навык "правильной работы с памятью" будет примерно настолько же важным, насколько для программиста на какой-нибудь Java важным будет навык "вытащить данные из БД". И то, и другое, безусловно, требует опыта и знаний, но с точки зрения практической полезности работа с памятью ради работы с памятью не имеет смысла — нужно что-то ещё.

AWW>То есть СИ более низкоуровневый язык, а чем ниже уровень, тем ближе к "железу", тем выше нужна квалификация. Ну что бы написать тоже самое на C# надо скажем 10 строчек, на СИ надо 100. C# даст кучу предупреждений которые в силу самого языка вожможно выявить и подсказать программисту.
AWW>В СИ есть у тебя указатель на буфер, это просто адрес, и крутись как хочешь — весь контроль тебе передали, в С++ уже есть ссылки, ошибок наделать можно меньше.

Т.е. самая высокая квалификация у программистов микроконтроллеров, а самая низкая — у энтерпрайзеров? По-моему неверно. Квалификация — это разница между самыми лоу левел и самыми хай левел знаниями/навыками. Всреднем, ИМХО, чем больше лоу левел, тем меньше хай левел.

AWW>Если в языке много поводов сделать ошибок, это писать на нем без ошибок — нужна более высокая квалификация.

Это не квалификация, а, извините, просто степень задротства Чем больше ресурсов уходит на борьбу с языком, тем меньше остаётся на решение полезных задач. Тут главное помнить, что ценность обычно представляют решения полезных задач.

AWW>Мы сейчас говорим, я надеюсь все это понимают, что имеется ввиду что если С++, то уже без указателей. Ну просто так как СИ и С++ есть близкие языки, то можно естественно и на С++ делать так же как обычно принято на СИ. То есть грань этак "проще" "легче" почти не видна.
AWW>Но суть еще раз в том, что — чем ниже язык по уровню, тем выше нужна квалификация что бы делать качественный код. И в вопросе архитектуры кстати тоже.

Может быть у нас просто терминология не совпадает. Квалификация — это произведение ширины опыта и знаний на глубину.
* Когда программист умеет программировать _вообще_, то знание всяких там указателей — это плюс
* Когда программист умеет работать с указателями и всё — это какой-то очень специфический программист

C>>>А в PCC их до сих пор нет.
E>>И що ?
C>То что С отстаёт от С++ !!!!11111!!!
Для того чтобы отставать нужно иметь хотя общий вектор развития. Согласен ?
Для Си и С++ общего вектора нет. С++ идет непонятно куда, скорее всего в УГ.

C>>>Или как?
E>>Возврат структурных типов в Си появился не сразу, довольно долгое время его не было.
C>Ну так он был в C89 или нет?
Не помню. В K&R его точно не было.

C>>>Ну так что это такое? Я не знаю термина "агрегатный объект".
E>>Значит учи матчасть.
C>Гугл со мной согласен. Этот термин упоминается в контексте программирования на 1С.
А также он много раз употребляется в MSDN. Вывод — ты не умееш пользоваться гуглом.

C>>>Я сказал. Ещё вопросы про вменяемое поведение в С будут?
E>>Отлично, а теперь покажи кодом, что это автоматическая переменная.
C>

C>int set_mode(const char *path)
C>{
C>   int mode;
C>   return chmod(path, mode);
C>}
C>

Отлично! Но ты все равно написал ошибочный код — в POSIX второй аргумент chmod имеет тип mode_t.

C>>>Я их не наслушался, а наиспытвался на себе.
E>>Если ты разбирал говнокод — это еще не повод для категоричных обобщений. Все говнокод разбирали.
E>>Ты же делаеш обобщение, аналогичное: был избит неграми — значит всех негров под расстрел. Надеюсь ты осознаеш, что твоё обобщение неверно ?
C>Синглтоны — это Гитлеры.
Это твое ничем не обоснованое мнение.

C>>>Синглтоны — это те же глобальные переменные и точно так же идут в морг.
E>>Тем не менее это один из архитектурных паттернов ООП. Ты противник ООП ?
C>Нет, я противник глобальных переменных. Оборачивание глобальной переменной в объект её менее отстойной не делает.
Ты просто не понял зачем они нужны и как их надо использовать. А без этого понимания проще запретить — думать то не надо.

C>>>Да, в зависимости от фазы Луны.
E>>Но виноват то не язык, а человек написавший код.
C>Или тот, кто проектировал язык.
В любом языке можно написать херню. Нет никакой серебряной пули — языка который отгородил бы автора кода от ошибок.

E>>Ну да, Java я не знаю. Предпочитаю писать на С++ и С. Как истиный валенок, поддавшить на маркетинговые лозунги об безопасном языке, первыми же строчками на Java выстрелил себе в ногу. Вот такой вот "безопасный язык".
C>Да, безопасный. Так как не имеет undefined behavior в этом случае.
Он имеет в этом случае падение с неадекватным сообщением об ошибке, в отличии от автоматически вызванного конструктора в С++.

C>>>А потом плакаться про забытую инициализацию m_.
E>>Ты любитель гемороя ? Зачем тебе лишний указатель ?
C>Ну так сам же любитель геморроя. Любой программист на Java написал бы:
C>

C>public class Test
C>{
C>    private final IdentityHashMap map=new IdentityHashMap();
C>}
C>

C>А не занимался бы созданием лишнего геморроя.
Но язык же позволяет ? и даже никаких ворнингов не дает.

E>>>>2. Сколько копий их будет ?
C>>>Ровно одна, за исключением случаев inline'а, даже если шаблон инстанцируется из нескольких единиц компиляции.
E>>Ровна одна для каждого варианта T.
C>Конечно.
Можеш взять дизассемблер и убетиться лично.

E>>>>3. Есть ли разница в количестве копий с Сишным вариантом ?
C>>>Есть. В С количество инстанцирований зависит от умности линкера.
E>>В С++ тоже вообще-то. Кол-во копий в обоих вариантах будет одинаковым. Внезапно, да ?
C>Нет, неверно. В С++ линкер удалит лишние копии. В С это не гарантируется, хотя часто работает.
Чтож неверно ? В Си линкер надо попросить удалить лишнии копии. В результате получается индентичный с С++ по кол-ву этих самых копий код.
Кроме того весьма сомнительно, что ты начал бы штамповать макросами в каждой единицы трансляции неиспользуемые функции. Даже не знаю, зачем это может понадобится человеку в здравом уме.

Здравствуйте, ramar, Вы писали:

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

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

Здравствуйте, eskimo82, Вы писали:

C>>>>

C>>>>int mode;
C>>>>chmod("/some/file", mode); //Are you feeling lucky today?
C>>>>

E>>>1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
CC>>А с чего ты взял что это глобальная переменная?
E>А с чего бы ей не быть глобальной переменной ?
Ты не можешь написать вызов функции рядом с определением глобальной переменной

Здравствуйте, eskimo82, Вы писали:

IID>>Ну, справедливости ради, GDB та еще какашка
E>Нормальный отладчик, ты просто им пользоваться не умееш.
Ты просто нормальных видимо не видел никогда.

Здравствуйте, eskimo82, Вы писали:

ХГД>>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
E>С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?
Потому что стандарт.

Здравствуйте, -n1l-, Вы писали:

CC>>

CC>>char *foo;
CC>>int bar;

CC>>printf ("%s %i", bar, foo);
CC>>

N>На си char* — общий указатель, там может быть что угодно.

Ок.

char *foo = "Blah";
int bar = 123;
...
printf ("%s %i", bar, foo);

N> И вообще, разве невнимательность программиста — это проблема языка?
Если бы люди были всегда внимательными то и память никогда бы не текла, ни по NULL поинтеру никто бы не ходил, все ошибочные ситуации правильно обрабатывались и проч. и проч.

Здравствуйте, eskimo82, Вы писали:

CC>>классы с конструкторами, деструкторами, операторами и наследованием
E>За исключением операторов всё реализуемо.
Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.

CC>>перегрузка функций
E>По указателю. Получается даже гибче чем в С++.
Overloading нужна по параметрам: http://www.cplusplus.com/doc/tutorial/functions2/

void DoSomething(int value);
void DoSomething(char value);
void DoSomething(double value);
void DoSomething(someclass& value);
void DoSomething(char* value);

CC>>templates (variadics included)
E>Некоторая часть реализуема на основе макросов, в том числе variadic-макросов.
Вы когда нибудь отлаживали макросы? В вложенные макросы? Я — отлаживал, больше не хочу.

CC>>и я уже буду счастлив.
E>Ты счаслив?
Не то чтобы, ибо вынужден на данный момент писать под линух и на С.
Держат только RSUs и прочие плюшки.

E>Что осталось:
E>1. Наследование, полиморфизм из ООП.
E>2. Автоматический контроль за временем жизни переменных, RAII
E>3. Темплейты и обобщеное програмирование.
Этого уже достаточно чтобы жить стало легче, кода стало меньше, читабельность и стабильность улучшилась драматически.

E>А теперь, можно задасться вопросом, насколько оставшийся функционал отличается от Сишного:
E>1. Наследование, полиморфизм из ООП.
E>- Элементы ООП прекрасно реализуются средствами Си.
Вот только не надо мне рассказывать про макросы. Я их давным давно наелся.

E>2. Автоматический контроль за временем жизни переменных, RAII
E>- Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно.
Исключения есть, лично писал kernel код с их использованием.

E>3. Темплейты и обобщенное програмирование.
E>Некоторая часть может быть реализована на основе макросов препроцессора, возможно эта часть даже перекрывает все потребности.
Ещё раз: макросы это разговоры в пользу бедных. Templates в итоге не от хорошей жизни придумали.
Поскольку макросы это просто подстановка без проверки типов то очень просто написать такой код, который скомпилируется без единого чиха и даже будет выполняться, но производить такие тонкие разрушения что придётся доооолго разгребать как же это получилось. Я это видел, дебажил и тыкал носом авторов много раз. Как только надо написать сколь либо сложное то сначала тратится море усилий чтобы написать макросы, потом море усилий чтобы их отладить. В итоге получается хрупкая конструкция, которая рушится как только надо что либо добавить или поменять.

E>Собственно очень хорошо видно, что оставшаяся огрызок от С++ никаких особых ++ по сравнению Си не дает, зато добавляет кучу всякого системного гемороя по поддержке ++ языка.
Весь "системный геморрой" заключается в написании С++ stdlib для кернела с поддержкой SEH/Signal исключений. Очень сложно, да!

E>Вам такой С++ вообще нужен ?
Мало того что нужен, мы его в винде давно уже используем.
Только линуксоиды упираются и цепляются за духовные скрепы С.

Здравствуйте, eskimo82, Вы писали:

CC>>Куда более серьёзная проблема в том, что на С нет никаких способов писать безопасный код.
E>Как показал мой пример, на Java есть способы писать опасный код.
Всё относительно.

Здравствуйте, CreatorCray, Вы писали:

CC>>>классы с конструкторами, деструкторами, операторами и наследованием
E>>За исключением операторов всё реализуемо.
CC>Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.
В GCC есть __cleanup__, что существенно упрощает работу.

#define autofree __attribute((cleanup(free)))__
#define release_return(x) __typeof__(x) res=x; x=0; return res;

const char *do_something()
{
   autofree char *x = (char*) malloc(32);
   if (something_failed())
       return 0;
   release_return(x);
}

Конечно, не так удобно, как в С++, но уже хоть что-то лучше "goto error_exit".

Здравствуйте, мыщъх, Вы писали:

М>вы совершенно правы. я был приятно удивлен, обнаружив, что в штатах можно знать си и совсем не париться по поводу плюсов. ладно бы я один не парился, так ведь и люди вокруг меня программируют на си и плюсы им совсем ни к чему. от рядовых разработчиков до архитекторов.
Верно, но потом смотришь на их код и грустишь. А если ещё и процесс написания наблюдаешь то грустишь вдвойне, ибо столько пара уходит в гудок на борьбу с ограниченностью языка.

Здравствуйте, Cyberax, Вы писали:

C>В GCC есть __cleanup__, что существенно упрощает работу.
C>Конечно, не так удобно, как в С++, но уже хоть что-то лучше "goto error_exit".

Лучше, но это ж всё равно костыль.
Ну и я так понимаю для полей структуры да со вложенностью оно работать не будет.