LINUX.ORG.RU

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

 , gsoap,


0

3

Реально эту штуку заставить генерировать код хотя бы на C++11 чтобы не void*, а std::unique_ptr и так далее было? Ну и хоть кто-то по-человечески с объявлением функций, дабы это всё не выглядело как обертка на С.

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от alysnix
                           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%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alysnix ★★★
()

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

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

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

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

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

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

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

Из известных мне у 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-е годы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()