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

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

!!! Так это делает "это" уже не С++.
То есть если хорошо знать С++ то ясно понятно, что чтобы именно его особые (отличные от СИ) возможности использовать то нельзя уйти от всего внутри.
То есть это уже не C++, а скорее СИ с классами!

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

CC>Удачи!

Себе пожелай. Мне на тщательное изучение стандарта не две недели, а четырёх дней хватило, лет пять
назад. Это проще раз в сто, чем, например, топология бесконечномерных простанств. Имеенно
тогда увидел его уродливость С++. С++-кривое, уродливое безобразие. Лучшие языки, по мне-это С и Lisp, perl.
И когда это, разные поциенты, перестануть думать, что те, кому не нравится C++, это обязательно те которые не смогли его
осилить? По себе судят?

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

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

Нет не достаточно. Надо знать C++.
Только знание СИ, это мало для создания коммерческого софта.

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


N>>К тому же всякие драйвера для линуксов не пишутся на С++.
CC>Причиной этому является ослиное упрямство ниасилившего Торвальдса. А мы в итоге сейчас в линуксячем кернеле жрём кактусы. Вбив бы!
CC>Под винду драйвера на С++ пишутся легко и приятно. С содроганием вспоминаю времена когда их по дурости пытались писать на С.

Похоже, Вы драйверы под линукс не то что не писали, но и уже написанные не видели.
В противном случее знали бы, что там истинный ООП, с структурированным разделением
сущностей на объекты, и очень изящно линкующиеся в ядро.

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

S>И когда это, разные поциенты, перестануть думать, что те, кому не нравится C++, это обязательно те которые не смогли его
S>осилить? По себе судят?

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

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

E>Это будет очень маленькое подмножество — "Си с классами и темплайтами" без какой-либо стандартной библиотеки вообще. Все остальное из С++ выпиливается всед за запретом RTTI, которое тянеят за собой исключения и все остальное.

Они это не поймут. ))
Тут я как-то столкнулся — типа "пришлите пример кода драйвера". Я высылаю — .... бабаба.... Ответ: Ну это же все на СИ, а нам хотелось увидеть как вы на С++ пишете.
Вот и это был ответ тех.спеца типа. )) Ну тимлидера из ядренной разработки. Я плакаль. ))

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


ХГД>>Да нормальный там код, даже обработка ошибок более-менее толково реализована. И даже утечек нет, если правильно хвосты зачищать. На плюсах, правда, все это раза в 3-4 компактнее получилось бы.

A>угу, компактнее и надежнее (те же баги типа вылезания за границы буфера, как у HeartBleed) ловились бы дебаг-итераторами

Скорее всего.

A>и можно было бы писать юнит тесты.

Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали

ХГД>>>Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?
E>>На затравку ты можеш начать медитацию с именоваными инициализаторами без затрат на конструирование обьектов в рантайме.

A>ок, 1 элемент списка есть, а еще?
A>ты не стесняйся, пиши все сразу
А зачем торопиться ? Составные литералы еще никто здесь не упомянал ?

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


CC>Профнепригодность detected.
CC>Без шуток. Это no hire сразу.

А мне мнение и видение сотрудников Pupkin Inc. из РФ о профпригодности в кодотворстве параллельны.
Там, где приходится вращаться, о профпригодности судят по другим признакам, в которые желание оформлять
код как цветочную клумбу, или букет для подарка женщинам, не входят.

CC>Да, в опенсорсе тот ещё говнокод.

Вот когда сотрудники Pupkin Inc из Мск выкатят что-то, хоть отдалённо приближающееся,
по степени распространённости и востребованности в мире, к опенсорсным проектам, тогда
и смогут судить о опенсорсных проектах.

ХГД>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
Те кто хочет, пишут юнит тесты и на Си с использованием соответсвующих фреймворков или без. Фреймворки для этого есть, cmockery например.

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

ХГД>>>>Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?
E>>>На затравку ты можеш начать медитацию с именоваными инициализаторами без затрат на конструирование обьектов в рантайме.

Ну да, было бы удобно. Но мелочь.

A>>ок, 1 элемент списка есть, а еще?
A>>ты не стесняйся, пиши все сразу
E>А зачем торопиться ? Составные литералы еще никто здесь не упомянал ?

А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать

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

E>Но в РФ за это знание платить будут мало.

Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.

ХГД>>>>>Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?
E>>>>На затравку ты можеш начать медитацию с именоваными инициализаторами без затрат на конструирование обьектов в рантайме.
ХГД>Ну да, было бы удобно. Но мелочь.
Так это не совсем мелочь.

A>>>ок, 1 элемент списка есть, а еще?
A>>>ты не стесняйся, пиши все сразу
E>>А зачем торопиться ? Составные литералы еще никто здесь не упомянал ?
ХГД>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.

task.state = (state_t) { .priority = 10, .name="task1" };

E>>Но в РФ за это знание платить будут мало.
PML>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.
Все уехали.

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

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

E>>Но в РФ за это знание платить будут мало.

PML>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.

Город, зарплата, небудте голословными.

Здравствуйте, Хон Гиль Дон, Вы писали:

A>>и можно было бы писать юнит тесты.
ХГД>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
я как-то не очень себе представляю юнит-тесты на Си. слишком мало возможностей чтобы подцепить фейки/моки, слишком много бойлерплейта.

по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

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

ХГД>>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
E>Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.
E>

E>task.state = (state_t) { .priority = 10, .name="task1" };
E>

Вот именно — "в отсутствии вызовов конструкторов". С чего бы им в плюсах отсутствовать? В C++11 даже POD могут иметь кое-какие конструкторы.

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


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

A>по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

Хотите пример? Есть такой DTrace. Посмотрите как он реализован в solaris, не где нибудь ещё, вроде freebsd,
а именно в солярисе. И увидите не что иное как реализацию организации модульного тестирования всего ядра,
на всём его протяжении. На каждом, хоть что-то значащем, его участке.

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


A>>>и можно было бы писать юнит тесты.
ХГД>>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
A>я как-то не очень себе представляю юнит-тесты на Си. слишком мало возможностей чтобы подцепить фейки/моки, слишком много бойлерплейта.

Ну фреймворков-то полно, как-то наверное цепляются. И вообще, в C слишком много бойлерплейта не бывает

A>по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

В плюсовом опенсорсе тоже как бы не особо распространенное явление

ХГД>>>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
E>>Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.
E>>

E>>task.state = (state_t) { .priority = 10, .name="task1" };
E>>

ХГД>Вот именно — "в отсутствии вызовов конструкторов". С чего бы им в плюсах отсутствовать? В C++11 даже POD могут иметь кое-какие конструкторы.
И это очень плохо. Не всегда есть желание и даже возможность вызывать конструктор, например до старта main в статических данных

Поясню. Если Вы напишете на С++ модуль к ядру Линукса и в этом модуле будет нечто статическое (необязательно обьект), для которого компилятор сгенерит инициализирующий конструктор, то Вас ждет много удивительных открытий и незабываемых часов с отладчиком и дизассемблером.