Хочу C++ без C++

Ну так не используй указатели с памятью, за которую отвечает GC.

Вот примерно в этот момент C++ можно выкинуть.

А если за ту же АТМегу речь, с четко обозначенными возможными задачами - то проща сразу нарезать\нафрагментировать пул памяти и ничего вообще никуда никогда не перемещать - просто писать куда надо и знать когда оно уже не надо.

Я чуваку предлагал забить на использование динамической памяти в принципе, но он зачем-то тут нафантазировал убогого фекалоида из мира GC :)

Надо начать с того, что shared_ptr используется очень редко.

Т.е. без указателей на C++ писать нельзя по-твоему?

Т.е. без указателей на C++ писать нельзя по-твоему?

Без указателей на C++ писать не имеет смысла, поскольку существуют лучшие инструменты.

Эээ... В C++11 auto_ptr уже deprecated, unique_ptr обладает эксклюзивным правом ссылаться на область памяти, а C-styled за пределами C это просто смешно.

Для чего ты используешь указатели на C++?

А для чего большой непрерывный кусок памяти? Можно ли использовать https://en.wikipedia.org/wiki/Unrolled_linked_list и написать оберток всяких под это дело, чтобы складывалось впечатление, будто это непрерывный кусок памяти?

Если без непрерывного куска никак, можно «логически» разбить непрерывный большой кусок памяти, ну скажем 64 килобайт, на кусочки скажем в килобайт. Если мы хотим писать в такие-то кусочки из этого 64килобайтного куска, мы просто выставляем что вот такие то кусочки мы меняли, и потом дефрагментатор, если он раньше этот 64килобайтник недокопировал, может перекопировать изменившийся кусок и потом дальше докопировать. А помечать это можно через битовые маски

И да, фрагментация кучи актуальна и для всяких там Си/С++, особенно если MMU нет

Move semantics в первую очередь, ссылки - во вторую. А те случаи, когда надо действительно «to share» очень редки.

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

Для чего ты используешь указатели на C++?

Это очень странный вопрос, учитывая, что в C++ указатели под капотом так или иначе повсюду, у всех классов из STL и так далее. Ссылки - это те же указатели по сути.

И как к ним пределать GC, который ты собирался костылить, не совсем понятно. Чтобы использовать GC в C++, нужно выкинуть собственно C++, и в этом случае необходимость использовать этот язык в принципе вызывает очень серьёзные сомнения.

«Складывалось впечатление» прокатит для гомогенного массива, и то с тройными расходами на переадресацию и доступ не за О(1).

Ну давайте я еще про пуловый аллокатор расскажу. А аллоцированные кусочки(чанки) в пуле тоже можно битовой маской помечать. Мои посты никак не переплюнут GC т.к. я не буду тут описывать в своих постах, как я буду отслеживать всякие там поколения, не надо мне будет циклические ссылки ловить, делать обход графа... ну короче все то, что делают GC

Ну давайте я еще про пуловый аллокатор расскажу. А аллоцированные кусочки(чанки) в пуле тоже можно битовой маской помечать. Мои посты ника не переплюнут GC т.к. я не буду тут описывать в своих постах, как я буду отслеживать всякие там поколения, не надо циклические ссылки ловить, делать обход графа... ну короче все то, что делают GC.

Твои посты похожи на странный плод насильственной связи между SLAB и GC.

C++ != STL. Опять же вернемся к вопросу «у нас RTS и эмбеддед». Не будешь же ты в RTS пихать STL? Но смысла отказываться от удобных синтаксических конструкций и того же RAII совершенно нету.

С доступом можно ускорить, если сделать вместо Unrolled linked list обычный массив из этих «обернутых» указателей на мелкие куски памяти

Локальность при обращении ломается. Если эти куски достаточно далеко, ты испортишь CPU кеш. И он будет очень-очень недоволен.

C++ != STL

Ага. Да, конечно. Угу. Точно. Да, так и есть.

Опять же вернемся к вопросу «у нас RTS и эмбеддед».

Если у нас RT и embedded, зачем нам C++ вообще в принципе? Опять же, для этого есть другие инструменты.

Не будешь же ты в RTS пихать STL?

В hard real time C++ никто не будет пихать вообще. «Си с классами» максимум. В soft real time это менее принципиально, и на ура работают Erlang, Haskell, Java, C#, да и вообще что угодно, хоть Javascript. Компьютерные игры - тоже real time, на секунду.

Но смысла отказываться от удобных синтаксических конструкций и того же RAII совершенно нету.

Смысла отказываться от удобных в C++ синтаксический конструкций и костыля из C++ при отказе от C++ нет, ты это имеешь ввиду? Мне всё таки кажется, при отказе от C++ всё же есть смысл отказаться от удобных в C++ конструкций. Например, при программировании на том же Haskell конструкции из C++ зачастую крайне неудобны.

P.S. Если что, в самом начале треда под RTS я имел ввиду рантайм GHC. А Real Time - это RT.

«Обычный массив» захочет непрерывный кусок памяти. Хотя я тоже думаю, что при реалтайме большой кусок аллоцировать неприлично - максимум при некритичных к реалтайму операциях типа автоматическиой смены прошивки. Но как уже упоминали, GC - это следствие, причина проблемы в аллоцировании без SLAB и фрагментации.

Ага. Да, конечно. Угу. Точно. Да, так и есть.

NASA софт для управления Curiosity писали на плюсах.

Если у нас RTS и embedded, зачем нам C++ вообще в принципе? Опять же, для этого есть другие инструменты.

Какие же?

В hard real time C++ никто не будет пихать вообще.

По религиозным соображениям разве что. F35 на C++, думаешь там не hard real time? :D

Компьютерные игры - тоже real time, на секунду.

Извини, но «лолшто?». Это в том месте они real time, когда у меня картинка опаздывает за мышкой на неопределенное количество миллисекунд, которое зависит от того, насколько много текстур и эффектов в кадре?

Хотя я тоже думаю, что при реалтайме большой кусок аллоцировать неприлично

Особенно в какой-нибудь медицинской технике, где объем данных постепенно уходит в десятки терабайт.

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

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

Потому что ты не знаешь объем данных заранее.

invy, ради интереса - а что дает такого С++ в данном применении, что приходится его терпеть? Чего нет в чистом С?

It's running 2.5 million lines of C on a RAD750 processor manufactured by BAE. The JPL has a bit more information but I do suspect many of the details are not publicized. It does appear that the testing scripts were written in Python.

The underlying operating system is Wind River's VxWorks RTOS. The RTOS in question can be programmed in C, C++, Ada or Java. However, only C and C++ are standard to the OS, Ada and Java are supported by extensions. Wind River supplies a tremendous amount of detail as to the hows and whys of VxWorks.

На Curiosity C, а не плюсы.

NASA софт для управления Curiosity писали на плюсах.

Какую часть? Потому что там VxWorks. Плюс у Curiosity весьма мощное железо: 256Mb памяти - это явно не мелкий контроллер.

Какие же?

Зависит от. Начиная от Atom и Copilot для hard real time, и заканчивая Erlang. Я на секунду забуду про Forth и чистый C.

F35 на C++, думаешь там не hard real time? :D

Я уже упоминал про C с классами? Почитай про ограничения на использование C++, там от ++ почти ничего нет. MISRA-C++ туда же.

Это в том месте они real time, когда у меня картинка опаздывает за мышкой на неопределенное количество миллисекунд, которое зависит от того, насколько много текстур и эффектов в кадре?

Это называется soft real time.

Потому что ты не знаешь объем данных заранее.

Хорошо, ты аллоцируешь сразу весь кусок с запасом? И тебе аллокатор говорит - погоди, я пока не готов, как скажу - можешь начинать свой реалтайм? Или постепенно, по мере прихода данных? Но тогда есть реальный шанс напороться на задержку дефрагментации, если не предпринять спец. мер.

https://youtu.be/3SdSKZFoUa8

Этот объем данных надо на диск писать (или выплевывать его из какого-нибудь интерфейса типа RS-485 и там на другом конце писать на жесткий диск непрерывным куском)

Этот объем данных надо...

Конечно при таких цифрах память внешняя. Но предположим цифрыбыли для красного словца и мы пишем в свое ОЗУ и частота такая, что интерфейс не потянет.

Их на диск и пишут. Тока перед этим данные нужно быстро обработать :) С твоим MMU этого сделать не получится.

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

Их на диск и пишут. Тока перед этим данные нужно быстро обработать :)

Простите за занудство, но стало интересно. Я в таких случаях делал так - нарезал в ОЗУ подходящей длины кольцевой буфер, писал в него сырые данные, обрабатывал и выдавал результат по интерфейсу. Тот же GPS-трекер например. (это не считая кучи других задач на том же камне). И вообще ничего не аллоцировал.

Смотри внимательное.

Их на диск и пишут. Тока перед этим данные нужно быстро обработать

Пожать каким-нибудь алгоритмом быстрым, и слать. А обработать потом можно

https://github.com/dropbox/pyston

Какие преимущества, недостатки и ограничения привносит использование Си++ в разработке ПО в бортовой авионике американских истребителей можно узнать от его разработчика в докладе: Bill Emshoff «Using C++ on Mission and Safety Critical Platforms».

Справедливости ради - в D/Nim GC отключается. Вопрос о том что останется от языка оставим за скобками.

в Go тоже отключается :)

Genie

rust, но там нет наследования и исключений.

Лень читать топик - Swift.

Хорошо, я написал логику на Mono или например Go, каким удобным способом я могу связать Qt5/GUI и логику? По-твоему это вообще без проблем осуществляется, без лишних затрат времени??? Дай мне пример способа.

Если по твоему представлению это должен делать каждый разработчик, то почему авторы платформы/языка не поставили целью чтобы все заинтересованные в GUI не скооперировались и мне сделали привязку GTK3 или Qt5 к своему языка, вместо того чтобы каждый это делал сам???

Вот Python+Qt5 - ноль проблем. Со мной спорить бесполезно, язык или платформа без привязки хорошего GUI типа более менее GTK3 или Qt5 - для меня это недоязыки и недоплатформы, с которым я связываться не буду, и скорее всего таких как я много, но это мое личное дело :)

Я читал подобный материал несколько лет назад. Ещё раз, обрати внимание на количество ограничений, налагаемое на использования языка: там нет RTTI, исключений и практически все стандартной библиотеки.

там нет RTTI, исключений и практически все стандартной библиотеки.

Ну вы бы на причины этого обратили внимание. Для начала. И на выводы. Дабы лучше понимать современную ситуацию и направление движения.

Не будешь же ты в RTS пихать STL?

Если RTS - это Real-Time System, то почему нет? Впрочем, к RunTime System это тоже относится.

В hard real time C++ никто не будет пихать вообще. «Си с классами» максимум.

В hard realtime собственно hard части часто невелики и могут быть изолированы. Т.е. в большой программе на Си++ некоторые части пишутся на Си-совместимом подмножестве.

В hard realtime собственно hard части часто невелики и могут быть изолированы.

Откуда инфа? И где твоя человеконенавистнический аватарка? Она забавная же была!

Кстати, у F35 большие проблемы с софтом.... Интересно почему?

В hard realtime собственно hard части часто невелики и могут быть изолированы.

Откуда инфа?

Отчасти собственный опыт, отчасти книги.

И где твоя человеконенавистнический аватарка?

Принесена в жертву политической корректности.

Кстати, у F35 большие проблемы с софтом....

У него самые обычные проблемы. «Большие» бы ли бы при потере хотя бы одного самолета. А так... там хоть раз приостанавливались полеты из-за проблем с софтом?

Забавно было бы посмотреть на такой третий курс... У меня в мухосранске около на подобное в принципе способны <5% программистов (с законченным высшим).