Архитектура: парсинг и выгрузка текстовиков

начало было положено в ветке - Считать текстовые файлы из папки - там и возник вопрос об Архитектуре...

Сообщение от JeyCi так и не собрала эти все объекты этого класса в group class...

вроде уже собрала...
осталось отображение создать (типа I_tbl_Show) и пронаследовать ? в разные классы пункта назначения (или на консоль, или в файл, или в БД, или допустим ещё в форму)... N.B. классы (пункты-назначения) делать не надо - эти View уже реализованы разработчиками того ПО, на котором сейчас идёт работа...
а) пока что можно просто прописать функции-члены класса; и по месту использовать, что надо при разработке - в файл или на консоль;
б) в перспективе для Release - реализовать и откомпилировать и выгрузку и в файл, и выгрузку в БД, и отражение в DataGrid...
===
!! Т.Е. если в Release захочется и выгрузку в текст, и в БД, и допустим ещё в форму (например с разных кнопок сделать) - тут уж лучше и писать, как положено, наследование??... -- к слову из прошлой ветки о:

Сообщение от JeyCi полагаю тут Наследования никакого не пригодится?

... или как раз тут (при выборе направления выгрузки) его (наследование) делать??
===
Обоснование выбора уровня Абстракции (I_tbl_Show со всеми виртуальными функциями):
чтобы не дублировать код-сбора-для-выгрузки -- сделать class Table - и класс-интерфейс I_tbl_Show, в котором обозначить virtual-функции выгрузки... эти функции определить в др. классах - типа Interface (IwriteCSV, IwriteDB, IwriteDataGrid)...
p.s.
классы консоль, файл, бд, DataGrid - не создаём, т.к. эти пункты назначения уже присутствуют...
p.p.s.
вывести конечные интерфейсы с определёнными методами записи на кнопки...
===
ИЛИ то, что подчёркнуто чуть выше, стоит реализовать в одном классе Table, и здесь же задать все virtual функции ??
===
на скрине: синие - классы, зелёные - интерфейсы (в с++ по сути тоже классы)
птицами отмечены уже кое-как реализованные классы (2 птицы)
курсивные стрелки - отсутствие наследования


Добавлено через 7 минут
вобщем вопрос:
class Table и класс I_Tbl_Show - объединить или нет?

Добавлено через 10 минут
p.p.s.
чтобы избежать проблем Ромба и такого:
Неоднозначность при множественном наследовании

Сообщение от DrOffset Тут нужно виртуальное наследование.

0

Сообщение от DrOffset вам всегда в С и С++ нужно помнить о том, где и сколько живут ваши объекты.

вот прямо в точку
уже загружается и btn_cancel работает
Благодарю!

0

Сообщение от DrOffset висячие ссылки в лямбдах - это частный случай - не понятно, с чего бы это именно к нему такое повышенное внимание. С простыми callback`ами даже в базовом C-шном API может быть все абсолютно тоже самое.

и всё-таки, я, честно говоря, всё думаю про код #222 от GoshaM и эту строку
и такой пример отсюда - page7

example of a callback which would contain a dangling reference, if references to local variables were stored instead of copies: C++ 1 2 3 4 5 6 7 void init gui() { ... label l = new label(”Hello”); button b = new button(”Change label”); b -> set on push callback(hi() -> void {l -> set text(”World”);}); ... } The pointer l is saved by copy inside the new closure, allowing the label’s text to be changed by this callback even after the function init gui() returns.

или всё-таки они разные - случай #222 и пример из статьи??
всё-таки, наверно, разница здесь у #222
и время жизни продолжается в Work? (несмотря на то, что Start уже окончен?)... значит UB в #222 не будет?..

0

Сообщение от JeyCi m_pstatus = pstatus; m_pprogress = pprogress;

Это не продлевает время жизни. Время жизни однозначно контролируется объектом MainWindow w.

Если время работы потока будет меньше, чем время жизни w, то UB в этом коде не будет.

Добавлено через 4 минуты

Сообщение от JeyCi if references to local variables were stored instead of copies

Это само по себе не всегда представляет опасность. Смотрите на scope`ы ваших объектов. Если время жизни объекта, который использует ссылки на локальные объекты меньше, чем время жизни этих объектов, то никаких висячих ссылок не будет.

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

1

Сообщение от DrOffset Смотрите на scope`ы ваших объектов

по объектам поняла...
а по scope'ам - это ведь могут быть и просто скобки {...int *ptr=null;... /*что-то с ним происходит ptr=smth */...} -- и за пределами скобок уже UB?.. или только в масштабе жизни объектов?

Добавлено через 3 минуты

Сообщение от JeyCi и за пределами скобок уже UB?..

или только после выхода из функции - UB?.. (если снова не сделать ptr=null до выхода)

0

Сообщение от JeyCi это ведт могут быть и просто скобки {...int *ptr=null;... /*что-то с ним происходит*/...} -- и за пределами скобок уже UB?.. или только в масштабе жизни объектов?

Ну, примерно так:

1

спасибо
со scope'ом тоже запомню

0

всё, поняла, почему callback'и - плохая идея, по совету от DrOffset - потому что управление View из Model - в принципе идея не-ахти... - с точки зрения SOLID... вариант - правда, на с# и тоже не-ахти - при длительных операциях, видимо, подвисать будет... и никакая Dependency Inversion тут не поможет...
вобщем справились подручными средствами и много нового почерпнуть можно с ветки и задача выполнена всем спасибо за весь ликбез
P.S.
в C#v7 - интересно async Main появился, чтобы async/await'ом обеспечивать выполнение кода с кнопки в др. потоке... иначе все async методы ходили сами по себе отдельно от GUI и на UI поток не возвращались... там (в более ранних версиях) тоже особо неподекомпозировать в этом плане было судя по всему... хотя в Console'и можно и с С#5 асинхронно что-то выполнять было... но зачем мне та консоль, если вводные данные и кнопку отмены хочется вводить.....
ВЫВОД:
С++ понравился! как компилируемый язык... это почитать... алгоритмы помнить...
SOLID не забывать

0

и кстати - главная задача потоков - чтобы не зависал app - отсюда и дизайн потоков (e.g. c# winform).... а уже возможное ускорение фоновых длительных задач - это бонусом - в зависимости от реализованного разработчиком архитектурного решения...
===
смысл ООП становится понятным, как только определяешься с целью :
1) брать из библиотеки нужное
2) на основе (1) создавать свои прослойки/обёртки выделяя/закрывая только нужный функционал - всё согласно SOLID
3) использовать свои созданные Классы и Интерфейсы для обслуживания MainGUI потока
... исключая возможности для хакеров в (2) ...
в случае крайней необходимости - писать свои библиотеки - хотя вроде всё уже давно написано - просто всё не надо - надо отобрать лучшее и удобное... - выразить в более высокоуровневые контейнеры и алгоритмы для удобства по задаче и воспользоваться этим stuff'ом для реализации задачи... имхо [поняла зачем мне ООП]

Добавлено через 11 минут

Сообщение от JeyCi управление View из Model

поправочка - "выполнение model задач на стороне view" - не comme il faut

0

и в завершение: Внутренняя и внешняя линковка в C++ - чтобы со стороны линкера понять, что делает компилятор, с тем, что мы написали в коде, и что делать линкеру с этим (встречаются ведь ошибки линкера, которые не всегда знаешь, как читать, по началу)...

0

Сообщение от JeyCi и кстати - главная задача потоков - чтобы не зависал app - отсюда и дизайн потоков (e.g. c# winform).... а уже возможное ускорение фоновых длительных задач - это бонусом - в зависимости от реализованного разработчиком архитектурного решения...

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

1

на rsdn хорошее введение в потоки - правда на c# - (он, вероятно, больше распиарен Microsoft'ом, как его детище) - но концептуальные понятия можно, полагаю, и на нём читать... вообще при знакомстве с фундаментом новой темы язык обычно вторичен, первична логика...
Работа с потоками в C# ч1
Работа с потоками в C# ч2

Сообщение от oleg-m1973 Главная задача, суть, потоков это прервать выполнение алгоритма в произвольной точке и потом возобновить это выполнение с того же места

Reentrancy (computing)
What is a reentrant function in C/C++?
Reentrancy
===
Resumable Functions (по async)
и здесь
-- отсюда
===
ещё не совсем разобралась в разнице между Reentrant и Resumable ??
===
Добавлено через 11 минут
а это всё дело - switching context - всё-таки на ассемблере компилировать лучше (если так правильно сказать), мне так кажется... поэтому и компилятор MSVC (с его ml.exe составляющей) реже имеет проблемы с компиляцией многопоточных проектов... имхо... он и зачточен на этот switching context...
может, и в коде #222 от GoshaM всё дело в этом ... или в самой библиотеке U++ (что более вероятно) в этом дело... когда не хочет распознавать IsWorker()...

Добавлено через 16 минут

0

Сообщение от JeyCi на rsdn хорошее введение в потоки - правда на c# - (он, вероятно, больше распиарен Microsoft'ом, как его детище) - но концептуальные понятия можно, полагаю, и на нём читать... вообще при знакомстве с фундаментом новой темы язык обычно вторичен, первична логика...

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

1

там привлёк моё внимание этот кусок (ч.1)

т.е. во-первых - не для моего случая (home pk with 1 socket) эти асинхронные методы
а во-вторых лучше на делегаты посмотреть (там по C#)...
==
насколько поняла, делегат (как указатель на функцию) выгодно использовать в системе взаимодействия View-Model... но вроде по логике смахивает на обычный коллбэк, а по смыслу и лямбдой может быть заменён для обработки событий ЭУ
(правда, возможность обработать одним махом и статус и прогресс и строки DataGrid - честно говоря привлекает)...
особенно если по скорости, действително, можно добиться улучшений?.. имхо?..
What is a C++ delegate
Делегаты и потоки
p.s.
или для любого (не только с UI) IPC (inter0process communication) тоже делегаты полезны?

0

JeyCi, callback - это частный случай делегата.

1

ВЫВОД:
рассортировала у себя по мозгам Python, C#, C++

0

Сообщение от oleg-m1973 седьмую-воду-на-киселе.

да, природа асинхронности вообще разная у C++ И С# ...
если применять C# - то стоит иметь ввиду -
Async Performance: Understanding the Costs of Async and Await
... но если писать свой класс асинхронности или template какой - то некоторые моменты на заметку стоит взять - как минимум, sync operations are cheap comparing with async, и как всегда при длительных операциях async дают выигрыш, если ! правильно их приготовить... хоть GNU и не оптимизирует так сильно, как JIT, но свои optimization costs по сбору мусора тоже стоит делать с умом... и др. нюансы... проблемы аллокатора, думаю, можно исключить из причин для беспокойства при использовании C++ - поскольку всё-таки природа async в C++ симметричная (switch-to-fibers), в отличие от C# (несеметричная async - distinct suspend & resume operations)... хотя в C++ свои нюансы с распределением памяти... имхо... вобщем небо и земля

0

Сообщение от JeyCi async в C++ симметричная (switch-to-fibers),

более точно - coroutines async-await boost'овские
писала на скорую руку

0

и напоследок,
An_Introduction_to_GCC

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

0

Using Exceptions | C++ - using RAII for cleanup - в частности, How to stop background work? (p.81)

Добавлено через 3 минуты
там, где попадалаа в deadlock, и std::lock_guard не сразу нашла...

0

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

Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2015. - стр. 38-40, наконец, обозначила целевые направления тех или иных паттернов а то как-то разбросано всё по сети... прямо нормальный DI получился по этим паттернам (aka выделение Общей Политики там, где она есть)

Добавлено через 5 минут
NB U++ не очень советуют использование pointers для управления кучей и run-time переопределение, на которых многие паттерны и основаны... но, наверно, потому что все эти паттерны - обычная история для MVC (Web-разработки)... для desctop'a можно проще... правильно предупреждают, не надо наворачивать там, где, действительно, ещё не надо...

0