Pull to refresh
42
1
Dmitry @domix32

Жопа котика

Send message

А Rust'у до появления легаси ещё надо дожить :)

Ну, он его уже примерно 10 лет копит т.к. 1.0 в 2015 вышел. Просто у него механизм резолва легаси несколько отличается от тех же плюсов. Примерно столько же времени у плюсов ушло от первоначального выпуска до выпуска ISO стандарта.

Так что я буду ждать с нетерпением С+=2)))))

cppfront и carbon как раз про это.

cppfront фактически делает апгрейд плюсов зашивая все механизмы GSL в язык, добавляя модули, обратную совместимость с плюсами и избавляя его от всякой дичи, типа спирали типов. В итоге всё это транспилируется в какой-то свежий С++ и в таком виде компилируется уже как обычно.

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

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

В питоне типы работают из под палки и просят много тестов, чтобы оказаться действительно эффективными. Что-то отлавливается в LSP/линтерах, что-то не особо. Так что пока все эти аннотации жёстко не приколотят к какой-нибудь фиче языка пользы от них не прям сказать чтобы много в сравнении с Java.

XPath has been adopted by a number of XML processing libraries and tools, many of which also offer CSS Selectors, another W3C standard, as a simpler alternative to XPath.

Идея XPath была использовать его для навигации по DOM, но когда усложнился CSS оно фактически зажило немного собственной жизнью и уже имело назначением делать запросы к DOM, а не просто обращаться по пути. Ну и встроенные функции реинкарнировали в отдельные псевдоклассы и прочие псевдоаттрибуты. Ну и буквально по вашей ссылке оно зовётся CSS Selectors - чем не имя?

объясните такой TIME PARADOX

не знаю чем оно вам time paradox, учитывая что сейчас фактически существует два консорциума по стандартизации - W3C и WHATWG. W3C принимает стандарты довольно неспешно - 3.0 и 3.1 различаются на 4 года, 3.0 от 2.0 - все 7 - а c 2019 W3C и вовсе импотент и вся работа по веб стандартам, исключая HTML, ведётся в рамках рабочих групп WHATWG. Да и ваша ссылка ссылается на черновик, которые тоже пока ещё неизвестно когда устаканится.

Для полного счастья не хватает Ü в compiler explorer.

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

Фронтенд clang генерирует тоже весьма неоптимизированный IR код

Там довольно немало подсказок имеется касательно данных, позволяя делать иногда не самые очевидные оптимизации - где-то автовекторизация срабатывает, где-то constexpr вычисляется, где-то память остаётся на месте (move семантика и return value optimization). Не знаю насколько это поддеживается в U, но с большой долей вероятности их может и не оказаться.

только если обращаться к произвольному индексу через оператор [].

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

let mut vec= Vec::with_capacity(sz);
/* 
...
массив как-то заполняется до sz
...
*/
for i in 0..sz {
...
   let blabla = vec[i]; // граница проверяется ровно 
                        // 1 раз при входе в массив
...
}

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

Я могу конечно ошибаться и U всё это могёт умеет, но и изначальный комментарий это скорее камень в ваш огород кастательно сравнения перформанса "на дцать процентов" на глазок без бенчмарок.

пардон, веткой промахнулся.

Средств выразительности языка вполне хватило для осуществления этого проекта.

Оно конечно хорошо, но киллер-фичей пока не замечено, учитывая большую вербозность языка в сравнении с тем же C++.

Производительность тоже весьма неплоха — на уровне других компилируемых языков, вроде C++

Вот тут press X doubt . Производительность скорее на уровне, который позволяет наоптимизировать LLVM из того наивного IR, который делает U. Да и снижение производительности на 10 процентов означает, что проверка границ происходит не при помощи инвариантов типа (как в том же Rust), которые выоптимизировываются, а наивными проверками.

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

С тем же эффектом "для примера" можно было сравнить print("hello world") с enterprise level hello world. Если ваш код не делает то же самое, то смысла сравнивать его по прочим параметрам смысла особо нет.

который (пока?) не называется никак

В веб станадартах оно зовётся XPath. Оно и в CSS и в JS и в XML/HTML используется. В среднем оно довольно универсально в плане API, но конкретно ваши примеры работают с HTML.

В примерах в статье предлагалось выносить if за пределы метода. Опять же внутри filter я так понимаю сидит оператор условия, который и предлагается вынести.

собственно использование filter и есть вынос - условие оказывается выше, а обработка в цикле ниже.

Так это он по сути и есть, просто выведеный через одно место.

Ну фиг знает. Иметь что-то вроде

shtuki
.filter(is_valid)
.filter(some_other_condition)
.split_by(process_condition)
.process_yes(/* обработка для if (true)*/)
.process_no(/* обработка для if (false)*/)

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

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

Более того, узнав про них, люди обижаются и начинают искать пути обхода. Да просто из принципа.

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

SDL довольно большой, почему именно он, а не Raylib например? Портировать его точно было бы проще.

На 15 штуках не сильно принципиально, но если штук заметно больше, то выгоднее сначала отфильтровать/поделить штуки по if и уже после вызывать обработку штук. Это во первых открывает путь к применению автовекторизации (то бишь когда в регистр процессора кладётся несколько штук сразу и все они обрабатываются за один такт), во вторых становится cache friendly - инвалидацию кэшей процессора можно будет делать реже, потому что предсказание веток уже сделано фильтром.

afaik там есть ещё кучка неожиданных побочек, которые толком не выявлены и не имеют понятного механизма воздействия. Готовы ли вы, например, частично ослепнуть? тот же ozempic из-за изменений в секреции как-то там начинает влиять на сосуды глазного дна, что может приводить к потере цветовой чуствительности и даже отслоениям.

 а на куя мне это???

кажется вопрос "зачем государству нужна собственная независимая ОС" имеет довольно очевидный ответ - оно его делает и им же управляет как им надо, а не как в нулевые 99% ОС составляла пиратская Windows XP, которую заразить вирусом легко настолько, насколько просто ткнуть флешку в компьютер - stuxnet тому свидетель. И это при том, что у винды тоже был сертификат ФСТЭК когда-то. У китайцев по тому же принципу Harmony OS не так давно в поля вышла, например.

Information

Rating
2,448-th
Date of birth
Registered
Activity