Здравствуйте, a.v.v, Вы писали:
AVV>есть две краеугольных библиотеки в мире плюсов stl и boost
Qt и boost. Это stl часть стандарта.
AVV>закрывает наверно 90% стандартных задач
С Qt да и даже, наверное, больше.
Здравствуйте, Skorodum, Вы писали:
S>Хотелось бы пример "Qt-шного стиля" без Qt Мне на ум приходит только преобладание динамического полиморфизма над статическим (наследование vs шаблоны).
Что-то типа такого. Делаются интерфейсы в виде абстрактных классов. Затем где-то спрятанные от глаз наследники. Создаются наследники через фабрики. Соответственно, все через динамические объекты. И хорошо, если владение делается через unique_ptr/shared_ptr (или их самодельные аналоги). Хуже когда свою систему владения выстраивают в стиле Qt.
Здравствуйте, night beast, Вы писали:
NB>думаю оно.
Оно.
NB>но не понимаю, чем это плохо.
Иногда доходит до маразма, когда вместо RectangularArea, делают интерфейс AbstractArea, а от него наследника RectangularArea. А используется это все всего лишь в одном сценарии, где никакого наследования и не нужно вовсе.
Речь шла не о том, что ООП плох. А о том, что плохо, когда ООП доводят до апофеоза.
NB>по крайней мере этот подход дает реальную раздельную компиляцию и не приходится выжидать перекомпиляции всего проекта если пришлось где-то в реализации что-то поправить.
Кстати говоря, научиться сочетать ООП с шаблонами тоже не просто так, чтобы соблюдался разумный баланс, тоже не просто. Требуется опыт и набитые шишки.
Здравствуйте, Skorodum, Вы писали:
S>Производительность. Если проивзодительность КРИТИЧНА и обращений к VTABLE может быть тысячи в секунду, то, конечно же, надо предпочитать статический полиморфизм, ведь это zero overhead в runtime.
Не припомню, когда мне доводилось сталкиваться с ситуациями, когда производительность была настолько критична, чтобы накладные расходы на VTABLE приходилось учитывать.
Тут скорее речь о ситуациях, когда за одним общим фасадом сложно спрятать разные вещи. Вот, скажем, у нас в RESTinio есть понятие response-builder-а. И эти самые builder-ы есть разные, с разным публичным API.
ИМХО, нормально общий ООП-шный фасад для них не сделать. Ибо в нем будут виртуальные методы, которые имеют смысл только для определенного типа builder-а, но не для других. И ничто не запретит пользователю вызывать их. Получая по руке в run-time, а не в compile-time, как в случае с шаблонами.
И это мы еще в рассмотрение вопрос DSL-ей не берем.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, AmSpb, Вы писали:
AS>>Если не embedded, то да boost S>В embedded мире boost уже давно много где используется.
Значит, у нас с вами рязное понимание embedded.
Для меня это микроконтроллеры, но не мощные, одно ядро и памяти SRAM до 1Мбайта
Вообщем на которых можно делать hard real time приложения.
Raspberry Pi тоже можно отнести к embedded, но это уже полноценный многоядерный компьютер,
на котором можно спокойно выполнять Linux, и использовать boost. Но на raspberry pi вы не сделаете hard real time
boost для однокристалок не годится, там и С++ как правило кастрированный.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>Проблема с C++ не в изучении синтаксиса, а в том, чтобы выработать рефлексы писать так, чтобы конечности не отстреливались. S>Еще системы сборки и управления зависимостями. В любом более-менее сложном и развивающемся проекте это не тривиально (для новичка) и никак не стандартизированно. Особенно если поддерживаемых платформ, процессоров и компиляторов несколько.
Conan сейчас лидер по управлению зависимостями для С++, возможно есть и другие инструменты для контроля зависимостями.
Здравствуйте, Skorodum, Вы писали:
S>Пришел тут к нам новый application engineer, вроде как с навыками в разработке, говорит в Нокии работала. Спрашиваю "Какой компилятор использовали, подо что собирали"? Отвечает: "Eclipse"
Здравствуйте, AmSpb, Вы писали:
AS>boost для однокристалок не годится, там и С++ как правило кастрированный. Но на raspberry pi вы не сделаете hard real time
Hard real time -- это ограничение io отклика, верно я понял? Если да, то почему rpi пролетает? Это же вообще от софта(ОС) зависит.
Здравствуйте, Sharov, Вы писали:
AS>>boost для однокристалок не годится, там и С++ как правило кастрированный. Но на raspberry pi вы не сделаете hard real time
S>Hard real time -- это ограничение io отклика, верно я понял? Если да, то почему rpi пролетает? Это же вообще от софта(ОС) зависит.
Нет, hard real time — упрощенно, это детерминированность времени исполнения задач (tasks).
Большинство многоядерных процов пролетает, т.к. есть куча вещей, вносящих недетерминированное время выполнения,
cache misses, speculative execution, inter-core communication e.t.c.
Есть гибридные чипы, где есть многоядерник и однокристалка для hard-real-time.
Hard real time в многоядерных процессорах это тема исследований, даже какие-то решения есть.
Здравствуйте, Nuzhny, Вы писали:
AS>>Conan сейчас лидер по управлению зависимостями для С++ N>Если смотреть на число зависимостей, то однозначный лидер — это vcpkg
Здравствуйте, AmSpb, Вы писали:
AS>Нет, hard real time — упрощенно, это детерминированность времени исполнения задач (tasks). AS>Большинство многоядерных процов пролетает, т.к. есть куча вещей, вносящих недетерминированное время выполнения, AS>cache misses, speculative execution, inter-core communication e.t.c.
И как это все влияет, если требования по времени отклика, скажем, 25ms?
Ну и да, cache misses, out-of-order execution & branch (mis)prediction -- это объективная реальность даже для одноядерных CPU уже лет 20-25 как.
Здравствуйте, so5team, Вы писали:
S>И как это все влияет, если требования по времени отклика, скажем, 25ms?
В RTOS, как правило работают несколько задач, возможно на такую длинную задачу это никак не повлияет, но вот на какую-то критическую может повлиять довольно сильно.
S>Ну и да, cache misses, out-of-order execution & branch (mis)prediction -- это объективная реальность даже для одноядерных CPU уже лет 20-25 как.
Да, но с одноядерником проще рассчеты Worst-case-execution-time делать, вопрос цены чипа также важен.
А вообще читайте
With the current technology we may not predict and provide any guarantee on real-time properties of multicore software, which restricts seriously the use of multicores for embedded applications. https://link.springer.com/chapter/10.1007/978-3-642-16901-4_3
Здравствуйте, AmSpb, Вы писали:
S>>И как это все влияет, если требования по времени отклика, скажем, 25ms? AS>В RTOS, как правило работают несколько задач, возможно на такую длинную задачу это никак не повлияет, но вот на какую-то критическую может повлиять довольно сильно.
Вот давайте поподробнее, что и как.
Ну и позволю себе напомнить, что hard real-time -- это не про длину задачи, это про тяжесть последствий. Так что длительность к hard/soft имеет косвенное отношение.
S>>Ну и да, cache misses, out-of-order execution & branch (mis)prediction -- это объективная реальность даже для одноядерных CPU уже лет 20-25 как.
AS>Да, но с одноядерником проще рассчеты Worst-case-execution-time делать, вопрос цены чипа также важен.
Внести в разговор про влияние особенностей современных процессоров на оценку задержек вопрос цены чипа -- это мощно.
Не так мощно, конечно, как утверждать, что Conan -- это лидер не зная про vcpkg, но все-таки.
AS>А вообще читайте
Правильно я понимаю, что в бесплатном свободном доступе этого нет?
Здравствуйте, so5team, Вы писали:
S>>>И как это все влияет, если требования по времени отклика, скажем, 25ms? AS>>В RTOS, как правило работают несколько задач, возможно на такую длинную задачу это никак не повлияет, но вот на какую-то критическую может повлиять довольно сильно.
S>Ну и позволю себе напомнить, что hard real-time -- это не про длину задачи, это про тяжесть последствий. Так что длительность к hard/soft имеет косвенное отношение.
hard real time — для меня это строгая гарантированность времени выполнения задач, нестрогая гарантированность — это soft realtime
Тяжесть последствий — это уже про то, где будет применяться ОСРВ. Одну и туже ОСРВ жесткого времени вы можете применить на атомной станции и в мобильном телефоне, хоть ОСРВ одна и таже, тяжесть ошибки будет разной.
S>Внести в разговор про влияние особенностей современных процессоров на оценку задержек вопрос цены чипа -- это мощно.
Когда вы производите продукт в кол-ве миллионов, десятки миллионов, то вопрос цены чипа для вас будет довольно существенным.
S>Не так мощно, конечно, как утверждать, что Conan -- это лидер не зная про vcpkg, но все-таки.
AS>>А вообще читайте S>Правильно я понимаю, что в бесплатном свободном доступе этого нет?
Интересоваться ОСРВ, а самому не знать, что все doi документы можно скачать со sci-hub, это мощно.
Здравствуйте, AmSpb, Вы писали:
S>>>>И как это все влияет, если требования по времени отклика, скажем, 25ms? AS>>>В RTOS, как правило работают несколько задач, возможно на такую длинную задачу это никак не повлияет, но вот на какую-то критическую может повлиять довольно сильно.
S>>Ну и позволю себе напомнить, что hard real-time -- это не про длину задачи, это про тяжесть последствий. Так что длительность к hard/soft имеет косвенное отношение. AS>hard real time — для меня это строгая гарантированность времени выполнения задач, нестрогая гарантированность — это soft realtime
Удивительно. Вы же сами делите на "строгую" и "не строгую". Но при этом тяжесть последствий вы рассматриваете как отдельное явление.
Если гарантированность "строгая" и она не выполняется, то по вашему, последствия этого каковы? Типа "а, плевать, работаем дальше?" И если они не являются тяжелыми, то о какой строгости тогда речь?
И это мы ушли далеко от первоначального вопроса вам. А именно, CPU уже несколько десятков лет имеют массу особенностей, которые влияют на предсказание времени исполнения куска кода. И, тем не менее, real-time задачи на этих CPU решаются. Как и есть RTOS с поддержкой многоядерных процессоров.
Так что попробуйте рассказать, как именно cache miss, speculative execution и пр. скажутся на hard real-time задачах, где время реакции определяется десятками миллисекунд. Сможете?
S>>Внести в разговор про влияние особенностей современных процессоров на оценку задержек вопрос цены чипа -- это мощно. AS>Когда вы производите продукт в кол-ве миллионов, десятки миллионов, то вопрос цены чипа для вас будет довольно существенным.
Это бесспорно. Вот только этот фактор никак не влияет на то, скажется ли cache miss на нарушение требований по времени отклика.
AS>Интересоваться ОСРВ, а самому не знать, что все doi документы можно скачать со sci-hub, это мощно.
Здравствуйте, so5team, Вы писали:
S>И это мы ушли далеко от первоначального вопроса вам. А именно, CPU уже несколько десятков лет имеют массу особенностей, которые влияют на предсказание времени исполнения куска кода. И, тем не менее, real-time задачи на этих CPU решаются. Как и есть RTOS с поддержкой многоядерных процессоров.
Можно примеры hard-real-time RTOS, которые крутятся на обычных, а не специализированных, многоядерных процессорах ?
S>Так что попробуйте рассказать, как именно cache miss, speculative execution и пр. скажутся на hard real-time задачах, где время реакции определяется десятками миллисекунд. Сможете?
Смогу, если вы мне примеры hard real time RTOS для обычных многоядерных процессоров приведете ( а не специализированные под hard real time многоядерные процессоры)
AS>>Интересоваться ОСРВ, а самому не знать, что все doi документы можно скачать со sci-hub, это мощно. S>А кто вам сказал, что я интересуюсь?
Если не интересуетесь, то к чему задаете вопросы, касательно ОСРВ ?
Неудобные для вас вопросы про "строгость" и тяжесть последствий вы решили проигнорировать?
S>>И это мы ушли далеко от первоначального вопроса вам. А именно, CPU уже несколько десятков лет имеют массу особенностей, которые влияют на предсказание времени исполнения куска кода. И, тем не менее, real-time задачи на этих CPU решаются. Как и есть RTOS с поддержкой многоядерных процессоров.
AS>Можно примеры hard-real-time RTOS, которые крутятся на обычных, а не специализированных, многоядерных процессорах ?
vxWorks?
AS>>>Интересоваться ОСРВ, а самому не знать, что все doi документы можно скачать со sci-hub, это мощно. S>>А кто вам сказал, что я интересуюсь?
AS>Если не интересуетесь, то к чему задаете вопросы, касательно ОСРВ ?
А что, нельзя? Может право задавать вопросы относительно реального времени вы присвоили только лишь себе?
С точки зрения банальной эрудиции вы говорите достаточно странные вещи.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, AmSpb.
S>Неудобные для вас вопросы про "строгость" и тяжесть последствий вы решили проигнорировать?
Пока софт не привязан к контролю физических процессов, тяжесть последствий есть абстракция.
Если вы ОСРВ пустите в Software-In-The-Loop, вместо атомной станции, какова тяжесть последствий, если дедлайн будет нарушен, и замигает красная лампочка ?
S>>>И это мы ушли далеко от первоначального вопроса вам. А именно, CPU уже несколько десятков лет имеют массу особенностей, которые влияют на предсказание времени исполнения куска кода. И, тем не менее, real-time задачи на этих CPU решаются. Как и есть RTOS с поддержкой многоядерных процессоров.
AS>>Можно примеры hard-real-time RTOS, которые крутятся на обычных, а не специализированных, многоядерных процессорах ?
S>vxWorks?
Если в многоядерных процессорах можно отключить все кэши, на крайняк оставить L1, отключить межядерную связь,
отключить механизм когерентности кэшей, каждому ядру по своему отдельному участку памяти, то допускаю, что при таких ограничениях можно добиться
детерминированности времени выполнения, т.е. hard-real-time
AS>>>>Интересоваться ОСРВ, а самому не знать, что все doi документы можно скачать со sci-hub, это мощно. S>>>А кто вам сказал, что я интересуюсь?
AS>>Если не интересуетесь, то к чему задаете вопросы, касательно ОСРВ ?
S>А что, нельзя? Может право задавать вопросы относительно реального времени вы присвоили только лишь себе?
S>С точки зрения банальной эрудиции вы говорите достаточно странные вещи.
Здравствуйте, AmSpb, Вы писали:
S>>Неудобные для вас вопросы про "строгость" и тяжесть последствий вы решили проигнорировать?
AS>Пока софт не привязан к контролю физических процессов, тяжесть последствий есть абстракция.
Hard real-time -- это когда превышение времени реакции означает, что всё, приплыли. Дальше работать смысла нет, полимеры уже того. И не суть важно, занимаетесь ли вы управлением оборудования, торговлей на бирже, трансляцией видео или еще чем-то.
Мне на ум приходит только преобладание динамического полиморфизма над статическим (наследование vs шаблоны).
