GSoap и современный C++

Также не испольpовал: class, std. STL, … Это вовсе не панацея.

Вот GUI здорового человека:

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

Вообще-то нужно рассеять туман суждений своих топиков.

Использую вместо class struct потому, что разработал свою подсистему управления объектами. Да и crt своё. Поэтому не использую std, STL, template, …

В результате код API прост и его можно собрать под любой версией C++, да и кроссплаформен.

                           area<%>
        _____________________|_______________
        |               |                   |
      subarea<%>     window<%>       area-container<%>      
<<<____|____       _____|__________       __|___  ___________________<<<
            |      |              |       |    |  |                  
           subwindow<%>           |       |    |  |                  
<<<______________|___________     |       |    |  |                 _<<<
            |               |     |       |    pane%                |
       control<%>           |     |       |     |- horizontal-pane% |
        |- message%         |     |       |     |- vertical-pane%   |
        |- button%          |     |       |                         |
        |- check-box%       |  area-container-window<%>             |
        |- slider%          |        |                              |
        |- gauge%           |        |            __________________|
        |- text-field%      |        |            |   
            |- combo-field% |        |-------- panel%       
        |- radio-box%       |        |          |- horizontal-panel%
        |- list-control<%>  |        |          |- vertical-panel%
            |- choice%      |        |              |- tab-panel%
            |- list-box%    |        |              |- group-box-panel%
                            |        |
                            |        |- top-level-window<%>
                            |            |- frame% 
                         canvas<%>       |- dialog%
                          |- canvas%
                          |- editor-canvas%
Menus:

    menu-item<%>                menu-item-container<%> 
        |                              | 
        |- separator-menu-item%   _____|___ 
        |- labelled-menu-item<%>  |       |- menu-bar% 
            _________|_________   |       |- popup-menu% 
            |                 |   | 
            |                 menu%
            |                          
            |- selectable-menu-item<%>               
                |- menu-item%                        
                |- checkable-menu-item%

Events and other:

       event%                                 timer%
        |- key-event%                         cursor%
        |- mouse-event%                    
        |- scroll-event%                      clipboard<%>
        |- control-event%                     clipboard-client%

Классы — то, что заканчивается на «%». Остальное интерфейсы.

Ещё немного скажу о C++.

ИМХО это безусловно язык для системного программирования. Что касаемо Rust, то не использую его потому, что те задачи, которые он решает решены в коде API.

monk, class это всего лишь один из возможных подходов к управлению объектами. ИМХО всё же твоё суждение о том, что не следует использовать иерархию более трёх лишь подтверждает то, что в «консерватории что-то не так». Но целом конечно можно и class использовать.

ракет юзает небось уже готовые нативные или еще какие контролы, а не строит их сам

Вот есть Qt. У него QDialog : QWidget : QObject. Тоже скажешь, что на Linux он их сам не строит?

Что такое нынешнии архитектуры компьютеров? Это байтики и память. Нужно просто уметь их правильно тасовать.

Что касаемо карьеры программистов, то здесь главное уметь делать задумчимое и умное лицо. Быть «загадкой».

Вот есть Qt. У него QDialog : QWidget : QObject. Тоже скажешь, что на Linux он их сам не строит?

QDialog - это какой-то нефинишный класс, внутри иерархии классов.

вот сюда надо смотреть, тут глубокое наследование.

https://doc.qt.io/qt-6/qtreewidget.html

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

monk говорит, что в 1С 8.3 два уровня в иерархии классов. А у них подсистем разного API весьма много.

Получается они «второклассники» …

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

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

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

P.S. Тред не читал.

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

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

А если во входящем файле .h писать std::unique_ptr разве не генерирует правильно?

monk, какую разработку ныне ведёшь?

У меня в планах разработка переводчика.
Эта задача вынудит начать разработку баз знаний.

https://github.com/Kalimehtar/russian-lang

Мир программирования не огранивается «миром компиляторов». Весь тред пронизан «миром компиляторов». Доминируют в мире программирования не компиляторы. Компиляторы лишь привносят «программирование по понятиям».

Из известных мне у C++ остаются три-четыре области применения:

(1) десктопные приложения (на Qt);

(2) числодробилки (хорошо оптимизируется код, у C++ почти лучшие результаты в индустрии);

(3) там, где нужна сертификация и где есть прочие требования к безопасности;

(4) (под вопросом) где нужно выжать максимум от компьютера, но нужно быть настоящим Мастером С++, а где вы таких видели, где найдете? Это штучные экземпляры на весь земной шар. Скажем, я к таким не отношусь и даже не хочу им быть - у меня другие интересы.

Во всех остальных областях C++ теснят и очень сильно теснят. И это происходит уже, как минимум, лет 20-30 (для тех, кто все еще не заметил). Пусть это будет «миром компиляторов». Можете назвать как угодно. Суть от этого не меняется.

Пока же у меня выходит, что rust запросто может дать более производительный и более эффективный по скорости исполнения код, чем C++. Причем, писать на rust часто проще. Это видно, в том числе, на примере того, как поддерживается семантика перемещения в обоих языках, а это дверь в мир асинхронщины и конкурентных программ.

Только тут еще есть такой момент. Если у вас много аллокаций в программе и у вас много краткоживущих объектов и особенно, если много циклических связей в программе, то тут даже rust не даст форы другим современным языкам со сборкой мусора. Здесь уже будут править балом JavaScript, Java, .NET, Go, в каких-то областях и Erlang/Elixir. Зачем мучаться на C++ или rust, если можно не страдать и иметь почти такой же по эффективности исполнения результат, используя ту же Java?!

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

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

Мне ближе использование C++ лишь для разработки библиотек и возмлжно некоторых утилит.

Прикладные задачи на C++ можно конечно разрабатывать, но более трудоёмко чем в многих иных ЯП.

Поэтому считаю, что так C++ заточен для системного программирования, то он вовсе не устарел.

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

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

Так что, писать на C++ библиотеку для JVM - такой себе вариант. Если только от безысходности, когда никаких других способов уже нет.

Просто на заметку

Ранее годами Java использовал, но так как ныне на 100% разрабатываю разные библиотеки, то использую для этого C++.

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

Более двух лет на ЛОР не постил так как таких неадеватов как вы на ЛОР много.

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

И это правильно!

Адекватный человек не будет тратить время на реализацию crt 1C 8.3 на C++ без использования: std, STL, class, template …

Это полнейшее непонимание парадигмы C++ …

И отмазка, что у меня разработано API, которое удобное и эффективное, да ещё вдобавок кросспоатформенно не принимается.

Так адекватный программист поступать не будет.

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

Значит, пункт 5) системное программирование (crt 1C 8.3 - чем бы это ни было)

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

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

Когда-то и в C++ это добавят, но зачем че-то от кого-то, когда-то ждать?

Проще самому ныне разработать и использовать.

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

А это как-то перекликается с COM? Скажем, можно ли из VBA использовать?

Можно использовать из любого ЯП.

Месяца через три начну разработку архитектуры и API для использования баз знаний.

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

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

И еще. А C++/CLI рассматривали? Если у вас мало зависимостей, то так можно выйти на .NET

С Net имею опыт работы. Система хорошая, своё core можно и в Net использовать.

Только C++/CLI - это win-only. А так, если хотите популяризовать свое решение, то желательно выйти на java и .net. Правда, когда происходит мост между java и C++ неизбежно возникают тормоза.

Хотя, постойте, из того, что я пока понял (про базу знаний), вам более всего может быть интересен даже питон. Я правильно понимаю? Для него можно extension-module написать на сях. Только у третьего питона довольно своеобразная сборка мусора - на основе подсчета ссылок. Я такое диво еще нигде не видел, когда одновременно и полноценная сборка мусора (именно в третьем питоне, а не во втором), и тут же подсчет ссылок. Как они умудрились такое сделать?)

Нет, API иожно будет использовать в любом ЯП. API в частности позволяет динамически создавать объекты, переменные, … Поэтому при работе в Python не будет необходимости использовать даже переменные Python, а лишь одни управляющие операторы. Конечно возможна разработка кода в котором используются все возможности ЯП. Собственно в core добавлю ещё веточки подобные crt 1С 8.3. Это позволит например 1С-никам без труда использовать core … Для этого crt 1С 8.3 и разработал. Если захотят иметь больше функциональности, то пусть знакомятся с API core. Пока как-то твк.

Пока ничего публиковать не буду. Займусь разработкой баз знаний. Когда core разработаю начну разработку ЯП программирования в котором можно будет просто давать задания системе. Например: «Подсчитать сумму целых чисел от одного до ста.». Поэтому программистам не придётся пол жизни спорить и доказывать, что ООП хорош.

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

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

Например: «Подсчитать сумму целых чисел от одного до ста.».

это называется лисп. его примерно именно для таких целей и разрабатывали.

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

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

Так-то есть, что сказать по поводу планируемой разработки, но ИМХО лучше разработкой займусь.

Шкуру неубитого ООП делить бессмысленно.

Пожалуй разработка переводчика не плохо поможет для разработки core баз знаний …

А с прологом как соотносится? Вот, вы пишете «база знаний». Это термин из пролога. Вы, наверное, оттуда берете вдохновение?

Ну, пролог на лиспе реализовывали. Если по-простому, то это есть в книге Пола Грэма. Если с компилятором и по-серьезному, то будет как в настоящем прологе

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

Написал много букв и все удалил. Лучше разработкой заниматься. Больше пользы будет. Однозначно!

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

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

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

Ладно, тоже продолжу заниматься делами

Похоже ты «в теме». Успехов тебе в разаботке и личной жизни.

Если есть силы, то попробуй ребятам с форума помочь понять, что от разработки больше пользы будет, чем флудить годами об ООП. class C++ это вего лишь один из методов управления объектами.

ИМХО живём в эпоху синтаксически ориентированных ЯП. Их архитектура, зизждится на грамматиках, которые не пригодны для разработки ЯП с удобным синтаксисом, …

мне вообще пофиг, что там делает питон. я им не занимаюсь и в него не вникаю.