Здравствуйте, igna, Вы писали:
I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?
Интересно вот что.
Есть ли такие, кто, владея на хорошем практическом уровне обоими языками, отказался от C++ в
пользу C в силу каких-то адекватных причин, о которых может внятно рассказать ?
Послушать таких людей было бы крайне интересно.
А то ведь принято ругать С++ за усложнизм, за всякие там SFINAE/CRTP/множественное виртуальное
наследование внучатого племянника шаблонного параметра-шаблона, а как послушаешь — оказывается,
что эти люди вообще на плюсах особо не писали и знают о нем только понаслышке.
I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?
Я пишу на C преимущественно код для kernel-mode. Ну еще иногда использую его для переносимых
программных интерфейсов, когда есть вероятность, что их будут вызывать из всяких там Delphi/.NET, а
использовать COM слишком дорого. Но вообще, программировать на C считаю неудобным.
В основном из-за отсутствия RAII. Тот, кто не знает, что такое RAII — не знает C++ и объяснять
ему плюсы бесполезно. В отсутствие RAII приходится постоянно следить за тем, кто зовет add_ref, а
кто release, кто инкрементировал счетчик на входе, а кто декрементировал на выходе, кто
занял дескриптор, а кто освободил, и так далее. Добавляешь новую ветку кода — будь добр, проследи,
чтобы и в ней была правильная очистка ресурсов. Удаляешь ветку — тоже проследи. Проследи, чтобы
не было двойного освобождения ресурсов. И так далее, до бесконечности. В C это очень утомляет, а
существующие решения на всяких там лонгджампах выглядят костыльно (и, по сути, костылями и являются).
Во время переработки кода очень легко внести ошибку. Правильно приготовленный C++ избавляет от
подобных проблем — всем заведует RAII и все счастливы, а накладных расходов нет. И код чище.
Я C++ бы выучил только за то,
что в нем присутствует RAII.
Здравствуйте, igna, Вы писали:
I>Любое точно нельзя. Вопрос в том, как выбрать значение, которое гарантировано не будет использовано в будущим стандарте.
Поэтому я и говорю, что технически можно, но делать так не надо.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Покажи чистый. Буду знать как надо писать правильно.
YO_ARRAY *Oj_Get_Lines(void *file) {
YO_ARRAY *arr = Array_Pchars();
char *S;
while (( S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
return arr;
}
1. Не понятно, что с ошибками. Обычно в C функции возвращают код ошибки, здесь мне не понятно, что будет если например вместо file передам 0.
2. Создали arr типа YO_ARRAY, где потом arr используется? Не понятно.
3. Что такое Pchars? Я еще пойму просто char или там utf32, но это
3. Oj_Read_Line, как я понял вернет нулевой указатель когда будет достигнут конец файла. Как определить, что это не конец, а ошибка файла?
4. Куда помещает строку Array_Push? Из кода не понятно.
5. Для чего нужно __Retain?
6. Почему местами YO, а местами Oj? Разные библиотеки?
7. Почему локальная переменная arr, но локальная переменная S?
Здравствуйте, igna, Вы писали:
I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?
Ну я, например.
I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?
Здравствуйте, igna, Вы писали:
I>Во! То есть errno не для переносимых программ.
Что имеется ввиду под "переносимыми программами"? В большинстве случаев достаточно errno со стандартными POSIX'овскими значениями ошибок. Если недостаточно, можно объявить аналогичную глобальную thread-safe переменную, или дополнительное поле в структуре контекста, и использовать по своему усмотрению.
Также можно возвращать код ошибки непосредственно из функции, если очень уж хочется (как сделано в pthreads).
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, MasterZiv, Вы писали:
MZ>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на MZ>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.
Непонятно как-то. Если C++ так хорош, то чем же он для ведра линуха не подходит? А если он не так уж хорош, то может есть и какие-то другие проекты, которым он не подходит?
Здравствуйте, Pzz, Вы писали:
MZ>>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на MZ>>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть. Pzz>Непонятно как-то. Если C++ так хорош, то чем же он для ведра линуха не подходит? А если он не так уж хорош, то может есть и какие-то другие проекты, которым он не подходит?
если использовать C++ для ядра Linux — то
1. желательно многое переделать -> это уже будет не Linux
2. часть сообщества самовыпилится из-за не знания или отрицания C++, включая Линуса, новые члены заполнят вакуум не сразу.
3. такие потрясения нафиг никому не нужны
Здравствуйте, igna, Вы писали:
P>>это просто пруфлинк — ты можешь не проверять I>Проверять и не собирался, просто народ собрался интересный, хотел узнать, что они там еще говорят. Но нет, так нет.
Здравствуйте, Piko, Вы писали:
P>если использовать C++ для ядра Linux — то P>1. желательно многое переделать -> это уже будет не Linux P>2. часть сообщества самовыпилится из-за не знания или отрицания C++, включая Линуса, новые члены заполнят вакуум не сразу. P>3. такие потрясения нафиг никому не нужны
Ээээ. Ну, если вы считаете, что ядро имеет смысл продолжать развивать на Си просто потому, что так исторически сложилось, непонятно, почему этот подход применяется только для ядра. Есть еще большие и ценные куски софтвария, исторически написанные на Си — те же иксы, гномий дектоп и т.п.
P>Что же касается использования C++ для ядер в общем, то процитирую Страуструпа, так как полностью согласен с ним: P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native P>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
