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

Вы реально забанены в гугле и до сих пор не смогли посмотреть определение?

Под этим термином можно понимать несколько довольно разных вещей. Например лабвью/фильтры в блендере/метапрог.

Циклические конструкции тоже синтаксический сахар?

Мы говорим не про циклические конструкции. В огороде бузина, в Киеве дядька…

QT ни разу не аналог, т.к. требует специальный препроцессор, в отличие от Object Pascal.

Препроцессор тут не причём вообще. PyQt не требует препроцессора. Учите матчасть.

Вы просто не компетентны в обсуждаемом вопросе.

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

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

Под этим термином можно понимать несколько довольно разных вещей. Например лабью/фильтры в блендере/метапрог.

Не вижу разницы.

Мы говорим не про циклические конструкции. В огороде бузина, в Киеве дядька…

Сливаетесь что-ли?

Препроцессор тут не причём вообще. PyQt не требует препрцнссора. Учите матчасть.

Причем здесь PyQt? Это просто биндинг к QT. Вы точно понимаете о чем пишите?

Да-да, а ещё кругозор у меня типа узкий

Эта дискуссия лишь это доказывает.

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

Я не буду писать про российское HPC ибо это очень грустная история. :(

Не вижу разницы.

Конечно не видите - потому что ничего в этом не понимаете. Так же как и в числодробилках.

Сливаетесь что-ли?

 -- Без проперти визуальное программирование невозможно!
 -- Возможно, проперти это не более чем синтаксический сахар.
 -- А циклические конструкции это тоже синтаксический сахар?
 -- Мы говорим не про циклические конструкции. 
 -- Сливаетесь что-ли?

Какая прелесть…

Причем здесь PyQt? Это просто биндинг к QT.

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

Вы точно понимаете о чем пишите?

Я да, а вот Вы точно не понимаете о чем пишете. Для Вас это обычное дело похоже…

Эта дискуссия лишь это доказывает.

Когда мы начали меряться кругозорами, то выяснилось что у Вас, по списку решенных задач, он едва ли 10% от моего. Эта «дискуссия» же доказывает что Вы дискутировать просто не умеете, у Вас уровень аргументации как у голубя который прилетел типа в шахматы играть.

Я не буду писать про российское HPC ибо это очень грустная история. :(

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

Тогда было совершенно другое время и другое понимание всего.

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

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

Речь идёт не о неизвестных предметах, а о том, что до сих пор работает в актуальных версиях компиляторов. Нет, можно объявить семейство С (то есть, всё, что обратно совместимо с ним) устаревшим, переходить на какой-нибудь D и говорить, что там этих недостатков нет (нет ли?), но для этого С действительно должен устареть. А сейчас как раз его в первую очередь и сравнивают с сабжем.

Какие структуры под какой процессор?

Работа с указателями от и до.

используется и по сей день

Не ну жопу камнем чистить можно и в 21 веке. Эффективность этого процесса никак не снизилась. Что касается инкремента в выражениях то это сейчас считается плохой практикой и не рекомендуется. Оно по-сути осталось только в идиомах вроде *i++=*j++. В любом случае сейчас оптимизатор переставит всё как надо. Т.е. по форме оно такое же, а по сути это совсем другой язык.

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

Чего чего? Надо понимать и итераторы вы += 1 двигаете? Бред же.

Работа с указателями от и до

Указатели в языке соответствуют адресам в процессоре?

Надо понимать

Надо, но ты не понимаешь. Перечитай ещё раз что я сказал.

В общем и в целом, да. За исключением языков, транслируемых в виртуальные машины, но там от такого стараются избавляться или максимально скрывать. В Паскале (который не ABC.NET) указатели разрешены, работают, но использование их в явном виде без особой необходимости считается не лучшим вариантом. Особенно когда указатель используют не просто так, а оперируют им (те же инкременты, декременты).

Зато можно писать быстрый код.

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

Из за невнимательности можно попасть под машину переходя улицу по пешеходному переходу на зелёный свет. Невнимательные не выживают, этот мир жесток…:-(

Из за невнимательности можно попасть под машину переходя улицу по пешеходному переходу на зелёный свет. Невнимательные не выживают, этот мир жесток…:-(

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

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

Так что я бы не стал говорить, что отсутствие работы с указателями это бонус ЯП. Никто ж руки не выкручивает…

Кто как, я пока как-то умудряюсь жить.

А я собираюсь жить вечно, пока неплохо получается :) (tm)

Просто глупые ошибки лучше отлавливать на этапе компиляции

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

Паскаль для обучения всё ещё хорош, хотя конечно старомоден (но так же старомодны будут и Си с питоном для юных зумеров), и слава FreePascal что до сих пор его пилят. Однако же для физики частиц он вряд ли применим, ибо беда не только в том что куча legacy на фортране или плюсах, проблема в том что Паскаль выходит довольно громоздким для физики. Плюсы по-лучше, а фортран с питоном ещё лучше конечно в этом плане. Было бы какое расширение языка Паскаля с удобным комплексным типом, векторами и матрицами, мб и взлетел бы.

ну вообще то в плюсах хватает либ для матриц, векторов и всего на свете.

Я вот все вспомнить не могу, у вас там в ФЭЧ вроде какие то свои хитрые ЯП/фреймворки для обработки больших объемов экспериментальных данных есть?

Я вот все вспомнить не могу, у вас там в ФЭЧ вроде какие то свои хитрые ЯП/фреймворки для обработки больших объемов экспериментальных данных есть?

Раньше был PAW интерпретатор подвязанный к фортрану, потом C++ интерпретатор ROOT, сейчас на питон всё переползло более-менее.

О, точно, root. И что, питон и его убил?

А данные в бинарном или текстовом формате хранятся?

И что, питон и его убил?

Пока рут пытается подстроиться и быть совместимым с питоном.

Данные в бинарном формате со всякими компрессиями и возможностями параллельной обработки. Но тут Балдин, думаю, гораздо больше знает, надо его кастовать.

Не отсутствие. В Паскале указатели тоже есть, и с ними можно делать многое. Нежелательность. Когда в языке есть всё, чтобы в указатели просто не надо было влезать.

В указатели все равно придётся влезать, если захочется ускорить код.

Как без указателей сделать итератор для своего сложного контейнера?

Почему бред? Я именно так и пишу, очень наглядно и универсально для любого шага инкремента.

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

Вообще-то это в ПТУ (ныне колледж) учат техническим навыкам. В нормальных ВУЗах учат фундаментальным знаниям и кругозору. Но, видимо, ты сам окончил ПТУ и преподаёшь в ПТУ. Можно даже название вообразить: «Колледж дробильных и фундаментных работ». Но тогда и не надо давать рекомендаций для более серьёзных мест. По уровню твоих речей тоже видно - он больше тянет на ПТУ, а не на универ.

Синтаксис плюсов является большой проблемой только в Вашем воспаленном воображении.

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

Но да, привыкнуть можно, и к теху, и к плюсам. И пилить деревья двуручкой тоже после 25 лет на зоне тоже будет легко и привычно. Однако это не означает, что это хорошее занятие. Как там говорил Достоевский? «Подлец человек, ко всему привыкает».

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

Через индексы, можно посмотреть как в Rust реализуют списки без unsafe, там тоже без указателей.

Итератор должен держать ссылку/указатель на контейнер. Можно конечно передавать контейнер в метод разадресации итератора каждый раз, но это такое…

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

один и тот же индекс может относится к разным массивам.

Да, я понимаю про что ты говоришь. В этом случае, нужно иметь две переменные size_t i, j; Где i относится к массивами массивов, а j к уже финальному массиву с данными. В паскале динамические массивы без указателей из коробки.

Список в структурах можно было бы описать так:

type 
  TListItem = record
    value: string;
    indexNext: integer;
    indexBack: integer;
  end;

  TList = record
    items: array[] of TListItem;
    firstItemIndex: integer; (* так как это список, и мы можем там все удалять, перемещать, не обязательно первый элемент, это первый элемент массива *)
    lastItemIndex: integer;
  end;

Примерно таким образом контейнеры в Rust и строят без unsafe. Из преимуществ, можем двигать память как угодно, а «указатель» на следующий элемент остается валидным.

Я уже не говорю про то, что сам по себе индекс бесполезен - к индексу нужна еще ссылка/указатель на массив.

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

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

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

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

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

ты сам окончил ПТУ и преподаёшь в ПТУ.

Я закончил Физфак МГУ им МВ Ломоносова, преподаю там же и на ВМК МГУ. Упс?

Вообще-то это в ПТУ (ныне колледж) учат техническим навыкам. В нормальных ВУЗах учат фундаментальным знаниям и кругозору… Надо было в нормальном месте учиться

Кто бы Вас туда еще взял…

привыкнуть можно, и к теху, и к плюсам

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

Вы точно программист? Больше похоже что Вы простой форумный балабол - за столько комментов ни разу не сказать хоть что-то имеющее отношение к действительности, это просто феноменально!

В этом случае, нужно иметь две переменные size_t i, j; Где i относится к массивами массивов, а j к уже финальному массиву с данными.

Буэээ… SoA далеко не всегда оптимальная архитектура данных (в т.ч. с т.з. производительности). Выглядит ужасно костыльно, обычный пойнтер куда проще.

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

Это конечно плюс, но это не всегда нужно.

А ссылка считается указателем?

Семантически конечно ссылка это указатель.

разыменовывать итератор придется через метод контейнера

Сравни:

*I
container.get(I) 

;-)

Выглядит ужасно костыльно, обычный пойнтер куда проще.

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

Сравни:

Можно перегрузить [] на итератор, если использовать С++

Охрененная претензия конечно.

Краткое содержание предыдущих серий - den73 в юности столкнулся с числодробилкой на плюсах (решалась там какая то СЛАУ) и не смог посмотреть в отладчике матрицу. Эта тяжелая психическая травма преследует его всю жизнь и приводит к иррациональной плюсофобии в терминальной стадии.

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

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

еще кстати и с отладкой проблемы

это отдельная песнь, отлаживать такой спагетти-код из цепочек индексов это полный трындец.

Можно перегрузить [] на итератор, если использовать С++

Можно, но container никуда не денется - а иногда доступ к нему весьма кучеряв.

В общем я за свободу!;-) Никто не заставляет юзать указатели везде и всюду, но иногда они здорово упрощают жизнь и лучше пусть они будут чем нет. И если в ЯП указатели объявлены чем то неправильным, то ИМНО с этим ЯП что то не так… ;-(

Почему бред?

Потому что += 1 как минимум дороже в терминах asm instruction size, даже для интов.

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

… и ловите циклы на пустом месте в случае не-random-access итераторов (std::list etc).

Потому что += 1 как минимум дороже в терминах asm instruction size, даже для интов.

Булшит сразу по двум причинам:
- x86 это не единственная ISA
- Компиляторы работают не так, как ты себе это воображаешь

x86 это не единственная ISA

Зато единственная интересная подавляющему числу людей.

Но мне хотелось бы увидеть хотя бы одну (одну, Карл!) платформу где бы add reg, const был бы компактнее и быстрее inc reg.

А до тех пор пока таких примеров не приведено - запишем вас в балаболы.

Компиляторы работают не так, как ты себе это воображаешь

Действительно, расскажите мне, просветите неразумного.

Но мне хотелось бы увидеть хотя бы одну (одну, Карл!) платформу где бы add reg, const был бы компактнее и быстрее inc reg.

ARM, RISC-V: там нет никакого inc reg.

Действительно, расскажите мне, просветите неразумного.

https://en.wikipedia.org/wiki/Instruction_selection

ARM, RISC-V: там нет никакого inc reg.

Их проблемы. Значит ++i вынужденно развернётся в add reg, 1, и только на этих кастрированных платформах. Это не повод заменять везде explicit инкремент на i += 1.

https://en.wikipedia.org/wiki/Instruction_selection

Смешно. Я то думал вы мне тут сейчас про всякие оптимизационные трюки рассказывать начнёте, типа замены i < 1 на i <= 0.

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

дороже в терминах asm instruction size, даже для интов.

А какая связь с +=1? Современный компилятор любую многоэтажную дичь расщепит на атомы как того требует конкретная платформа.

А какая связь с +=1? Современный компилятор любую многоэтажную дичь расщепит на атомы как того требует конкретная платформа.

Это (+= const) идиоматически другая операция. И даже если в случае += 1 оно по всем side-effects совпадает с инкрементом (а в случае интов скорее всего в inc reg там где он доступен и развернётся, но я не проверял) оно может приводить к лишним циклам которые будут проходиться ровно один раз (я итераторы не просто так упомянул). Лучше так не делать. Удивляет что кто-то вообще это пропагандирует и советует.

Я то думал вы мне тут сейчас про всякие оптимизационные трюки рассказывать начнёте, типа замены i < 1 на i <= 0.

Трюки ради задачи, которая решается тупо выбором инструкций? Вот это действительно смешно.

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

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

Я пишу свой оптимизирующий компилятор (да, включая бекенд).

И как успехи? Ядро уже собирает?

А вот ты рассуждаешь о том, о чём нихрена не знаешь.

Действительно. Я это - вообще просто попИсать вышел…

оно может приводить к лишним циклам которые будут проходиться ровно один раз (я итераторы не просто так упомянул)

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

любой инкремент вида

x = x + 1;
x += 1;

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

А ты зачем мне про это пишешь? Ты это bugfixer пиши.

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

и по идее нельзя += сводить к ++.

Поправочка: если отбросить патологические варианты ++ - это частный случай += const. Если кто-то не хочет «снимать на этом сливки» - да ради бога, я только за.

А ты зачем мне про это пишешь? Ты это bugfixer пиши.

Зайдём с другой стороны. Если ++ не имеет права на жизнь - зачем тогда господин Вирт вводил в Паскаль Inc() и Dec()? Задумайтесь.

Какие в жопу итераторы

Итератор это базовое понятие не привязанное к ЯП. Итераторы есть и в С, для переключения итератора не обязательно юзать перегруженный ++.

Ваш К.О.

И да, чем хамить всем подряд - подучили бы матчасть, а то ведёте себя как последнее быдло, только семок не хватает:-(