LINUX.ORG.RU

Rust vs C

 ,


3

7

Я Rust не знаю.
Допустим решил я написать быстрый лексер (разбиватель токенов),как я делаю это в Си:

typedef struct {
    const char* text;
    size_t      text_len;
    size_t      text_pos;

    const char* token;
    size_t      token_len;
} lexer_t;
 
void lexer_next_token(lexer_t* lexer);

И я могу получить все токены без выделения памяти,я просто иду по тексту и ставлю lexer_t.token в начало токена, и в token_t.token_len записываю длинну токена.А в расте как сделать подобную вещь?Тоже без выделения памяти естественно (ну кроме стека,где выделяется код возврата и 2 size_t для функии next_token).Верней можно ли сделать такое в расте?



Последнее исправление: linuhs_user (всего исправлений: 2)

Ответ на: комментарий от DarkEld3r

Теоретически, можно даже лучше из-за того, что сценарии использования собираются в рантайме. На практике - другой вопрос.

Profile-Guided Optimization

O02eg ★★★★★
()
Ответ на: комментарий от DarkEld3r

Теоретически, можно даже лучше из-за того, что сценарии использования собираются в рантайме. На практике - другой вопрос

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

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от ckotinko

идея языка С и С++ в том, что ты получаешь код максимально близкий к тому что написал

Как там в 70-х?

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

А, понятно: твоя сишка - не наша сишка.

anonymous
()
Ответ на: комментарий от ckotinko

ваша сишка это шайтан-арба с глюками

Это записано уже в ANSI C. Я горжусь только тем что не слоупок :D

Вопрос-то предельно ясный: либо выбираем C/C++ и пишем, постоянно удерживая стандарт в голове, ибо так порешили отцы. Либо берем другой язык. А ты пытаешься усидеть на двух стульях - естественно, где-то возникает боль :D

anonymous
()
Ответ на: комментарий от vodz

Вот, скажем, взять старый советский Эльбрус. Там на уровне железа наворочена безопасность, и оно тормозит собственно ровно потому же

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

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

потому что программно их жевать (как сейчас) железо тех лет не позволяло.

Да лана. Ада, PL/1 и прочий Лисп... А Эльбрус тормозил именно обидно, так как эта защита была скорее заковыристыми палками в колёсах, изнутри на языках высокого уровня эта защита во-первых не управлялась, а во-вторых была ну очень сама в себе, чужие наработки просто так взять не откуда.

vodz ★★★★★
()
Ответ на: комментарий от vodz

и прочий Лисп

https://ru.wikipedia.org/wiki/Лисп-машина

Проверка типов впоследствии была улучшена и автоматизирована, когда традиционный размер машинного слова в 32 бита был увеличен до 36 бит у Лисп-машин модели Symbolics 3600, и даже до 40 бит или больше (обычно избыточные биты использовались для кодов коррекции ошибок). В первом блоке добавочных битов хранился тип данных (что и делало архитектуру теговой), а оставшиеся использовались для CDR-кодирования (когда обычные элементы в связном списке сжимались примерно вдвое), упрощая сборку мусора на порядок.

Таким же образом Эльбрус - это автокод-машина. Ни о какой безопасности тогда не думали, потому что тогда это тебе не сейчас (тогда доступ к машине надо было иметь физический что бы что то сломать да и кто вообще знал во что эволюционируют компьютеры). Думали об эффективном и быстром выполнении динамических языков, да и как вообще софтовая прослойка для динамического языка может быть быстрее аппаратной поддержки?

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

тогда доступ к машине надо было иметь физический что бы что то сломать да и кто вообще знал во что эволюционируют компьютеры

Во-первых, речь тут была не о преднамеренных взломах, а о аппаратных защит на доступ к каждой ячейки в отдельности и проверки диапазонов массивов. Во-вторых, нет, первый Unix червь ломал систему по модему через gets().

vodz ★★★★★
()
Ответ на: комментарий от vodz

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

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

uin ★★★
()
Ответ на: комментарий от anonymous

Скоро ты узнаешь, как на твоём расте что-то сложнее хелворда компилируется минут 5.

Проект с асинхронным HTTP сервером, ORM, сериализацией-десериализацией и кучей кодогенерации на macros1.1

Время сборки — ~80 сек со всеми зависимостями или около 7 сек на горячую.

ЧЯДНТ

mersinvald ★★★★★
()
Ответ на: комментарий от vodz

В/на стеке.

А это типа не память :) Это мало того, что память, так ещё и ограниченная и медленная при первом расширении.

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

Разве стек не вшит в тело исполняемого бинарника при компиляции? Как оно может быть медленнее, если оно уже загружено и зарезервировано в начале исполнения? Всегда думал, что куча медленнее на расходах на выделение/освобождение.

Просто любопытно. (держу ссылку на ваши комментарии на лоре - очень познавательно пишите обычно).

Deleted
()
Ответ на: комментарий от Deleted

Разве стек не вшит в тело исполняемого бинарника при компиляции? Как оно может быть медленнее, если оно уже загружено и зарезервировано в начале исполнения?

Похоже вы перепутали с сегментом данных.

vodz ★★★★★
()
Ответ на: комментарий от RazrFalcon

То есть если я не могу выразить какую-то концепцию в C++, то это я виноват, а не язык?

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

Ну а язык в любом случае не при чем.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

язык в любом случае не при чем.

Логично.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Логично.

Если кто-то приходит с ножом на перестрелку, то это не проблема ножа. Это проблема того, кто выбрал нож.

Точно так же и с языками программирования. Haskell вряд ли следует винить в том, что он не подходит на написания драйверов и ядер ОС. C++ тоже не виноват в том, что parser-combinator-ы или персистентные структуры данных на нем разрабатывать несколько сложнее, чем на Haskell-е.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Если кто-то приходит с ножом на перестрелку, то это не проблема ножа. Это проблема того, кто выбрал нож.

Это даже не проблема того, кто выбрал нож - это проблема того, кто пришел с ножом.

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

C++ тоже не виноват в том, что parser-combinator-ы или персистентные структуры данных на нем разрабатывать несколько сложнее, чем на Haskell-е.

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

результате мы имеем крайне сложный язык с очень специфическими выразительными способностями.

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

vodz ★★★★★
()
Ответ на: комментарий от tailgunner

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

Не при чем. Если приплетать сюда еще и заказчика, то заказчику абсолютно фиолетово, какие концепции захотел использовать разработчик. И если разработчик берет C++ и пытается туда притащить парсер-комбинаторы или правила логического вывода из Prolog-а, то это не проблема C++. А проблема разработчика, который пытается использовать C++ как Haskell или Prolog.

Но Си++ (точнее, его разработчики) совершенно точно виноваты в том, что сделали несколько плохих решений.

Ну, блин, возьми язык, в котором это сделано хорошо. И все будут счастливы.

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

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

На английских форумах какие-то другие люди?

Да. Во всяком случае, они себя ведут по-другому. Ну и там обычно модерируют, в отличие от. Сюда пока хожу по [вредной] привычке, но уже бросаю.

anonymous
()
Ответ на: комментарий от anonymous

Это лишь значит что там диагнозы скрывают, а тут демонстрируют. Ну и чудно :D

Я тоже бросал, но в итоге бросил только логин. Интересный контент тут еще бывает.

anonymous
()
Ответ на: комментарий от tailgunner

Приветики!

Кагдила у тебя? Что-то давно не появляешься!

Рад тебя видеть! Остальные растоманы какие-то унылые, даже срач не могут поддерживать на комфортных скорости и уровне неадеквата!

shkolnick-kun ★★★★★
()
Ответ на: комментарий от anonymous

Нет. Там просто модерация такая, что лору и не снилась.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Нет, на место C++ вы можете подставить любой мейнстримовый язык: хоть Java, хоть C#, хоть Python.

Да даже ваш любимый Rust. Если я не могу на Rust-е изобразить множественное наследование, то это Rust виноват?

Ну или чтобы пример был нагляднее: некий RazrFalcon регулярно демонстрирует узость кругозора и, скажем так, явные признаки скудоумия. Виноват ли он в этом? Или это нужно просто принимать как данность при попытке что-то объяснить RazrFalcon-у?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Нет, на место C++ вы можете подставить любой мейнстримовый язык

Нет, не могу. Я пишу именно на C++. И когда я спрашиваю, а не требую: есть ли у языка такие-то возможности - местные фанбои сразу же обвиняют меня в скудоумии.

Мне фиолетово, что именно вас не устраивает в том же Rust. Я его вам не навязываю. Но после рассказов о «невероятной универсальности C++» вдруг оказывается, что шаг в сторону и расстрел.

И да, как выше уже указали, я пишу на C++ потому, что этого требует заказчик. А заказчику нужен Qt. Пока не появится аналога Qt на более адекватном языке - я вынужден страдать.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

слушай, я тут по работе копался в документации и даже подскажу тебе, вдруг это то, что тебе нужно:

QMetaObject::Connection QObject::connect(const QObject * sender, PointerToMemberFunction signal, const QObject * receiver, PointerToMemberFunction method, Qt::ConnectionType type = Qt::AutoConnection)
This function overloads connect().

Creates a connection of the given type from the signal in the sender object to the method in the receiver object. Returns a handle to the connection that can be used to disconnect it later.

The signal must be a function declared as a signal in the header. The slot function can be any member function that can be connected to the signal. A slot can be connected to a given signal if the signal has at least as many arguments as the slot, and there is an implicit conversion between the types of the corresponding arguments in the signal and the slot.

Помоему это как раз то, что тебе нужно.

Что касается концепций: тебе никто ничего не должен. Ты в реальном мире живешь, и надо уже это понимать, что всем вокруг на тебя насрать. В том числе и тем, кто придумал С++. С++ не должен позволять реализовать необходимую тебе «концепцию». Он может позволить реализовать её но допустим путем лютого применения шаблонов. Я тебе уже писал как можно без них обойтись.

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

Возможно тебе следует посмотреть в сторону component object model. Например заведи shared library чисто для интерфейсов. libinterfaces.so.1. Пусть всё с ней линкуется. Кстати, внимание: на линуксе есть баг ld-linux.so.2 - эта библиока должна лежать либо в /usr/lib, /usr/local/lib или будь готов к тому, что вызываешь из неё функцию, а в стектрейсе ?? или вообще рандомные адреса. эта ска не прописывает .got.plt причем это однопоточная гонка, я не знаю почему. крах ~30% вероятности, иначе все работает. винда не падает.

Туда добавь интерфейс IUnknown который будет возвращать тебе nullptr либо интерфейс. Если у тебя все классы производные от QObject, то просто используй qobject_cast и макрос Q_INTERFACE. И следи за умиранием QObjectов - все твои классы должны в деструкторе дергать какой-нибудь сигнал «меня_убили(QObject*). его вызывает сам QObject но когда его вызовут твой класс уже совсем разрушен, и ты конечно еще можешь убить указатели на него, но бывает так что надо еще туда подглядеть.

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

ckotinko ☆☆☆
()
Ответ на: комментарий от RazrFalcon

Что касается С++. С++ дает тебе свободу делать что хочешь.

Лично я считаю, что С++ говно потому что пока UB является отмазкой для генерации говнокода - это не нормальный язык. Можно упасть, сглючить и т.д. но компилятор не имеет права поменять сам порядок принятия решений. То есть как тут писали в другом треде - нельзя инлайнить функцию, потому что адрес перехода может указывать либо на неё либо на null. Даже если null = UB, упади. Но адрес не константа - нельзя считать его константой.

Но в том, что программы падают С++ не виноват. Не виноват от и в том, что тебе приходится думать как бы соединить два класса. Это не волшебная пуля. Java наверно тут справится в одну строку. Но С++ не для этого делался. Это как молоток, если он бьет по пальцам, или им трудно закручивать шурупы - молоток всё таки не виноват.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Помоему это как раз то, что тебе нужно.

Святая толстота...

Во-первых, зачем вы этот бред пишете в этой теме, а не в оригинальной? Покрасоваться?

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от ckotinko

С++ дает тебе свободу делать что хочешь.
С++ не должен позволять реализовать необходимую тебе «концепцию».

Шиза, ой шиза...

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Но после рассказов о «невероятной универсальности C++» вдруг оказывается, что шаг в сторону и расстрел.

Я уже неоднократно просил вас подтвеждать слова ссылками на конкретные цитаты. Но вы регулярно сливались. В этот раз вы можете показать какой-нибудь из рассказов про «невероятную универсальность C++»? Или сольетесь опять?

Ну и главное: может это у вас какое-то собственное понятие «универсальности»? С++ давно показал свою универсальность, т.к. на нем пишут и ядра ОС, и системы жесткого реального времени, и браузеры с текстовыми процессорами, и одноразовые програмульки на один раз.

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

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

eao197 ★★★★★
()
Ответ на: комментарий от ckotinko

тут в соседнем треде выяснилось что UB из С++ пролезает в раст, привет от llvm

Ссылкой поделишься?

Ну а вообще, судя по постановке вопроса, ты тупо передёргиваешь. Так-то баги и в компиляторе и в стандартной библиотеке и в ОС и где угодно быть могут: это никак не отменяет желания обеспечить большую безопасность.

Вам ничего такого не обещали.

Кому нам? Я на джаве вообще никогда не писал, основной опыт как раз плюсовый. Ну и раз постоянно на личности переходишь, то позволю себе это же: ты, судя по максимализму, довольно молод. Особенно весело смотрятся эти понты, если припомнить некоторые твои сообщения.

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

Ага и что ты сделаешь кроме нытья на лоре?

DarkEld3r ★★★★★
()
Ответ на: комментарий от O02eg

Profile-Guided Optimization

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от ckotinko

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

Почему ты это мне пишешь?

Кстати, раст умеет. (:

DarkEld3r ★★★★★
()
Ответ на: комментарий от mersinvald

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

Время сборки — ~80 сек со всеми зависимостями или около 7 сек на горячую.

Вася рассувал свою лапшу в 25модулей, чтобы это не собиралось тысячу лет. И то получил(скорее чутка наврал) 7секунд, которые не получил бы в С++ никогда на хелвордах такого уровня. А на си и одной секунды не получил бы.

anonymous
()
Ответ на: комментарий от eao197

Я не говорил, что это лично вы это утверждали. Но если вам хочется, вон, двумя сообщениями выше:

С++ дает тебе свободу делать что хочешь.

Классика жанра.

RazrFalcon ★★★★★
()
Ответ на: комментарий от vodz

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

Я не совсем понимаю о чём ты, но правда не можешь представить ситуаций когда это работало бы? Первое, что приходит в голову: likely/unlikely - к неправильным данным они не приводят.

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

Да, реально классика. Из вот этого:

С++ дает тебе свободу делать что хочешь.

Вывести вот это:

рассказы о «невероятной универсальности C++»

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну в вашей, абсолютной правоте никто и не сомневается.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

а браузер на расте наплодил 330 потоков и сдох на linux.org.ru

это даже не интересно. некие люди запретили себе сегфолтиться на уровне языка, но говнокод писать не перестали. зато отрастили ЧСВ размером с глиста.

ckotinko ☆☆☆
()
Ответ на: комментарий от RazrFalcon

Мне вообще похеру где писать. не нравится - вали с ЛОРа.

Твои проблемы на самом деле смешные. Я правда тебе подсказал как можно сделать. Другие люди подсказали еще вариантов. Не хочешь так - я тебе уже предлагал шаблоны, javascript в QWebEngine, и проверять typesafety в amazon cloud. Еще можно спиннер, гироскутер и вэйпалку прикрутить.

Что ты на нашем ЛОРе ноешь про то, какой С++ плохой? иди заказчику своему раст проповедуй. Не будь писькой, скажи буржую в лицо что за растом будущее.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

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

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

П.С. и таки, если язык делает дополнительные проверки, - это хорошо, я бы не отказался от проверки лайфтаймов (насколько это возможно) в С++.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.