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

Неиспользуемые включения и так оптимизируются компилятором, зачем их править?

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

а теперь на нем уже можно делать не менее чем графически интерфейсы

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

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

Сомнительный плюс.

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

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

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

Это из за хака с окнами. Он скоро будет убран.

Графический интерфейс уже неплохо собирается кстати, есть обвязки для nk_edit_string, который требует хранения состояния от пользователя, итд. Простой примерчик выглядит так: https://i.imgur.com/hgqpdij.png

клоун… дворник это потолок Вашего карьерного роста… паразит

Ребят, ну может, хватит уже?

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

Предлагаю оставить ТСа в покое. И комментировать только конкретные вопросы и высказывания и только по существу. Или просто игнорировать, если комментировать нет желания/смысла. Так он либо быстрее слепит что-нибудь, что можно обсуждать, либо забьёт. Оба результата на мой взгляд можно считать положительными. :) Пусть у человека будет рабочая обстановка…

На 90% комментариев ТСа в этом треде лучший ответ — молчание. На оставшиеся 10% можно ответить, если охота поделиться знаниями (но можно и не отвечать).

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

куча варнингов при компиляции, утечки памяти

Ну вот это да, имеет смысл обсуждать. Кстати, предупреждения при компиляции опять вылазят? ТС же вроде это заборол в предыдущих темах…

Лично мне по существу надоело, потому что он не умеет слушать.

Ну тогда можно просто не комментировать. :)

Да я и подсказываю

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

Так я и так почти не комментирую уже.

И чем больше обидных кличек ему будут клеить — тем больше он в своём убеждении укрепяются.

Это не клички, это увы факты. Ты с такими в жизни не встречался? Я встречался пару раз, хуже всего когда такое чудо выбивается в начальники, пусть даже в зав.отделом очистки.

Да, с ним в общем говорить уже не о чем - он перестал быть даже смешным.

На самом деле, вот какой должен бы быть Метапрог:

https://statebox.org/what-is/

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

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

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

Там половину предупреждений если не все (не проверял именно будильник) можно махом снять просто удалив не нужные инклуды, ну по крайней мере это нормально работает с примером «теста массива» который конечно же ничего не тестирует по сути.

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

осталось сделать что-то сродни карго для С++ из коробки

C++20 с модулями уже вот вот должен релизнуться, дальше уже остается подождать, пока в компиляторы это запихнут (в шланге уже есть превью) и популярные библиотеки переедут на модули, и тада уже нормальный ПМ не заставит себя долго ждать.

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

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

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

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

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

А всякие разные make?

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

Да, в общем согласен - gcc -M еще надо правильно приготовить. Мне иногда лень и при сборке крупного проекта на первый анализ зависимостей уходит секунд 5-10…

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

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

Про технические детали я не могу сказать я не интересуюсь особо экосистемой С и что у них там на переднем краю разработок, надеюсь тут есть люди которые мейнят с/c++ и живо этим интересуются, а то бывает так что мейнить то мейнят, а продолжают писать на условном С++11

Как связаны модули и ПМ? Чем vcpkg не нормальный пакетный менеджер?

Модули уже есть и в gcc: https://gcc.gnu.org/wiki/cxx-modules

И в MSVC: https://imgur.com/a/cH3cwGk

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

In a C-based language, it is hard to build tools that work well with software libraries, because the boundaries of the libraries are not clear. Which headers belong to a particular library, and in what order should those headers be included to guarantee that they compile correctly.

Это отсюда

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

vcpkg кстати неплох (я его даже советовал где-то), но всё равно это просто набор костылей, и он не отменяет необходимость возиться с кривым cmake (если кроссплатформенное приложение, в родном виндовом msbuild оно просто работает).

За другие фичи модулей пока не скажу, т.к. меня от крестов отталкивает именно ужасающий тулинг. То ли дело Go с Растом, cargo build и всё, одинаково без проблем соберётся как на венде, так и на линуксе.

этот vcpkg есть на всех популярных платформах

Да. https://github.com/microsoft/vcpkg/blob/master/docs/index.md

Windows, Linux, Mac (FreeBSD и Android, не официально, но умеет тоже)

поддерживает версионность кода

Да, это же git, в папке с библиотекой можно уйти на заданный коммит, если нужна какая-то старая версия библиотеки, а не последняя

вытягивает зависимости автоматом по конфигу

Зависимости сам вытягивает.

Установка происходит глобальная(для конкретной папки с vcpkg, может быть несколько таких папок для разных проектов с разными версиями одних и тех же библиотек): Выглядит примерно так:

C:\Dev\vcpkg\vcpkg.exe install boost-math:x64-windows

если напишешь свой скрипт, который будет парсить текстовый файл, то можно и не в ручную а для конфига. В отличие от Nuget, или cargo, которые компилируют каждый раз все зависимости для проекта. vcpkg собирает зависимости глобально.(можно иметь несколько папок с vcpkg, если нужны разные версии библиотек)

умеет собирать кроссплатформенный код?

Это пакетный менеджер, а не система сборки. CMake умеет собирать кроссплатформенный код.

cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=C:\Dev\vcpkg\scripts\buildsystems\vcpkg.cmake -S . -B build.x64

В отличие от Nuget, или cargo, которые компилируют каждый раз все зависимости для проекта.

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

Да, это же git, в папке с библиотекой можно уйти на заданный коммит, если нужна какая-то старая версия библиотеки, а не последняя

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

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

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

Это пакетный менеджер, а не система сборки

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

хуже всего когда такое чудо выбивается в начальники

Ты, наверное, про немного другой тип личности говоришь (и да, такой начальник — катастрофа). ТС слишком простодушен для этого.

vcpkg он вообще в сторонней папке находится и никак не связан с вашим проектом. Он устанавливает зависимости в свою папку. И у него просто есть cmake скрипт который говорит cmake где искать зависимости вместо стандартных мест…

vcpkg\scripts\buildsystems\vcpkg.cmake

Вот тут можно прочитать про костыли если нужно указывать не просто название библиотеки, а конкретную версию: https://github.com/microsoft/vcpkg/issues/1681 (все эти git махинации производятся над папкой vcpkg, а не вашего проекта)

лайк

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

Почему же про другой? Оно думает что все может прошарить, а то что оно сходу не знает/понимает то вообще не нужно.

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

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

C++20 с модулями уже вот вот должен релизнуться

Ой, неужели наконец-то решились? А то я то же самое слышал перед C++17…

P.S. Погуглил, нашёл пример экспортируемого хеллоуворлда. Но меня бы заинтересовал пример модуля с классом: сохраняется ли там разделение на определение и реализацию, или свалили их в кучу, как в C#/Java. Мне бы хотелось первый вариант, конечно…

Верующий да обрящет :3

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

Тем, что её нет.

В плюсах есть раздельная компиляция в объектные модули, дополненная костылями из говна и палок на препроцессоре из начала 70-х. Это — не модульность. #include — это всего лишь включение одной стены текста в другую стену текста, единицей языка оно не является. Препроцессор делает из стен текста набор мегастен, компилятор эти мегастены преобразует в кучку объектных файлов, подставляя для каждой функции первый попавшийся прототип, потом в дело вступает компоновщик, пытаясь разрешить все неразрешённые имена. Из какой стены текста что взято, он не знает, он тупо шарит по библиотекам.

Это приводит к очень разнообразным и весёлым последствиям. Начиная с банального падения скорости сборки, и кончая непредсказуемой реакцией на ошибки программиста. Если я в языке с модульностью забуду директиву импорта, я гарантированно получу сообщение об ошибке. Если я в крестах или сишечке забуду #include, результат зависит от фазы Луны, поскольку в одной версии некоей библиотеки порядок вложения заголовочных файлов друг в друга может быть одним, в другой — совсем другим.

Ок, спасибо.

Дополню, что нормальные модули были, скажем, в Турбо Паскале (который тут принято презирать) уже году так в 1990-м. Ещё можно на Java посмотреть, она помоложе и поинтереснее…

А в питоне нормальные модули?

ну там тоже разброд и шатание в том как поддерживать модульность и куча инструментов для этого, но в принципе все лучше с/с++ в этом плане.

Ой, неужели наконец-то решились?

Ну, во всяком случае обещают в этом месяце выкатить.

разделение на определение и реализацию

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

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

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

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

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

«Антиметапрогеры» — отличное название для метал-группы! Присоединяйтесь!

https://i.imgur.com/nsEKiVx.jpg

Дык злые антиметапрогеров всех распугали! На самом деле его упоротость перебила его харизму. Он просто не туда зашёл, в песочнице у подъезда вся школота была бы его.

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

а руст так и в этих задачах почти ни чем не уступает С

Уступает по скорости, библиотекам, переносимости...

лайфтаймы это только будущее с++, в русте «они» уже есть из коробки

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

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

Важно же, во первых rust делают анскильные лалки, которые не могут даже -ffast-math поддержать, во вторых rust строится на llvm, а значит шагнуть дальше C/C++ просто не может, ну нету такой возможности, тем более он состоит из ограничений (возможностей).

осталось сделать что-то сродни карго для С++ из коробки

vcpkg

А что модули дадут? Ограничения? Не знаю зачем это ПМу.