Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, призвал комитет WG21, отвечающий за разработку стандартов для языка C++, предпринять меры для сохранения актуальности C++ в условиях активного продвижения инициатив по переходу на языки, обеспечивающие безопасную работу с памятью. Страуструп считает, что язык С++ уже предоставляет все возможности, необходимые для безопасной работы с памятью. Остаётся только предоставить средства, гарантирующие, что код написан с использование только безопасных возможностей...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62821
Засуетили, забегали)
Это хорошо, хорошо
Но ведь раст не настоящий язык, почему такая реакция /sДидов корёжит и это хорошо. В результате выиграют все.
От этого выиграет даже раст, которой без C++ного LLVM может примерно ничего.
Это будет его единственное предназначение.
Rust конкурент C т.к. в обоих языках нет ОПП в принципе. ООП черты имитируются и там, и там очень похоже.Go норм - на нем держится инфраструктура вроде Kubernetes, Docker, Helm, Prometheus, Grafana и тд. Java в морг, но C# норм. Ruby фтопку, уж лучше Python. SWift не пробовал никогда. Довольно нишевой, для macOS/iOS.
Думаю, что Бэйсика хватит всем!
Я соглашусь, только надо говорить о Free Pascal
В каких-то Бейсиках было обращение к адресам памяти - небезопасТно.
> Rust конкурент C т.к. в обоих языках нет ОПП в принципе.на Rust не написать ничего подобного seL4, а ООП не нужен в принципе
Лично тебе ненужен - не испольщуй.
На язике программирования нельзя написать программу. Подробней в новостях в 23.
> На язике программирования нельзя написать программуsel4 написали на С за 2 месяца, но сделать полную верификацию кода на расте у тебя памперс переполнится
> уж лучше Pythonдля системных скриптов - да. Но проблема в том, что им жестко заcpaли области программирования, для которых его применение сомнительно.
> для системных скриптов - да. Но проблема в том, что им жестко заcpaли области
> программирования, для которых его применение сомнительно.Черта с два. Из за вечных проблем с версиями - для этого он полный отстой.
>для системных скриптов - да. Но проблема в том, что им жестко заcpaли области программирования, для которых его применение сомнительно.А показать как надо было делать - как всегда некому. Если есть отличные альтернативы, которые действительно лучше, то почему же ими никто не пользуются в этих "областях", а мучаются с Пайтоном?
> Rust конкурент C т.к. в обоих языках нет ОПП в принципе. ООП
> черты имитируются и там, и там очень похоже.В Си++ нет ООП в принципе. ООП черты имитируются. Слова "метод класса" могут оказаться последними.
C++ - мультипарадигменный язык. На нем можно писать объектно и аккуратно, как на Джаве. А можно настрогать портянку, как на С.
К сожалению, студентов учат только второму, и они вообще не понимают, что такое С++. В принципе. Но при этом считают, что они этот язык - "выучили".
Не понял, какая связь с моим сообщением. Намёк на то, что на Си++ можно написать паттерн синглтон?
Намек на то, что не надо тупых вбросов про "нет в принципе".
> Намек на то, что не надо тупых вбросов про "нет в принципе".Действительно, не надо тут вбрасывать. Приму лишь цитату стандарта.
https://lleo.me/dnevnik/2011/09/16_mail - что уж цитату, вот сам стандарт.
Стандарты у меня есть, и черновики есть. Мне бы цитату про ООП.Что-то вроде "The storage duration is the property of an object that defines the minimum potential lifetime of the storage containing the object" (6.7.5/1), но что бы "свойства" и "объекты" хоть чем-то напоминали вон ту аббревиатуру.
Вы сегодня уже второй человек на этом сайте, убедительно демонстрирующий мне преимущества общения с нейронками перед попытками диалога с живыми собеседниками.
Весна, что ли...
Что характерно, тот демонстрировал IQ замерзшего постового, вы пытаетесь продемонстрировать незримые простыми смертными высоты - а результат ну совершенно идентичный!
Я знаю, что цитаты из стандарта Си++ на тему ООП быть не может -- этим валят джунов на собеседовании -- потому и прошу её.
А я знаю, что человека-граммофона бесполезно сбивать с заготовленной речи - он токует, не слушая, исступленно предаваясь публичному самоудовлетворению.
Осталось понять, зачем он влез со своим особо ценным мнением. Не увидел подвох?
> Я знаю, что цитаты из стандарта Си++ на тему ООП быть не
> может -- этим валят джунов на собеседовании -- потому и прошу её.Ты сам уже превратился - в старого деграда. Валят джунов, ха. Умение мыслить - это не накопленные знания и опыт, внезапно. Совершенно отдельный аспект. Ты этот аспект давно продолбал. Джун имеет шансы отыграть аспект опыта. А вот отвалившееся активное принятие решений - билет в 1 сторону.
Умение мыслить подтолкнуло бы тебя к мысли, то "валят" -- несовершенный вид, что дало бы тебе шанс не завалиться.
> Умение мыслить подтолкнуло бы тебя к мысли, то "валят" -- несовершенный вид,
> что дало бы тебе шанс не завалиться.Дедуля, ты не понимаешь. Я срубаю сомнительную "радость" общения с такими как ты "валильщиками" на другом уровне абстракций. Так что заниматься этим ты будешь - с отборными идиотами. Которые с одной стороны зазубрят все то чтобы ублажать тебя, с другой будут настолко тупы чтобы вообще зачем-то тратить время на тебя и твою помойку при этом.
Что это могут быть за рожи и чего вы достигнуть сможете - я и так знаю. Заранее. Очень уж характерный антипаттерн.
Но я этим уже занимаюсь прям здесь и сейчас, и вы сами себя "отбираете". Разве что ума хватает не подписываться. ;)
> Но я этим уже занимаюсь прям здесь и сейчас, и вы сами
> себя "отбираете". Разве что ума хватает не подписываться. ;)Чем вы занимаетесь? Демо как выглядит "спустит на свой уровень и задавит интеллектом"? :)
Поищи в сообщении на которое я отвечал слово "занимаюсь", если контекст теряешь.
>>Стандарты у меня есть, и черновики есть.
> У тебя и "Русский язык. Полный курс для начальной школы (Ф. С.
> Алексеев)" есть, но и то и другое тебе не помогает.У тебя галлюцинации?
Стандарт информирует, что "C++ is an object-oriented language" - [diff.expr].Вспоминаю твоё старое двоемыслие про то, что Windows и Linux якобы написаны на Си.
Либо они написаны на других языках, которые грубо нарушают стандарт и поэтому должны называться иначе, например, "похожими на Си языками" (по аналогии с твоей "похожей на Си библиотекой"[1]).
Либо они написаны на Си, и библиотека совсем даже не похожая, а вполне себе сишная. А вот стандарты Си и Си++ при этом надо свернуть в трубочку и за... задвинуть подальше, там много оторванной от реальности чепухи.
[1] https://www.opennet.dev/openforum/vsluhforumID3/130995.html#32
> Стандарт информирует, что "C++ is an object-oriented language" - [diff.expr].Эксперт информирует, что ему удалось найти единственное вхождение "object-oriented", но он постеснялся скопировать целиком -- поскольку тогда бы пришлось ставить знаки вопросов, а он их задавать стесняется, так как сформулировать не удаётся. С чем я и помогу.
[diff] это у нас "информирующее" приложение -- Annex C (informative) Compatibility
[diff.expr] это -- C.5.3 Clause 7: expressions
то есть подраздел
C.5 C++ and ISO C
This subclause lists the differences between C++ and ISO C, in addition to those listed above, by the chapters of this document.
Собственно пункт, откуда эксперт выдрал "объектную ориентированность":C.5.3 Clause 7: expressions [diff.expr]
...
5 Affected subclauses: 7.6.16, 7.6.19, and 7.6.20Change: The result of a conditional expression, an assignment expression, or a comma expression may be
an lvalue.Rationale: C++ is an object-oriented language, placing relatively more emphasis on lvalues. For example,
function calls may yield lvalues.Effect on original feature: Change to semantics of well-defined feature. Some C expressions that implicitly
rely on lvalue-to-rvalue conversions will yield different results. For example,char arr[100];
sizeof(0, arr)yields 100 in C++ and sizeof(char*) in C.
Difficulty of converting: Programs must add explicit casts to the appropriate rvalue.
Итак, вопрос: неужели эксперт полагал, что такое прокатит? Он не понял слово "Change"? Что он ещё не понял?Или он, как обычно, забыл, на что я отвечал? Напоминаю:
> Rust конкурент C т.к. в обоих языках нет ОПП в принципе. ООП
> черты имитируются и там, и там очень похоже.В Си++ нет ООП в принципе. ООП черты имитируются. Слова "метод класса" могут оказаться последними.
Ты просил цитату из стандарта С++, с высокомерием и апломбом, уверенный, что такой цитаты нет. Хотя непонятно, что отсутствие этой цитаты доказало бы. Но тебе её всё равно предоставили. Хотя и не обязаны были. Тебя перегирали на твоём поле, по твоим же правилам. Теперь ты бьёшься в истерике. Научись уже проигрывать достойно.
Я привёл пример, какая цитата мне нужна. Если корму не ясно, то в примере определение, что такое storage duration объекта. Я жду цитату, в которой такой объект обменивается сообщениями с другими объектами. А что каждый кретин способен выполнить поиск и скопировать без понимания, это и так ясно. На то и расчёт. ;)
Шизофрения, как и было сказано.
Я слышал, это заразно. Ты поэтому мне пишешь с таким усердием?
>Я слышал, это заразно.Слышал звон, да не знаешь где он. Нет, ты не сможешь заразить окружающих своей шизофренией.
Тема твоего усердия не раскрыта. Что заставляет тебя писать мне глупости который год?
> Я привёл пример, какая цитата мне нужна. Если корму не ясно, то
> в примере определение, что такое storage duration объекта.Не корму - а дюзы! Если стандарт говорит что оно объектно ориентированное, иди нафиг с попытками быть святее папы римского. То что тебе не нравится как именно оно там сделано - это лично твои проблемы. Тебя другие аноны утерли ткнув в цитату стандарта, требовать быть авторитетнее стандарта - это уж совсем финиш.
> Если стандарт говоритА я ведь перевёл, что означает "Annex C (informative) Compatibility". Перечитай, что бы не писать глупости.
>В Си++ нет ООП в принципе. ООП черты имитируются. Слова "метод класса" могут оказаться последними.Не могли бы вы пояснить, что такое принципиальное наличие ООП в языке программирования? То есть, какие критерии могли бы свидетельствовать о том, что в данном языке ООП не имитируется, а является частью языка?
>>В Си++ нет ООП в принципе. ООП черты имитируются. Слова "метод класса" могут оказаться последними.
> Не могли бы вы пояснить, что такое принципиальное наличие ООП в языке
> программирования? То есть, какие критерии могли бы свидетельствовать о том, что
> в данном языке ООП не имитируется, а является частью языка?С превеликим удовольствием попробую.
Предположим, мы решили, что модель "объекты, обменивающиеся сообщениями" лучше прочих подходит для решения наших задач.
Далее, пишем ТЗ с пунктами
- Сокрытие реализации.
- Наследование.
- Полиморфизм.
...Когда возникает необходимость выбора между "соответствовать модели" и чем-то еще (скорость исполнения, наличие дополнительных возможностей, ...), перевешивает первое.
В итоге часть ТЗ превращается в документацию по языку (или даже стандарт), где явно написано "ООП". Заодно получается Smalltalk. Динамическая типизация, байткод, вот это вот всё -- цена за "всё есть объект".
Если же мы хотим "кроссплатформенный ассемблер" или "язык, на этапе трансляции выявляющий ряд ошибок при работе с памятью", то при составлении ТЗ мы будем говорить разве что "плюс ко всему, это позволяет реализовать вон ту фишку из ООП" и "а это зачем надо? будет тормозить".Получается C или Rust.
В том же Си++ у классов могут быть не "методы" (как принято в ООП), а функции-члены, это термин из стандарта. Объектом там называется нечто, занимающее память, например символ 'А'. Такой объект не обменивается сообщениями и не имеет функций-членов, не то что методов.
> Предположим, мы решили, что модель "объекты, обменивающиеся сообщениями" лучше прочих
> подходит для решения наших задач.А вы тут что, истина в последней инстанции за всех решать?
Под ООП обычно понимают - что угодно, но не "обмен сообщениями", хоть вы там тресните с досады.
>> Предположим, мы решили, что модель "объекты, обменивающиеся сообщениями" лучше прочих
>> подходит для решения наших задач.
> А вы тут что, истина в последней инстанции за всех решать?Истина в том, что Аноним упорно не видит и не понимает слово "предположим".
> Под ООП обычно понимают - что угодно, но не "обмен сообщениями", хоть
> вы там тресните с досады.А вы тут что, истина в последней инстанции за всех решать, что они обычно понимают?
Если аноним что-то понимает, это одно. Если авторы Smalltalk - это другое. Очевидно, их понимание имеет вес отличный от нулевого.
> Истина в том, что Аноним упорно не видит и не понимает слово "предположим".О! Предположительно-неООПшный C++ это пять!
> А вы тут что, истина в последней инстанции за всех решать, что
> они обычно понимают?Объектно-ориентированное программирование по определению - про объекты. Что и как с ними можно делать - второстепенные технические детали.
> Если аноним что-то понимает, это одно. Если авторы Smalltalk - это другое.
Smalltalk на данный момент - мертвый язык прежде всего. Возможно в том числе и поэтому.
> Очевидно, их понимание имеет вес отличный от нулевого.
Очень небольшая величина, я бы сказал. Глядя на его использование.
>> Истина в том, что Аноним упорно не видит и не понимает слово "предположим".
> О! Предположительно-неООПшный C++ это пять!Да, это надо было очень постараться, не увидеть ещё и остальное. Приписать-то глупость оппоненту - уже дело техники.
>> А вы тут что, истина в последней инстанции за всех решать, что
>> они обычно понимают?
> Объектно-ориентированное программирование по определению - про объекты. Что и как с ними
> можно делать - второстепенные технические детали.Голословно.
>> Если аноним что-то понимает, это одно. Если авторы Smalltalk - это другое.
> Smalltalk на данный момент - мертвый язык прежде всего. Возможно в том
> числе и поэтому.Прежде всего, Аноним всегда был и остаётся тем, кто под своими словами не подписывается. Что и определяет цену слов.
>> Очевидно, их понимание имеет вес отличный от нулевого.
> Очень небольшая величина, я бы сказал. Глядя на его использование.По сути ничего не изменилось: небольшая величина против нуля.
> Прежде всего, Аноним всегда был и остаётся тем, кто под своими словами
> не подписывается. Что и определяет цену слов.Тем не менее, ты отвечаешь анониму, что делает цену твоим высказываниям равной нулю. Ты просто балабол, которого выперли из преподавания.
>> Прежде всего, Аноним всегда был и остаётся тем, кто под своими словами
>> не подписывается. Что и определяет цену слов.
> Тем не менее, ты отвечаешь анониму, что делает цену твоим высказываниям равной
> нулю. Ты просто балабол, которого выперли из преподавания.Я в доступном для обозрения каждому месте заставляю тебя выдавать примеры, что из себя представляет типичный активист Free Software. например, сейчас:
1. Пытается набить себе цену.
2. Бредит про преподавание.
> Тем не менее, ты отвечаешь анониму, что делает цену твоим высказываниям равной
> нулю. Ты просто балабол, которого выперли из преподавания.Его еще из росы, чтоли, выперли. Или типа того. Он на них ядом брыжжет буквально в каждой новости минимально касающейся линуха.
А сейчас этот чудак вбил себе в бошку что ооп == message passing. Ктулху бы его знает почему так. Но он внаглую присвоил себе монополию на истину, не доволен что в стандарте C++ написано что оно - ООПшное, кивает на какие-то annex'ы и вообще.
> А сейчас этот чудак вбил себе в бошку что ооп == message
> passing. Ктулху бы его знает почему так.Потому что этот чудак не понимает смысл слова "предположим". Русский язык не понимаешь и приписываешь мне свою глупость.
> Но он внаглую присвоил
> себе монополию на истину, не доволен что в стандарте C++ написано
> что оно - ООПшное, кивает на какие-то annex'ы и вообще.В стандарте написано другое, а именно "C++ is a general purpose programming language based on the C programming language". Ты и инглишь не понимаешь за пределами Basic English.
> Да, это надо было очень постараться, не увидеть ещё и остальное. Приписать-то
> глупость оппоненту - уже дело техники.Умный человек не брякнул бы что C++ не оопшный, имхо.
>> второстепенные технические детали.
> Голословно.Голимая софистика. Почему ООП про объекты - я понимаю. Почему там в обязаловку какая-то конкретика типа message passing отрастает - нет. Это _ваш_ тезис - вам и обосновывать с какого бы хрена вон то ООП - а вон то - нет. "Предположим" - обоснованием не является. Только отсебятиной некоего n00by.
> Прежде всего, Аноним всегда был и остаётся тем, кто под своими словами
> не подписывается. Что и определяет цену слов.С вашим то гитхабом только про цену слов париться. Комплекс неполноценности долбит?
> По сути ничего не изменилось: небольшая величина против нуля.
В этих наших цифровых системах, видите ли, есть квантование. Так что очень небольшую величину мы можем и к нолю приравнять так то. Без особых потерь информации.
>> Да, это надо было очень постараться, не увидеть ещё и остальное. Приписать-то
>> глупость оппоненту - уже дело техники.
> Умный человек не брякнул бы что C++ не оопшный, имхо.Умный человек, как минимум:
1. способен держать в голове более одного предложения, в том числе и то, на которое я отвечал.
2. не будет приписывать искажённую фразу.>>> второстепенные технические детали.
>> Голословно.
> Голимая софистика. Почему ООП про объекты - я понимаю. Почему там в
> обязаловку какая-то конкретика типа message passing отрастает - нет.Беда твоя в том, что ты, именно ты написал слова "в обязаловку", когда у меня "предположим". По сути ты заявил о непонимании, что же ты вообще делаешь, но предварил это точным определением своих действий. Да, это голимая софистика.
Как-то очень мутно получилось. Неясности:1. Где можно посмотреть стандартное определение, что такое ООП? Вы о нём так уверенно говорите, но не проводите источники. Smalltalk? Это ИСТИННЫЙ стандарт? А Питон или Руби уже нет? Если да, то почему вы так решили?
2. Если язык А поддерживает только фичи из ООП, а язык Б поддерживает ещё что-то (например ФП), но и ООП тоже, пусть и в меньшем объёме, то почему язык Б нельзя считать таким который не занимается имитацией, а поддерживает ООП, так сказать, нативно? Всё дело в объёме поддержки? Или есть ещё какие-то критерии? Нет, я внимательно прочитал ваше объяснение. Вы там говорите о соответствии некой модели. Но этот критерий очень и очень неочевидный (см. п.1).
> Как-то очень мутно получилось. Неясности:
> 1. Где можно посмотреть стандартное определение, что такое ООП?Не ведаю. Наверное, нигде -- если нет документа "ГОСТ/ISO/IEC на ООП".
> Вы о нём так уверенно говорите, но не проводите источники.
Я уверенно говорю "в Си++ нет ООП в принципе", отвечая на "Rust конкурент C т.к. в обоих языках нет ОПП в принципе".
Уверенно -- поскольку экспертам пока удалось найти лишь буквы "ОО", без "П", в приложении к стандарту. :)
> Smalltalk? Это ИСТИННЫЙ стандарт?
> А Питон или Руби уже нет? Если да, то почему вы
> так решили?Я писал о том, что если бы мы решили и сделали Smalltalk, то тогда бы и авторитетно учили всех прочих, что такое ООП (в нашем понимании), приводя как аргумент написанную нами документацию. Smalltalk выбрал как пример, поскольку он появился раньше, соответственно, оказал на последователей влияние (не всегда повторяли, иногда делали наоборот, учитывая опыт).
> 2. Если язык А поддерживает только фичи из ООП, а язык Б
> поддерживает ещё что-то (например ФП), но и ООП тоже, пусть и
> в меньшем объёме, то почему язык Б нельзя считать таким который
> не занимается имитацией, а поддерживает ООП, так сказать, нативно? Всё дело
> в объёме поддержки? Или есть ещё какие-то критерии? Нет, я внимательно
> прочитал ваше объяснение. Вы там говорите о соответствии некой модели. Но
> этот критерий очень и очень неочевидный (см. п.1)."плюс ко всему, это позволяет _реализовать_ вон ту фишку из ООП"
То есть не "имитируем", а сами пишем, используя предоставляемые языком возможности. Если надо. И "ассемблер", и "borrow checker" - всё это абстракции существенно ниже уровнем, чем "объект" из ООП.
Поскольку пишем сами, может получиться как у того эксперта "имитация" (какое-то жалкое подобие), а может и лучше подойти под задачу, чем в жёстко заданных "настоящим" ООП-языком рамках.
>Уверенно -- поскольку экспертам пока удалось найти лишь буквы "ОО", без "П", в приложении к стандарту. :)Вам шашечки или ехать? В стандарте и не должна идти речь о такой вещи, как парадигма программирования. Стандарт должен детально описывать синтаксис языка и ничего более. А что там в синтаксисе скрывается - ООП или ФП - дело десятое.
Размышляем далее. Если какой-то язык содержит в себе абстракции, соответствующие какой-то парадигме программирования, то почему нельзя сказать, что в этом языке эта парадигма поддерживается, пусть и в несколько ограниченном объеме, по сравнению с другим языком? Тем более, что такое ООП вы не знаете достоверно, как выясняется. Я тоже не знаю, если что. В том плане, что ссылку на какой-то авторитетный источник привести не могу.
Что из этого всего следует? То, что не имея чёткого определения, что такое ООП, вы не можете сколь-либо аргументированно утверждать о том, что в этом ЯП ООП нативно, а в том - имитируется. Точнее, можете, но только в отношении каких-то отдельных абстракций, которые отсутствуют в другом ЯП.
>>Уверенно -- поскольку экспертам пока удалось найти лишь буквы "ОО", без "П", в приложении к стандарту. :)
> Вам шашечки или ехать?Мне ехать. Я стандарт читал не от нечего делать, а что бы реализовать в нём написанное.
> В стандарте и не должна идти речь о
> такой вещи, как парадигма программирования.Да ладно. Именно стандарт -- записанный на бумаге договор создателей языка -- определяет, кто и что должен. Стандарт нужен, что бы в спорных ситуациях побеждал не мастер софистики, а требования стандарта, цитирую их:
1 Scope [intro.scope]
1 This document specifies requirements for implementations of the C++ programming language. The first such
requirement is that they implement the language, so this document also defines C++. Other requirements
and relaxations of the first requirement appear at various places within this document.2 C++ is a general purpose programming language based on the C programming language as described in
ISO/IEC 9899:2018 Programming languages — C (hereinafter referred to as the C standard). C++ provides
many facilities beyond those provided by C, including additional data types, classes, templates, exceptions,
namespaces, operator overloading, function name overloading, references, free store management operators,
and additional library facilities.Как видим, С++ - язык общего назначения, а не что там нафантазировали эксперты.
> Стандарт должен детально описывать синтаксис
> языка и ничего более. А что там в синтаксисе скрывается -
> ООП или ФП - дело десятое.Стандарт описывает синтаксис, семантику, плюс стандартную библиотеку. Бытие таково, что не обязано всем нравиться.
> Размышляем далее. Если какой-то язык содержит в себе абстракции, соответствующие какой-то
> парадигме программирования, то почему нельзя сказать, что в этом языке эта
> парадигма поддерживается, пусть и в несколько ограниченном объеме, по сравнению
> с другим языком?Можно сказать: стандарт не запрещает, и оно верно, поддерживается.
Но какой смысл на этом основании строить утверждения "Rust конкурент C"?
Что бы конкурировать с С, Rust-у надо быть в чём-то лучше, иначе кто станет тратить на него время? Так что написавший "конкурент" заявил мне не совсем то, что хотел. :)
> Тем более, что такое ООП вы не знаете
> достоверно, как выясняется. Я тоже не знаю, если что. В том
> плане, что ссылку на какой-то авторитетный источник привести не могу.Никто не знает достойно веры (создатели вариантов ООП меж собой спорят), но признается в этом не всякий. :) Соответственно, можно посмотреть на кривую Даннинга-Крюгера и понять, с кем стоит поговорить об ООП, а кого следует отправить искать в стандарте.
> Что из этого всего следует? То, что не имея чёткого определения, что
> такое ООП, вы не можете сколь-либо аргументированно утверждать о том, что
> в этом ЯП ООП нативно, а в том - имитируется. Точнее,
> можете, но только в отношении каких-то отдельных абстракций, которые отсутствуют в
> другом ЯП.Когда я ручками пишу таблицу виртуальных функций, тогда я использую её как аргумент для "я реализовал полиморфизм из ООП".
Когда я заставил транслятор Си++ сгеренировать эту таблицу, написав virtual, тогда я могу заявить "эта функции-член реализует метод" - что бы людям в теме было понятно, что я читал книжку потолще чем "Си++ за 21 день".
Заявлять, что я что-то там сымитировал, не стал бы. Могут ведь подумать, что сделал фуфло. :)
Итоги нашей с вами дискуссии.1. Ни в одном стандарте не определено, что такое ООП. Поэтому делать какие-либо однозначные выводы о поддержке или неподдержке той или иной парадигмы в том или ином ЯП логически неверно - потому что у нас просто изначально не определена терминология ни одним авторитетным источником.
Вполне допустимо говорить о каком-то списке абстракций из какой-либо парадигмы, поддерживаемых или нет данным ЯП. Но даже в этом случае, не имея чёткого определения для, например, ООП (и, как следствие, исчерпывающего списка присущих ему абстракций), подобные размышления будут не вполне корректными.2. "Стандарт описывает синтаксис, семантику, плюс стандартную библиотеку", но не перечисляет поддерживаемые языком парадигмы программирования. Поэтому ссылаться на стандарт, как источник информации о парадигмах программирования для этого ЯП, неверно с точки зрения логики и здравого смысла.
3. На основе п.1 и п.2 легко прийти к выводу, что говорить о том, что такой-то ЯП имитирует парадигму неверно в том случае, если в таком ЯП поддерживается по крайней мере одна абстракция из этой парадигмы. Правильно было бы сказать, что ЯП1 не поддерживает все возможные абстракции такой-то парадигмы по сравнению с ЯП2. Но вы так не сказали.
За сим откланиваюсь.
> Правильно было бы сказать, что ЯП1 не поддерживает все
> возможные абстракции такой-то парадигмы по сравнению с ЯП2. Но вы так
> не сказали.Ну... да. Я ведь скопировал исходное утверждение, на которое отвечал. В той "логике" выходило бы, что Rust конкурент С++ и С++ конкурент С. Почему меж С и С++ не затеяли спор?
> Поэтому ссылаться на стандарт, как
> источник информации о парадигмах программирования
> для этого ЯП, неверно с точки
> зрения логики и здравого смысла.Так ведь ссылаются, когда попросишь, ищут с завидным упорством. Было бы там определено, я бы не просил, а сам первый показал. :)
> Поскольку пишем сами, может получиться как у того эксперта "имитация" (какое-то жалкое
> подобие), а может и лучше подойти под задачу, чем в жёстко
> заданных "настоящим" ООП-языком рамках.Если уж сравнивать C++ и хруст, C++ явно мощнее. Потому что то у хруста вечно требуются патчи стдлибы и тулчейна. А плюсеры - делают абстракции хруста типа борова или option прямо средствами плюсов. И bound checking оверлоадом operator [].
А хруст постоянно патчит тулчейн и стдлиб для любой фичи. Без этог там просто ни шагу.
В rust другая вариация ООП. Нет классов. Нет наследования. И то и другое есть хорошо. Плюс ООП не является доминирующей частью rust, которая диктует, как писать весь код. Оставаясь при этом инструментом на каждый день.
> И то и другое есть хорошо.Потому что ты так сказал?
Об этом даже в вики успели написать: https://en.wikipedia.org/wiki/Composition_over_inheritance
тебе никто не мешает использовать композицию вмест с наследованиемне нужно заменять наследование композицией, и наборот
если использовать не подходящий вариант, то можно испортить что угодно
а вот отсутствие такой возможности в принципе уже накладывает констрейнты на проектирование
>а вот отсутствие такой возможности в принципе уже накладывает констрейнты на проектированиеЗаведомо плохие решения надо отсекать на этапе проектирования. Так что наличие подобных ограничений с одной стороны не даёт свободы для полёта фантазии, а с другой - не позволяет отстрелить себе ноги. Сродни моделям работы с памятью в Си и Раст. В Си - полная свобода. В Раст - куча ограничений на этапе компиляции. Качество конечного кода в итоге выше там, где больше ограничений.
> Качество конечного кода в итоге выше там, где больше ограничений.В корне неверно.
Качество лучше там, где лучше можно управлять ограничениями.
>где лучше можно управлять ограничениямиВ корне неверно. Качество лучше там, где ограничения жёсткие. У меня и доказательства есть в виде отчётов фирм Гугл и Майкрософт о лучшем качестве кода на языке Раст перед кодом на Плюсах. А какие у вас доказательства, кроме голословного утверждения?
> В корне неверно. Качество лучше там, где ограничения жёсткие. У меня и
> доказательства есть в виде отчётов фирм Гугл и Майкрософт о
> лучшем качестве кода на языке Раст перед кодом на Плюсах.Google и Microsoft - это вообще не доказательства. В Microsoft не осилили калькулятор написать нормально для винды обновлённый (исходники лежат в сети - и это полный треш на корутинах, код C++, а сломать его легко можно поигравшись с введёнными значениями), т.е. старый калькулятор, который наследовался с Windows 95 был лучше.
Далее: WinUI - это ужасный проект с отвратительным качеством кода и тоннами ошибок, которые уже никогда не будут исправлены. И да, там тоже код на C++, значит виноват C++. В вашей системе ценностей это так и работает, хотя на деле, если человек не может корректно написать калькулятор для системы, которой пользуются почти все нормизы - он не должен быть программистом (или должен доучиваться).
>>а вот отсутствие такой возможности в принципе уже накладывает констрейнты на проектирование
> Заведомо плохие решения надо отсекать на этапе проектирования. Так что наличие подобных
> ограничений с одной стороны не даёт свободы для полёта фантазии, а
> с другой - не позволяет отстрелить себе ноги. Сродни моделям работы
> с памятью в Си и Раст. В Си - полная свобода.
> В Раст - куча ограничений на этапе компиляции. Качество конечного кода
> в итоге выше там, где больше ограничений.нет ничего плохого в наследовании, главное чтобы оно было сделано не так как в JS )))
другими словами не надо забивать гвозди микроскопом
>нет ничего плохого в наследованииЕсть. Когда оно многоэтажное (много уровней иерархии) или множественное (несколько родителей, находящихся на одном уровне). Код получается очень сложным для понимания и последующего сопровождения. Я уже не говорю про конфликты, могущие возникать при множественном наследовании.
>>нет ничего плохого в наследовании
> Есть. Когда оно многоэтажное (много уровней иерархии) или множественное (несколько родителей,
> находящихся на одном уровне). Код получается очень сложным для понимания и
> последующего сопровождения. Я уже не говорю про конфликты, могущие возникать при
> множественном наследовании.и ничего плохого в этом нет, даже множественное наследование можно использовать грамотно, в частности для реализации патерна адаптер
ты просто не умеешь в ООП, и любишь читать хайповые статьи в интернете, молотком ведь тоже можно голову пробить, но молоток это не есть плохо
Composition_over_inheritance
Это кстати прогрев. Доля истины в этом конечно тоже есть: наследование семантически опасный инструмент при плохо проектировании и злоупотреблять им не следует. То есть чаще в программировании на самом деле нужно использовать композицию, а не наследование, НО наследование также мощный инструмент изменения поведения всей иерархии объектов, то есть то, за что наследование часто критикуют, одновременно является его основной фишкой. В результате мы должны понимать разницу и применять наследование там, где его механизмы дают преимущества, а здесь из крайности в крайность: мы придумали композицию, которая в кривых руках показывает себя менее вредной, чем наследование, значит композиция лучше.
>В rust другая вариация ООП.Не нужно изобретать свою собственную терминологию.
Рекомендую пойти и попробовать разные языки. Скажем, в JavaScript или Lua вариация ООП, основанная на прототипах.На счёт ООП в rust рекомендую 18 главу учебника: https://doc.rust-lang.org/book/ch18-00-oop.html
https://doc.rust-lang.org/book/ch18-01-what-is-oo.html
https://doc.rust-lang.org/book/ch18-02-trait-objects.html
https://doc.rust-lang.org/book/ch18-03-oo-design-patterns.htmlХотя предыдущие 17 могут быть нужны для контекста.
ООП для части - "поднятие солнца руками"ООП для другой части - мы поднимаем НОЧЬЮ прожектор и глядите - он как солнце
Если чего-то сделать нельзя - это не достоинство - это недостаток. Хотя, кому я это говорю.
Продолжая аналогию, ООП в rust от самого сердца> Если чего-то сделать нельзя - это не достоинство - это недостаток
Не очень понимаю, о невозможности чего ты говоришь. Окей, невозможно построить иерархию классов ибо нет наследования и классов. Но есть трейты, которые, в отличии от классов, вполне неплохо стыкуются с фишечками из ФП. Как там кстати с ФП в C++? А то я лет 10 назад в него погружался, может изменилось чего.
> Но есть трейты, которые, в отличии от классов, вполне неплохо стыкуются с фишечками из ФП.Для работы с железом нет необходимости в ФП, хотя использовать можно.
Для работы с железом есть необходимость в наследовании данных. Настолько что эту фичу постоянно эмулируют в разных частях ядра. Иначе придется дублировать огромное множество описаний данных и работу с ними.
ФП в c++ есть. Насколько оно отвечает требованиям функцианальщиков не вкурсе... И спросить не у кого.
> Иначе придется дублироватьС этим прекрасно справляются макросы. Разумеется я не про C++, там макросы скорее проблема сама по себе.
> Для работы с железом есть необходимость в наследовании данных
Можно по подробнее, что это вообще значит в контексте ядра? Я уверен, что в ядре так или иначе используют vtable и создают их по сути вручную. В rust трейты с натяжкой можно назвать классами без данных и сходную конструкцию можно в других языках найти. Иногда это ещё интерфейсами называют. Но общая идея в том, чтоб как раз таки на уровне данных была только композиция.
> Для работы с железом нет необходимости в ФП
Так и в ООП нет необходимости. Тип-суммы (продвинутые enum), итераторы (со всеми этими fold/map), паттерн-матчинг (продвинутый switch) - это всё невероятно полезно при написании embedded-кода.
> Можно по подробнее, что это вообще значит в контексте ядра?Часть структур с резервом в конце. В подтипах в этом резерве лежат данные необходимые для этих подтипов.
И да. Иногда резерв бывает в начале. Со смещениями в минус. :)
> Так и в ООП нет необходимости. Тип-суммы (продвинутые enum), итераторы (со всеми
> этими fold/map), паттерн-матчинг (продвинутый switch) - это всё невероятно полезно при
> написании embedded-кода.Чтоб утратить понимание что реально происходит в плане работы с железкой и паттернов доступа к ней, и - профачить какие-нибудь требования железки - и прострелить себе пятку максимально неочевидным способом. Который вроде как живой - но пару раз в год совершенно непонятная хрень случается (из-за нарушения constraints на операции с железом), и счастливой отладки.
Интересно как вы хрусту вообше объясните что
- Между этим доступом и этим доступом не должно быть иных доступов в иные адреса?
- Между этим доступом и этим достоупом должно пройти не более 4 тактов проца?Иначе оно - инвалидируется, на уровне железа - и вообще заворачивается. Обычные safeguard в железе на случай runaway софта и проч, если что - режект всей опесной операции если оно не оформлено как ожидалось либо заняло слишком долго.
Напрямую с железом контактирует максимум 20% кода. И то, в случае мелких микроконтроллеров. Обычно задача драйвера - перевести язык, на котором говорит железка, в язык абстракций системы.> Между этим доступом и этим доступом не должно быть иных доступов в иные адреса?
> Между этим доступом и этим достоупом должно пройти не более 4 тактов проца?Такие мелочи вообще на ассемблере делаются. Потом оборачиваются в абстракции языка. Си тоже не гарантирует таких штук. Ибо в любом современном компиляторе есть оптимизации, полагающиеся на возможность перестановки инструкций. Единственный контекст, где с этим возможна работа - многопоток и всякие lock-free. Есть всякие штуки вроде барьеров или точного выставления выравнивания. Но тут как раз очки в пользу Rust.
Вот после создания обёртки низкоуровневых инструментов у тебя получается набор высокоуровневых инструментов. На этом уровне как раз и проявляют себя как ООП-приблуды, так и ФП-приблуды.
> Напрямую с железом контактирует максимум 20% кода.И в этих 20% в случае раста придется очень помучаться. Де факто, написать такой код - это вообще филиал черной магии, доступный буквально нескольким человекам на всю планету.
Остальные - на этот пантеон ходить не умеют, и автоматически выписываются в второй сорт. Вы или способны bring-up новой платформы, или нет. Бинарная величина. Это разные ступеньки пантеона. Без тех - вас вообще не будет существовать. Как класса.
> И то, в случае мелких микроконтроллеров. Обычно задача драйвера - перевести
> язык, на котором говорит железка, в язык абстракций системы.Железка вывешивает пачку регистров в памяти и ожидает вполне характерные паттерны доступа туда. В том числе - для компактности - битовыми полями и прочей прелестью. С критичностью к тому как паттерн доступа туда выглядит. Весь "язык" в общем то.
Бывают и иные понятия - но mem-mapped оказался удобнее всего. Это просто делается из си. Это просто подпирается DMA. А если кто хочет 100500 гиг в секунду гонять, отвлекать системный проц на это и грузить шины не только потоком данных, но еще и инструкций описывающих что с данными делать - не айс.
> Такие мелочи вообще на ассемблере делаются.
На си можно такое попробовать скроить. Это не 100% гарантии, но...
> Потом оборачиваются в абстракции языка.
Прелестно. Взять высокоуровневый ЯП чтобы ... костылить сие потом асмом.
> Си тоже не гарантирует таких штук.
Но обычно таки - номер катит. Да, иногда надо таки чекать сгенеренный асм или гонять тесты что оно реально - работает. Си прекрасен тем что - простой. И инициализациа арены, и его взаимодействия с окружением. Это позволяет нехило понимать происходящее, избегая совершенно дурных прострелов пяток.
А представляете, например, хруст сам по себе не знает о DMA или IRQ и что они - под ним - состояние системы меняют - в виде отличном от того что он ожидал бы видеть. Си достаточно прост чтобы понимать как это взаимодействует. Но с более сложными яп это имхо будет вести к нетривиальным гибридным, комплексным ошибкам. В хучшем случае - это будет стрелять раз в год, и будет почти невозможно это отладить.
> Ибо в любом современном компиляторе есть
> оптимизации, полагающиеся на возможность перестановки инструкций.В сях это лечится, кейвордом "volatile" у переменной. Все HW REGS просто указаны как volatile и поэтому компилер знает что все паттерны доступа к ним должны быть как написано.
Это имеет смысл еще и потому что регистры - "dual port RAM". В них пишете не только вы - но и железка! Если вы удумаете сумничать, заоптимизив, знаете что будет потом? Железка поменяет регистр - неожиданным для оптимизера образом! Допущения обломаются. И вы получите очень интересный класс багов. Если не повезет - стреляющий раз в год. Удачи в дебаге.
> Единственный контекст, где с этим возможна работа - многопоток и всякие lock-free.
Вообще-то это может стрельнуть в пятку
- Везде где есть IRQ
- Везде где есть DMA
- Железо может писать в регистры само, НЕОЖИДАННО для вас и оптимизера!
- Все неатомарные операции в зоне риска.А если вы будете блин лок получать на то чтобы с регистром железки поработать - вы опупеете с перфоманса всего этого действа. И это все равно никак не решает тот факт что IRQ, DMA и железо живут side by side, компилеру не видны, и могут поменять что-то неожиданным образом.
> Есть всякие штуки вроде барьеров или точного выставления выравнивания. Но тут как
У си есть так то очень простая штука, volatile квалификатор переменных. Запрещает оптимизации, требуя именно тот паттерн доступа. Правда вон те соображения все равно учесть придется.
> раз очки в пользу Rust.
Об этом мы поговорим когда вы сможете bring-up'нуть пару железок своим ходом, без "богов" за спиной.
> Вот после создания обёртки низкоуровневых инструментов у тебя получается набор
> высокоуровневых инструментов. На этом уровне как раз и проявляют себя как ООП-приблуды,
> так и ФП-приблуды.Спасибо если не простреленными пятками и факапами которые вообще никто не знает как отлаживать. Ибо редкие "хардварные" гонки где assumptions failed можно вылавливать, буквально, годами.
В частности - компилер и его пруверы/сольверы/оптимизеры понятия не имеют про IRQ/DMA/железо пишущее вон туда само. И это нехилое такое поле для залета.
> филиал черной магии, доступный буквально нескольким человекам на всю планетуЯ один из этих людей. Не то, чтоб я был каким-то особенным. Но это не чёрная магия, а просто идёшь и пишешь.
> Это просто делается из си
И так же просто это делается в rust.
> но еще и инструкций описывающих что с данными делать
Ты будто про zero-cost не слышал. И в отличии от C++, в Rust с этим всё в порядке.
> Взять высокоуровневый ЯП чтобы ... костылить сие потом асмом
Например превратить внутренний API некой GPU в Gl/Vulkan. 5% будет низкоуровщиной, остальное - абстракции, которые сильно проще делать на высокоуровневом языке. И чем более мощные средства предоставляет язык, тем проще весь процесс.
> А представляете
Я не представляю это всё, я этим всем занимался. На Rust. При чём это было 7 лет назад. https://habr.com/ru/users/lain8dono/articles/
То, чему ты меня пытаешься "научить", является для меня базовыми знаниями.
Rust неплохо подходит для разных вещей. Но embedded это та категория, в которой Rust проявляет себя лучше всего. 7 лет назад безусловно были некоторые (решаемые) подводные камни, но сейчас Rust является объективно лучшим языком для низкого уровня. По одной простой причине - он для этого и создавался в первую очередь.
> Спасибо если не простреленными пятками и факапами которые вообще никто не знает как отлаживать. Ибо редкие "хардварные" гонки где assumptions failed можно вылавливать, буквально, годами.
На си. Ввиду отсутствия адекватных инструментов и большого количества UB повсюду. И нет unsafe, который вообще говоря про инкапсуляцию штук, о которых компилятор, очевидно, не в курсе.
> Об этом мы поговорим когда вы сможете bring-up'нуть пару железок своим ходом, без "богов" за спиной.
Читаешь документацию по железке, пишешь код. Это то, что я могу пойти и сделать. Я безусловно не являюсь мировым специалистом в этой области, но embedded не rocket science. Ну или для меня так, может для тебя это какое-то богоподобное знание, не знаю даже.
> Я один из этих людей. Не то, чтоб я был каким-то особенным.
> Но это не чёрная магия, а просто идёшь и пишешь.Странно. Вы были не в курсе про "volatile", и с умным видом рассказали мне про оптимизер, хотя тот кто залез на ту ступеньку пантеона - должен бы знать.
Но если вы утвержжаете, окей, и как в хрусте аналог "volatile" делаете, послав оптимизер нафиг? В си то это просто: заводится например пачка typedов нужной битности, как volatile, указателями (адрес указателя указывает на регистр). Можно обернуть абстракциями, но фича в том что это thin shim над железом как раз. Он не пытается умничать, оптимизер послан нафиг volatile - и можно более-менее уповать что доступ будет именно такой.
Конечно иногда даже например фирма ARM играет на грани фола, скажем, делая typedef как (указатель на) struct, с содержимым struct равным внутренней структуре регистра, типа битовых полей. Однако сие все же работает. Хоть и несколько фривольный маневр (или точнее, дурной стандарт).
>> Это просто делается из си
> И так же просто это делается в rust.И, конечно, Вы покажете? Допустим, есть регистр железки, с адресом в памяти 0x100500, шириной 32 бита. В нем битовые поля (LSBit -> MSBit) 4, 8, 16, 3, 1 битов. Покажете как к нему форсировать доступ именно 32 бита (мало ли, шина не умеет иное, и другая ширина доступа UB или хардварное исключение)? А заодно поменять допустим вон те 3 бита? (Биты 29:27)
И поскольку вы о именно bringup вписались вещать - мы допустим что это микроконтроллер или типа того, урезанное окружение где чем меньше тем лучше и стандартной либы в привычном полном виде может и не быть. Так что нет богов на которых вы можете опереться. А вот расскажите как вы такое вообще разруливаете? Как выглядит порт на железку, какие абстракции/фичи вы будете (ре)имплементить, все такое.
>> но еще и инструкций описывающих что с данными делать
> Ты будто про zero-cost не слышал. И в отличии от C++, в
> Rust с этим всё в порядке.Си (а порой даже и C++ с классами) генерит код для, допустим, работы с GPIO - такой что его и вручную на асме лучше хрен напишешь. Ну, это из того что меня колыхало, там скорость важна.
Так что можно закатить знатный ногодрыг - вообще не парясь ассемблером, не в ущерб скорости. Да, порой придется посомтреть в дизасм этого чтобы понять как делать (не) надо. Но это довольно просто.
Хотя если мы про zero cost, я довел идею до абсолюта. Запускается DMA (да, его назначением может быть и GPIO порт воон там) - заряжается транзакция - и вот оно машет лапками как надо вообще без участия какого либо кода. А что, поговорим про косты codeless фичи? Оно так лапами машет - а поток команд проца шину собой не занимает, проц может чем-то еще заняться или поспать :)
>> Взять высокоуровневый ЯП чтобы ... костылить сие потом асмом
> Например превратить внутренний API некой GPU в Gl/Vulkan. 5% будет низкоуровщиной, остальное
> - абстракции, которые сильно проще делать на высокоуровневом языке.Это мы еще будем посмотреть что там - проще. Пока в основном много хайпа - и мало дела. Если это будет как с сервой, когда вот-вот-уже-почти-ой, уволили девов, ой, мозилла на грани кончины... ээ...
> Я не представляю это всё, я этим всем занимался. На Rust. При
> чём это было 7 лет назад. https://habr.com/ru/users/lain8dono/articles/Да, там неплохо расписано. То что в сях один долбаный кейворд - который к тому же в декларации typedef'а, так что мы его потом вообще не видим, в хрусте ээээээээвона какая убер-механика получилась, в цать раз больше писанины. И это типа в плюс зачислено? ORLY? :D
> То, чему ты меня пытаешься "научить", является для меня базовыми знаниями.
А как вы тогда про volatile не в курсах что задвигаете мне про оптимизатор? Вон то вообще довольно нубский перевод - какой-то стенфордской штуки. Это не вы на пантеон сходили, а чуваки из Стэнфорда. То что они так могут - я не сомневался.
> Rust неплохо подходит для разных вещей. Но embedded это та категория, в
> которой Rust проявляет себя лучше всего.
Мы можем записать 32-разрядное целое число без знака с адресом 0x12 в ячейку с адресом 0x34 примерно вот так:B.write_volatile(A.read_volatile());
(c) вы всами. Я б не сказал что это - "проявляет себя лучше всего".> некоторые (решаемые) подводные камни, но сейчас Rust является объективно лучшим языком
> для низкого уровня. По одной простой причине - он для этого
> и создавался в первую очередь.По нему это не очень заметно. Особенно судя по тому как ld от GCC для сборки МКшной фирмвари еще не так давно требовался.
Более того - мне уже интересно. Скажем как вы объясните borrow что вон то сейчас - юзается DMA движком, асинхронно относительно вот этого блока программы? Или в этом месте "all bets are off" и попробуй угадать - выстрелит оно в пятку или нет?
> На си. Ввиду отсутствия адекватных инструментов и большого количества UB повсюду. И
> нет unsafe, который вообще говоря про инкапсуляцию штук, о которых компилятор,
> очевидно, не в курсе.У си конечно есть дурацкости, но в фирмварях есть простое и радикальное средство: Keep it simple, stupid. А хруст с кучей черной магии, огромной stdlib'ой и постоянно перетряхиваемым тулчейном - он антипод этого подхода. И, имхо, за это воздаваться - будет.
И идея ставить ночнушку хруста - такое себе, опять же. Ибо в эмбедовке мы начинаем доверять компилеру ой как не сразу. А лишь сделав нехило тестов и проверив что все работает как и должно. Если же статейка начинается рассказом про rustup... эээ... ну значит вот этот горе эмбедер и завалидирует тулчейн на своей тушке. Правда, ресурсов хорошо тестануть ночнушку у него ессно не хватит - так что потестирует фирмварь, на пользаках. Отличная идея - если это все у конкурента будет :)
> Читаешь документацию по железке, пишешь код. Это то, что я могу пойти
> и сделать. Я безусловно не являюсь мировым специалистом в этой области,
> но embedded не rocket science. Ну или для меня так, может
> для тебя это какое-то богоподобное знание, не знаю даже.Я бутанул STM32 исключительно моим кодом. Даже startup - лично мой. Терь покажи как ты ЭТО для хруста вообще нарисуешь. Смогешь ему сам стартап написать энной платформе? :) Наверняка у него куда сложнее стартап и подготовка арены. И в целом - рантайм окружение наверное куда интрузивнее с таким набором фич. Сишка хорош тем что - не мешается под ногами.
В чем отличие от вас VS чуваки с беркелея? Я не уповал ни на каких чуваков из беркелея. Только на даташит, компилер в freestanding, без stdlibs и builtins, и - себя :). В проце только мой код. И более - ничего. Мне было просто интересно: могу ли я сам bring up энной железки по спекам.
> Вы были не в курсе про "volatile"Да. Лет 10 назад. Или я должен родиться с этим знанием? Мне попросту скучно обсуждать, как завязывать шнурки, мы не в детском саду.
> как в хрусте аналог "volatile" делаете
https://doc.rust-lang.org/std/?search=volatile
Внутри есть интринсики volatile_load/volatile_store и подобные. Они обычно используются не напрямую, а через методы read_volatile/write_volatile у сырых указателей. И используются они при написании обёрток над регистрами памяти. Оные превращают "записать биты туда, прочитать оттуда" в "провести такую-то операцию". Весь этот путь zero-cost по большей части. Опять же есть всякие макросы, которые облегчают это дело. И есть crates.io, где я эти обёртки могу для многих штук готовыми найти. Некоторые вендоры предоставляют машиночитаемую документацию, так что подобные штуки могут быть целиком сгенерены.
Случайные примеры:
https://docs.rs/stm32-eth/latest/stm32_eth/
https://docs.esp-rs.org/esp-hal/esp-hal/0.23.1/esp32/esp_hal/
https://docs.rs/avr-device/latest/avr_device/
https://docs.rs/cortex-m/latest/cortex_m/> как к нему форсировать доступ именно 32 бита
#[repr(C, align(4)]
struct AwesomeRegister(u32);Если у нас шина в 32 бита, то у нас есть ровно две операции: прочитать 32 бита, записать 32 бита. Если нет специальных инструкций конечно.
> с кучей черной магии
Читаешь документацию, перестаёшь верить в сверхестесвенное
> огромной stdlib'ой
std для юзерспейса. Ещё есть alloc и core. Ещё можно вообще без всего (no_core). Кстати кучу либ из crates.io можно использовать без std.
> Я бутанул STM32 исключительно моим кодом. Даже startup - лично мой.
Молодец. Обычно такие штуки делают в рамках обучения. Не могу ничего плохого сказать о таком и сам подобное делаю в разных контекстах. Однако использовать исключительно свой код не практично.
> Смогешь ему сам стартап написать энной платформе?
Да, смогу. Но делать это не буду ибо зачем оно мне.
> Наверняка у него куда сложнее стартап и подготовка арены
https://doc.rust-lang.org/core/index.html
https://doc.rust-lang.org/alloc/index.htmlНужно реализовать memcpy, memmove, memset, memcmp, bcmp, strlen и ещё парочку. После этого я получаю core. Затем (опционально) реализую аллокатор и получаю alloc. Если мне нужна арена, то я конечно могу сам написать, но могу готовую из crates.io подрубить.
Если речь о том, как инициализировать стек, FPU, MMU или что-то такое, то это всё зависит от платформы.
> В проце только мой код. И более - ничего. Мне было просто интересно: могу ли я сам bring up энной железки по спекам.
Ты не знаешь rust ибо задаёшь вопросы, ответы на которые можно найти в документации. Очевидно ты не можешь что-то пойти и сделать на расте, если ты его не знаешь. И, в отличии от C++, ты не можешь просто пойти и начать писать. Придётся учить целиком ибо и трейты и ФП и макросы и cargo и всё остальное используются везде. Высокий порог вхождения, который затем окупается.
Тортик может быть вкусным и невкусным. Но понять это можно только после дегустации.
> ФП в c++ есть. Насколько оно отвечает требованиям функцианальщиков не вкурсе... И
> спросить не у кого.Функция не является объектом (в терминологии Си++, а не "ООП"). Нельзя передать куда-то функцию, можно лишь ссылку (указатель) на неё. В частных случаях можно заменить функторами, но не всё. Поискать требования функциональщиков можно по "first-class citizen". Но тут вопрос больше в том, как такое вообще компилировать в машинный код.
Да очень понятный синтаксис ФП [](auto a, auto&& b){return a < b;};
>Но есть трейты, которые, в отличии от классов, вполне неплохо стыкуются с фишечками из ФПДавайте не смешивать в одну кучу разные понятия. ООП вполне себе может жить и в функциональном языке, как например во всём том же ocaml. Там и наследование будет, и виртуальные методы, и даже ограниченное приведение типов. Ничего из этого в rust - нет
>Там и наследование будет, и виртуальные методы, и даже ограниченное приведение типов. Ничего из этого в rust - нетНаследования нет. Остальное - есть.
> Если чего-то сделать нельзя - это не достоинство - это недостатокИз-за ремней и подушек безопасности при аварии нельзя разбить голову о торпеду или вылететь в лобовое стекло. Наличие в автомобиле ремней и подушек безопасности - это существенный недостаток.
> Из-за ремней и подушек безопасности при аварии нельзя разбить голову о торпеду
> или вылететь в лобовое стекло. Наличие в автомобиле ремней и подушек
> безопасности - это существенный недостаток.С другой стороны, если автомобиль упал в воду, это может сыграть с тобой злую шутку.
> С другой стороны, если автомобиль упал в воду, это может сыграть с тобой злую шутку.... и другие истории от знакомого кума свата))
Точно так же можно сказать "при падении в ремни спасли от разбития бошку и потери сознания, и позволили выбраться из авто"
Это я уже молчу про вероятность падения в воду в сравнении с обычным дтп.
>Рекомендую пойти и попробовать разные языкиДавайте хотя бы терминологию в программировании оставим в далеке от повестки
>Скажем, в JavaScript или Lua вариация ООПЭто не вариация ооп, это эмуляция ООП на прототипах и хештаблицах. И рано или поздно, случится протечка абстраций, и у ничего не подозревающего человека порвётся шаблон. В условной java нельзя взять и скопировать метод с одного объекта в другой, в js или lua это вполне себе пройдёт. В java у объекта всегда есть какой-то класс, в lua классов вообще нет, вопрос о том, к какому классу принадлежит объект попросту лишён смысла. Можно конечно это имитировать, но проблема в том, что это будет по прежнему имитация, которая отвалится на каком-то следующем шаге.
>На счёт ООП в rust рекомендую 18 главу учебника: https://doc.rust-lang.org/book/ch18-00-oop.htmlТак это не ООП, это со вкусом ООП
>Many competing definitions describe what OOP is, and by some of these definitions Rust is object-oriented, but by others it is notВ ООП есть виртуальные методы. Емнип в расте из-за мономорфизации во время компиляции никаких виртуальных методов не остаётся. Это уже не говоря про то, что виртуальные методы имеют смысл при наследовании, а наследование в расте тоже отсутствует.
> Давайте хотя бы терминологию в программировании оставим в далеке от повесткиКакая ещё повестка? Ты твитора обчитался или что ты несёшь вообще?
Есть ли где-то святой или целебный источник, который говорит, что только класс-ориентированные языки являются объектно-ориентированными языками? Кстати, забавный момент, есть язык, который использует одновременно и классы и прототипы: Tcl (но весь этот язык - одна большая шутка). Так-то к JS тоже вроде бы прикрутили классы. Впрочем всё, что происходит в вебе не смешно, а грустно.
https://en.wikipedia.org/wiki/Class-based_programming
https://en.wikipedia.org/wiki/Prototype-based_programming
https://en.wikipedia.org/wiki/Object-oriented_programming> И рано или поздно, случится протечка абстраций
Если брать Java, то конечно там сначала память протечёт. Принцип "всё объект" может иметь некоторые теоретические плюсы, однако так же имеет и вполне практические минусы.
> Емнип в расте из-за мономорфизации во время компиляции никаких виртуальных методов не остаётся.
Если нужна динамическая диспетчеризация, то она есть.
>Какая ещё повестка? Ты твитора обчитался или что ты несёшь вообще?Когда смысл слов начинает перекручиваться, типа положительной дискриминации
>Есть ли где-то святой или целебный источник, который говорит, что только класс-ориентированные языки являются объектно-ориентированными языками?Такими темпами у нас почти все языки становятся ооп, даже тот же хаскель, даже си. Разве что какие-то игрушечне языки останутся.
> Когда смысл слов начинает перекручиваться, типа положительной дискриминацииДумал, у нас специальная олимпиада. А сейчас это называют повесточкой. Интересно.
Спор об определениях бессмысленен. Мы используем термины для удобства общения. Если под терминами мы понимаем разное, то просто разговариваем на разных языках. Есть два способа решить эту проблему - взять любой внешний источник за точку отсчёта, либо перестать использовать термины, раскрыв их.В моём понимании ООП существует одновременно и как концепция не привязанная к языку и как набор свойств конкретного языка. Да, я могу использовать ООП в хаскеле и в си, нет они не являются ООП языками. Однако есть некоторое количество мультипарадигменых языков, в которых одновременно есть продвинутые инструменты для ООП, но при этом эта парадигма не является доминирующей. Это своего рода шкала, где 100% будет у языков, где нельзя сделать ничего без ООП в принципе, а 0% у языков где ООП применяется исключительно как концепция. Не обязательно набирать 100%, чтоб считать язык поддерживающим ООП. И это определённо не шкала лучше/хуже.
Прототипное ООП характерно для динамических языков. Имеет место быть как модель, конкурирующая с классами. Просто в силу малой применимости классов в динамических языках.
С моей точки зрения Rust имеет вполне достаточный инструментарий. Но это в первую очередь мультипарадигменный язык.
Как будто, C++ диктует, как писать. Да хоть в стиле C.
>Ruby фтопку, уж лучше PythonPython тоже фтопку. Уже куча репозиториев заражена python-ом, хотя он там не нужен совсем, и в отличии от rust-а это почти никого не возмущает.
А руби-то лучше на самом деле, там хотя бы отступов нет.
Потому что профессиональных, квалифицированных программистов знающих СИ, С++ становится всё меньше, а им на смену приходят вкатуны просле курсов, которые кроме Pyton не знаю ничего. Скоро всё будет на Pyton и тебе будут рассказывать что C++ не безопасен, а Pyton идеально подходит.
Потому что полно людей, для которых ЯП и программирование в целом вторичны по отношению к их основной специальности, всякие там млщики, математики и ученые. Им нецелесообразно разбираться какая там модель памяти в языке и как нужно классы отнаследовать, чтобы код был расширяемым. Лучше потратить время на развитие основных скиллов. Те же самые люди, которые напишут код на С вообще без отступов.Вот для них питон как раз хороший выбор и вкатывание ни при чем.
>Потому что профессиональных, квалифицированных программистов знающих СИ, С++ становится всё меньшеВот как раз такие проекты и подвержены заражению питоном. Взять тот же vim - зачем ему питон? Или apparmor? Да что там, даже uBlock зачем-то заразился питоном, хотя у них уже есть js, могли бы и без питона обойтись.
>и тебе будут рассказывать что C++ не безопасенДа, кресты небезопасны. Это неоспоримый факт, как бы вы к этому не относились
Это еще что! Тут вот набИгают неспособные название - название, Карл! языка программирования выучить...
Стесняюсь спросить. А знатоки Джаваскрипт - это какая категория людей по вашей классификации? На всякий случай. Там есть скобочки, и отступы не обязательны.
Вы ещё скажите, что ООП не в Haskell
Ну так, ведь, поэтому и прелагается сделают в настоящем языке.
> Дидов корёжит и это хорошо.Судя по таким комментариям - корежит только их авторов.
>Профили близки к применению флагов "-Wall" и "-Wextra" при компиляции, но в отличие от них работают на уровне запрета применения определённых возможностей языкаВообще, конечно, C++ уникальный язык. Нигде больше, насколько мне известно, нет настолько выраженной ситуации, когда новые или мощные средства языка были бы проблемой на проектах, и требовали дисциплины от разработчика. И вот то, что всегда было зафиксировано в кодстилях команд, теперь в каком-то виде появляется официально в языке...
> в кодстилях командТочнее "в костылях команд". Увы, при нынешнем состоянии языка это костыли.
> Нигде больше, насколько мне известно, нет настолько выраженной ситуации, когда новые или мощные средства языка были бы проблемой на проектах, и требовали дисциплины от разработчика.perl
А что случилось? Ведь нормально же всё было. Что ни день, так новое CVE из-за неправильной работы с памятью. Где теперь хакеры харчеваться будут?
> А что случилось?Тебе де сказали - требование оборонки.
Если что самолеты сделанные по требованиям оборонки никчему отстой, потому что изначально требования взяты с потолка.
А ребята с той оборонки (?), что эти требования сформулировали (под определённую часть цифровиков), свои стулья сохранили в нынешней обстановке?
> А ребята с той оборонки (?), что эти требования сформулировали (под определённую
> часть цифровиков), свои стулья сохранили в нынешней обстановке?Думаешь придут новые и скажут "а давайте писать как диды, ну чтобы китайские и корейские хакеры нас ломали полностью!"
Хотя учитывая какой там сейчас сброд, то не удивлюсь)
> "а давайте писать как диды, ну чтобы китайские и корейские хакеры нас ломали полностью!"Я придерживаюсь мнения, что новые веяния направлены на одновременное упрощение/унификацию внедрения и точное тагетирование объекта атаки. Это экономически целесообразнее, да и требует куда меньшей квалификации от атакующих. При современных реалиях разработки, естественно.
Я, может, чего недопонял, но звучит примерно как. "Не ставьте замки на двери, а решетки на окна, ведь лазить через печную трубу требует куда меньшей квалификации. При современных реалиях домушничества."
>> "а давайте писать как диды, ну чтобы китайские и корейские хакеры нас ломали полностью!"
> Я придерживаюсь мнения, что новые веяния направлены на одновременное упрощение/унификацию
> внедрения и точное тагетирование объекта атаки. Это экономически целесообразнее, да и
> требует куда меньшей квалификации от атакующих. При современных реалиях разработки, естественно.Сейчас БПЛА уже с нейронками летают, могут игнорировать РЭБ, принимать решения при потере сигнала, даже иногда "понять", что ему сбили геолокацию, при этом храня команды маршрута. Всё это добро пишется сегодня в РФ на C++. Следующий шаг (который уже есть), это полностью автономные модули, где реакции на любые ситуативные решения принимает нейронка, удачи взломать систему, которая вообще не принимает управляющие команды оператора. Концепция самолётов кстати уже устарела. Весь этот выпендрёж с самолётами 5-го поколения, бубубу, оказался мусором, очень дорогим мусором...
>свои стулья сохранили в нынешней обстановке?Да,сохранили,в принципе нормально там с стандартами.Язык недавно обновлялся,но криков в отличие от раста нету.До сих пор в обороне и авиации применяется,даже у нас !!!Язык Ада называется .
Так Ады в том списке кошерных языков не было, если я правильно помню. ;)
> Так Ады в том списке кошерных языков не было, если я правильно
> помню. ;)А SPARK включен ? Ада совместимое подмножество, язык, прошедший верификацию и как у раста проверка во время компиляции :-)
Раньше требовали всё писать на Аде. Но её уже никто не учит. Поэтому для F-35 пришлось нанимать программистов на C++. Язык не столь безопасный, зато программистов много. За четверть века спустя нормально отладить хотя бы до уровня F-22 так и не смогли. Поэтому стали требовать писать безопасно. Тем более, С++ уже мало кто учит, можно будет всё переписать на Расте :)
> Где теперь хакеры харчеваться будут?Возьмутся наконец за раст, увидишь тогда, что нет CVE:)
Кто забегал? Страуструп просто рассказал широким массам неосиляторов то, что разработчики C++ знают и используют уже давно. В любой компании, если она не средневековая шарага уже давно используются гайдлайны и языковые инструменты для безопасной работы с памятью для бизнеса. Сырые указатели плюсовики если и используют, то в домашних проектах просто для того чтобы поковыряться с байтами. Rust-сообщество же считает что они открыли священный грааль рекламируя то, что уже было в плюсах под другим соусом. И разница в том, что C++ предоставляет программисту ВЫБОР в каком стиле писать и какой уровень предупреждений вызывать в "опасных" ситуациях, в Rust программист - это послушная обезьянка.
Какой ужасный синтаксис теперь в С++, код с вариадиками, обвешанный if constexpr, макросами, концептами и теперь уже профилями совершенно не читаем.
Вопрос привычки. Раст слишком уж инородный, чтобы найти применение в большинстве областей.
Лол, не выдумывай. Даже фронтендерам раст больше понравился, чем С++. Единственные, кто противится это сишники и прочие деды.
конечно, ведь не фронтендерам на нём писать. покажи им брайнфак, им ещё больше понравится
Интересное кино. Плюсы с костылями - вопрос привычки, а руст значит вопрос инородности. Афигеть манёвры))
Обычная зог брехливость, он вобще потому навернака питонщик максмум и-за его тормозизма вынужденный пользоваться растом как чуть менее тормозным, но тоже не идеал даже без тестирования вияния защиты памяти и прочего.А, в статье предложения частью - сами трешь...
Как и С++ совремнные стандарты местами, и т.б.либы. Даже вот это "std::" что как не трэш............
Стандарт надо откатить к 89/93 а то и с нуля(я бы помог, т.к.много такое продумал уже, но оставаясь в стиле програмирвания оригинала, Сей, даже не С++ с их подменами вроде cin/cout/... которые сами используют операторы вроде << - некорретно же) и заново пересмотреть все нововедения стандартов, в т.ч.и с эстетической стороны как в примере. Если бы так сделали я бы ещё 100-500-5000 улушений С++ накидал бы, т.к.у самого тупо нет времени на програмирвание, в т.ч.часто нужных для доп.оптимизаций. Но, этого понятно не сделают :[
Пример бы такого кода на плюсах и аналог на расте для наглядности еще
Нет, нельзя допускать сравнения, иначе станет понятно, что проще нанять хороших программистов, чем все переписать на Раст.
Ещё бы у плюсов документация по этим фичам существовалаЯ не понял это предложенный синтаксис или реализованный, однако
template<class T>
class slice_iterator/(a)
{
T* unsafe p_;
T* end_;
T^/a __phantom_data;public:
slice_iterator([T; dyn]^/a s) noexcept safe
: p_((*s)~as_pointer), unsafe end_((*s)~as_pointer + (*s)~length) { }optional<T^/a> next(self^) noexcept safe {
if (self->p_ == self->end_) { return .none; }
return .some(^*self->p_++);
}
};vs (дословный перевод, код на Rust так не пишут)
struct SliceIterator<'a, T> {
p: *const T,
end: *const T,
_marker: PhantomData<&'a T>
}
impl<'a, T> SliceIterator<'a, T> {
fn new(s: &'a [T]) -> Self {
let p = s.as_ptr();
Self {
p,
// SAFETY: offsetted pointer is derived from the same allocation
end: unsafe { p.add(s.len()) },
_marker: PhantomData,
}
}
fn next(&mut self) -> Option<&'a T> {
if self.p == self.end {
return None;
}
// SAFETY: pointer is in bounds
let result = unsafe { &*self.p };
// SAFETY: offsetted pointer is derived from the same allocation
self.p = unsafe { self.p.add(1) };
Some(result)
}
}Примечательно что в плюсах арифметика указателей тут судя по стандарту никак не проверяется, однако никаких unsafe они не требуют. Если бы в Rust тоже вместо unsafe был safe, то код бы превратился в...
impl<'a, T> SliceIterator<'a, T> {
safe fn new(s: &'a [T]) -> Self {
let p = s.as_ptr();
Self {
p,
end: p.add(s.len()),
_marker: PhantomData,
}
}
safe fn next(&mut self) -> Option<&'a T> {
if self.p == self.end {
return None;
}
let result = &*self.p;
self.p = self.p.add(1);
Some(result)
}
}Also Rust не требует везде ставить аннотации лайфтаймов, много где он сам может их расставить, '_ - implied lifetime
impl<T> SliceIterator<'_, T> {
safe fn new(s: &[T]) -> Self {
let p = s.as_ptr();
Self {
p,
end: p.add(s.len()),
_marker: PhantomData,
}
}
safe fn next(&mut self) -> Option<&T> {
if self.p == self.end {
return None;
}
let result = &*self.p;
self.p = self.p.add(1);
Some(result)
}
}
Ключевого слова safe в Rust нет, это я добавил чтобы сравнению не мешали unsafe{} и комментарии которыми принято unsafe{} сопровождать
У плюсов всегда был ужасный синтаксис, но не хуже раста то уж точно
Проблема синтаксиса плюсов в том (в отличие от раста) — а давайте-ка мы при…ним вот что-то ещё!
У раста этой проблемы нет, мы сразу при…ли что-то ещё.
У него будет тоже самое через несколько десятилетий развития... (если они будут вообще, конечно)
> Какой ужасный синтаксис теперь в С++, код с вариадиками, обвешанный if constexpr, макросами, концептами и теперь уже профилями совершенно не читаем.Типичное мнение неосилятора. Классы с вариадиками создаются в реальных проектах крайне редко. Макросы - вообще сишничество, в С++ придумали константы и inline функции, именно чтоб не использовать макросы, и придумали очень давно. Насколько старая твоя методичка? Концепты создали для лучшей читаемости сообщений об ошибках. Но неосиляторам не угодить. И без концептов и плохо, и с ними плохо.
Анука накидай нам тут кросплатформенного когда без макросов, например для последовательного порта на чистом С++ без указателей. Ассилятор ты наш.
Анукать лошади своей будешь. По остальным пунктам возражений, стало быть, нет?
Цена кроссплатформенности в GCC, скули не скули. В DOS и т.б.Windows компиляторах тако проблемы меньше за отсутвие идеалогически надобности в совместимости с иным чем, хоть желающие могут в 16/32/64, с минимумом макросов, так что всё под задачу.Вообще же, макросы в Си требует даже расширения, хоть до уровня Ассемблера, что порой одна из причин его использования (оч.редко но, когда надо деваться некуда).
Боюсь, что и без "вариадиков" в С++ делать нечего - ужасный крючкотворный синтаксис, следствие "надстройки" ООП над обычным "высокоуровневым ассемблером". Чудес не бывает: если язык сразу не проектировался под все свои возможности, добавление "фич" потом порождает таких монстров, как С++.Я бы двигался в сторону Ди - тоже непростой язык, но хотя бы большинство кода выглядит адекватно.
> Боюсь, что и без "вариадиков" в С++ делать нечего - ужасный крючкотворный
> синтаксис, следствие "надстройки" ООП над обычным "высокоуровневым ассемблером". Чудес
> не бывает: если язык сразу не проектировался под все свои возможности,
> добавление "фич" потом порождает таких монстров, как С++.Ничего подобного. Си с классами в плане читабельности - вполне себе торт.
Современные фичастые навороты в модном мейнстриме - это конечно беда.
Но вы сами в праве выбрать стиль программирования на Си++.
Я выбрал простой стиль и код у меня читаем практически как на питоне/php (или даже лучше).
>Но вы сами в праве выбрать стиль программирования на Си++.В этом и заключается основная проблема. Вы для себя выбрали такой стиль. Но ваш выбор может оказаться совершенно неочевидным для другого человека. И он будет писать по-другому. В итоге, если ваши разные стили встретятся в одном проекте - быть беде.
>>Но вы сами в праве выбрать стиль программирования на Си++.
> В этом и заключается основная проблема. Вы для себя выбрали такой стиль.
> Но ваш выбор может оказаться совершенно неочевидным для другого человека. И
> он будет писать по-другому. В итоге, если ваши разные стили встретятся
> в одном проекте - быть беде.Едва ли. В том то и дело, что в простом стиле не запутаешься.
Беда будет у любителей писать на брейнфаках без комментов. Они сами через год забывают что понаписывали.
>Едва ли. В том то и дело, что в простом стиле не запутаешься.А кто вам сказал, что у другого человека будет простой стиль? Далее, если два простых стиля содержат разные подмножества фич, то запутаться - проще простого, даже при кажущейся простоте стилей.
Ну так наговнокодить на любом языке можно, для этого используются стандарты в крупных проектах
И самое паршивое что, говно-кондинг - это уже какой то тренд, от безказанности всем причастным.Т.к.
1) хочется подешевле (т.б.кога деньги есть жутко смотрится) - значит с меньшей квалификацией и опытом в конкретной [суб]сфере...
2) надо же и родственничкм пристраивать - с типично неважной даже днищенской квалификацией
(вот у меня например у одного мобильного/Internet-оператора - с десяток отослал Issues, другому - даже ещё больше, настолько что в одном только "SMS" меню смены режима работы тарифа - десяток багов! включая активаюцию не того что, надо режима... (и вообще его там выясниось что неудастя активировать только через оператора) притом в "SMS" о числе оставшихся гигабат - ни факт актвиации этого ни доп.гигабайты также багово никак не отражон...И ведь всё это всё делается - на этих ваших безопасных языках, так что идите как вы обсиратели Сей!
Безопасность кода и вообще безбажность - только там где она нужна сверху и обратное наказуемо им и ниже - законом
(хоть по закону по потребителях, и без ожидания обращения от пострадавших - а, автоматически прверяя и с сертификацией хоть на минимальную пригодность после анализа кода и тестов).
И в довершение последней мысли про наказуемость - самое ужасное: ни один баг у них, включая жутко позорные вроде указанных, за уже пол года, - так и не был исправлен. Даже не не смотря на дискредитацию ими сами компаний!
Rust с его ручным разрешением времени жизни и штрихи ' в коде - вот это читаемость. Причём в сложном коде вопрос о том скомпилируется у вас код или нет может зависеть от одного штриха. Одна эта семантическая особенность - полный треш. Также Rust берёт ХУДШИЕ примеры синтаксиса, и не понятно нафига!? Мало что-ли в крестах угловых скобок < >? давайте сделаем! Ведь все так кайфуют и в C++ и в C#. То есть Rust обладает одновременно уродливой, непродуманной семантикой, при этом дополняя это уродливым синтаксисом, который ещё и писать проще, чем читать. А в сложных ситуациях вы даже не сможете нормально (читаемо) его отрефакторить, т.к. вам ещё и компилятор нужно удовлетворять.
>То есть Rust обладает одновременно уродливой, непродуманной семантикойИз вашего сообщения непонятно, в чем конкретно это выражается, поэтому звучит голословно. Не могли бы вы расшифровать своё утверждение?
>при этом дополняя это уродливым синтаксисом
Синтаксис - вкусовщина и/или дело привычки. Мне вот этот синтаксис нравится своей лаконичностью. Да, поначалу, с непривычки, бывает тяжело что-то распарсить. Потом, с опытом, начинаешь понимать, насколько на самом деле он красив по-своему. Местами не без проблем, понятное дело. Но по большей части - вполне годный. Также авторы постоянно его улучшают, убирая излишние сложности.
> Каждый объект должен быть корректно создан и освобождён.Ну надо же!
Я думал что это должно быть по умолчанию для любой программы для с++.
Ну, чтобы она работала правильно хотя бы в этом контексте.
А тут оказывается для этого нужен отдельный профиль!Ну а если профиль не включен, то можно создавать и освобождать объекты не корректно?
Как диды раньше?))
Прямо как программисты на Typescript. Вроде бы классы и красивая типизация, а в обертках код на жиэс, где на все эти типы кладется. Без кода на жиэс ничего работать не будет. И убрать его слишком долго/дорого.
Typescript давным давно можно было бы заменить любым вариантом: Ocaml, ReasonML, ReScript. Если особо хочется, то можно было бы взять даже Haskell или PureScript.
>Вроде бы классы и красивая типизацияЭта типизация прекрасно обходится даже без кода на js. Во-первых тип Any, во-вторых, если писать на ts как будь-то это динамически типизированный язык, то никаких ошибок компиляции не будет
>Без кода на жиэс ничего работать не будет. И убрать его слишком долго/дорого.Начать бы с того, чтобы этот код был бы только под копотом и только в нескольких часятх приложения, а не буквально везде
> Typescript давным давно можно было бы заменить любым вариантом: Ocaml, ReasonML, ReScript. Если особо хочется, то можно было бы взять даже Haskell или PureScript.Только не заменяется никак. В чем проблема?
Опять диды виноваты. Ой, то есть эти, как их там, а, да, сму3ихлёбы, да, они. Нормальным языкам к0пр0тивляются, ибо думать придётся.
> Прямо как программисты на Typescript. Вроде бы классы и красивая типизация, а
> в обертках код на жиэс, где на все эти типы кладется.
> Без кода на жиэс ничего работать не будет. И убрать его
> слишком долго/дорого.Что значит "обёртки" и "убрать"? Typescript - изначально надстройка над яваскриптом, в который он и транспилируется. Ляпнуть такое это всё равно что сказать, что любой язык - фуфло, потому что все эти классы, функторы это обёртки над ассемблером который поклал на классы и функции, а убрать его долго и дорого.
> Ну а если профиль не включенТо ты можешь прибить все что нужно туда куда нужно.
В С++ полно библиотек, предполагающих, что объект создается в пользовательском коде, а временем его жизни и освобождением памяти занимается библиотека. И компилятор от этой библиотеки видит только заголовки, так что проконтролировать не может ничего в принципе.
И как это изменят профили?
Профили предлагают использовать std::unique_ptr и std::shared_ptr, которые определяют время жизни (да, есть способы обхода, например в `std::unique_ptr::release()`, но может их в профилях запретят).
Библиотеки, видимо, должны будут принимать только умные указатели.
"Вы зачем код с багами пишете? Пишите код без багов!"
— Бьорн Страуструп, автор 14 разных методов инициализации в C++дед опять выдает базу, абсолютно базированную и абсолютно бесполезную))
Зачем вам топоры, пилы, струганки, наждачка, долота, гвозди и клей? Все надо делать одним топором!(с) очередной неосилятор с++ на опеннете.
Это ты так про Бьорна?
Не надо, чел сделал большую работу. И заслуживают уважение.
Да она получилась кривоватая, но... он сами в интервью рассказывал, что не является спецом по созданию языков.
Собственно так и изобрели мультитул
Мультитулы прекрасны. Они сочетают в себе двух до двух десятков различных инструментов. Есть только пара нюансов.
- они никогда не заменяю ни один инструмент,
- они в сумме используются реже, чем КАЖДЫЙ из инструментов, который они как бы заменяют.
ты это серьезно?топоры, пилы, струганки, наждачка, долота, гвозди и клей для одной задачи - инициализация? кучей разных способов?
учитывая, что это база, точно не надо к набору из "топоры, пилы, струганки, наждачка, долота, гвозди и клей" добавить специализированный инструмент "инициализатор", который будет заниматься, внезапно, инициализированием, и только им одним, единообразно и прозрачно?
> ты это серьезно?Уверен на 99%, что да.
> топоры, пилы, струганки, наждачка, долота, гвозди и клей для одной задачи
Да.
Именно так.
Хороший программист старой закалки, сможет пилить с помощью долота, стругать гвоздем, а гвозди каждый топором вырубать.
Можно посмотреть на ядро (СИ) или на гемдев (С++)
Потому что по канону прорамма должна быть полна костылей, велосипедов и, главное, неочевижных моментов.
Это обестпечивает незаменимость работника и сложность в его увольнении.
если задача огреть по голове, то любое справится
А почему у вас эта логика _внезапно_ кончается, когда вам предлагаешь несколько ЯП использовать? Начинается - уой, сложна, слишкам многа инструментов.
> А почему у вас эта логика _внезапно_ кончается, когда вам предлагаешь несколько ЯП использовать?Потому что это другое™! Это понимать надо™! Ты бы ещё спросил, почему некоторые из лицензии или текстового редактора делают фетиш.
Наверное потому что в качестве мультитула идет c++.А несколько языков - это не мультитул, а несколько инструментов. То же хорошо. Но не настолько.
> Зачем вам топоры, пилы, струганки, наждачка, долота, гвозди и клей? Все надо делать одним топором^W болгаркой.Вот так правильнее.
Дурацкая аналогия от тynых зумеров.Если уж говорить про С++, то речь идёт о 10 видах молотков/киянок/топоров, которыми делается ОДНО И ТО ЖЕ - забивается гвоздь. Вот про такую чехарду инструментов рассуждать даже не хочется - Страус сам виноват, что ниструя не стандартизировал десятилетиями, а затем хватается за "безопасную память".
Новичок вообще не должен париться, сколько там напридумано фуфла для указателей. Под указатели должен быть ОДИН стандартный инструмент, а все остальные преданы анафеме. Пока это не сделано, можете С++ смело хоронить.
> можете С++ смело хоронитьC++ еще простудится на похоронах rust'а
Вообще говоря у C++ сегодня дела ЛУЧШЕ, чем ДО выхода C++11. Тогда был период, когда C++ как раз начал проседать. C++11 дал существенное развитие во множестве сфер. Подарил фактически многопоточность из коробки и инструменты для работы ней, систематизировал и ускорил параметрический полиморфизм. Сегодня же, кто бы что не говорил, на C++ пишется огромное количество нового кода.
Уместно спросить - может надо было сразу делать отдельный язык, а не надстройку, которая за сорок лет так и не смогла Embrace и Extinguish?
Пора плюсам на свалку истории. Кто работает и не может перестроиться - никакой жалости, валите на пенсию.
Не забывайте, что все актуальные компиляторы Си написаны на C++. GCC был сначала на Си, но потом перешёл на C++.Компилятор Си на Си -- это разве что примитивный TCC, не умеющий оптимизации.
> Не забывайте, что все актуальные компиляторы Си написаны на C++.актуальный как раз не на С++
Да, выкинуть 40 с гаком лет написания кода и начать всё с нуля, такая прелесть.
> Да, выкинуть 40 с гаком лет написания кодаДелаются биндинги, новый код пишется на нормальном ЯП.
> и начать всё с нуля
Ага.
Иногда так приходится делать.
Например при переходе от повозок к автомобилям.
Какие бы ни были лошадки милые - кушают сахар, фыркают и пахнут навозом, но их потолок был ограничен.> такая прелесть.
Что поделаешь. Прогресс не остановить, можно только замедлить суванием палкок в колеса.
От сухой каменной кладки тоже отказались, хотя ей тысячи лет и пирамиды так построили.
Но сейчас по какой-то причине сталь и бетон.
Одна проблема, когда вместо лошадки пробуют заставить впрячь в повозку слизня, ибо на нем ехать безопасно, как-то мало ассоциируется с прогрессом
> вместо лошадки пробуют заставить впрячь в повозку слизняПлохая аналогия подобна котенку с дверцей (с)
Вон недавно раст-либа обогнала по скорости СИшную - у дидов предсказуемо подгорело)
По скорости раст сравним с си или плюсами. В интернетах есть куча бенчмарков где люди меряются.
И да, то кто вместо безопасности выбирает скорость, остается и без первого и без второго.
> По скорости раст сравним с си или плюсами.Вот только на си и плюсах пишут полноценные проекты.
А на rust уже почти допереписывали и планируют догнать по паритету функциональности к...
>Вот только на си и плюсах пишут полноценные проекты.Новые проекты пишут на Rust. И они вполне себе полноценные.
>и планируют догнать по паритету функциональности
Некоторые обгоняют. Например, прокси от Клаудфлэр. Или ripgrep.
Толсто. Запомни, сишку может обогнать только ассемблер.
Я бы не стал запоминать эту чушь. На любом языке можно наваять какаху.
> Вон недавно раст-либа обогнала по скорости СИшнуюТы про попытку замены для zlib? Которая быстрая потому, что в ней отсутствует большая часть планируемого функционала?
>Что поделаешь. Прогресс не остановить, можно только замедлить суванием палкок в колеса.Прогресс, ага, про GNOME тоже самое твердят.
>Какие бы ни были лошадки милые - кушают сахар, фыркают и пахнут навозом, но их потолок был ограничен.Только кучеры в то время орали, что на ваших убогих автомобилях ни по одной колее не проедешь и вообще какое-то непонятное колесо вместо интуитивно понятных вожжей.
На ту "свалку истории" изрядная очередь.
Перед Плюсами туда давно отправлен, например, Пых - ужасный, неконсистентный, несколько раз переделанный... и продолжающий работать на 75% сайтов интернета, например.
То что у нас есть уже 100500 написанных это одно.
А сколько новых сайтов пишутся на пыхе? Это другое)Всегда новая технология будет соседствовать со старой.
Например дома из "глины, овна и палок" стоили тысячелетиями.
Потом пошел нормальный кирпич.
А сейчас рядом с ним есть и железобетон, и пенобетон + ЖБ плиты, и всякие пустотелые керамики.
Но куча домов по старой технологии будет стоять ровно столько, пока не развалятся или их не снесут.
> А сколько новых сайтов пишутся на пыхе?Да столько же, ЧСХ. Ни одного альтернативного варианта, который позволит дешевле создать сравнимый результат, для массового сайта просто нет.
Прогресс происходит отнюдь не в выпиливании Пыха и переползании на смузи-Ноду, например.
А в более четком разделении фронта и бэка и передаче первому все больше работы. Причем не потому, что Пых плохой, а потому, что браузеры нынче стали достаточно жирными и достаточно стандартными, чтобы владелец сайта мог меньше тратить на сервер, свалив нагрузку на клиентов.
Не только деление на фронт и бек, но и деление бека на экземпляры и модули, которые можно безопасно подменять, чтобы можно было по частям переписать с одного языка на другой, не останавливая сервис.Но проблема больше в мотивации и в кадрах, потому что если у вас куча пхпшников, то они не все захотят переучиваться, да и менеджеры не захотят вкладывать деньги в модернизацию. А раз так, то и потребность в пхпшниках остаётся и они дальше будут плодиться, что не есть хорошо.
> экземпляры и модули, которые можно безопасно подменять, чтобы можно было по частям переписать с одного языка на другой, не останавливая сервис.Код, разумеется, делится на модули, чтобы его можно было безболезненно поддерживать.
А завиральные идеи еще на чем-нибудь переписать то, что по большей части является просто прослойкой между фронтом и базой - это скорее к нодерам, гошникам и прочей публике, которой просто скучно просто работать.
Ошибочное представление. PHP всё ещё медленный, и многие задачи хочется переписать на более вменяемых языках, более быстрых и приспособленных к вычислениям. Кроме того, размещение в облаках способствует разделению на микросервисы. А те в свою очередь удобнее писать на более быстрых языках.
Для практических задач, которые встают перед реальными сайтами, "медленность пыха" в 99% случаев обусловлена дичью в SQL.
Если сайту требуются мощные вычисления - их в принципе нет смысла делать в коде сайта, логичнее оставить его мордой к соответствующему сервису. На пыхе никто и не пишет биржи или игрушки. Если вам приходится с него что-то "переписывать" - вы просто неудачно выбрали инструмент с самого начала.
>Но проблема больше в мотивации и в кадрах, потому что если у вас куча пхпшников, то они не все захотят переучиватьсяЗачем? Вы хоть десять фронтендов, хоть сто сделайте, без бекенда это работать всё равно не будет
Технологии понемногу меняются. Если двадцать лет назад Пых выдавал на фронт готовую верстку, то сейчас реактивным фреймворкам бэк нужен только как API = CRUD + та бизнес-логика, которую нельзя доверить браузеру + чисто серверные дела. Работы на бэке все-таки поуменьшилось.
> если у вас куча пхпшников...То у вас считай "куча вымирающих динозавров". :))
Когда вам надоест кормить эту ораву, вы выкинете их на мороз и наймёте одного ASP-шника, который всё сделает по-уму.Плюс, рынок и перспективы: кто умеет смотреть дальше собственных ботинок, тот видит - в похапэхе ничего нет, это технология "неосиляторов перла" для хоумпэйджей девственниц. И если будут начинать новый проект, зачем им ОПЯТЬ заводить тесто на старых дрожжах? Позовут бравую команду ASP-шников и те всё напишут по современным стандартам.
Люди не дураки, их "обилием похапэ страниц" не купить. Умный инженер смотрит в будущее, а не оглядывается на прошлые заслуги.
> > А сколько новых сайтов пишутся на пыхе?
> Ни одного альтернативного варианта, который позволит дешевле создать сравнимый результатЕрунду пишете, милейший! Во-первых, про "дешевле" речи не идёт - на ЛЮБОЙ язык есть свои погроми3ды в соотв. категории оплаты. А во-вторых, опять же - если речь про "лэндинг", который "напишут и выбросят" - там хоть на Рефале пиши! (или похапэхе) Но если тебя хоть как-то интересует будущее сайта (включая его РАЗВИТИЕ), ты выберешь нормальный язык, на котором пишут много профи. Например, C#(ASP.NET) или Kotlin. Да даже JSP будет куда адекватнее похапэшных Bыceрoв!
Кто хочет "быстро и задёшево", потом получает трёхкратный по стоимости пендель. Бесплатных чудес не бывает!
А теперь посмотрите на статистику про стабильные 75% снова. Без радуг и единорогов.
Заодно вспомнив, сколько на пыхе готовых решений, вообще не требующих "программиздов", и заготовок, кратно упрощающих работу над сайтом, если он нестандартен, но все равно - это сайт, так что нестандартен он на 20%, а остальные 80% все равно можно брать-приспособить из готового.
Вот примерно так и оказывается, что программистов можно найти каких угодно, а ценник на них выходит - разный.
+1, очень точная аналогия! То, что есть кучи программ на вымерших языках, не делает языки живее. Просто придёт очередной менеджер, спросит: это Г кто-нть может поддерживать? Нет? Переписываем!
Ровно наоборот - Страус был ОЧЕНЬ ГОРД(!), что смог над своим ассемблером прикрутить на изоленте ООП! Мол, смотрите какая мощща! :)))) Этот дypа4ок не понял главного: людям не нужны "трюки", делающие из молотка плоскогубцы - людям нужны чистые, простые инструменты. А когда он это понял, то было уже поздно - синтаксис и так превратился в полный Перл!С++ и так по факту "история"; зомбак, бродящий по закоулкам ИТ и на который с сожалением смотрят живые. Старики - те уже точно не осилят переход с каких-нть C# на С++. Молодые - те вообще шарахаются от сипиписного синтаксиса! Так что как с коболом - пока не вымрет последний кобольщик, это гуано будут терпеть, а потом всё равно перепишут на пестоне :))
>Этот дypа4ок...Очень самоуверенное заявление.
>людям нужны чистые, простые инструменты
Расскажите это создателям компиляторов, или браузеров, или игровых движков.
В остальном, в принципе, согласен. C++ - сверхсложный ЯП. Уверен, никто его полностью не знает. Или таких очень и очень мало.
Вам не нужно знать полностью C++, за вас его знает стандарт. Чистый код, соответствующий стандарту имеет монументальную обратную совместимость (нюансы её нарушения потребуется искать целенаправленно), особенность лишь в том, что в некоторых особо важных для конкретной задачи вещах иногда используют непереносимые кастомные фишки компилятора или окружения, что для большинства разработчиков не актуально, а для тех кому актуально УЖЕ знают этот аспект своей работы. Большинству разработчиков хватит и "типового" использования инструментов языка, скажем у r-value ссылок может быть немало "хаков", но большинство используют их лишь типовом контексте move-семантики и даже не вдаются в глубокие подробности, но вы МОЖЕТЕ изучить вопрос, если это интересно или важно и это довольно легко, т.к. есть и стандарт и смежная литература по любой теме.
На самом деле и UB в C++ - это тема плохо понимаемая теми, кто с C++ не работает и не понимает его философию.
>Вам не нужно знать полностью C++, за вас его знает стандарт.Так это стандарт за меня программы будет писать и сопровождать? Простите, но вы здесь откровенную глупость сморозили.
> По мнению Страуструпа, времени осталось очень мало и необходимо до 2026 года успеть предпринять какие-то мерыНе успеют, а если и родят что-либо, то это опять будет нечто монструозное, тянущее за собой половину буста и c сопроводительными доками чуть меньше "Войны и Мира" Толстого.
Не смеши публику. Большинство из указанного включается с помощью опций -Werror у gcc или clang.
> Не смеши публику. Большинство из указанного включается с помощью опций -Werror у gcc или clang.Осталось рассказать это Страуструпу, а то он не в курсе поди.
Проблема не в выявлении подобных мест. Это, очевидно, хотели сказать.Проблема только в том, что бы договориться разным разработчикам, как ОДИНАКОВО включать и выключать эти фильтры доступности функциональности для разных артефактов программы.
> Большинство из указанного включается с помощью опций -Werror у gcc или clang.Как я понял, профиля позволяют включать не всё сразу, а только желаемые части перечисленного. Так удобнее.
Страуструп - топовый тролль, конечно. Глумится и не скрывает этого.
В смысле, что комитету следует успеть до конца года? :)
Не только. Это полумеры все. Будет чуть лучше и чуть тормознее и больше похоже на Java.Если все запретит и код все равно тотально переписывать - то не проще ли сделать все то же самое, только на языке, который уже есть? Точно так же, постепенно.
Или он думает, что те, кто не смогли в Rust, смогут проделать все то, что он написал? В любом случае придется корежить свои привычки.
Ты или тролишь или не понимаешь о чем речь.А речь о добавлении системы настройки включения и выключения функциональности для разных артефактов кода программы.
То есть программа без таких настроек имеет доступ ко всей функциональности и, соответственно, компилируется.
Добавляешь артефакту программы ограничивающую настройку и переписываешь его. Все остальное не трогая.
В этом варианте программа ВСЕГДА готова к использованию в процессе такого рефакторинга.
Я "не смог" (не нашёл причин и целей) в Rust, но смог проделать описанное в стандарте. В чём проблема? Вполне проработанное ТЗ, если воспринимать его так.
Блин, да ежу же понятно, что вопрос не технический, а денежный. Всё всегда туда упирается. Дед засуетился только когда госуха стала запрещать использовать кресты. Рассказать почему?)
На java ? Чем ? В основе java сидит ВМ, именно из-за которой джава такая какая она есть, а в случае плюсов предлагается просто возможность перекидывания вопроса фильтра возможностей с разработчика на компилятор, по большому счёту позволяя форсировать более строгую культуру разработки к которой и так приходят крупные плюсовые команды, которые самостоятельно отказываются от сырых указателей в пользу умных и пр. фильтров, только с фильтрами не нужно будет за этим следить - поставил флажок при сборке и всё. Другой вопрос в том, что насколько вообще реально будет на такое переезжать в условиях когда есть богатое наследие плюсов с его кучей библиотек фактически нужно будет переписывать примерно по образу раста, причём часто переписывая не что-то вредное, а просто что-то "гипотетически" способное стать опасным, что влечёт миллионы человекочасов непроизводительного труда. Кмк куда логичнее просто часть диагностик статических анализаторов сделать обязательными или вовсе какой-нибудь PVS нанять с целью интеграции их СА в компиляторы и опять же по умолчанию врубать и бед бы не знать.
Вы зачем поставили слова "комитет" и "успеть" в одном предложении?
Так после "топовый тролль" же. Не все знакомы с работой комитета.
По моему С++ уже ни чего не спасёт. Он просто устарел.
Только вот беда, что в основе IT инфраструктуры по прежнему C++ и переписывать это не собираются. Компиляторы Си GCC, Clang -- на C++. Все браузерные движки на C++.
"Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас."В СССР было написано ПО под PDP-11 больше чем в США. Где сейчас DEC?
В России было написано масса ПО на Delphi. Появился C#.
Лучше упомянуть такие языки как Алгол и BCPL, о них только помнят, никто ими не пользуется.
А на Delphi до сих пор есть софтина - например, FL Studio.
Зачем их упоминать? Я привёл примеры, когда в России что-то западное начинали использовать слишком активно, после чего на западе что-то случалось.
Думаю, причина в том, что Дельфи ворованый у многих был на просторах бывшего СССР. Если бы покупали лицензии, возможно, Борланд бы и смогла выдержать конкуренцию.
Если бы пришлось покупать, популярности бы такой не было. Микрософт бы не посмотрела на это, и не сделала свой вариант с диезом и активистами. бесплатный, кстати.
> Где сейчас DEC?В спутниках ГЛОНАСС.По информации с открытых источников- там применяется процессор сделанный перед самым развалом СССР, сделали DEC совместимый процессор на 1 микросхеме- по сложности переходное между 386 и 486.Обещали заменить на более лучшее- тишина,после нашего Крыма.
> В спутниках ГЛОНАСС.По информации с открытых источников- там применяется процессор сделанный
> перед самым развалом СССР, сделали DEC совместимый процессор на 1 микросхеме-
> по сложности переходное между 386 и 486.Обещали заменить на более лучшее-
> тишина,после нашего Крыма.При том судя по состоянию спутниковой группировки, паре довольно жирных завалов навигации, периодическому выпадению ниже минимального кворума в 24 спутника и проч - что-то где-то пошло не так.
Не могу найти источники. Это случайно не МЦСТ-R?
>Не могу найти источники. Это случайно не ?Была статья давнишняя,может и найду в архиве как наши пилили DEC процессор, что удивительно коллектив был с Армении (в основном) и они всего лишь за 1,5 года уложились в задание. Процессор л1839вм1.Комплект микросхем назывался (из Вики) л1839.Писали что микросхема используется в 1 и возможно 2 поколение ГЛОНАСС.
МЦСТ-R это Спарк процессоры, от бывшей SUN ,ныне Оракл.Для реалтейма не совсем подходят,у них есть беда с переключением регистровых окон,хотя там можно было это дело сгладить с потерей производительности.
Дополню.
Нашел первоисточник - скан статьи Электроника 32 .Начало работ 84 год ,запущено в производство в 89.ЭВМ называется БЦВМ 90-50хххх.
Благодарю. Vax я видел только на картинках, а вот с PDP-11 пришлось столкнуться: за пару часов изучил формат и читал прям маш.код (надо было выдрать ресурсы из одной игрушки). Очень простой и понятный опкод, потому в версию с диверсией ЦРУ против DEC я верю легко.И вот этот вот Л1839ВМ1, кажется, можно было бы штамповать заместо RISC-V для каких-то целей?
В общем, опять подтверждает конспирологию: как только в России начинает что-то взлетать западное, оно по странному стечению обстоятельств приземляется, заменяется чем-то новым модным. Партнёры настолько раздобрились последнее время, что бесплатно раздают.
С плюсами ведь примерно также, у нас сильных пилюсовиков достаточно много (было).
> С плюсами ведь примерно также, у нас сильных пилюсовиков достаточно много (было).старика банально на пенсию отправляют.
"""
1993 — Премия имени Грейс Мюррей Хоппер, «за его ранние работы в области языка C++, базирующиеся на его разработках и внёсшие наибольшее влияние в языки программирования за всю историю вычислительной техники»
"""
> Все браузерные движки на C++.Servo смотрит на это утверждение с недоумением.
Не все конечно умеет, по сравнению с двумя (ок, тремя) другими, но если в него вложить столько же денег, то будет не хуже.
Нужно только простимулировать к этому))
> Нужно только простимулировать к этому))Что бы получить в итоге "ну не смогла я, не смогла"?
> Что бы получить в итоге "ну не смогла я, не смогла"?С чего бы это?
WebRender и многопоточное css прекрасено работают в FF.
В остальном Servo сейчас работает отлично в контексте вложенных ресурсов.
И нет никаких причин почему он станет работать хуже или вообще перестанет работать если туда сложить еще пару сотен лямов.
Кобыла:
Мужик, поставь на меня
> вложить столько же денег
> Нужно только простимулировать к этомуНадо просто убрать кучу ненужных web api и не раздувать веб-стандарты, тогда и свои бразуерные движки можно будет писать на любом языке.
... да кто ж иму дастЪ?! (С)У людей на этой сложности суриоус бусинес построен, с годовым доходом больше чем доход всей твоей страны и всех стран с ней соседствующих ...
Забудь!(С)
> и всех стран с ней соседствующихИ даже нашего самого восточного соседа? ну дела....
>> Все браузерные движки на C++.
> Servo смотрит на это утверждение с недоумением.
> Не все конечно умеет, по сравнению с двумя (ок, тремя) другими, но
> если в него вложить столько же денег, то будет не хуже.Уж и разработчиков - уволили, и мозилла - вот-вот сдохнет. А серва все - нигде. И ни для чего. Успешные инвестиции в новый яп и новый браузерный движок как они есть.
> А серва все - нигдекак нигде !?
серва в линукс фундейшон !
> и переписывать это не собираютсяТо-то столько драмы каждый раз, когда таки переписывают. Аж целого Линуса призвали.
Тут есть ньюанс. Переписывать и переписать немного отличаются.
Ты бы хоть читал на что отвечаешь… Как всё написанное тобой соотносится с «C++ просто устарел»? :)
ну так переезжайте на марс, там ничего переписывать не придётся, всё с нуля. вам уже и язык подходящий сделали
По-твоему там не будет доступа на GitHub?
Ты в курсе какой до марса пинг? :)
C и C++ не первые языки. На фортране тоже много чего было написано, и наверняка у него были такие же сторонники, с такими же аргументами.
Вот только это язык другой целевой ниши.
И только сравнительно недавно пропал смысл его использовать.
Фортран это просто к примеру. Вместо фортрана подставьте любой другой старый популярный язык.
> сравнительно недавно пропал смысл его использоватьСмысл пропал давно, просто менеджеры не хотели вкладываться в модернизацию. А из-за этого потом возникают проблемы с поддержкой и интеграцией старого ПО.
Ну значит не везде менеджеры - тупицы, прям в кои то веки - хорошая новость!
А знаешь почему до сих пор кода на COBOL активно работавшего 24/7/365 просто невбибичекое количество? Поспрашивай :)
«Использование Кобола калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление» Дейкстра
> ДейкстраЭто тот который шел войной на goto?
Того самого goto - что является основным средством в ядре для работы с ресурсами?
GCC это не «компилятор c»
GCC это GNU Compilers Collection
Коллекция компиляторов GNU
Чуешь разницу?А то вы своей фантазией уже задолбали
В следующей версии коллекции ожидается включение нового ЯП :)
Нет, не раст :) COBOL! Я не шучу, даже тут новость была.
А уж эти точно знают что нужнее :)
Видимо у кого-то из оплачивающих разработку(RH и прочие) возникла необходимость
Дело не в том, что «эти точно знают что нужнее», а дело в том, что они знают что необходимо спонсорам разработки
И это нормально
Так вот почему rust попытались в gcc сделать...
И это реально беда.
Это вы просто тыкаете палочкой в мамонта. Современный канпилер (для доказательства своей же пригодности) пишется на себе самом, bootstrap - слышали про такое? Вот язык Nemerle написан на себе самом, к примеру. Остальная "инфраструктура" - да, конечно там много С++, но... доколе? Без "свежей крови" ни один проект не выживет. Сегодня ты хвалишься С++-ным бэкендом банка, а завтра соседняя компания запиливает проект на D (по современным стандартам), а ты лихорадочно бегаешь по рынку, ища "дидов", которые смогут хотя бы прочитать то, что у тебя написано на С++. Проект на D будет идти вперёд, а ты будешь "трясти полутруп", выдавливая последний профит.
С++ - это кобол современности, он просто ужасен для средних-крупных проектов.
> С++ - это кобол современности, он просто ужасен для средних-крупных проектов.Не оскорбляйте кобол си плюс плюсом! )))
А вообще, вы не правы. На Си++ реально тянуть средне-крупные проекты, нужно только уметь его правильно готовить и документировать код.
Но современный тренд - это безусловно - попытка превратить плюсы в брейнфак.
Дело не в языке, а в кодерах. Некоторые специально всё переусложняют на плюсах чтоб оправдать высокие зарплаты, выглядеть незаменимыми, имитировать бурную деятельность, следуя самым новомодным стилям.
Хотя на деле, всё можно упростить, было бы желание.
Он уже родился старым :)))) Как можно писать на языке, где ООП было "прикручено сбоку на изоленте"?! Вдвойне смешны потуги писать на "сипипишном синтаксисе" при наличии java, C#, D, Kotlin и иже с ними.
> времени осталось очень мало и необходимо до 2026
> года успеть предпринять какие-то мерыУчитывая скорость работы комитета по стандартизаци...
удачки, хехе))Учитывая, что отчет АНБ был опубликовал в конце 2022 года и никто не чесался больше двух лет, то как раз к 2036 плюсовики сделают новый стандарт. Но это не точно.
Правда потом нужно будет дождаться когда это все завезут в компиляторы...
А чего АНБ свой проект Тор на Раст перевела.
> А чего АНБ свой проект Тор на Раст перевела.Потому что им не хочется, чтобы их сотрудника набутылила местная контрразведка только из-за того, что сишники не смогли в память.
А контроль над тором можно и другими способами получать.
> А контроль над тором можно и другими способами получать.Используя закладки в rust?
> Используя закладки в rust?Слишком палевно. Можно контролировать сами ноды.
Можно использовать закладку прям в ядре линукса - 10 лет жила и всем было норм.
Или в процессоре. Или прям закладки в криптографии на уровне алгоритма и стандарта.Вариантов много.
Вспомнилась новость о том что Касперский запретил использовать апл.Типы было теоретически 3 формы попытки взлома компанией апл телефонов пользователей и ВСЕ три были применены к управленцам Касперского.
Так что запас карман не тянет.
> было теоретически 3 формы попытки взлома компанией апл телефонов пользователейСмахивает на ЛПП. Пруфы-то были?
>закладку прям в ядре линукса - 10 лет жила и всем было нормТы бы хоть раз ссылочку привёл на эту закладку. А то, может, это и не закладка, а уязвимость, которых там немало бывает?
> Ты бы хоть раз ссылочку привёл на эту закладку.Ищи по Bvp47.
> А то, может, это и не закладка, а уязвимость, которых там немало бывает?
Уязвимость, потому что сишник "забыл" проверить входные данные и получилось RCE с получением рута?
Да-да, ну разумеется это точно не закладка, а просто уязвимость))
Все сишники рано или поздно так делают, поэтому прекратите задавать глупые вопросы, гражданин.
Используя разводной ключ за пять баксов и судебную систему. Всякий раз как речь заходит о безопасности, начинается какая-то оголтелая гибсовщина в комментах. Объясни, зачем нужны закладки в расте, если большая часть инфраструктуры интернета находится под прямым или косвенным контролем сша? АНБ не надо это всё, они просто™ звонят в офис и просто™ говорят какой порт куда отзеркалить по стандартному протоколу. И пока ты с ними на телефоне утрясываешь детали, в дверь уже стучится курьер с предписанием суда.
А зачем apple все три теоретически возможных взлома системы пользоваетля, если достаточно одной?Запас карман не тянет.
Фантазеры, блин
Tor Project был создан не АНБ(гражданская структура), а NRL(структурой военно-морского флота)
Как же ваши фантазии про АНБ вокруг утомили
Главное, не отечественный т. майором.
- Одно слово румын
- Так он болгарин
- Да?! А какая разница...Для большинства это обобщенное "тов. майор" только забугорный.
И да. Операция Кондор. Проект синяя птица. И т.д. И т.п.
Мы такого не придумаем, какое они отморозят...
Да вот в том-то и дело, что нет там майоров, в АНБ этом вашем
А в NRL есть(ну или капвторанги какие-нибудь)
АНБ, как и ЦРУ, это гражданская организация и в ней нет воинских или специальных званий
Tor не АНБ (как тут верно уже указали). Он "инструмент", но в другом смысле --- ("если вы не поняли, кто тут лох, ..."). У АНБ-то как раз инструментаий наполовину на C++/наполовину на на Java'е.
Воу, воу! Палехше! Куда так гнать, ну? Этж в 26 стандарт принять, в 30м поддержка (частичная, всеми разная) стандарта компиляторами появится, в 31 понять, что все не так и вот вам ещё один (но другой!, лудший) способ получения безопасной безопасности - так году в 35м придётся начинать ДУМАТЬ что-то там переписывать под самую пенсию? Неее. На это комитет пойтить не могет - мужики, может ещё годика три форму скобочек пообсуждаем? Юникод он большой...
А это не тот самый мужик, который в своей книжке писал что насоедование 8-го уровня это нормально?
> насоедование 8-го уровня это нормально?Трудно понять о чем ты. Переформулируй.
Про наследование.
8-го уровня.
Средства(т.е. инструменты) есть, у̶м̶а̶ желания их использовать при политике "****, **** и в продакшн" нет.
Когда от тебя требуют скорость, плевав на качество и тем более сферические стандарты в вакууме, то так то не до феншуя.
Жаль деда. Линуксоиды по сути его предали, не осилили плюсы в ядро.
> Жаль деда.Так он и не стал дедом, все такой же "мальчишка". Дед тот, слово (мысль, идея) которого имеет вес, а тут какое-то КИСА (осколок АНБ) имеет больше веса, и вес то совсем не мысли, а дубинки.
Вряд ли его таким ужалить. Дед спорный, как и Вирт, но свой след оставил. В отличие от нытиков по поводу включения Rust в ядро, но их и совсем не жалко.
Ты в разработке руководствуешься концепциями типа "жалко деда"?
Я плюсы в ядро осилил, а "жаль" - это императив по НЛП.
> Жаль деда. Линуксоиды по сути его предали, не осилили плюсы в ядро.Не нужно его в ядро. По-моему мнению, C++ - это язык для прикладного программирования.
Мнение - это из области мнимого. В действительности драйвера антивирусов нередко пишут на плюсах.
Авторы Genode с вами несогласны,
Нет ничего более прикладного чем операционная система.
SerenityOS написана на C++
SerenityOS, нормальная.
Интерфейс нормального пользователя.
> Каждый объект должен быть корректно создан и освобождён.Гениально. А что, можно иначе?
Можно. А еще некоторые в бинарниках шестнадцатиричным редактором заголовки правят.
Конечно!
Просто добавляешь коммент "тут все ровно, мамой клянусь" и пишешь как получится.
А там пусть потомки лет через 10 разбирают CVEшки.
> Гениально. А что, можно иначе?Иногда НУЖНО иначе.
> Гениально. А что, можно иначе?Конечно, например сделал new для буфера, использовал, вышел из программы. Можно в принципе не освобождать, если всё равно выходишь. И уж тем более, если это программа-однодневка.
Конечно, особенно в какой-нить стековой модели объектов. Тогда выделяешь сразу буфер подо всё и двигаешь нижнюю границу.
Так конструкторы-деструкторы всё равно вызовутся, в отличие от предложенного выше new без delete.
И дрежать только одно соединение за раз
то то и оно что в языка низкого уровня - можно и иначе, и через иначе, и через-через иначе. И так далее.
И как на таком новом-кленовом C++ написать linked-list?)
C умными указателями конечно же!? Я сам конечно не пробовал, мне некогда пока было :)
Не, умные указатели не подходят, поскольку сразу же после присоединения нового элемента он мгновенно зациклится с предыдущим. А если делать слабые указатели, то часть списка может в любой момент просто взять и испарится.
> Не, умные указатели не подходят, поскольку сразу же после присоединения
> нового элемента он мгновенно зациклится с предыдущим. А если делать
> слабые указатели, то часть списка может в любой момент просто взять и испарится.А давайте добавим сильные, но глупые!
Вот тогда плюсы взлетят))
> Не, умные указатели не подходят, поскольку сразу же после присоединения нового элемента он мгновенно зациклится с предыдущим. А если делать слабые указатели, то часть списка может в любой момент просто взять и испарится.А вот для этого и надо бы сделать время жизни контейнеров. Как раз то чего в rust нет и никогда не будет.
Но, я уверен, в каком-нибудь из следующих языков мы получим необходимое для полноценности концепции применённой в rust.
Осталось только "будем посмотреть".
Вполне нормально сделать нормальный linked list единожды и использовать его везде. Свой список в каждом проекте писать это уже пережиток прошлого.
Умные указатели вполне подходят для списков. Просто ссылки на предыдущие элементы должны быть слабыми, что логично, ведь им незачем управлять жизнью предыдущего элемента.
Так в конце дед предложил аж 6 вариантов [[unsafe]]
Вот ими вся libstdc++ и будет утыкана.
Уже написан, в STL. А если свой хочется - можно через ссылки.
Поздно спохватились. Доктор сказал в морг, значит в морг. С++ изжил свое.
Что на замену?
Rust. Если уже Линус Торвальдс (ярый сторонник C и противник C++) начал отказываеться от C в пользу Rust - уже говорит о многом. А он в ЯПах разбирается получше местный диванных экспертов.
Хитро передёргиваешь. Лично Торвальдс считает, что "нет ничего лучше Си" - это его цитата. Раст он принял в ядро не хотя, его долго уговаривали, ну он типа "ну ладно-ладно, уговорили". К Расту у него отношение "терпимое".Конкретно, языку Раст не место в ядре Линукса. Пусть растаманы пилят свою экосистему. Плоть и кровь GNU/Linux состоит из чистого Си.
> Что на замену?Условный C++2.0.
Нужно просто решиться и сломать обратную совместимость с++ сильнее чем при переходах между стандартами.Убрать все UB. Добавить то, что описано в предложении, на уровень языка, сделав его по умолчанию. А для использования всяких опасных штук сделать специальные директивы, тоже на уровне языка.
Выкинуть всякие неудачные вещи, которые тянуть только ради совместимости.
> Убрать все UB.И получить необходимость дублировать код и структуры для разных архитектур, получая комбинаторный взрыв?
> И получить необходимость дублировать код и структуры для разных
> архитектур, получая комбинаторный взрыв?Пример в студию.
"Вот такая UB позволяет сделать то-то"
Иначе это пустой треп о том что "без UB жизни нет"
До недавнего времени тип char в ядре linux был для разных платформ разным. Где то знаковым, где-то беззнаковым. Ибо железо такое было. Код же работал один и тот же. Пришли разработчики rust и уговорили от этого избавиться. Теперь все привели к одному виду и для части платформ это выражается в небольшом понижении производительности.
> Теперь все привели к одному виду и для части платформ это выражается
> в небольшом понижении производительности.Это все невероятно интересно, но где "комбинаторный взрыв"?
Плюс там пробелема была в том, что написанный код работает хз в зависимости от платформы, компилятора, флагом, ретроградности меркурия. А для signed еще получаем UB для overflow.
> UB для overflowЯ вообще-то только это и комментировал :)
А комбинаторный:
Из за одного типа надо было дублировать почти все структуры что бы работали на всех платформах.
А таких отличий у платформ еще бесчисленное множество.
> Из за одного типа надо было дублировать почти все структуры что бы работали на всех платформах.Забыл добавить похорошему бы. А так разработчики решили забить...
> Из за одного типа надо было дублировать почти все структуры что бы работали на всех платформах.
> А таких отличий у платформ еще бесчисленное множество.Давай по пунктам
1. сколько таких платформ?
2. сколько из них живы?
3. неужели они не обойдутся старой версией компилятора, чтобы собирать код для дидовской моторолки MC680x0?
Какая разница? Это был пример.
Разница огромная.
Если мы можем выкинуть 100500 ifdef'ов для 100500 некроплатформ, то это большой плюс.
И это очень крутая возможность.А если слушать вопли всякие некролюбов и ʼнинужностиʼ не выкидывать, то прочитаем очередную "помер в своей квартире тк завалило хламом".
Любая хрень становится некро - только когда исчезают люди способные это поддерживатьТак что не спеши лепить ярлыки где нипопадя.
И еще. Есть способ повышения качества кода. Для этого разными компиляторами собирают под разные платформы и тестируют, даже если используется на одной.
>До недавнего времени тип char в ядре linux был для разных платформ разным. Где то знаковым, где-то беззнаковымТак, а где тут UB? А то я думал, что тут про разыменновывание нулевого укзателя будут говорить или про двойное освобождение памяти
Операции сдвига UB.
Поведение char от компилятора зависит. Просто char - это не сокращение от signed char, там аж 3 типа выходит:
char - для хранения символов, или другой последовательности байт неопределённого назначения (это в принципе тоже числа, но какие - решают разработчики компилятора);
signed char - знаковые однобайтные числа;
unsigned char - беззнаковые однобайтные числа.В C++ с этим много мелких неудобств бывает. Используем POSIX в программе на C++ и где-то cast всплывёт.
В C++ для похожих целей (указатель на блок данных неопределённого назначения) вроде резервировали void* с менее жёсткими требованиями к преобразованию типов, но от C-API достаётся char* и никуда он уже не исчезнет. Да и если вдруг захочешь поковырять блок данных void* - тоже потребуется cast.Но это в целом проблема сериализации, а не какой-то заговор. Там ещё и byte order надо учесть, а бывал ещё и pdp byte-order. Решать это всё можно по-разному, но обычно костыли где-то вылезают.
Так ржавый и получится же ну. Только он уже готов и даже стабилен
Не получится. Классов нет, наследования, шаблонов. В C++ 2.0, если таковой появится, это всё будет, но уже без сырых указателей, с контролем границ массивов по умолчанию.
Так в русте же все эти штуки одним общим механизмом трейтов реализованы
Да, это такие штуки в Русте.
> Условный C++2.0.
> Нужно простоА можно просто узнать, сколько за эти годы было написано языков на замену Крестам. Начиная с D, например. Вы о нем даже не слышали, полагаю. И об остальных - тоже. Почему бы это?...
Тот Д который со сборщиком мусора (опциональным, но тем не менее)?
И для которого потом пытались колхозить "безопасные" сабсеты типа SafeD?
Я бы сильно удивился если бы он взлетел.
Так комментарий выше - в аккурат про то, что а вот давайте теперь напишем... то, что Александреску уже двадцать лет назад написал, внезапно.
SafeD там там теперь по умолчанию из коробки.
>Условный C++2.0.С++++
C+=2
> Убрать все UB.А ты, решительный!
> С++ изжил свое.Буквально все, чем ты пользуешься на нем. Изжил:) Откуда вы лезите? Где у вас гнездо? (с)
>> С++ изжил свое.
> Буквально все, чем ты пользуешься на нем.И? Когда появилось эл-во и факелы и свечки заменяли на него, наверняка такие же бухтели "вы эти лампочки пилят при свечах!! позор! никакого уважения к тысячелетним технологиям".
> Изжил:)
Ага. Именно изжил. В комитете раскол и Драма за Драмаю.
Как минимум 2 группы тянут одеяло на себя.Тащится просто жуткое старье в угоду древним платформам.
При некоторые вещи можно ускорить в 2-3 раза если поломать совместимость.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf
Если бы электричество.А то ведь предлагают вместо свечей дыру в потолке прорубить. Правда ночью невидно ничего и дождь на голову падает, зато пожара не будет - безопасно!
https://www.mobygames.com/game/1837/gauntlet/
Что-то Qtшники переписываться на Rust не спешат.
Их уже переписали =)
> Их уже переписали =)
> https://slint.dev/alternative-to-qtНу вот когда серъезные проекты на нем появятся, тогда можно что-то утверждать. А пока qt - промышленный стандарт.
> Что-то Qtшники переписываться на Rust не спешат.У них есть qml с js-ом (стоит заметить своей реализацией). Так что все безопасно и проще.
C#
ИЧСХ, Паскаль с самого начала не давал программисту делать всё что угодно, а только то, что правильно. Потому что программист делает ошибки. Потому что программист хочет то, что он хочет, а не то, что он пишет. Через 50-60 лет до мэйнстрима дошло.
Просто до этого нехаватоло мощностей и приходилось выжимать до капли любым способом.
Проблема Паскаля не в том, что он "слишком правильный". И даже не в том, что медленный. А в том, что он придуман в Европе, а не в США.
Насчёт "медленности" Паскаля вопрос сомнительный.
Зависит от многих факторов, в том числе и от компилятора, но в среднем, примерно в 2 раза медленнее Си (в рейтинге сразу за Си).
Та же Java (на тех же задачах), показывала производительность в 10 раз меньше.Была на опеннете такая статья с исследованием несколько лет назад. Не могу найти.
Ну так естественно, если над компилятором (FreePascal) трудятся по-сути случайные люди, хотя и опытные.
Будь у Паскаля такая же поддержка, как у GCC и LLVM, производительность была бы схожей.
Вон Фортран до сих пор затыкает сишку в чистых вычислениях, всё потому что сишники до сих пор не научились использовать ключевое слово "restrict" и не обладают той же алгоритмической базой, что и фортранщики.
> в среднем, примерно в 2 раза медленнее Си (в рейтинге сразу за Си).Даже близко там такого быть не может. Эти языки отличаются на плюс-минус 5-10% (причём ещё вопрос в какую сторону, lcc из quake наверняка сольёт delphi).
Тоже искал как-то почему c++ работает в разы быстрее pascal. А там оказалось #pragma omp ... и вуаля - числодробилка распараллелилась по ядрам. Хотя на первый взгляд программа написана в один поток.
>Проблема Паскаля не в том, что он "слишком правильный". И даже не в том, что медленный. А в том, что он придуман в Европе, а не в США.Не в бровь, а в глаз. 50 лет назад, американцы всячески игнорировали Алгол, и везде где могли протаскивали свой Фортран. В XXI веке создатель Питона внёс в язык оператор присваивания := , и тут американские программисты начали сильно возмущаться. Гвидо опечалился и хотел было покинуть пост лидера. В Америке был сговор компаний, не принимать на работу людей, которые пишут программы на Дельфи. Прикол в том, что Дельфи это американская программа.
Я люблю Си и Юниксы. Но вынужден признать, у американцев есть неприязнь к европейским языкам программирования. Это факт.
Это не неприязнь, а бизнес-модель. США должна быть центром притяжения, соответственно и конкурентов следует задавить.
Ээээ... Вы код на том паскале видели? Нет, не на "этом", который хипстерское "турбо", и не на смузи-с-объедками, ой, объектами конечно же?
То, что видел я - эталонное лапшемесиво, если честно. Не притендую на широту охвата, но пред-по-ло-га-ю, что "дiды"(тм) у них с сями плюс-минус одiнаковыя)
И как в паскале дело обстоит с указателями? Так же как в си/крестах?
Если постараться, то выстрелить себе в ногу тоже можно.
Но компилятор много чего ловит.
Что значит постараться? Я не знаю все 100500 языков какие есть. Если вы расхваливаете паскаль то говорите конкретнее: есть ли там nullptr, что будет если его разыменновать, бывает ли там утечка памяти, бывает ли двойное освобождение и так далее. И как ко всему этому относится компилятор.
Ну в lazarus будет @, ^ и nil. Забыть вызвать Free()/Destroy()/Dispose() можно. А до кучи ещё и ${ifdef} имеется.
Паскаль - отличный язык. Но создавался он исключительно для обучения и там только и должен применяться
Да что всё Поцкаль да Поцкаль? Ведь, есть же более промышленный Modula-2, который теперь и в GCC имеется. Со строгостью у него, должно быть, не хуже.
Какая модуль, какой Паскаль. Оберон!
> ИЧСХ, Паскаль с самого начала не давал программисту делать всё что угодноТак удивился этому заявлению, что аж заглянул в свой архив. Нет, похоже, исходники тех программ из прошлого века, где использовались ассемблерные вставки и прямая запись в видеопамять (потому что штатные библиотеки люто тормозили, и даже int 10h был нетороплив), уже выкинуты...
Так-таки и не давал? Как-то я этого не заметил.
Это Turbo Pascal? Все коммерческие реализации как раз и добавляли разные небезопасные возможности, чтобы "профессионалам" было удобнее. Но не суть. Просто то, что Си небезопасен и плохо спроектирован, было очевидно уже очень давно.
> Си небезопасен и плохо спроектированА верблюд несимпатичный и низко летает. Вообще непонятно, что арабы в них нашли...
> Вообще непонятно, что арабы в них нашли...На вкус и цвет - кому и кобыла невеста
Скорее "на бесптичье и жoпа - соловей".Причем оглядываясь на прошедшие десятилетия, нетрудно заметить, что именно такая ситуация - не исключительная, а сугубо характерная и логично формирующая то, что мы имеем сейчас. Не обещая никаких изменений и в ближайшем будущем, собственно.
>Так удивился этому заявлению, что аж заглянул в свой архив. Нет, похоже, исходники тех программ из прошлого века, где использовались ассемблерные вставки и прямая запись в видеопамять (потому что штатные библиотеки люто тормозилиТо есть ты ставишь знак равенства между американской реализацией компилятора (Turbo Pascal), и настоящим компилятором созданным Никлаусом Виртом? А железо на котором ты запускал свои программы, тоже американского производства.
>ИЧСХ, Паскаль с самого начала не давал программисту делать всё что угодно, а только то, что правильно. Потому что программист делает ошибки. Потому что программист хочет то, что он хочет, а не то, что он пишет. Через 50-60 лет до мэйнстрима дошло.Проблема не в том, что до мэйнстрима что-то дошло или не дошло. Американцы были против Паскаля. Потому-что это европейский язык программирования. И все идеи идущие от Паскаля они упрямо игнорировали. Иногда они поступали хитро, потихоньку заимствовали идеи европейских учённых в обласи Информатики.
Вот Pascal имхо надо воскрешать и любить. Он как раз может занять нишу, которая позволяет "просто делать вещи", сейчас эту нишу занимает отчасти Go (и даже некоторые синтаксические конструкции похожи!), который во многом тоже довольно прост. Более крупные проекты пилятся уже на Java (+смежные технологии), C# и Qt, если речь идёт о бизнес-приложениях.
Meanwhile in the Pascal camp...
> lifetime - запрещены ссылки на освобождённые или неиспользуемые области памяти, разыменование указателей, явный вызов new/delete.Тут уже поднапряглись авторы и пользователи Qt…
Qt закрыть и забыть. Хорошо, много на нем не успел сделать.
А что вместо него?
flutter, slint
Помнится, ещё какой-то Клиттер пытался взлетать, не вышло.
Клиттер,
Который в Latex, да это он.
Отличная инициатива. Так оно и будет, затащат все основные примочки растов и никто никуда миргировать не станет, моментально отпадет желание переносить огромные пласты легаси кода.Так от части происходит и с другими платформами. Например java много впитал из scala, и теперь смысла как-то перекатываться на scala особо и нет.
> Так оно и будет,Может и будет, вопрос "когда")
Пока комитетчики расшевелятся, пока это попадет в компиляторы...
В некоторых крупных проектах уже полным ходом от дырявых ЯП избавляются - весь новый код пишут на более новых.Даже через три года, кол-во написанного кода будет достаточно существенным, программисты обучены, процессы настроены.
А лет через 5-6 о возвращении к плюсам можно будет забыть.
> Даже через три года, кол-во написанного кода будет достаточно существенным, программисты обучены, процессы настроены.Сколько там прошло с момента появления rust. А в новостях про переписывальщиков только: паритет по функциональности планируется достич к ...
> паритет по функциональности планируется достич к ...Это современный метод ведения бизнеса. Обещать, а концу дедлайна сваливать по горизонтали. Или по-другому. Недавно интервью читал одного деятеля о разработке самолетов. Типа делаем проект 10 лет, признаем устаревшим, начинаем снова. Делаем проект 10 лет, признаем устаревшим и т.д. И ведь прокатывает!
Отвечу тут:> Какой паритет?
Паритет функциональности проекта на Си С++ и переписываемого на rust.
Практически везде его никак не могут достигнут.
>> Какой паритет?
> Паритет функциональности проекта на Си С++ и переписываемого на rust.В соседней новости fish переписали с СИ на С++, потом с С++ на раст.
Суда по их блогу паритет сохранен.> Практически везде его никак не могут достигнут.
А они уже закончили)?
АРТИ (который TOR) стабильно добавляют feature parity.
И по их же словам версия сишки будет сущесвтовать какое-то время, но неминуемо будет дропнута.
Fish? Возможно. Но.Насколько я понимаю, сам fish это упрощенная версия командной оболочки. Заточена на интерактивность за счет скриптования. То есть проект уступающий по функциональности тем, кого хотел переписать.
А tor - да, обещают, ... вот-вот...
> Насколько я понимаю, сам fish это упрощенная версия командной оболочки. Заточена на интерактивность за счет скриптования. То есть проект уступающий по функциональности тем, кого хотел переписать.Э? То что оне не ПОФИГС совместимый не делает его упрощенным.
> А tor - да, обещают, ... вот-вот...
Pingora, Хикорри, COSMIC, pgp sq, куча либ для андроида...
У тебя просто bias и ты видишь только то, что хочешь.
> Э? То что оне не ПОФИГС совместимый не делает его упрощенным.Ну не смогла я - не смогла.
> Pingora, Хикорри, COSMIC, pgp sq,
Что это? Это есть в дистрибутивах?
> куча либ для андроида...
А вот в это верю. Только их не видно.
> У тебя просто bias и ты видишь только то, что хочешь.
Или просто вижу то что вокруг. Копаться на свалке и искать желания нет.
> Сколько там прошло с момента появления rust.Первый стабильный релиз - май 2015.
В андроид добавили в начале 2021 года.
В ядро добавили в октябре 2022.> А в новостях про переписывальщиков только: паритет по функциональности планируется достич к ...
Какой паритет?
В расте уже возможностей больше чем в дыряшке или плюсах - у вас есть там паттерн матчинг? А нормальная работа со строками? А линейные типы?Чего в расте меньше, так это возможностей отстрелить себе ногу, по самую опу.
а еще помимо языка удобный тулинг, стандартизированный подход к тестам, доке и бенчмаркам.
Отсутствие компилятора в машинный код забыл добавить
>и теперь смысла как-то перекатываться на scala особо и нетДжависты не перекатываются на скалу ни когда в этом смысла нет, ни когда смысл есть
Джависты, они такие да.
"Жаба", "Жабисты". Пиши правильно.
> запрещены ... явный вызов new/deleteВсегда так делал и буду делать. Мне так удобно контролировать выделение/освобождение памяти. Кстати, GCC предупреждает, если в программе для объекта есть new, но нет delete.
Ты и без них можешь контролировать
А если delete в другой функции. Или на другом потоке.
Неужели GCC все проверяет?
Или это топорная проверка в узкой областе видимости?
У меня в проекте проверяет. Но проект собирается из исходников, хотя и по частям.
> А если delete в другой функции.Нет, delete в той же функции. Функция исполнилась - освобождает ресурсы, которые выделяла. Результаты проверяет.
ИМХО неудобно контролировать каждый указатель. Про что-то можно и забыть.Любая функция с каким-никаким ветвлением (с учетом, что исключения - тоже вид ветвления) превращается в кусок полусишного кода с функционалом плюсов, поскольку тебе нужно:
+ Освободить указатель, если произошло исключение
+ Освободить указатель при преждевременном return'е
+ Не забыть то же самое в циклахДаже такой кусок кода может содержать утечку:
```cpp
void foo()
{
auto a = new int(2);
auto b = new int(3);delete a;
delete b
}
```Умные указатели избавляют от этих проблем. До тех пор пока не ошибся с семантикой перемещения.
>ИМХО неудобно контролировать каждый указатель. Про что-то можно и забыть.Если забыть, то в данном случае, напомнит статический анализатор кода?
Зачем? Есть же automatic storage duration.
>Функция исполнилась - освобождает ресурсы, которые выделялаОчень интересно, как вы собираетесь в той же функции освобождать ресурсы, если их планируется возвращать наружу. Или вы постоянно копируете данные туда-сюда?
почему тогда operator new() не освобождает ресурсы, когда исполнился?
А вообще, считаю высшим пилотажем, когда вычисления производятся в тех же массивах, что были переданы в функцию (например, в некоторых алгоритмах линейной алгебры или теории дифференциальных уравнений). Хотя, конечно, о разрушении исходных массивов программист должен быть предупрежден.
высший пилотаж :D
тебе что 20 лет, как можно быть таким зелёным?
Да, зеленый он совсем. То ли дело, взять готовую библиотеку, которая хрен знает как и что считает, написать обвязку на Python и выдать на-гора готовый продукт. Всё равно никто пользоваться не будет.
Неужели это настолько сложно делать в C++, что это считается чем-то... стоящим упоминания?> Хотя, конечно, о разрушении исходных массивов программист должен быть предупрежден.
Звучит так, будто у вас до сих пор нет нормальной документации. Опять же, что значит "разрушение исходных массивов"? Это типа вот так:
fn do_some_math<'a>(input: &'a mut [f32]) -> &'a [f32]
Я для наглядности оставил маркер времени жизни, но оно так по умолчанию работает в данном конкретном случае (все 'a для наглядности). Тут буквально сказано, что функция использует входной кусочек памяти в качестве выходного кусочка памяти. И все подводные камни, связанные с таким использованием проверяются на уровне компиляции.
Это не подойдет, по многим причинам:
- у дедов уже зрение не то, они просто не видят мелкие символы'
- других просто пугают незнакомые значки
- да и это же надо подумать заранее, а то компилятор будет ругаться
Какая-то мелкая букашка по монитору пробежала.
Дедов на поддержку легаси можно оставить.> да и это же надо подумать заранее, а то компилятор будет ругаться
Лучше думать один раз при создании интерфейса, чем каждый раз при использовании интерфейса. И уж точно лучше, чем думать, как исправить ситуацию, где все начинают шутить шутки про дырени и показывать на тебя пальцем.
Когда сидишь на диване и палец об палец не ударяешь, всё предельно просто
Кто нибудь ударьте палец, о палец.
Молодец.
> fn do_some_math<'a>(input: &'a mut [f32]) -> &'a [f32]У тебя ошибка, растолюб.
Правильно вот так:
fn do_some_math<'&^$a>(input: &!@#$'a mut [f32]) -> &()&%#'\'a [f32]
В реальном коде этот конкретный случай вот так выглядит:fn do_some_math(input: &mut [f32]) -> &[f32]
На сишечке скорее всего что-то такое будет:
void do_some_math(float*const input, int input_length, float**const output, int*const output_length);
> void do_some_math(float*const input, int input_length, float**const output, int*const output_length);Растолюб, почему у тебя длинна знаковая в примере на Си? Вы же типа, в отличие от Сишников, не допускаете таких ошибок.
Там скорее всего нужно использовать size_t. Хотя всё это не важно для контекста.> Вы же типа, в отличие от Сишников, не допускаете таких ошибок.
Если я допущу такую ошибку в rust, код просто не скомпилируется. Мне не требуется держать такие детали в голове. Вместо этого я сосредоточусь на более важных вещах.
> Там скорее всего нужно использовать size_t. Хотя всё это не важно для контекста.ну т.е. без раста вы также не можете чистый безопасный код написать. Ясно-понятно.
> ну т.е. без раста вы также не можете чистый безопасный код написать.Не, я растом я могу написать чистый и безопасный код)
А вы даже на своем любимом С/C++ не можете.> Ясно-понятно.
Ага.
То ли дело CVEшный код от дырявых))
Я могу потратить полчаса времени и вспомнить детали. С другой стороны я пишу на расте, а не на си. Зачем мне держать в голове мелкие детали си?Или претензия в том, что я не пишу на си? Пишу на чём хочу.
> Растолюб, почему у тебя длинна знаковая в примере на Си?А почему бы и нет! Может это закладка чтобы потом туда -100500 передать.
Вот захоте и написал! Кто мне запретит?
> На сишечке скорее всего что-то такое будет:
> void do_some_math(float*const input, int input_length, float**const output, int*const output_length);скорее всего будет вообще не так. Вы там const-ов наставили вообще не в тему. Скорее всего будет выглядеть так (если я правильно понимаю, что на Rust функция возвращает массив и принимает на вход изменяемый массив).
Если то самое, "разрушаемое" заполнение, то будет:
void do_some_math(float* input, size_t input_length);
Если функция на C сама выделяет память для результирующего массива, и входной массив не трогает, то будет что-то типа:
float* do_some_math(const float* input, size_t input_length);
Если результирующий массив может по размеру отличаться от исходного, то:
float* do_some_math(const float* input, size_t input_length, size_t* output_length);
Если надо, чтобы заполнялся другой массив, внешний относительно подпрограммы, то будет что-то типа:
void do_some_math(const float * restrict input, size_t input_length, float * restrict output, size_t output_length);
Если надо, чтобы кроме всего прочего функция сигнализировала, что размера результирующего буфера не хватает, то будет что-то типа:
size_t do_some_math(const float * restrict input, size_t input_length, float * restrict output, size_t output_length);
> Вы там const-ов наставили вообще не в темуНеизменяемый указатель на изменяемую память:
fn do_some_math(input: &mut [f32]) -> &[f32]
Без const будет так:
fn do_some_math(mut input: &mut [f32]) -> &[f32]
Полагаю, несущественная мелочь. Тоже могу сказать и про restrict, которого нет в rust ибо это поведение по умолчанию.
Но в обоих случаях возвращается пара из указателя+длинны на кусочек памяти в пределах изначального. Не обязательно начало/длинна равны изначальным, но обязательно не выходящие за границы. Если бы это была выделяемая память, то было бы что-то вроде такого:
fn do_some_math(input: &mut [f32]) -> Box<[f32]>
fn do_some_math(input: &mut [f32]) -> Vec<f32> // не только length, но ещё и capacityВ случаях, если возможна реаллокация изначального массива, то:
fn do_some_math(input: &mut Vec<f32>) -> &[f32]
А если мне эти данные ещё нужны, как быть в этом случае?
Использовать f# ocaml. Массив по определению можно изменить. Пляши от стенки
OCaml, Oberon... А вы опасный человек...
>Использовать f#Вендузятник детектед.
> lifetime - запрещены ссылки на освобождённые или неиспользуемые области памятиНу, и как он предлагает этого достичь? Да еще и во время компилиции? Ну вот банальное типа:
const int& i = std::max(x, 10);
Сори, но у плюсов родовые травмы от С: в языке фундаментально не заложена безопасность - ни при работе с ресурсами, ни с арифметикой.
Ну как, запретить такие конструкции.
Какие "такие конструкции"? Возврат ссылки, что ли?
Да. Ссылка на литерал не есть хорошая идея.Но С++ --- мультипарадигменный язык. Для тех кто не понимает (или не хочет понимать), что происходит, других языков понаделали. Там следят не только чистотой конструкций, но и за мыслепрес^W правильной областью применения этих языков.
> Да. Ссылка на литерал не есть хорошая идея.Как ты себе представляешь запрет возвращения ссылок? Ты не понимаешь, что людям придется переписывать весь плюсовый код, включая стандартную библиотеку?
И да, проблема с кодом выше не в лтюитерале как таковом: любой временные объект в этом случае имел бы тот же эффект. Потому что язык г*о, и пулю ты из него, увы, уже не сделаешь.
Так ошибки же нет. Просто возмутительное незнание С++. Позоришь хрустиков.
OK, конкретно в этом коде
>> const int& i = std::max(x, 10);ошибки нет. Константная ссылка слева продлевает время жизни возвращаемого rvalue.
> Константная ссылка слева продлевает время жизни возвращаемого rvalue.Нет, не продлевает.
продлевает
Превознемогает.
Молодец.
Не переживайте. Сказать не значит сделать.
Ага то есть был язык с++, наверно, самый переусложнённый из ныне используемых, а будет ещё и ещё переусложнённый? Причём обработка даже какого-нить utf8 на стандартных библиотеках какой-от цирк с конями. Далеки это трупы страусов от народа. Уж лучше пусть даже хруст будет.
Когда с++ разрабатывался, utf8 ещё не придумали.
но большинство мейнстрим языков его смогли осилить, хоть даже и через боль. кто не смог скоро отомрет, раз плохо умеет адаптироваться?
если тебя не устраивают существующие библиотеки, можешь написать свою. или кто по-твоему должен это для тебя делать?
поэтому и имеем 100500 разных библиотек, которые хрен вместе подружишь и проще еще один велосипед накостылить
а кто же его переусложнил? прибегали всякие хипстеры с криком, давайте сделаем очередные яйца в профиль
На современном С++ (вернее, на стандарте 11 и выше) вообще можно писать как на питоне. Чуть ограничить совместимость с С-шными практиками, и это все что нужно, чтоб несиляторы не наделали себе в штаны. А то понаберут несоиляторов, вроде тех небинарных из мозиллы, которых к программированию просто нельзя подпускать. А те потом верещат на весь тырнет, что это ЯП-ы плохие, а не они бараны.
Это ещё они про MISRA не слышали — вообще массовый подрыв произошёл бы.
Подрыв пока происходит только у тебя.
>На современном С++ (вернее, на стандарте 11 и выше) вообще можно писать как на питоне.С 14ю способами инициализации, ага.. что еще с чем сравнишь?
>С 14ю способами инициализации, ага..Выбери один по вкусу, и используй только его. Или абы чо ляпнуть?
Проблемы начинаются при использовании чужих библиотек - и вдруг тебе оказывается нужным выучить все нюансы каждого способа инициализации.
40 (сорок) вариантов константных выражений.
>небинарных из мозиллы, которых к программированию просто нельзя подпускать.Что за стереотипы. Откуда ты лохматый такой? Из пещеры?
> На современном С++ (вернее, на стандарте 11 и выше) вообще можно писать
> как на питоне. Чуть ограничить совместимость с С-шными практиками, и это
> все что нужно, чтоб несиляторы не наделали себе в штаны. А
> то понаберут несоиляторов, вроде тех небинарных из мозиллы, которых к программированию
> просто нельзя подпускать. А те потом верещат на весь тырнет, что
> это ЯП-ы плохие, а не они бараны.Можете предоставить ссылку на свою проект в котором с++ раскрывается как простой и понятный ЯП, чтоб мы "бараны" смогли приобщиться в прекрасному? Или будет как всегда? :D
Вообще говоря, авторы Си задумывали так, что программы на Си будут использоваться со сборщиком мусора.По признанию самого Кернигана, ни одна программа на Си не должна превышать 500-1000 строк и в программе не будет более 1-2 вызовов malloc.
А всё, что крупнее, будет уже обвязками на shell вокруг маленьких Си программ.
Хм, весьма интересно, а нет какой-нибудь ссылки на исходник или около того? Хотел бы детальнее ознакомится с вопросом
AWK programming language, Aho/Kernighan/Weinberger.The Unix Programming Environment, тот же Kernighan.
Вторая книга особенно показательна, проводится в пример, например, troff, который состоит из десятка маленьких программ, соединённых пайпами.
AWK это вообще по сути C со сборщиком мусора.
В первой же утверждается, что на AWK можно решить большую часть нужных в повседневной жизни задач. Ну, а небольшое количество оставшихся, чувствительных к скорости, да, придется на Си.
Благодарю, любопытное наблюдение. Стоит еще добавить, что сам компилятор Си состоит (состоял) из препроцессора и собственно транслятора, соединённых пайпом. При такой архитектуре сборщик мусора может быть реализован "заменой препроцессора", что и сделано в языке Vala.
Ага, верим. Особенно учитывая что Си создавался чтоб переписать UNIX с/на PDP11. Включая его ядро. Ядро с не более 1-2 malloc'ами и не длинее 1000 строк, и обвязки в ядре(!) на шелле(!) - это реально круто, без стёба (нет)
При чём тут ядро?Во-первых, ядро тогда было сильно меньше.
Во-первых, в ядре не так много malloc'ов.
В-третьих, специально чтобы избежать большого количества кода в ядре, как раз и была придумана концепция "всё есть файл", чтобы драйвера были не сложными монстрами с кучей системных вызовов, а просто маппили устройство на файл, и дальше пусть юзерспейс разбирается.
Обычный программист почти никогда не пишет ядерный код, поэтому ваша критика ну совсем пустая.
Изначально вброс был, что Си создавался чтоб писать проги не длинее 1000 строк и с 1-2 malloc'ами. Но Си создавался чтоб портировать UNIX, а не для того что ты только что придумал.> В-третьих, специально чтобы избежать большого количества кода в ядре, как раз и была придумана концепция "всё есть файл", чтобы драйвера были не сложными монстрами с кучей системных вызовов, а просто маппили устройство на файл, и дальше пусть юзерспейс разбирается.
Плйать, да откуда ты всё это берешь? Почему тогда физические сетевые интефрейсы не файлы /dev? А если все было бы не файл, а просто в памяти лежало без отражения на фс, то syscall'ы бы не работали?
З.Ы. Напишешь amdgpu.ko чтоб не больше 1000 строк там было? Ну или может ядерный гипервизор?
Чо так возбудился-то? Он просто процитировал мнение Кернигана, из книги написанной самим Керниганом. Кстати, Керниган не дурак и дельные вещи говорит.
> Изначально вброс был, что Си создавался чтоб писать проги не длинее 1000
> строк и с 1-2 malloc'ами. Но Си создавался чтоб портировать UNIX,
> а не для того что ты только что придумал.Не вижу противоречий, а вот ты что-то себе придумал о "UNIX":
https://github.com/dspinellis/unix-history-repo/tree/Researc...
> covering the period from its inception in 1970 as a 2.5 thousand line kernel and 26 commands...
> Плйать, да откуда ты всё это берешь? Почему тогда физические сетевые интефрейсыКакие-какие сетевые интерфейсы в начале 70х?
> З.Ы. Напишешь amdgpu.ko чтоб не больше 1000 строк там было? Ну или
> может ядерный гипервизор?Я тебя дважды расстрою
1) куда ты в тот PDP11 собрался AMD-GPU втыкать и что именно в ядерном гипервизоре гонять?
2)
>> "По признанию самого Кернигана, ни одна программа на Си не должна превышать 500-1000 строк"
> Напишешь amdgpu.ko чтоб не больше 1000 строк там было?Л-логика, че. Писать-то и не такое писали (в смысле объема - раз в 10 больше и на асме) еще не так уж и давно, но удовольствие сие таки ниже среднего ...
> Ага, верим. Особенно учитывая что Си создавался чтоб переписать UNIX с/на PDP11.Ты эта, посмотри старенькие сишные "API" и ответь нам, хипстрорам, на один вопрос:
почему в структах (когда-то) было принято добавлять префиксы к названиям полей:
struct tm {
int tm_sec; /* seconds after the minute [0-60] */
int tm_min; /* minutes after the hour [0-59] */struct ar_hdr {
char ar_name[16]; /* name */
char ar_date[12];
struct sockaddr {
unsigned char sa_len; /* total length */
sa_family_t sa_family; /* address family *
Потом еще раз подумай над своим яростным "неверю, вы фсе врети!"
> Вообще говоря, авторы Си задумывали так, что программы на Си будут использоваться
> со сборщиком мусора.
> По признанию самого Кернигана, ни одна программа на Си не должна превышать
> 500-1000 строк и в программе не будет более 1-2 вызовов malloc.
> А всё, что крупнее, будет уже обвязками на shell вокруг маленьких Си
> программ.Именно так. си создавался в парадигме unix - простой язык для простых программ которые делают только одну вещи и связываются через шел. И для этой цели он прекрасно подходит. Только вот аффторы с++ ставили своей целью объять не объятое и сделать яп на котором можно сделать всё на свете и без потери производительности. Ну и в итоге получилось то что получилось.
> аффторы с++ ставили своей целью объять не объятое и сделать яп на котором можно сделать всё на свете и без потери производительностиНа момент появления C++ (а это уже ближе к середине 80-х) язык C далеко ушёл за рамки "маленьких" утилит в 1000 строк. Язык C++ - это примерно тот же C, только с возможностью ООП и мелочевкой (вроде перегрузки функций, inline и т.д.). А чуть позже и ещё с разными плюшками вроде исключений, шаблонов и т.д.
В целом на C++ можно сделать всё, что можно сделать на C. Только потребление памяти повыше выходит (в основном из-за шаблонов и способов реализации inline). Первые версии C++ вообще компилятора не имели и просто переделывали C++ в программу на C, которая потом компилилась обычным C-компилятором.
Вот думаю.. если ИИ начнет писать код, то скоро требование человекочитаемости станет не важным... Тогда зачем все эти новые стандарты?
Не начнет, сейчас только общий код выдает, который надо много править.
А если начнет то тостеры будут писать композиции произведения получше людей, что обесценит это.
>если ИИ начнет писать кодИИ не будет писать код, если ему задачу не поставить. И задачу нужно будет ставить однозначно и в подробностях, если это не хелловрот. И вот тут начинают говорить про ЯП, который почти как естесвенный ЯП, на котором будут ставить задачи ИИ, а тот уже сразу генерить машинный код. То есть, ИИ как компилятор, и ЯП почти как естественнй язык, на котором погроммисты будут расказывать ИИ что и как должна делать прога. Это не грезы, а уже обозначенный вектор развития софтоклепства с применением ИИ. Вот это тема. Сразу в динозавры все прошлые практики погроммирования.
Э... галюцинированние без которого невозможно ни одно ИИ как на разработку ложится?
>Э... галюцинированниеНе беспокойтесь. Чуваки еще лет пят поколдут с матрицами, ембедингами и кучей остальных приколов типа "внимания", и галюцинаций не будет.
> и галюцинаций не будетЭто математически невозможно.
Машинное обучение - это сжатие. Причем только той части которая входит в обучение.
Если не существует частей не входящих в обучение, то обучать смысла нет.
А если есть части не входящие в обучение, то галюцинации гарантированы.
Кто запрещает контролировать одну сеть другой?
> То есть, ИИ как компилятор, и ЯП почти
> как естественнй язык, на котором погроммисты будут расказывать ИИ что и
> как должна делать прога. Это не грезы, а уже обозначенный вектор
> развития софтоклепства с применением ИИ. Вот это тема. Сразу в динозавры
> все прошлые практики погроммирования.В октябре 1981 года Японское министерство международной торгов-
ли и промышленности объявило о создании исследовательской организа-
ции — Института по разработке методов создания компьютеров нового
поколения (Institute for New Generation Computer Technology Research
Center). Целью данного проекта было создание систем обработки инфор-
мации, базирующихся на знаниях. Предполагалось, что эти системы бу-
дут обеспечивать простоту управления за счет возможности общения с
пользователями при помощи естественного языка. Эти системы должны
были самообучаться, использовать накапливаемые в памяти знания для
решения различного рода задач, предоставлять пользователям эксперт-
ные консультации, причем от пользователя не требовалось быть специа-
листом в информатике. Предполагалось, что человек сможет использо-
вать ЭВМ пятого поколения так же легко, как любые бытовые электро-
приборы типа телевизора, магнитофона и пылесоса. Вскоре вслед за
японским стартовали американский и европейский проекты.
>>если ИИ начнет писать код
> ИИ не будет писать код, если ему задачу не поставить. И задачу
> нужно будет ставить однозначно и в подробностях, если это не хелловрот.
> И вот тут начинают говорить про ЯП, который почти как естесвенный
> ЯП, на котором будут ставить задачи ИИ, а тот уже сразу
> генерить машинный код. То есть, ИИ как компилятор, и ЯП почти
> как естественнй язык, на котором погроммисты будут расказывать ИИ что и
> как должна делать прога. Это не грезы, а уже обозначенный вектор
> развития софтоклепства с применением ИИ. Вот это тема. Сразу в динозавры
> все прошлые практики погроммирования.И.. гораздо проще написать то, что железяга выполнит более менее однозначно (однозначно без глубоких оптимизаций), чем создавать огромную систему, которая если заглючит, то хрен знает как это пофиксить, т.к. компилятор "встал не с той ноги".
> хрен знает как это пофикситьТак в этом и цель внедрения. Остальное можно исправить, изучить, в крайнем случае отреверсить, даже если нет исходников.
Даёшь ещё больше сахару в ЯП!!!!
> Профили близки к применению флагов "-Wall" и "-Wextra" при компиляцииТак а кто ж раньше то мешал это юзать?)
> Даёшь ещё больше сахару в ЯП!!!!Где ты это увидел в новости?
А настройки профилей это не расширяет список того что надо знать и прописывать куда то?
Еще раз: При чем здесь синтаксический сахар, о котором ты вещал?
>Даёшь ещё больше сахару в ЯП!!!!Что само по себе хорошо.
Наконец то достойный конкурент rust y, если я правильно понимаю.
Нет. Потому что в Раст по умолчанию всё опасное запрещено. Его можно разрешить частично, но обычно это делается в огороженных местах. А тут же профили предлагается ставить только там, где может быть опасно. То есть, вероятность возникновения ошибок всё ещё выше, чем в Раст.
Очень даже логично заюзать флаги при компиляции, не ломая кодаХочешь пиши Си с классами, хочешь C++
>Хочешь пиши Си с классамиТак не делай, сразу пиши мета-код в соответствии с последним стандартом.
> Хочешь пиши Си с классами, хочешь C++и получится лапша из смеси того и другого обмазаная CVE, что собственно практика и показывает
Не получится, для этого есть профили, чтобы отделить одно от другого
Проблема в том, что профили - дело добровольное. Можно и забыть выставить. А раз так, забывать обязательно будут.
> По мнению Страуструпа, времени осталось очень мало и необходимо до 2026 года успеть предпринять какие-то мерыСмешно. Там просто ГОРЫ важного кода на С++ и С, который никто не будет переписывать. Разве что с помощью AI. Но они даже крипту осилить не могут пока.
они... они - это не вы?
Сейчас все навалятся на раст, потребуют чего не хватает. Раст скатится в еще больщее УГ. Все ошибки все равно ловить не будет. Потом будете сами стонать раст - не торт! Скриньте.
Они так уже с TCP на OSI переходили, даже целый RFC наваяли, №1169 - с дедлайном август 1990го.
В айти такое форсирование не работает.
> В айти такое форсирование не работает.Работает, но не в контексте TCP.
Просто на тендер не допустят часть фирм. А другие пройдут.
Есть маленькая веротяность, что на тендер нитко не придет, но учитывая суммы - это очень-очень-очень маловерятно))
>Агентство по кибербезопасности и защите инфраструктуры США и ФБР стали более активно продвигать среди производителей ПО идею перехода на языки, безопасного работающие с памятью.Теперь все стало понятно.
Тот кто раньше писал что допилят C++ чтобы сделать безопасным и что будет такая идея был прав однако.
Так других вариантов и нет. Бьёрн Страуструп абсолютно прав. Нужно допиливать инструменты.
его не допиливать нужно, а выкидывать, но жалко
пилите редокс, шура, там золото... )))
> язык С++ уже содержит все возможностиНихрена он не содержит. Во-первых, о какой безопасности можно говорить без поддержки лайфтаймов в синтаксисе? А без явной связи мутекса с данными которые им синхронизируются? Сделайте хотя бы чтобы нельзя было обращаться к moved-from объектам, пока это вообще абсолютно легальное поведение.
Если это будет отключаемой или опциональной возможностью никто пользоваться не будет.
> Если это будет отключаемой или опциональной возможностью никто пользоваться не будет.Будут когда государство при закупке напишет в тендере, что софт должен компилироваться с этой опцией,
> А без явной связи мутекса с данными которые им синхронизируются?1. GUARDED_BY
2. Можно свою обертку написать по аналогии MutexGuard раста, например, folly/Synchronized.h
Rust это не только про безопасную работу с памятью, но и про оптимизацию работы с памятью. Получится ли в C++ при включении безопасного профиля автоматически применять __restrict к указателям?
Допустим нет, не получится. Тогда получается, что раст отстой потому что в LLVM __restrict не будет применяться к уккзателям автоматически, а раст компилируется LLVM'ом.
В LLVM __restrict не будет применяться потому что его там нет, там есть атрибуты noalias, nocapture и другие, которые использует Rust. Но ты слышал краем уха, что в rustc используется LLVM и на этом твои познания заканчиваются.
> там есть атрибуты noalias, nocapture и другие, которые использует RustНо зачем? Во имя чего? Почему божественный раст, позволяющий безопастно работать с памятью, использует (и главное зависит!) от каких-то там аттрибутов в плюсовой дыряшке? А если из-за use-after-free или неицилиализированной переменной в LLVM, потом бинарник из LLVM-IR, который раст так старательно и безопастно в области работы с памятью генерировал, получится с дыренью. Ты об этом подумал?!
А почему бы и в самом деле не реанимировать Паскаль? К нему претензий нет у Агентства по кибербезопасности и защите инфраструктуры США и ФБР.
Паскаль приятнее ржавчины во всех отношениях.
Он никуда не девался, FreePascal потихоньку что то там пинают еще оставшиеся в живых олды. Сам пару лет назад делал один проект на нем и даже получилось лучше всех новомодных шляп. Но время идет.. теперь копаюсь в rust и go, так как ума не хватило осилить сборку проектов кhоме как в IDE паскаля. Если интересно покопать, CodeTyphon вам в помощью.
Это лишь вопрос финансирования. На Паскале очень много всего написано, в отличие от Го и Раста. По любому далеко не всем понравится ковырятся в синтаксисе Раста, поэтому возрождение Дельфи - уже не звучит как шутка.
Пруф: “Software Memory Safety” Cybersecurity Information Sheet
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...Цитата: "Examples of memory safe language include Python®, Java®, C#, Go, Delphi/Object Pascal, Swift®, Ruby™, Rust®, and Ada"
Лучший кандидат на замену Си++ - это Паскаль. На втором месте Го. Раст - это если уж совсем нет вариантов.
Набрасываешь на вентилятор. Из цитаты видно, что там перечислили языки программирования. Паскаль там не лучший, и не первый. Он просто в ряду языков.
interfacetype
TCustomClass = class
FSomeOtherClass: TSomeOtherClass;
public
function GetOtherClass: TSomeOtherClass;constructor Create;
destructor Destory; override;
end;
implementationuses
Classes;
//----------------------------------------------------------------
constructor TCustomClass.Create;
begin
FSomeOtherClass := TSomeOtherClass.Create;
end;
//----------------------------------------------------------------
destructor TCustomClass.Destroy;
begin
FreeAndNil(FSomeOtherClass);
end;
//----------------------------------------------------------------
function TCustomClass.GetOtherClass: TSomeOtherClass;
begin
Result := FSomeOtherClass;
end;
//----------------------------------------------------------------
var
customClass: TCustomClass;
someOtherClass: TSomeOtherClass;
begin
customClass := TCustomClass.Create;
try
someOtherClass := customClass.GetOtherClass;
finally
FreeAndNil(someOtherClass);
FreeAndNil(customClass);
end;
end.
//----------------------------------------------------------------
Счастливой отладки, motherfucker.
Во Free Pascal'е нет интеллектуальных указателей, там всё должно быть написано явно и вручную, нет автоматизации. Он хорошо подходит для обучения основам программирования, но для фирм самое главное - скорость программирования и он не подходит, потому что вручную освобождать, нет функционального программирования, нет перегрузки операторов
Тогда объясните мне почему в АНБ он объявлен безопасным?
АНБ это сказала про Delphi, а в нём есть интеллектуальные указатели и много чего.
Да, он многословен, нет тех "ништяков" которые давно завезли в Си++. Мне Си++ тоже больше нравится.Получается, что "безопасность" - это чисто когда искусственно что-то ограничивают в мейнстриме?
Тогда почему бы просто не выработать гайдлайн безопасного программирования на Си++ и его строго придерживаться?
При чём тут язык вообще?
Так я и говорю что дело не в языке, а в индустрии. В целях, в приоритетах.
>Тогда почему бы просто не выработать гайдлайн безопасного программирования на Си++ и его строго придерживаться?Офигеть как просто ☺. Сначала выучи Стандарт (ты не можешь быть квалифицированным C++-программистом, не зная Стандарт, ведь не можешь?). Потом выучи "гайдлайн безопасного программирования" такого же объёма. Ну, а потом просто программируй, не делая ошибок.
Так Бьёрн Страуструп как раз и предлагает для этих целей инструментальное упрощение в виде профилей.
>Офигеть как просто ☺. Сначала выучи Стандарт (ты не можешь быть квалифицированным C++-программистом, не зная Стандарт, ведь не можешь?). Потом выучи "гайдлайнТы не прав. Прежде чем начать программировать, он должен 5 лет изучать математику. Уж потом "каунт хеловрот".
>нет функционального программированияВ свежих делфях есть лямбды, дженерики и циклы на итераторах — самый минимум чтобы начать функциональное мракобесие в коде.
Но вообще очень хорошо, что у паскаля слава процедурного и объектного языка. Он оазис чистоты подхода в мультипарадигменном болоте языков тащащих все самое модное без разбора. А функциональщина в целом это тупик — мозгового онанизма много, а практического смысла мало.
> Но вообще очень хорошо, что у паскаля слава процедурного и объектного языка.
> Он оазис чистоты подхода в мультипарадигменном болоте языков тащащих все самое
> модное без разбора.Золотые слова.
Язык для эффективного решения задач.
А у Си++ был главный фейл: уродливое изобретение Саши Степанова - библиотека STL, чрезменное увлечение шаблонным метапрограммированием по лунным заветам Александреску, куча многословных выражений, чего стоит постоянное std:: , постоянный оверинжениринг в проектах.
Причесать Си++ до вменяемого вида вполне реально, но это уже будет не Modern C++ style.
Да, итераторы не всем понятны. Но зачем столько слов?
Я поддерживаю Страуструпа, профили с отключением фич хоть чуть-чуть, но сделают программы надёжнее. Хотя ... проблема даже не в конкретном языке, а в индустрии.
Пока не понятно, кто-нибудь может объяснить. То есть включаешь lifetime и двухсвязный список перестаёт билдится или будет некий unsafe режим?
Это же не стандарт, это предложение Страуструпа. Он конечно в комитете сидит как почётный и пожизненный, но это одно из предложений. Аналогичных предложений уже штуки 3-4 было и по разным причинам их заворачивали, или отправляли на доработку. Это ещё около года будут обсуждать и может быть тоже завернут.Конкретно Страуструп сказал, что надо так:
> Привязку к профилям можно задавать не только для проекта и файлов (например, "[[profile::enforce(type)]]"), но и включать/отключать на уровне отдельных конструкций (например, "[profile::suppress(lifetime))] this->succ = this->succ->succ;").Ну т.е. можешь отдельные инструкции пометить как "проверено, всё ок". Можешь для всего файла отключить, можешь для всего проекта отключить (а так по контексту новости - скорее "не включать").
Пока ещё не поздно всё это ввести, главное чтобы не тянули до последнего
П.С: Даже если С++ умрёт, я всё равно буду его любить :heart:
>(например, "[profile::suppress(lifetime))] this->succ = this->succ->succ;"И эти люди называют Common LISP нечитаемым?
Щас бы сранвивать язык с GC и без. CLS при этом во сколько раз медленней лучше озвучить для начала?
Нет, я говорю, что у меня от однообразия скобочек в глазах рябит.
> arithmetic - блокируются целочисленные переполнения, запрещены знаковые/беззнаковые преобразования, изменяющие значениеДопустим мне нужно получить младший байт двухбайтового слова. И как это сделать без преобразований, изменяющих значение? Ну то есть да, я-то могу сообразить, что в static_cast<uint8_t>(x & 0xFF) приведение не изменяет значение, но как компилятор об этом догадается? А раз не догадается, то придётся писать [profile::suppress(arithmetic))]? Но тогда пропадает почти весь смысл затеи.
Для сравнения в Rust это пишется как u8::try_from(x & 0xFF).unwrap() и если лажанул, будет паника.
Современный компилятор прекрасно знает, что "&0xFF" байт не превысит (если у тебя байт 8-битный).На delphi было так https://github.com/glprog/dcpcrypt_laz/blob/master/Hashes/dc...
Обрати внимание на "{$R-}{$Q-}" это оно и есть.
Интересно. А особенно интересно как они будут это впихивать в стандарт. Одно дело — добрая воля компилятора, который хочу анализирую, не хочу — не анализирую, и совсем другое — описать анализ потока данных в стандарте.
Некоторые тут уже собрались хоронить С++, я скажу - подождите. Смотрите, есть компания Red Hat, она лидер в мире Linux-дистрибутивов, и она делает новую версию менеджера пакетов DNF 5 на С++ (не на Rust'е!) и переписывать его на Rust не собирается.
https://github.com/rpm-software-management/dnf5Привязки для Python уже есть, для Perl и Ruby в разработке, а для Rust'а не только нет, но и не планируются даже. Так что старичку С++ ещё придётся помучатся ...
> Некоторые тут уже собрались хоронить С++, я скажу - подождите. Смотрите, есть
> компания Red Hat, она лидер в мире Linux-дистрибутивов,А есть компания гугл, которая делает AOSP, хромиум и хромось.
И там раст во все поля.А еще есть амазон которая, и клоудфаря, которая конечно поменьше...
> Привязки для Python уже есть, для Perl и Ruby в разработке, а для Rust'а не только нет, но и не планируются даже.
Про "не планируется" это ты сам выдумал?
> Так что старичку С++ ещё придётся помучатся ...
И правда) Вместе с программерами.
Вы бы хотя бы статистику языков в перечисленных проектах на гитхабе посмотрели бы. Например, rust там в принципе нет. А это значит, что его там меньше 4%.
Где во все поля? В фантазиях.
Rust, он такой он скрытный.
Ты не видишь его на git хабе а он есть.
Всё, С++ спасен: https://www.reddit.com/r/cpp/comments/1j1lywn/release_of_the.../
Да, я пару дней назад уже замечал в списках этот проект (https://github.com/rsashka/memsafe)Непонятно только почему так мало активности/популярности.
Пока это только proof-of-concept, надо думать.
Если нащупают решение, то это будет революция.
Уже Carbon делают, надо только подождать, затяните пояса.
Тут, наверное, кто-нибудь уже пошутил про раннее зажигание насчёт первого апреля?
Нет. Плюсовики напряжены. Растаманы издеваются.
> Нет. Плюсовики напряжены. Растаманы издеваются.Вот жеж недалёкие и неблагодарные! Жизнь целого раста зависит от развития C++, потому что LLVM написан на C++.
Его имя – Бьярне Строуструп.
Спасибо. Теперь мы знаем, как его имя произносится на норвежском языке и английском языке.
Он кстати датчанин, не норвежец
Устоявшееся в языке имя != правильное произносимое имя.
> Его имяУ нас в 8Д аналогичный случай был. В кабинете литературы висит "Вильям Шекспир", а в учебнике по литературе написано "Уильям Шекспир". Такие дела...
И ни один из вариантов не является правильным.
Нет, его имя Бьёрн. Это мой сынуля.
активиздов CISA прикрыли, может будут более адекватные идеи.
Си++ за столько лет хорошо зарос гавном, в отличии от С
> Си++ за столько лет хорошо зарос авном, в отличии от СКоторый им был изначально (начиная с того цирка под названием стандартизация)))
Все таки не зря бедный автор ругал комитетчиков, которые сотворили такое, на чем писать нормально невозможно.
>> Си++ за столько лет хорошо зарос авном, в отличии от С
> Который им был изначально (начиная с того цирка под названием стандартизация)))
> Все таки не зря бедный автор ругал комитетчиков, которые сотворили такое, на
> чем писать нормально невозможно.https://www.stroustrup.com/From-C-to-Cpp-dmr.pdf
про комитет:
The upshot is that I think they did a good job. Certainly, though, if I'd continued to work on things, some of the details would have been different.
...
So, to summarize X3J11, the two largest things the committee did were function prototypes and the standardization of the library. It was more work than anybody expected, but I'm perfectly happy with what they did.
Речь была про С и Ритчи.
То что Бьйорни не будет ругать комитет в котором ему дали пожизненное место - это понятно.
> Речь была про С и Ритчи.
> То что Бьйорни не будет ругать комитет в котором ему дали пожизненное
> место - это понятно.Вообще-то это интервью Ритчи.
И да, там он ругался на "no alias" и в стандарт этот "no alias" не приняли. Ещё ругался на прототипы функций, точнее, как я понимаю, на то, что оставили и старый вариант и новый. И тоже, его пожелание как-то учли.
Лучше бы сишку или какой-то аналог вроде D развивали с интерфейсами, замыканиями и структурами вместо всего этого.