Метапрог-прототип, версия 7 + графические диалоги на Метапроге

Я даже прототип Метапрога на хорошо знакомом мне Лабвью разрабатываю крайне медленно, и дело в недостатке не знаний, а времени.

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

Унижают себя в первую очередь антиметапрогеры.

Мне повторить тут Ваши цитаты? Если Вы и правда начнете учиться, то со временем Вы поймете какую ахинею Вы тут несли…

скорость хуже

Може и чуть-чуть хуже, но разница не отличима,в отличии от, например, сравнения С и Питона.

низкоуровневости нет.

Кто сказал? С++ обратно совместим с С. Стреляй себе по ногам сколько влезет. У того же operator new под капотом простой malloc. Да и зачем тебе «низкоуровневость»?

ядро и дрова на плюсах не сделаешь

Я недавно писал про свои впечатления от Mbed от ARM, которая в 64К флеша влезает.

по крайней мере под х86

А что в архитектуре х86 мешает написанию ОС на С++?

сложности с ООП,

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

Вот давайте разберем для примера этот Ваш пассаж про С++:

скорость хуже, низкоуровневости нет, ядро и дрова на плюсах не сделаешь (по крайней мере под х86), сложности с ООП, которое я даже на Лабвью не использую (хотя там есть ООП с классами).

Итак:

скорость хуже

Это неправда, и Вам про это много раз говорили. Я уж не говорю про то что со своими СУВТ Вы про скорость можете забыть.

низкоуровневости нет

Это тоже неправда

ядро и дрова на плюсах не сделаешь (по крайней мере под х86)

Это спорно (особенно про дрова)

сложности с ООП

ООП это парадигма. На С тоже можно делать ООП, на плюсах можно не юзать ООП. В Вашем случае ООП как раз таки весьма показано.

Текст — одно из величайших изобретений человечества.

Для общения с людьми, а не с машиной. В Метапроге тоже текста много.

опытные лабвьюшники

Я - опытный лабвьюшник. Даже можно сказать, что я царь Лабвью.

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

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

Ну так и в графике тебе надо будет параметры этого цикла протыкать, что-то к ним подтащить

Какие еще параметры цикла? Количество итераций? Если подключил массив (а это большая часть циклов) - оно определяется автоматом.

Кстати, ты упорно пишешь «диагармма» и «пропиетарный».

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

Для общения с людьми, а не с машиной.

99.9(9)% общения с машиной сейчас идет через текст.

В Метапроге тоже текста много.

И это особенно забавно, да.

Какие еще параметры цикла? Количество итераций? Если подключил массив (а это большая часть циклов) - оно определяется автоматом.

А если мне нужен каждый второй элемент массива? А если мне нужна первая половина массива? То что Вы не сталкивались с такими задачами не значит что их нет.

разумеется можно. не метапрогер же писал.

основного языка

В Метапроге его нет. Ну разве что в прототипе, но он на Лабвью, которое многоязычность не поддерживает.

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

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

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

И наши, и ваши политики с воплями рассказывают о языках и мовах, но возмущатся тем, что в программировании один только «лэнгвич», забывают. Разве что den73 что-то пилит по этой теме, но без микроскопа, к сожалению, не заметно. 1С - не более чем скриптуха для бухгалтерии (черт, нет чтобы «бугалтерии» - никто б от этого не умер, а говорить было бы проще, мы ж не немцы), ядра ОС и многое другое на ней не написать.

На форумах ты получишь лишь такие советы +-: Метапрог-прототип, версия 7 + графические диалоги на Метапроге (комментарий)

Он корректный в пунктах 1-3?

Уже знаю по Лабвью. Думаю сделать опциональное распараллеливание циклов for.

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

И слава Б-гу! Были исследования еще в 80-90е ЕМНИП, людям для которых английский неродной программировать проще, нет путаницы в голове. Для меня for - это в первую очередь цикл, для англоговорящего это в первую очередь обычное слово.

Я писал немного на 1С и русском алгоритмическом (русифицированный паскаль) - это ужОс…

Параллелится не цикл а конкретная задача. for в разных вычислениях может быть разбит а может и не быть разбит. Все зависит от связанности вычислений

Кстати clang поддерживает OpenMP?

И вообще что быстрее - OpenMP или pthreads?

Вызод за границы массива невозможен, что еще?

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

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

Ты ищешь утечки в метапроговских трансляциях, чтобы их устранить и помочь проекту?

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

Некогда. Я даже прототип Метапрога на хорошо знакомом мне Лабвью разрабатываю крайне медленно, и дело в недостатке не знаний, а времени.

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

Кстати clang поддерживает OpenMP?

И вообще что быстрее - OpenMP или pthreads?

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

Вот в Лабвью я кликнул право мыши по циклу, configure iterational parallelism.

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

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

Если что, то моя версия сразу компилируется C++ компилятором. А в версии i-rinat мне потребовалось сделать 4 правки:

// изменить имя переменной try
main.cpp:25:19: ошибка: expected «catch» before «=» token
main.cpp:25:19: ошибка: expected «(» before «=» token
   25 |   for (size_t try = 0; try < 10; try ++) {

// добавить каст
main.cpp:28:24: ошибка: invalid conversion from «void*» to «u8**» {aka «unsigned char**»} [-fpermissive]
   28 |     u8 **array = malloc(sizeof(u8 *) * ARRAY_SIZE);
      |                  ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                        |
      |                        void*

// добавить каст
main.cpp:34:24: ошибка: invalid conversion from «void*» to «u8*» {aka «unsigned char*»} [-fpermissive]
   34 |         u8 *hs = malloc(HAYSTACK_LENGTH + 1);
      |                  ~~~~~~^~~~~~~~~~~~~~~~~~~~~
      |                        |
      |                        void*

// добавить каст
main.cpp:55:34: ошибка: invalid conversion from «u8*» {aka «unsigned char*»} to «const char*» [-fpermissive]
   55 |         count += !!strstr(array[k], needle);
      |                           ~~~~~~~^
      |                                  |
      |                                  u8* {aka unsigned char*}

У C++ достаточно хорошая совместимость с С.

дереференсинг нулевого указателя

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

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

– давайте подарим прапорщику книжку на ДР
– книжка у него уже есть, мы в том году подарили

Может ТС прапорщик?

На винде фурычат? Можно будет компилять сорцы использующие POSIX Threads и на линуксе, и на винде без изменений?

можно

Он корректный в пунктах 1-3?

Да. Но там ещё много чего есть.

А статью ты можешь прочитать раз на книги времени нет?

Кроме этих пунктов прочитай ещё вот эти 32: https://www.viva64.com/ru/a/0054/

Тогда есть маленький шанс что у тебя что-то будет работать на уровне HelloWorld…

Кстати clang поддерживает OpenMP?

Да.

И вообще что быстрее - OpenMP или pthreads?

OpenMP удобнее. По скорости +- одинакого. Может кто-нибудь и сделает какой-нибудь пример где pthreads выиграет чуток, но OpenMP гораздо удобнее.

Ладно, OpenMP подождет. С меня еще условные схождения.

Так что по сравнению pthreads и OpenMP? Что быстрее? Или это вещи несравнимые?

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

Вот что загуглил:

http://www.dalkescientific.com/writings/diary/archive/2012/01/13/openmp_vs_posix_threads.html

https://www.cs.colostate.edu/~cs675/OpenMPvsThreads.pdf

если коротко, то OpenMP норм.

Може и чуть-чуть хуже, но разница не отличима,в отличии от, например, сравнения С и Питона.

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

У того же operator new под капотом простой malloc

А чем он уравновешивается? Деструкторами?

Да и зачем тебе «низкоуровневость»?

Для универсальности. Так-то мне б и скриптухи в виде Лабвью хватило.

А что в архитектуре х86 мешает написанию ОС на С++?

Вроде ничего. Дерзай. Но Линусу эта идея не нравится: http://harmful.cat-v.org/software/c /linus

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

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

Избавив от одних - добавить новые: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

Why OO was popular?

Reason 1 - It was thought to be easy to learn. Reason 2 - It was thought to make code reuse easier. Reason 3 - It was hyped. Reason 4 - It created a new software industry.

I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind OOPs.

В Лабвью тоже есть ООП с классами, и мне доводилось щупать код с этим. Черт побери, нельзя обращаться к приватным полям, только через методы - ужас! Лучше просто кластера (структуры). Я в Лабвью оперирую этим: https://www.ni.com/getting-started/labview-basics/data-structures

Правда не хватает юнионов и нормальных указателей (но есть подобие указателей без управления памятью типа malloc+realloc+free).

Ты уже проверил пример с одним окошком на утечки? Метапрог-прототип, версия 7 + графические диалоги на Метапроге (комментарий)

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

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

Использование памяти после освобождения, двойное освобождение, дереференсинг нулевого указателя, гонки (data races), использование неинициализированных переменных. Это навскидку очевидное. Кстати, помимо работы с памятью есть ещё инициализация и освобождение ресурсов (файлы, сокеты, и т. д.). Там тоже возможны утечки и краши.

Что ж, буду иметь в виду. С этим бороться сложнее, чем с выходом за пределы буфера, но в принципе можно.

Но Линусу эта идея не нравится

Ещё одна никому не известная статья

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

И опять же про низкоуровневость. Ты так и не объяснил внятно, зачем ты тащишь семантику Сей в своё поделие. Ладно бы это был просто бэкенд-язык, как например сделали гномовцы в своём Vala. Только Vala это высокоуровневый язык с автоматическим управлением памятью (подсчёт ссылок) и во многом напоминает C#, а ты тащишь всё прямо из цэ в свои диаграммы. Тут тебе и ручной вызов malloc, free. Красота! И при этом генерируется адовая текучая лапша.

Мог бы дальше пойти: сделать не Си на диаграммах, а ассемблер, тем более ты, насколько я помню, когда-то говорил, что Си говно, а ассемблер круто, ведь да?

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

Ну, а это нужно срочно в цитатник на metaprog.org

Про скорость плюсов ему говорили много раз. Да что уж там:

– Кстати clang поддерживает OpenMP? И вообще что быстрее - OpenMP или pthreads?
– OpenMP удобнее. По скорости +- одинакого.
– Так что по сравнению pthreads и OpenMP? Что быстрее? Или это вещи несравнимые?

Кто то еще сомневается что у ТС диcлексия (в самом лучшем случае)?

OpenMP удобнее. По скорости +- одинакого. Может кто-нибудь и сделает какой-нибудь пример где pthreads выиграет чуток, но OpenMP гораздо удобнее.

Вот это хотелось бы знать чтобы понимать что брать. Под капотом OpenMP те же потоки?

Проскипал, пишут много.

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

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

Да под капотом потоки 100%.

Но возможно не всегда pthreads. Вот что нашёл в github:

https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h#L1337

Котечка пишет что в OpenMP под капотом pthreads. Впрочем, неважно - будем юзать потоки из SDL_CreateThread для кроссплатформенности.

ну норм вроде: https://wiki.libsdl.org/SDL_CreateThread

почти как pthread

Интересно во что оно будет транслироваться в вебе (Emscripten)?

Если подключил массив (а это большая часть циклов) - оно определяется автоматом.

В циклах по контейнерам оно и в большинстве современных ЯП определяется автоматом. Даже в C++, начиная с C++11 сделали (раньше приходилось либо городить этажерку из итераторов, либо сводить цикл к циклу со счётчиком). И как тебе уже написали — это не все циклы.

Черт побери, какая же сложная калька с инглиша - лучше б ее упростить.

Да легко. «Проприетарный» вполне адекватно переводится как «собственнический». Просто если этот перевод начать употреблять на ЛОРе в том же смысле, у верующих в Непогрешимость Рыночной Экономики начнёт бомбить.

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

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

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

Я выложил пример попроще Метапрог-прототип, версия 7 + графические диалоги на Метапроге (комментарий) там вызов nkc_init только раз, и он честно уравновешен SDL_Quit.

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

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

Предан анафеме как ярый поборник антиметапржества будешь! Покайся!

Критика не грех, каяться не в чем.

P.S: хи-хи.

А мы тут полы волею пославшего нас ТС-а моем, велкам то ве клаб.

То есть, ты утверждаешь, что выложил пофикшенную версию программы, но при этом ты не виноват в том, что предыдущая версия текла? Нуну

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

В данном случае я вообще ничего не утверждаю. Всего лишь спрашиваю есть ли здесь утечки. Можешь проанализировать? Это упрощенная (читал хоть тот коммнт) прога с только одним диалогом.

Ну как бы валгринд запустить бы ты и сам мог, но так уж и быть)

==76337== LEAK SUMMARY:
==76337==    definitely lost: 26,169 bytes in 1,684 blocks
==76337==    indirectly lost: 82,554 bytes in 446 blocks
==76337==      possibly lost: 0 bytes in 0 blocks
==76337==    still reachable: 774,139 bytes in 1,202 blocks
==76337==         suppressed: 0 bytes in 0 blocks

==76337== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 0 from 0)

Полный репорт https://pastebin.com/41BrxZBL

с какими ключами запускали?

Покажите еще так, а то что-то там в выхлопе аллок фри для хипы не заметил

Valgrind options: –leak-check=full –show-leak-kinds=all –track-origins=yes –verbose

==76337== Conditional jump or move depends on uninitialised value(s)

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