Metaprog: универсальная графическая среда программирования [в разработке] часть 5

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

Так вы сами мусорите тут, вот когда были анонимы получалось по ~150 сообщений в день, почти все бесполезные были, сейчас вот их забанило в теме, сразу ценность среднего комментария повысилась! %)

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

Как с рекурсией? Решето Эратосфена и фибоначи уже можно пилить?

Здрасьте, циклы готовы! Как ты это мог пропустить? Все же вынесу их в шапку.

Рекурсии пока нет и появится тогда, когда руки дойдут. Циклы уже готовы.

и всё? технических подробностей не будет?

Обнови страницу и прочитай шапку.

Циклы уже готовы.

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

В шапке ссылки на комментарии с ними

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

В шапке ссылки на комментарии с ними

Подфункция, измеряющая размер нуль-терминированной строки и превращающая ее в метапроговский массив с известной длиной:

Это надо на баш или лурк.

Подфункция, измеряющая размер нуль-терминированной строки и превращающая ее в метапроговский массив с известной длиной:

а как этот метапроговский массив реализован? если ты говоришь энкапсуляция и access control не нужны получается объект клиентский код сможет легко привести в невалидный state путём записи в length без изменения реального размера участка памяти reallocом и как следствие всё закончится в лучшем случае segfaultом а в худшем сознательным buffer overflow данными от malicious user и выполнением его кода с привилегиями процесса.

Блоки: вызовы сишных функций, собственные метапроговские подфункции, константы, контроли/индикаторы (отличаются от констант хвостиком и носиком, служат терминалами подфункций). У циклов есть входной и выходной блоки, соединенные жесткой последовательностью. Все соединено линиями с данными (на которых бывают квадратики-разветвления) и жесткими последовательностями (их легко отличить от остальных линий). Жесткая последовательность гарантирует порядок выполнения блоков.

Чтобы сказать как реализован «метапроговский массив» надо стать травой.

это по твоему «подробная инструкция»? на да ладно. начнём с простейшего примера https://i.postimg.cc/YCywWbSh/fwrite.png

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

На сишном уровне метапроговский массив - это две отдельные переменные (указатель на массив и на длину). Посмотри скрины и сишный код первых консольных хеллоуворлдов.

объект клиентский код сможет легко привести в невалидный state путём записи в length без изменения реального размера участка памяти reallocом... сознательным buffer overflow данными от malicious user и выполнением его кода с привилегиями процесса

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

Зеленые стрелки означают последовательность, как в структуре (чтобы отличить от юниона, где были бы фиолетовые квадраты). На самом деле, в массиве не очень уместны, но пока я использую функцию рисования от структуры.

и где вообще определяется текст hello world или что там который должен выводиться?

Содержимое массива определяется в редакторе массива. Открывается отдельно при клике на массив. Все что на рисунке видно - это длину массива в байтах и тип, что это «б8», то есть беззнаковые 8-битные, то есть байты, [тип] - что массив. Да, стоило бы и отображение в виде строки добавить, но это позже, скорее всего уже после раскрутки. Тогда будет множество возможных режимов отображения одного и того же объекта.

и рисуй уже хотя бы по русски раз по английски тебе сложно

После раскрутки будут мультиязычные строки и будет русский и английский.

а что с дестракторами?

если я к примеру в C++ пишу что то типа

void f(string s1, string s2) {
  string s = s1 + s2;
  // ... some processing
}

я знаю что после выхода из ф-ции память выделенная для хранения текста в объекте s будет автоматически освобождена дестрактором т.к. исполнение выходит из scope для s. как проблема освобождения памяти будет решаться при работе с метапроговскими массивами? получается забыл вызвать нужную ф-цию и всё memory leak? и это ты называешь «в обычной практике, возможно, нужды прямо управлять памятью не будет»?

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

Может кто-нибудь из знатоков метапрога это объяснить?

Зеленые стрелки означают последовательность, как в структуре (чтобы отличить от юниона, где были бы фиолетовые квадраты).

последовательность чего? структура это вообще то ни разу не последовательность ни какая.

После раскрутки будут мультиязычные строки и будет русский и английский.

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

От memory leak будет спасать встроенный функционал для его обнаружения. Да и то что ты написал редко бывает нужно.

хорошо, с б8 понятно хотя шрифты говно прямо скажем. но что такое DказиDник и что за число 4022?

получается будет garbage collector как в ненавидимой автором джаве?

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

получается будет garbage collector

Нет, статанализ же.

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

Только там и нужно такое.

Нет, статанализ же.

и как же он будет реализован?

Только там и нужно такое.

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

и как же он будет реализован?

Превосходно.

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

Бывает, но не строки ж как ты выше написал. А с другими объектами более просто управляться, ты прям думаешь что на каждую переменную нужен будет free.

хорошо, с б8 понятно хотя шрифты говно прямо скажем. но что такое DказиDник и что за число 4022?

Да, шрифт не очень, размер тоже. При раскрутке Метапрога я это учту. Вказівник=указатель, 4022 - длина массива.

Это же можешь спросить у знатоков Си. Нет классов, есть только лишь типизированные данные и функции, работающие с ними. В ООП функции связываются с объектами (классами) и являются их частью, без ООП данные и функции в одной упряжке не сидят.

и как же он будет реализован?

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

У GCC есть расширение для деструкторов, можно заюзать: https://phoxis.org/2011/04/27/c-language-constructors-and-destructors-with-gcc/

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

Дык это вообще не про ООП %) А расширения нужны будут, обязательно. Ну не сразу конечно их крутить...

А, это типа чтобы в начале скопа был malloc и что еще нужно, а в конце делалось free и другие вещи?

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

Превосходно.

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

Бывает, но не строки ж как ты выше написал. А с другими объектами более просто управляться, ты прям думаешь что на каждую переменную нужен будет free.

а с какими другими? int, float, double? а программы которые требуют более сложной структуры данных поддерживаться не будут? и заметь строки это далеко не самый сложный тип данных.

Вказівник=указатель

откуда ты откопал такой уродский шрифт в котором В выглядит как D?

4022 - длина массива

какого массива. в коде в который оно компилируется написано unsigned long int metaprog_array_size_10156130170823954432 = 11; (кстати почему не size_t). так в каких это единицах измерения? даже в битах столько не получается.

вот ты вообще даже близко на его вопрос не ответил. то есть ты будешь кастить к (void*) и скармливать одной и той же ф-ции разные типы данных и похеру что дальше будет или как?

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

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

Конкретнее вопросы задавай.

а с какими другими?

Строки слишком базовый тип.

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

Конкретный вопрос: приведи пример не слишком базового типа.

class TriangleMesh : public SceneNode { ... };

ну и что он делает?

От memory leak будет спасать встроенный функционал для его обнаружения.

«У него внутре неонка!»

статанализ

Прочёл без второй буквы - стало не по себе. Катализ, диализ, сатанализ…

Да. Воистину Выбегалло.

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

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

откуда ты откопал такой уродский шрифт в котором В выглядит как D?

Издержки маленького размера шрифта.

какого массива. в коде в который оно компилируется написано unsigned long int metaprog_array_size_10156130170823954432 = 11;

Вот этого: char metaprog_array_pointer_10156130170823954432[]. Цифра та же, заметь.

(кстати почему не size_t).

Хороший вопрос. Возможно, стоит использовать именно size_t. Пока что оно у меня все сведено к примитивным типам. А 32-битное использовал именно из-за того, что, кажется, size_t такой. Хотя тут уже вопрос а что делать если у меня массив больше 4 Гб?))

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

Байты. Черт, 4022 - не тот скрин, спутал, должно быть 11. Хотел цитату Линуса про С++ или еще что такое толстое впихнуть вместо хеллоуворлда - кажется, ЛОР матюкнулся что слишком длинное сообщение.

Далеко не самый толстый пример

struct {
struct {
struct {
struct {
unsigned long int element0;
} *  element0;
} element0;
unsigned long int element1;
struct {
} *  element2;
} element0;
struct {
} *  element1;
} * metaprog_instance_0_pointer_6579771454770309121 = (
0);