LINUX.ORG.RU

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

 , , ,


4

3

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

FAQ

1. Где скачать?

Релиза еще не было. Идет разработка, темы посвящены ей. Есть сделанный на LabVIEW прототип (его работа показана в примерах).

2. Почему не открыт код LabVIEW-прототипа Метапрога?

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

3. Почему не Дракон, MIT App Inventor, Unreal Blueprints?

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

4. Чем плохи LabVIEW или MyOpenLab?

LabVIEW пропиетарный, а MyOpenLab - хоть и опенсорсный, но какой-то недоделанный (пытался у себя запустить - выдало джава эксепшоны). Да-да, опенсорсный «клон» LabVIEW написанный на джаве! LabVIEW хотя бы на C++, а это все же меньшее зло. Обе эти системы даже не сделаны «сами на себе» в графике. Они даже не пытаются претендовать на универсальную замену всем текстовым языкам, хотя LabVIEW могло бы, если бы не тупость копирастов. Эти системы написаны на текстовых языках, их код (даже если б LabVIEW был опенсорсным) невозможно редактировать, ни разу не обращаясь к текстовым языкам. Метапрог изначально предполагает полный отрыв от текста и текстовых языков, за исключением Си как бэкенда. И то пользователям никогда не придется иметь дело с текстовым Си за исключением блоков сишных вставок (для особых случаев типа арифметических операций, ассемблерных вставок итп).

5. Почему как бэкенд выбран именно Си?

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

6. В Си указатели и ручное управление памятью. Это же так сложно!

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

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

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

8. Почему в Метапроге будут предпочитаться бинарные форматы и чем это лучше?

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

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/unflatten_from_string/

Что-то подобное будет и в Метапроге. При открытом коде никаких сложностей с чтением бинарных файлов не будет.

9. А как будет обеспечиваться совместимость со старыми файлами, сетевыми протоколами итп, если будет изменен тип?

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

Примеры

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

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

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

Прокручиваемая и выделяемая строка с автопереносом

https://i.postimg.cc/Gm6KMJBs/image.png

https://pastebin.com/SWJJwvvC

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

Скрины подфункций в следующем примере.

Тот же пример, но покрасивее

Что можно сделать для большего удобства? Убрать инициализацию, подвязку коллбэка на закрытие окна и главную петлю гтк в подддиаграму «главное окно»:

https://i.postimg.cc/vm5DYjsw/image.png

На сей раз не поленюсь сделать скрины и объяснить их суть.

В подфункциях есть три вида контейнеров с данными: константа (стала, constant), контроль и индикатор (сверху вниз):

https://i.postimg.cc/gJkfRVBd/image.png

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

Сама подфункция «главное окно»:

https://i.postimg.cc/fbsDKR61/image.png

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

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

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

Подфункция для подцепки асинхронных функций:

https://i.postimg.cc/3r0rYVCS/image.png

Добавить объект в контейнер:

https://i.postimg.cc/SNGBhf51/image.png

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

https://i.postimg.cc/xjv7vP0j/image.png

Делаем лейбл (и любой другой нужный виджет) прокручиваемым:

https://i.postimg.cc/R0PtCmkd/image.png

Как видим, сишные функции успешно уходят под капот и программировать в графике становится намного проще. Из этого получается такой код:

https://pastebin.com/16bq1Jbs

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

Каст типов и тактическая победа над нуль-терминированными строками

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

https://i.postimg.cc/s2hrDj6b/image.png

Беззнаковое 32-битное, означающее размер массива (темно-синий провод) кастуется в знаковое 32-битное (светло-синие провода и пустая константа, задающая тип). Функция gtk_text_buffer_set_text в качестве размера строки берет беззнаковое, а не знаковое, как принято - видимо, чтобы через "-1" говорить, что строка нуль-терминированная. Но из-за этого вместо 4 гб строки туда можно подать лишь 2 гб - аж в 2 раза меншье! Что за люди?

Тем не менее, с нуль-терминированными функциями в текстовых полях покончено - и это победа!

https://pastebin.com/hQRMSZ1s

Также там был изменен текст. В остальном пример соответствует скринам выше.



Последнее исправление: CYB3R (всего исправлений: 7)

Ответ на: комментарий от Deleted

Это не в языках. Почти во всех языках можно создать сколько угодно сущностей. Но в самих языках они тоже есть. И в более высокоуровневых Хаскеле и Питоне (хоть и никогда не любил Питон) их меньше чем в Си.

vlad9486
()
Ответ на: комментарий от Deleted

В любом языке с массивами можно такое сделать.

Можно, и никто не делает. Т.к. потеря гибкости никому не нужна.

Иногда это оправданно.

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

Нет.

Да.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

О чём и речь. Потом оказывается что нет

...

Да.

Просто С легкий язык, на нем много ерунды пишут, так как «начинающие».

Deleted
()
Ответ на: комментарий от hobbit

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

rebforce
()
Ответ на: комментарий от rebforce

Есть куча скринов и компилируемого кода для демонстрации. Хотя, конечно, это не сравнить с работающим прототипом. К сожалению, Лабвью платное и среди линуксоидов мало котируется, смысла его выкатывать нет. Придется для полноты ощущений ждать альфы.

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

при том что судя по задаваемым вопросам ты далеко не системный программист. когда страустрап делал свою надстройку над C каковой по сути являлся первый интерпретатор C++ -> C думаю он обладал явно большим запасом знаний.

iluha16
()
Последнее исправление: iluha16 (всего исправлений: 1)
Ответ на: комментарий от iluha16

Не трогай дерьмо, и оно вонять не будет. Ему уже 4 треда объясняют, а он прям по методичке «Правила демагога» шпарит. Бесполезно.

vq156 ★★
()
Ответ на: комментарий от iluha16

интерпретатор C++ -> C транслятор C++ -> C

извиняюсь за опечатку

iluha16
()
Ответ на: комментарий от iluha16

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

iluha16
()
Ответ на: комментарий от iluha16

Для чего существует ООП? Оно проще? Для чего С++, если есть чистый Си? Он проще? Если да, то освоить его должно быть проще, но в реальности С++ неимоверно сложнее в освоении чем чистый Си. Если даже сам Страуструпп оценивает свое знание С++ на 8 из 10 (из вики), то ООП явно сложнее. И для компиляции и выполнения «железом» ООП-код тоже сложнее. Так зачем учить и осваивать ООП?

metaprog
() автор топика
Ответ на: комментарий от rebforce

Близится 4 мая, а концепт твоей «визуальной среды» был обещан до 3 мая. Успеешь за оставшиеся часы?

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

iluha16
()
Ответ на: комментарий от rebforce

Осталось меньше 2 часов. Часики тикают.

metaprog
() автор топика
Ответ на: комментарий от metaprog

Говорить, что ООП сложное потому, что С++ сложный - это как говорить, что все ноуты говно потому, что винда - говно. ООП не ограничивается С++, как и ОС не ограничивается виндой. Вообще, пример С++ неудачный. С++ - это один из самых сложных (в плане количества особенностей языка) ЯП в мире. И переделать, чтобы всё с нуля и правильно не получится - потеряется совместимость на уровне исходников и ЯП станет никому не нужным.

99% С++ разработчиков используют своё подмножество языка, а не все фичи, и им норм. Тот же Qt для С++ - на нём можно писать проект любой сложности (под силу далеко не каждому), и при этом использовать 30% возможностей языка.

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

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

arturianec100
()
Ответ на: комментарий от metaprog

да проще чем другие ООП языки (тот же python) не говоря уже о вебдаунистических технологиях пихаемых ныне повсюду. если ты говоришь о фичах самого языка perfomance hit настолько незначителен что им можно пренебречь на фоне современного железа и современного жирного софта. тем более к примеру методы в C++ по умолчанию даже не virtual что позволяет избежать вставки в объекты класса малюсенькой таблички с pointer'ами, одним словом на perfomance он ориентирован и вряд ли какой то другой ООП язык может сравниться с ним по производительности. если ты говоришь о производительности STL то ты можешь наклепать конечно более эффективный код с pointer'ами и malloc наделав при этом кучу багов.

iluha16
()
Ответ на: комментарий от arturianec100

C прост в изучении и написании hello world. Язык прост и логичен. Python сложен для изучения целиком но прост в написании скриптов из готовых библиотек для чего не нужно знать весь язык а в большинстве случаев только основы. C++ для профессионалов время которых стоит дороже чем полсекунды процессорного времени о чём говорить вообще считаю абсурдным на фоне других современных языков джавы, python'а, javascript'ов от которых загибаются мощнейшие компы под тяжестью тонн оопического говнокода.

iluha16
()
Ответ на: комментарий от arturianec100

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

Зависит от задач.

Deleted
()
Ответ на: комментарий от iluha16

Хром и нода jit'ят js в машинный код + нашлись извращенцы, что пихают js в ардуину! даже не в одноплатники а-ля малинка, а схема, что не тянет ОС, где код пишется на js!

С учётом этого драйвера на js вполне возможны. Но слава Богу, что это никому не нужно кроме кучки извращенцев.

arturianec100
()
Ответ на: комментарий от iluha16

Сколько раз писали, что тормозит не js, а DOM и кривой код. Правда, в js и питоне объекты сделаны на основе словарей. В результате сишное и с++ное person->name в жс и питоне person.name де-факто превращается в что-то типа

std::map<std::string, std::variant> person;
name = person["name"];
person["hi"]();
Правда, гугл потратил кучу усилий и теперь жс в этом плане не сильно отстаёт от плюсов.

arturianec100
()
Ответ на: комментарий от iluha16

Qt очень сильно понижает порог входа для С++ для разработки полезных программ. Даже в таких областях как быстрый обмен данными между разными потоками без дедлоков.

Плюс есть куча десктопного легаси, где чёрт ногу сломит а-ля фотошоп, 3д макс. Хотя почти любой огромный десктопный и не только софт пишется на С++. Ядра и драйвера - это уже царство сишки.

И что же это за мастера С++ и какие проблемы они решают, что им платят такие космические зарплаты?

arturianec100
()
Ответ на: комментарий от rebforce

концепт AMP будет устаканен в течение недели

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

Неделя прошла. «Спецификаций» и чего-либо еще нет. Торжественно объявляю тебя пи брехуном.

metaprog
() автор топика
Ответ на: комментарий от iluha16

Бесспорно С++ лучше питонов, джав и другого говна, даже как пользователь программ замечаю. Но это все же меньшее из зол. Чистый Си лучше http://harmful.cat-v.org/software/c /

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

metaprog
() автор топика
Ответ на: комментарий от arturianec100

какие космические зарплаты? труд уборщика дороже в 10 раз того процессорного времени которое затратится на C++ программу в сравнении с тем что на быдлокодит этот школьник pointer'ами на C. с учётом повсеместного засилья вебдаунизма даже джава выглядит performance oriented технологией. да я в курсе что тормозит dom, и ещё css3 и прочие свистопердящие онемацеи в электронах и т.д. говнофреймвёрках. глазам своим не верю что в век засилье жырных фреймвёрков, джав, питонов и прочих многотонных выжирающих память софтовин кто то завёл разговор о производительности C++ который уже во времена начала работы страустрапа был не актуален.

iluha16
()
Ответ на: комментарий от metaprog

C++ никак не может быть лучше или хуже питонов так же как отвёртка никак не может быть лучше молотка а грузовик лучше мотоцикла.

iluha16
()
Ответ на: комментарий от iluha16

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

metaprog
() автор топика
Ответ на: комментарий от arturianec100

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

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

а всё потому что на C пишется системный софт системными программистами относительно высокой квалификации и тестируется всё это дело очень хорошо потому что используется много где в том числе корпорациями. ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

в то же время если ты делаешь GUI для работы с базой данной хранящей сотни миллионов записей ты можешь убить месяц на клепание этого гуя на C и ещё год на обработку баг репортов о сегфаултах или наляпать на Python за день только узким местом всё равно будет являться база данных которую как раз надо делать на C и желательно ещё со вставками ассемблерного кода местами потому как поиск по таким объёмам информации дело не простое и твой супербыстрый GUI всё равно большую часть времени будет простаивать дожидаясь ответа от базы данных.

а что у тебя на плюсах падает?

iluha16
()
Ответ на: комментарий от iluha16

а что у тебя на плюсах падает?

Мне вот проще сказать что не падает %)

ты можешь убить месяц на клепание этого гуя на C

Но GUI делается в glade, плюс там еще удобное подключение сигналов чисто для С!

Deleted
()
Ответ на: комментарий от metaprog

Для чего существует ООП? Оно проще?

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

  • ООП — namespace isolation
  • Функциональное — работа с массивами, списками
  • Реактивное — интерфейсы пользователя, и может ещё что-то
  • Императивное — связка между всеми этими вот

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

На чистом Си нету никакой изоляции пространства имён, кроме static. Да и вообще с пространством имён у Си наверное хуже всего в мире. Анонимных функций нету — придумывать имена нужно для всяких затычек.

kostyarin_ ★★
()
Ответ на: комментарий от metaprog

Я сужу языки программирования по программам, на них написанным.

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

Ну и эта... если судить «по программам, на них написанным», то для твоей задачи лучший язык - это Java. Поскольку почему-то всякие моделлеры, диаграммеры и др. народ предпочитает писать именно на ней. (Это если не вспоминать про рантайм, сборку мусора и прочие технические подробности, а именно судить «по программам, на них написанным».)

hobbit ★★★★★
()
Ответ на: комментарий от kostyarin_

говорят, после примерно 30,000 LOC в C начинаются реальные проблемы с пространством имён. но это ещё не самое страшное. огромное количество ошибок в C это отсутствие гарантированной инициализации сложных структур (constructor).

iluha16
()
Ответ на: комментарий от iluha16

ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

Я это знаю и даже приводил в пример в контексте «не ждите слишком многого от первых версий Метапрога». Этот пример показывает как низкоуровневый Си позволяет допиливать софт практически до совершенства, не оглядываясь на всякие идиотские абстракции и объектные модели. Метапрог тоже будет весьма низкоуровневым, с указателями (ручным управлением памятью). Всякие дополнительные плюшки для удобства построения диаграмм будут только на уровне редактора диаграмм. Метапрог генерирует сишный код, в котором каждому куску кода однозначно соответствует блок на диаграмме.

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

metaprog
() автор топика
Ответ на: комментарий от iluha16

отсутствие гарантированной инициализации сложных структур

удваиваю

начинаются реальные проблемы с пространством имён

А ещё прикол в том, что нельзя сделать

enum x {
   X_ONE
};

struct x {
};

Т.е. блин приходиться

enum x_enum {
    X_ONE
};
struct x_struct {
};
или типа того. При этом struct и enum становятся частью имени. У меня в одно время от этого сгорело.

kostyarin_ ★★
()
Ответ на: комментарий от iluha16

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

Сделать разделяемую библиотеку Метапрогом не получиться или будет не тривиальной задачей?

kostyarin_ ★★
()
Ответ на: комментарий от metaprog

Кстати, как насчёт выложить исходники на bitbuket.org? Там есть приватные бесплатные репозитории, к которым Вы можете допустить только тех, кого хотите. И сделать репозиторий открытым, если будет нужно.

kostyarin_ ★★
()
Ответ на: комментарий от hobbit

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

Этот пример показывает как низкоуровневый Си позволяет допиливать софт практически до совершенства, не оглядываясь на всякие идиотские абстракции и объектные модели

аххаха. идиотские абстракции как раз таки и созданы для удобства допиливания. представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код. почитай книгу Bruce Eckel «Thinking in C++» что бы разобраться а не тупо обсирать. там такие вещи очень хорошо описаны. и довести до ума программу на ООП гораздо проще чем без него.

iluha16
()
Ответ на: комментарий от kostyarin_

Я либо открываю код под GPL, либо не открываю. Код лабвью-прототипа не открываю потому что п. 2 FAQ.

metaprog
() автор топика
Ответ на: комментарий от kostyarin_

Библиотеку типа .so, .ko и .dll? Думаю будет несложно... когда руки дойдут до этого, но это уже будет после раскрутки Метапрога.

metaprog
() автор топика
Ответ на: комментарий от metaprog

т.е. ты предпочитаешь писать в стиле

if (!( dirp = opendir(argv[1]) )) {
  perror("opendir(3)");
  return 2;
}

вместо обработки exceptions в одном месте? или просто игнорируешь проблему, пущай её идёт дальшь dirp == NULL и падает в segfault?

iluha16
()
Ответ на: комментарий от iluha16

идиотские абстракции как раз таки и созданы для удобства допиливания

Только самая главная моя претензия к ООП - сложность в освоении - никуда не девается. Читай что-то да учись все время, ведь даже сам Страуструпп оценивает свое знание С++ на 8/10. ООП - хороший выбор для любителей вечно учиться да читать, но я не из таких.

представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код.

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

metaprog
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.