Rust всемогущий: ищу истории успеха

character(LEN=:),allocatable::str
include"text.txt"
Print'(A)',str
pause
end

text.txt

str="А.С.Пушкин"

И снова - здравствуйте!

по теме говори. ты рекурсию увидел или нет?

Не знаю, какое отношение к теме имеет рекурсия, но нет её в linked list, за исключением патологических случаев «учителей», и их слепых последователей.

Не знаю, какое отношение к теме имеет рекурсия, но нет её в linked list,

это у тебя сработал «ген осторожности», когда ты аккуратно пишешь «linked list», хотя речь идет о списке на смартпоинтерах, где элементы связываются через нечто вроде unique_ptr.

мы не говорим о списках воообще (куда ты осторожно свалил), а о списках на смартах(речь то идет о русте, где смарты - наше все, вернее о переносе «парадигм руста» в с++).

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

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

https://solarianprogrammer.com/2019/02/22/cpp-17-implementing-singly-linked-list-smart-pointers/

тут об этом говорится.

Obviously, this is a serious bug in our code. As a side note, if you reduce the numbers of elements to something like 10000 nodes, the program ends without a stack overflow.

Let’s remove the above limitations by creating a clean function member that when called will iteratively go through all the list nodes and remove them one by one:

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

 void clean() {
    while(head) {
        head = std::move(head->next);
    }
 }
 
 ~List() {
    clean();
 }

Так разговор про rust, там конечно можно raw-поинтерами развлекаться, но тут не нужно.

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

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

Какой пипец! Спасибо что предупредили - теперь я вот это вот и 3х метровой палочкой шерудить не буду! Ну нафиг такие приключения…

вот видишь, можно спокойно, без скандала во всем разобраться.

Но Lorawan NS - это вообще довольно наркоманская штука так-то, там своя атмосфера.

Там очень, ОЧЕНЬ, своя атмосфера и отсутствие стандартизации. На столько, что при интеграции в новую сеть приходится вносить существенные изменения в фирмварь.

MVP

Нет, софт версии 2.х.х. Думаю, что чувак просто решил изучить новый хайповый ЯП.

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

Это камень не только в огород смартпоинтеров, но к большей части современного программирования, где повсюду наблюдаются «спагетти-данные». И тут проблема даже не в том, что нет современного авторитетного Дейкстры, который бы запретил использовать GOTO в данных. Нет понятной альтернативы.

Я уже говорил в другой теме, что без смартпоинтеров или сборщака мусора проблематично реализовать большинство паттернов GoF. Придумать что-то можно. Например, фабричный метод мог бы не создавать новый объект, а видоизменять передаваемую ему заготовку (изменять её класс, например). Где-то вместо наследования можно было бы использовать варианты. Но в современных языках не очень удобно производить такие действия. Будет громоздко и плохо читаемо.

Это камень не только в огород смартпоинтеров, но к большей части современного программирования, где повсюду наблюдаются «спагетти-данные».

я не к тому что смарты бессмысленны. смарт типа unique_ptr, просто удобней, чем глазками следить за выходом из блока. shared_ptr, необходим в случаях когда владение отследить невозможно и приходится ссылки считать. weak нужен, когда счет ссылок ломается на циклических ссылках.

тем не менее сам концепт владения не является поводом для провозглашения эпохи смены парадигм. просто такие вот полезные абстракции.

абстракции классов и ООП мне вот кажутся несравнимо мощнее. сливать ооп в угоде владению, как в русте - это глупо. потому руст с плюсами и сравнивать нельзя. пусть сравнивают руст с си.

Я знаю, какие бывают смартпоинтеры. Вопрос в другом. Вот мы тут вроде пришли к выводу, что они не нужны в огромных списках. Но и в маленьких связях между объектами они тоже сомнительны.

Возьмём простой случай. Есть объект parent у которого есть объекты child1 и child2 (тут не наследование, а владение), которые должны обмениваться данными между собой. Если мы свяжем три объекта через смартпоинтеры, то это будет удобно, но получим монолит. Это будет почти то же, что пользоваться глобальными переменными.

Если child1 и child2 ничего не знают друг о друге и обмениваются данными через parent, то это менее удобно, но нет монолита и не нужны смартпоинтеры: child1 и child2 будут уничтожены раньше parent-а, поэтому они могут обращаться с ним через простой указатель или ссылку. А могут и про parent не знать, пусть он сам весь обмен ведёт, если требования по быстродействию позволяют.

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

сливать ооп в угоде владению, как в русте - это глупо

Не уловил как ООП противоречит владению.

Возьмём простой случай. Есть объект parent у которого есть объекты child1 и child2 (тут не наследование, а владение), которые должны обмениваться данными между собой.

что значит - обмениваются данными??? в терминах акторов обмениваются данными акторы - проще говоря треды или процессы.

а обьекты в пределах одного треда скорее «используют» друг друга, это отношение вида dependence.

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

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

что значит - обмениваются данными?

Ну можно конкретный пример с GUI привести, например, когда есть окно с вкладками (как листы в Excel, например). Нажали кнопку в одной вкладке - изменилось текстовое поле в другой и наоборот. Можно, конечно, контролы всех вкладок в единое пространство имён свалить. Но это будет месиво. Поэтому лучше для каждой вкладки свой объект иметь.

Потоков и процессов нет. Есть очередь сообщений от пользователя, которые обрабатываются разными объектами и полученные данные передаются в другие сестринские объекты системы. Какую тут ссылку передашь, если объект начинает работать по функции обратного вызова?

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

Проще сделать иначе: перечислить случаи, когда смартпоинтеры на самом деле нужны. Сходу могу вспомнить только vector с умными указателями на объекты разных классов, с одним предком. Да и тут могло бы быть удобнее и эффективнее, если бы был какой-нибудь умный vector.

Это, кстати, странно, если ns не самодельный. Там основные проблемы были с переходом между 1.0.3 к 1.0.4 и тем, что 1.1 почти никто не стал использовать в итоге. Получился зоопарк. Chirpstack все версии вроде корректно обрабатывает.

Скажем так, если почитать спеку и не особо ломать семтековский стек, то работать должно везде примерно одинаково.

Изучаю nushell. Непривычно, но пока нравится. :)

Ну можно конкретный пример с GUI привести, например, когда есть окно с вкладками (как листы в Excel, например). Нажали кнопку в одной вкладке - изменилось текстовое поле в другой и наоборот.

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

Это всё более высокий уровень, чем мы обсуждаем. Если бы речь была о C#, где всё это из коробки, почти на уровне синтаксиса языка, то можно было бы согласиться. Тут же мы берём целый фреймворк, у которого в глубинах могут быть аналоги умных указателей.

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

это делается на синхронных ивентах

И снова Вы свои вусмерть пересинхронизированные очереди рекламируете? Вы таки ещё не написали свой IntrusiveEventSource / IntrusiveEventSink с прямым dispatch? Двойка Вам…

https://github.com/shssoichiro/oxipng

«пересинхронизированные очереди», клован, это стандартные каналы сообщений, например включенные в golang, как channels, и являющиеся там основным методом синхронизации, так и передачи данных между потоками.

а синхронные ивенты - классический механизм синхронной диспетчеризации событий в event-driven модели и есть везде, в яве, шарпе, дельфи, жабаскрипте, во всех приличных фрймворках вне зависимости от языка и так далее.

ты как пролетарий из «Собачьего сердца» - там мариан, и андриан, а у меня - мандриан.

клован

Обо всех по себе судить не надо, плохая привычка.

а синхронные ивенты - классический механизм синхронной диспетчеризации событий в event-driven модели и есть везде

Так что ж вы лезете со своими очередями в каждую дырку?

ты как пролетарий из «Собачьего сердца»

Ну, а себя вы, наверное, профессором Преображенским возомнили?

Так что ж вы лезете со своими очередями в каждую дырку?

с какими очередями и куда я лезу? вы меня с кем-то путаете.

мне вообще кажется, что вы, в основном, не понимаете с кем говорите и на какую тему.

вы меня с кем-то путаете.

Ой, нет - конкретно вас я теперь никогда и ни с кем не перепутаю.

не понимаете с кем говорите

И с кем же?

И с кем же?

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

И с кем же?

вы сначала определитесь с темой.

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

Но, что-то мне подсказывает на этот вопрос ответа я не получу, так что не утруждайтесь.

таки мне утруждаться или отдохнуть?