Qt и с++ для всего системного

Спасибо, будем пробовать.

ого, они добавили это в Qt5 как модуль, супер, я серьезно, это давно пора было сделать

Защита от хотлинкинга. Нажать энтер в адресной строке.

Еще пока не добавили, но надеюсь добавят. Но до этого момента еще нужно многое допилить...

Почему ядро Linux не перепишут под плюсы

Потому что плюсы намертво прибиты к библиотекам в user-space, потому что некоторые вещи на плюсах дают больший overhead и наконец потому что даже если это бы имело смысл, переписывать сейчас такую кодовую базу никто бы не стал.

Вот и не знаю, на что грешить: плюсы с их классами, кривость КуТэ в целом или на саму либу

Наиболее вероятно - руки, наименее вероятно - баг в qserialport. Я использовал и его, и свой велосипед и никаких просадок производительности никогда не замечал.

http://www.kernel.org/pub/linux/kernel/v1.0/CHANGES

CHANGES since 0.99 patchlevel 12 and earlier:

 - compiled with plain C by default instead of C++

Таки писали на плюсах ядро.

Профилировать не пробовали, прежде чем кидаться какашками?

Прочитать тред не пробовал, прежде чем давать советы?

А ты думал, Линус это все говорит безосновательно только лишь бы потроллить, да обосрать плюсофагов?

в ядре фичи из С++ почти не использовались, только дополнительные проверки, которые делает компилятор С++; более того - Торвальдс даже все возможности С не использует, причем осознанно избегая их, глупо было вообще ему предлагать что-либо другое

И, надо отметить, делает он это таки не зря.

ес-но, но это не значит, что за пределами ядра жизни нет, тут он говорит, что Java кусок говна:

http://www.youtube.com/watch?v=Aa55RKWZxxI

в других своих письмах он пишет, что emacs с лиспом - лютый п%ц и т.д., ну нравится человеку плевать на всех своей колокольни - ну и пусть, его дело, не он же, например, Android разрабатывает, или llvm или тот же emacs

А ты думал, Линус это все говорит безосновательно только лишь бы потроллить, да обосрать плюсофагов?

Линус знатный тролль, все это знают

Что мешает на плюсах не использовать стандартные библиотеки? В плюсах есть шаблоны и строгий контроль типов, код в итоге получается более типобезопасный и чем на чистом си. На плюсах и под микроконтроллеры пишут. Принципиальной разницы нет, когда знаешь какой асм код сгенерит твой с++ компилятор. По сабжу : куте не самая быстрая либа) но проблема явно с кодом аффтора. На работе есть девайс у него 18 портов через плату расширения, rs485 и километровые кабели работает на amd geode lx. Успевает и опрашивать, и отрисовывать параметры, и сохранять на флешку все системные события.

Кстати, а какие возможности С не использует Торвальдс? Просто ИМХО Си не особо богат на разнообразие языка, что там можно не использовать?

к примеру он призывает как можно реже использовать typedef, обосновывая это тем, что пользы от этого нет, зато не видно сходу, что это за тип данных, к примеру важно видеть структуры, чтоб не класть их лишний раз на стек

Зато получил ответ на вопрос, который иногда меня мучал (и будил по ночам): «Почему ядро Linux не перепишут под плюсы».

Типун тебе на язык.

Что мешает на плюсах не использовать стандартные библиотеки?

Особо ничего не мешает - перегрузил глобальные new/delete и вперед. Просто C++ без STL теряет очень много.

На плюсах и под микроконтроллеры пишут.

Писать-то пишут, только из-за невозможности использовать кучу (мало памяти), шаблоны (компилятор часто не умеет) и исключения (не умеет сам МК), использование C++ на МК обычно превращается в C с классами и строгой типизацией + кучей геморроя с зоопарком макросов и расширений языка от производителя МК. Это я говорю об IAR и простейших МК, потому что на серьезных МК обычно работает полноценная ОС и разницы действительно нет вообще.

Вот чёрт, я наоборот в коде часто typedef использую — паскалевская привычка.

Вот чёрт, я наоборот в коде часто typedef использую — паскалевская привычка.

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

А typedef примитивных типов в С++ это плохая привычка?
Например, в игровом движке заменить unsigned int на SceneID для контроля типов.

с открытой моделью разработки нет ничего невозможного.

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

Потому что плюсы намертво прибиты к библиотекам в user-space,

Перед тем как писать подобный бред, ты бы сначала поинтересовался тем, что такое «hosted implementation» и «freestanding implementation» в С++.

потому что некоторые вещи на плюсах дают больший overhead

Список в студию!

Список в студию!

Не знаю, то ли Вы имеети ввиду, но выскажу свое мнение. Язык предполагает стиль. С++ предполагает ООП. ООП предполагает (иногда) кучу «мусора» (или оверхеда, аля геттеры-сеттеры). Вот такой примитивнейший пример.

или оверхеда, аля геттеры-сеттеры

они не несут никакого оверхеда

Потому что плюсы намертво прибиты к библиотекам в user-space,

так к сведению - ядро линукса в свое время собирали компилятором С++

ООП предполагает (иногда) кучу «мусора» (или оверхеда, аля геттеры-сеттеры).

Которые в большинстве случаев являются inline-функциями. Следующий пример?

Лучше класс создать, вдруг ты потом захочешь его битовым полем сделать, например

С++ предполагает ООП

C++ - мультипарадигменный язык, но допустим.

ООП предполагает (иногда) кучу «мусора» (или оверхеда, аля геттеры-сеттеры).

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

Можно пример инкапсуляции в C? (если это не структуры и множества).

Например, структура, с указателем на которую работает группа функций, при этом объявления этой структуры нет в публичных заголовках.

Список в студию!

Исключения, вызовы виртуальных функций, шаблоны (code size), implicits, RTTI, dynamic_cast, mangling (просто как неприятная особенность), что-то ещё? Ну и сами библиотеки могут вносить оверхед (те же iostreams) - либо сами по себе, либо потому что они всё это используют.

к примеру он призывает как можно реже использовать typedef

the_t world_t would_t be_t a_t better_t place_t if_t some_t people_t did_t not_t feel_t the_t need_t to_t typedef_t everything_t

by Theo de Raadt :)

Исключения,

Сишный аналог в студию! Иначе просто не используем исключения и все ок. Проектов, где отказались от исключений - туча.

вызовы виртуальных функций,

Никакой разницы по сравнению с вызовом функции по указателю в С.

шаблоны (code size),

А по скорости они как правило быстрее, потому что находятся в том же модуле и отлично инлайнятся. Мы же про скорость?

implicits,

ЩИТО?

RTTI, dynamic_cast,

Люди отлично обходятся и без него. Никто не заставляет. И да - С-шный аналог в студию.

mangling (просто как неприятная особенность), что-то ещё?

Mangling и скорость? Каким образом?

Ну и сами библиотеки могут вносить оверхед (те же iostreams) - либо сами по себе, либо потому что они всё это используют.

Вот прямо у тебя отбирают libc и заставляют юзать только libstdc++.

Сишный аналог в студию!

Речь же была про список фич С++ имеющих определённое влияние на рантайм? В принципе, в разных embedded coding style подобные фичи перечисляются, можно использовать С++ как «лучший Си» избегая этих фич и всё будет ок. Но при этом придётся отказаться и от фич С99 тоже (инициализация структур, flexible/VL arrays, заголовки, etc.).

Иначе просто не используем исключения и все ок. Проектов, где отказались от исключений - туча.

Ну да, как в гугло-стилях, например. Только это получается язык в котором приходится отказываться от своей же стандартной библиотеки (если мы говорим про «всё системное»).

Никакой разницы по сравнению с вызовом функции по указателю в С.

Смотря с каким компилятором, наверное. Такой код

struct A { void (*m)(void); };
struct B { struct A a; };
struct C { struct A a; };

void B_m(void) { puts("B"); }
void C_m(void) { puts("C"); }

int main()
{
    struct B b = { .a = { .m = B_m } };
    b.a.m();
}

легко сводится к call B_m. А такой:

struct A {
    virtual void m() { puts("A"); }
    virtual ~A() {}
};
 
struct B : public A { void m() { puts("B"); } };
struct C : public A { void m() { puts("C"); } };
 
int main()
{
    B *b = new B;
    b->m();
}

к непонятно чему.

ЩИТО?

Конструкторы от одного аргумента не помеченные как explicit (абстрактные в вакууме, то есть без указания компилятора).

Mangling и скорость? Каким образом?

Никаким, говорю же, просто неприятная особенность. Но системный ЯП это, в том числе, вменяемый ABI. Если только как прикладной - ок.

Только это получается язык в котором приходится отказываться от своей же стандартной библиотеки (если мы говорим про «всё системное»).

Речь о неиспользовании исключений в проекте, а не во внешних либах (включая libstdc++). Т.е. не использовать throw. При этом использования STL, которые могут выкинуть исключения, аккуратно оборачиваются в try...catch, ну и на высоком уровне ловится bad_alloc.

Смотря с каким компилятором, наверное. ....

Проверю дома ради интереса.

Конструкторы от одного аргумента не помеченные как explicit (абстрактные в вакууме, то есть без указания компилятора).

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

Но системный ЯП это, в том числе, вменяемый ABI.

Соглашусь.

Проверю дома ради интереса.

Там new надо на объект на стеке поменять, тогда действительно получается идентичный код в области main (gcc ещё this в регистр передаёт, clang этого не делает). Как-то не могу придумать пример демонстрирующий оверхед virtual - с -O2/3 всё хорошо получается.

А я тебе подскажу: множественное наследование даст два разыменования указателей вместо одного. Но это нечасто происходит - не проблема критичные участки кода писать без него.