Программируете ли вы на Паскале?

Пока вы тут хороните паскаль, на нём годную штуку написали.

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

Там 2к строк вызова проектов на С.

индексы

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

Вирт-то в определённый момент разочаровался в Паскале и пошёл пилить другие языки.

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

Мышление человека носит императивный характер. Нам проще оперировать последовательностями операций, а не соотношениями.

Поэтому ФП это именно повышение сложности.

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

Но я в любом случае по этой классификации динамик.

Язык может поощрять стиль, а может и наоборот.

На Си без плюсов можно писать в ОО-стиле, и даже пишут (GTK, некоторые места из Linux Kernel), но выглядит это куда вырвиглазнее, чем в плюсах, и менее безопасно.

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

даа к тому же, а то что с индексами теперь отсутствуют уб, все скопом, они намного эффективнее гибче и не выжирают память - это так, ерунда какая-то

Об UB имеет смысл говорить только если речь идёт о конкретном языке. При разговоре об алгоритмах вообще разговор об UB смысла не имеет. Уточните область.

они намного эффективнее гибче и не выжирают память

Ничо сказки пошли.

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

Д-р Вирт не верил в Универсальный Промышленный Язык, профессионально изучив который, Универсальный Профессиональный Программист может с успехом профессионально наклепать все Универсальные Программы, необходимые Промышленности.

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

Короче, вообще не верил в программирование как в сферу деятельности? В чем суть его работы?

О, я думал, ты про Double Commander…

Не понял как ты пришел к такому вопросу. Вирт предполагал что языки будут с доработками под задачу. Как например есть Java Card, а есть Java EE, общего у них «много но мало».

Чтобы язык имело смысл дорабатывать под задачу, нужно явным образом разграничить «вот у нас язык», а «вот у нас доработки». Ведь если доработки превращают «Паскаль» в «Объектный Паскаль», это уже не доработки, просто исходный продукт никуда не годен.

Мне представляется, что все языки Вирта лишены конкретности в спецификации. Хотя Вирт как раз гордился лаконичностью своих спецификаций. За этой лаконичностью пропадает СМЫСЛ.

Банальный пример — это размеры целочисленных типов.

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

Вирт рассматривал программирование как систематическую целенаправленную деятельность.

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

Мышление человека носит императивный характер

Люди разные бывают.

ФП это именно повышение сложности.

Если пихать его везде не глядя то да. Если юзать там где надо то наоборот. Скажем питоновские ФП однострочники здорово упрощают код.

соционика делит людей

Соционика делит людей на тех кто верит в соционику и тех то над ней ржет;-)

На тех, кто о ней знает, и тех, кто нет)

с индексами теперь отсутствуют уб

UB с индексами ровно столько же если не больше

они намного эффективнее

операция ptr[i] дороже чем *ptr.

гибче

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

не выжирают память

К индексу нужен указатель, т.е. памяти уходит больше.

UB с индексами ровно столько же если не больше

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

операция ptr[i] дороже чем *ptr.

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

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

да какая разница кроме того что с индексами меньше мусорных звёздочёк, что особенно заметно на математическом коде

К индексу нужен указатель, т.е. памяти уходит больше.

в споре индексы vs указатели обычно подразумевается массивы(хэшмапы и тп) vs самоссылающиеся структуры на указателях (пресловутые списки), соответсвенно с индексами или не надо вообще ничего хранить или подобрать меньший тип(а не фиксированные 8 байт) под реальное количество элементов. Вообще, зачем таким быстрым указателям вдруг понадобились костыли в виде аж целого ключевого слова restrict и прочие убэшные стрикт алиасинги? Место сырым указателям в ffi и интеропе с операционкой т.е. глубоко внутри библиотечных контейнеров или в ембедеде - дёргать фиксировонные численные адреса- собственно всё, для прикладного алгоритма есть быстрые безопасные ссылки и индексы. Как-то так

Давно я таких восторженных неучей не видел.

Ну давай посмотрим, насколько оно одинаковое:

https://godbolt.org/z/PPsT1WE59

А что такое, может компилятор не той системы?

Попробуем сабж этого топика. Упс:

https://godbolt.org/z/h7KT9WTWP

Тут херни в генерируемом коде еще больше.

выход за диапазон - стоимость проверки давно на уровне погрешности

До-до, то-то в std::vector есть и operator[](int) и at(int), а еще флаг компиляции _GLIBCXX_DEBUG. Хотя конечно если код от рождения тормоз, то там такие проверки и правда на уровне погрешности добавляют. Но тогда зачем Вы тут что то то пишете об эффективности?!

указатели же даже сравнить просто так нельзя

настало время афигительных историй!

одинаково же

Нет. Учите матчасть.

с индексами меньше мусорных звёздочёк

Но больше мусорных скобочек, причем ГОРАЗДО больше.

что особенно заметно на математическом коде

Пример в студию. Вы как то не так математические коды пишете… а ведь еще есть референсы, там ни [] ни * нет, но тем мне менее семантически референс это указатель;-)

самоссылающиеся структуры

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

с индексами или не надо вообще ничего хранить

К любому индексу ВСЕГДА нужен указатель. Да, он может быть один на несколько индексов - иногда это помогает, иногда нет.

подобрать меньший тип

Да, иногда это помогает уменьшить размер данных.

для прикладного алгоритма есть быстрые безопасные ссылки и индексы

WTF ссылка в Вашем понимании?

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

https://godbolt.org/z/33Kss6ee6

Тут херни в генерируемом коде еще больше.

Ровно столько, сколько в исходнике: {$RANGECHECKS ON}

Так с проверкой выхода за диапазон, ровно как собеседник просил. Ты чем читаешь?

https://habrastorage.org/r/w1560/files/1b3/dc7/df6/1b3dc7df62e04219bbfa72a1ae6c028c.png

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

держи переуч, https://quick-bench.com/q/AIGVv0AMT4cXWLlaFMoMZydlRMA и начинай уже реально мерять, вместо гаданий на ассемблерных выхлопах, здорово отрезвляет(как и меня в своё врёмя), но вообще на таких функциях в две строчки даже измерения это пальцем в небо. gcc13 почему-то не шмог, 12 и ллвм нормально соптимизировали

настало время афигительных историй!

Сюрприз-сюрприз, UB на UB.

семантически референс это указатель;-)

Чушь.

Если Вы не видите в коде указателей, это не значит что их нет под капотом.

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

… Но тогда зачем Вы тут что то то пишете об эффективности?!

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

Нет. Учите матчасть.

имелось ввиду вот эта «разница» - https://godbolt.org/z/s9rqasbq9 , ну и выше сообщение с ссылкой на бенч

Но больше мусорных скобочек, причем ГОРАЗДО больше.

соглашусь на том что это вкусовщина

WTF ссылка в Вашем понимании?

такие как в расте, например, или хотя бы в плюсах, за которыми стоит строгая и умная система типов, которая гарантирует наличие и корректность объекта, отсутсвие алиасинга и УБ, что даёт компилятору дополнительную инфу для хитрых оптимизаций

Еще раз, только индексы (как и только указатели) не являются панацеей - панацеей является их грамотное совместное использование

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

Чушь

Афигенная у Вас аргументация!

A a;
A *ptr = &a;
A &ref = a;

Синтаксически ref ведёт себя как a (* ненужна, вместо -> юзается .). Семантически ref это ptr. Что такое синтаксис и семантика погуглите сами.

Если Вы не видите в коде указателей, то их в коде нет

Если Вы хотите писать хороший код, то хорошо знать как устроены используемые либы. Скажем в std::vector указатель есть, даже если Вы его и не видите.

эффективность уехала далеко

Про ассемблерные вставки и пр. я ничего не говорил, я говорил только про указатели - указатели вполне себе остались. Какой у Вас опыт написания эффективных кодов и что Вы понимаете под эффективностью вообще? Приходилось ли Вам:

1. считать такты затрачиваемые на какой то фрагмент кода на бумажке?

2. делать замеры, сколько тактов ушло на этот же фрагмент кода в реальности?

3. оценивать эффективность распараллеливания (запусктт последовательную и параллельную версии кода и смотреть ускорение)?

4. анализировать как на производительность влияет размер данных (рисовать графики времени выполнения от размера данных в дважды логарифмическом масштабе)?

5. использовать perf?

соглашусь на том что это вкусовщина

Нет. Ещё раз - приведите пример математического кода.

строгая и умная система типов, которая гарантирует наличие и корректность объекта

В с++ типизация не строгая. Всякие умные указатели это дорогое удовольствие вообще то, и главное - проверять все везде и всегда не имеет смысла. Чем сырые пойнтеры Вам не угодили я так и не понял…

сырой тупой указатель должен сидеть в глубине

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

Лицоладонь. Ты сам-то свой код смотрел? У тебя оба «бенчмарка» оптимизированы в no op.

Давай дальше жги.

Нет. Ещё раз - приведите пример математического кода.

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

Я представляю, какое открытие еще ждёт zurg, если он узнает, что мой пример с простой структурой размером 16 байт, был еще щадящим. Если взять структуру побольше, для которой компилятор не сможет оптимизироваться до операций сдвига и lea, то в коде появляются НАСТОЯЩИЕ ОПЕРАЦИИ УМНОЖЕНИЯ.

zurg, привет!

ну так то ещё хуже https://quick-bench.com/q/KKm-Jc-danvTnhlWmUbkTZ70Hus )

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

Снова фейл. Попробуй еще раз.

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

Ну ты знаток оптимизаций, я угораю.

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

Ну ты знаток оптимизаций

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

и по поводу бенча интересно, а что тогда вот эта ф-ия benchmark::DoNotOptimize() делает

страдание хернёй

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

и по поводу бенча интересно, а что тогда вот эта ф-ия benchmark::DoNotOptimize() делает

Интересно? Тебе интересно? Так это ты в тему этот бенч притащил с апломбом. Так уж разберись, как он работает.

а знаешь кто знаток? - современный оптимизирующий компилятор

наслаждайся. https://habr.com/ru/companies/ruvds/articles/747826/

Вообще-то это в меня сначала начали кидаться ассемблерными выхлопами

Семантически ref это ptr.

Да вот ни разу.

const A * ptr = new A{};
const A & ref = A{};

В чём разница погуглите сами.

Если Вы хотите писать хороший код, то хорошо знать как устроены используемые либы.

На SQL вы тоже не пишете, пока не изучите весь код СУБД?

Читал читал, а также ещё и аналогичную растовскую поучительную историю https://ipthomas.com/blog/2023/07/n-times-faster-than-c-where-n-128/ :

поначалу, вроде-бы тоже упёрлись в вполне себе си-подобную замешанную на макросах ансейфную портянку на интринсиках с n =128, но в самом конце есть ссылка на умельца который просто чуток подсказал компилятору и … в 2 с лихером раза обошел эту портянку https://github.com/tommyip/n_times_faster_than_c/blob/4a1ec26c53a228daf3d14a61290129a69bc33c09/README.md вот такой вот красотой:

pub fn opt6_chunk_exact_count(input: &str) -> i64 {
    let iter = input.as_bytes().chunks_exact(192);
    let rest = iter.remainder();
    let mut n_s = iter
        .map(|chunk| chunk.iter().map(|&b| b & 1).sum::<u8>())
        .map(|chunk_total| chunk_total as i64)
        .sum::<i64>();
    n_s += rest.iter().map(|&b| b & 1).sum::<u8>() as i64;
    (2 * n_s) - input.len() as i64
}

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

Да вот ни разу.

Бггг, какая прелесть! Вы читать и понимать написанное умеете? Да, если в пойнтер и референс положить РАЗНЫЕ объекты, то они и семантически будут РАЗНЫМИ - с этим вообще никто не спорит. Но Ваш пример как бы ничего и не доказывает.

На SQL вы тоже не пишете, пока не изучите весь код СУБД?

Аналогия не является ни аргументом ни доказательством. В общем Вам за навыки ведения дискуссии твердая двойка.

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

Зависит от того чего Вы хотите найти.

Я там выше пять вопросов задал и попросил привести пример «математического кода». Ы?

Да, если в пойнтер и референс положить РАЗНЫЕ объекты, то они и семантически будут РАЗНЫМИ

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

Дяденька, ещё раз для дислектиков - одинаковые объекты с разным лайфтаймом (особенно когда один превратился в тыкву) - это РАЗНЫЕ объекты.

Из Вас Ванга такая же херовая как и читатель.

Откуда взялись

одинаковые объекты с разным лайфтаймом

если

семантически референс это указатель;-)

?

Т.е. то что у Вас в одном месте new стоит а в другом не стоит Вас не смущает? Даже и не знаю что сказать…

Есть один семантический нюанс отличающий референс от указателя - референс на nullptr это UB, указатель на nullptr это сегфолт или нормальное поведение.

Т.е. то что у Вас в одном месте new стоит а в другом не стоит Вас не смущает?

Ещё как смущает вкупе с заявлением, что «семантически референс это указатель;-)». Впрочем, всё легко разрешимо, если признать, что это семантически разные вещи. У них на самом деле мало общего.

Вы придуриваетесь или всерьез?!

Да, если по указателю положить обьект в кучу, а по референсу объект на стеке, то это будут разные вещи. А если по указателю положить в кучу экземпляр класса-наследника, то это будут совсем разные вещи.

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

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

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