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

Да, C - частично ООП язык. Большая часть кода пишется в процедурном стиле, но никто не мешает писать и в ООП-стиле (что и сделано в GTK, например)

ОП без всяких сомнений взял ООПнутые библиотеки и на них строит metaprog, в чем проблемы собсна?

В том, что он обсирает ООП, не понимая, о чём говорит (при этом использует это ООП, что вообщем-то очевидно)

Но в С ООП используется к месту, в отличие от...

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

В С, потому что в С++ практически принудительное ООП.

Палишься.

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

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

Если бы я был таким сильным сторонником графического программирования, я бы выделил направления для реальной работы:

0) формат диаграмм. Как я понимаю, это уже более-менее определилось, поэтому ставлю номер ноль;

1) формат внутреннего представления, и как на него отображаются диаграммы. Вот это бы надо покрутить потщательнее. Как я уже писал, я бы этот формат сделал текстовым. Ибо как минимум пока вся система не получила общественного признания, писать визуальный дифф, систему управления версиями и ещё дофига всего — пустая трата времени. А текстовый формат даёт свободу выбора, и не только тебе (подробнее раскрою чуть ниже);

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

3) написать IDE, он же редактор диаграмм. По мере реализации этого пункта, скорее всего, придётся несколько раз возвращаться к предыдущему. Это нормально.

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

Теперь, как обещал, раскрою тезис о доверии. Внутренний текстовый формат помог бы убить двух зайцев:

1) воспользоваться богатейшим аппаратом работы с текстовыми исходниками, разработанным под свободными лицензиями;

2) предоставить потенциальным товарищам по разработке возможность выбора. Один будет пользоваться текстовым гитом, не изменяя своим привычкам, а второй - будущей графической VCS (которая так же может быть надстроена и над текстовым представлением). Да может, он сам её и напишет со временем, если ты его сразу не распугаешь.

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

Ты таблетки забыл принять.

Теперь, как обещал, раскрою тезис о доверии. Внутренний текстовый формат помог бы убить двух зайцев:
1) воспользоваться богатейшим аппаратом работы с текстовыми исходниками, разработанным под свободными лицензиями;

Зато тормоза, ну можно сделать конвертер в текст если так хочется!

Пусть ТС ответит. :)

новые понятия - это жуткий геморрой

;) смотря кто чем думает. Вот диаграммы и поддиаграммы это крутЪ! Разве там есть новые понятия? Нет, конечно! Зелёные стрелки — крутЪ! Если, чо 7 цветами радуги ограничиваться не стоит. Ведь глаз человека способен различать тысячи оттенков (толи 16 тысяч, толи 100 тысяч) — хватит на всё! А вот текстовые подсказки говно, которое тянет гениальнейший metaprog в болото текстового программирования! Их надо сразу выпилять!

Ну я просто идеи даю!

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

А дальтоники?

А вот текстовые подсказки говно

Иногда, потому во всех соверменных IDE мешают текст со всякими рисовалками.

Для дальтоников сделаем metaprog c оттенками серого. Или пусть сидят на убогих текстовых языках.

А вот текстовые подсказки говно

Иногда, потому во всех соверменных IDE мешают текст со всякими рисовалками.

Я шото не понял, тебе что metaprog не нравиться?!

ТС не троллить пришел, а «донаты» собирать. Это было очевидно уже по наличию биткоин-кошелька в самом первом треде. Интересно, хоть копейку собрал?

C++ - надмножество C, из чего следует, что не обязательный там ООП (если в C он не обязательный)

C++ - надмножество C

Просто схожи, у них много различий.

Хммм, что-то интересное. map or unmap files or devices into memory - это? http://man7.org/linux/man-pages/man2/mmap.2.html

Если да, то попробуй рассказать подоступнее как им пользоваться (мануал есть, но слишком заумный). Можно ли им мапить массивы в файл и из файла?

Я просто вспомнил «Царя». Вообще это штука позволяет использовать файл как будто бы он уже загружен весь, но это обман, он подгружается только в той части где ты к нему обращаешься.

Пересылать данные из файла в файл вроде нужно через линуксовую функцию sendfile!

Можно ли им мапить массивы в файл и из файла

Не совсем понял, но ты можешь имеешь виду запись? Можно открыть файл mmap'ом одновременно на чтение и запись. А работать как с массивом простым.

А, просто работать с файлом как с массивом, через указатель?

Да, так и делается, тебе дается указатель как при вызове malloc.

Различия там совсем минимальные, из того, что реально вспоминается - только очень логичное требование явного каста из void* в любой другой указатель и отсутствие всяких стремных безымянных структур. В остальном C++ - это надмножество C, т.е. любой код на C (не содержащий этих минимальных отличий) будет валидным C++ кодом.

0, 1. Уже строю диаграммы в лабвьюшном прототипе метапрога (в том числе те, что вы выдели на скринах) и определяюсь с их форматом. Пока как-то так:

https://i.postimg.cc/4ys016Fp/image.png

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

2, 3. Транслятор блок-диаграмм в Си как раз уже делается, и IDE тоже. Но пока в лабвьюшном прототипе (его вы и видите на скринах, а в коде - результат работы транслятора), так как на чистом Си без помощи графического IDE я такое программировать буду раз в 100 медленнее. Чуть позже начнется перенос Метапрога «сам на себя».

zero-size struct, void*, union, pointer cast, complex, atomic, old C arguments declaration, inline, restrict. Ну а еще плюсисты зарубят тебя если ты не будешь использовать классы, всякие перегрузки итд.

Это я назвал что реально попадается в коде, различий которые «скрыты» 100500!

Версионированный бинарный формат убввает двух зайцев:

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

2. Быстродействие из-за «тупой» сериализации без парсера.

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

Бинарный формат будет читаемым, исходники Метапрога вместе с типами формата будут открытыми.

inline

Появился в сишечке уже после плюсов, не в счет.

union

А в чем разница?

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

Если это мешает читаемости/идиоматичности, то да.

требование явного каста из void* в любой другой указатель и отсутствие всяких стремных безымянных структур

Да, транслятор с Метапрога на С++ был бы куда сложнее чем на чистый Си. Я как раз декларирую безымянные структуры и пользуюсь void-указателями - и они работают, черт побери!

Это очень плохая идея. В самих по себе void* нет ничего плохого, но они очень сильно запутывают при неявных кастах. Хотя читать тот код всё равно невозможно.

Появился в сишечке уже после плюсов, не в счет.

Только это совсем другой inline, лол.

А в чем разница?

В С++ можно читать только тот тип в который в последний раз была произведена запись.

Если это мешает читаемости/идиоматичности, то да.

То есть нужно их везде впихнуть!

Зачем код читать, если есть графические диаграммы? Там и так все очевидно.

Кстати, в указатели типа void*, int* итд нельзя ложить указатели на функции и наоборот, так как на некоторых архитектурах (например x86/real-mode) они разного размера! (Ну или вообще устройства)

Указатели на функции то вообще отдельная песня вроде как. Думаю их делать через проводники жестких последовательностей.

В С++ можно читать только тот тип в который в последний раз была произведена запись.

Хотя бы ради этого стоило в этом треде быть. Today We Learn!

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

То есть нужно их везде впихнуть!

Если делать разумно, то не везде.

Разумно это не про людей, логика понятие искушственное! Страуструп сказал надо, значит надо.

Хорошо, замени слово «разумно» на «по ситуации».

Да, если подумать, то вы частично правы. Как-то не обращал в реальной жизни внимания на различия, и всё казалось, что Страуструп и правда сделал superset of C. Прям глаза сегодня открываются!

Ну вот в Лабвью ловлю иногда 0xBULLSHIT fatal error in govnocode.cpp line 235

Прям глаза сегодня открываются!

Глядишь скоро и к metaprog'у потянешься!

А я в ядре ловлю паники на китайской арм-борде. Значит, C - лютое говно и нужно выкинуть на помойку, так?

Это точно.

Но лучше же никто не сделал!

Ты зачем кормишь этого недоумка? Пора уже изгнать дебила.

Букварь уже прочитал свой?

Сделаем ещё на метапроге!