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

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

Сообщение от 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

скажите мне, как быстро перейти к радостной девочке в смайлах?.. очень долго scroll идёт...
вроде получилось - вывалились все файлы... только добавила i++ иииииии

Добавлено через 6 минут
P.S.

Сообщение от Avazart async/await pattern как бы не определяют асинхронность это лишь дизайн.

в Python - тоже - лишь указывает, что будет использоваться асинхронная функция...

0

Тогда при чем тут Qt?

0

не при чём - реализация сделана на U++ IDE
тему можно считать завершённой

0

P.S. добавлю для инфо:

Сообщение от GoshaM void Worker::Start ( StatusBar* pstatus, ProgressIndicator* pprogress )

Есть ли преимущества передачи по указателю над передачей по ссылке в C++? хоть перевод и не очень...
и цитату с форума:

Сообщение от Большой_Стен В С++ нет универсального способа, чтобы и лишнюю переменную не создавать, и утечки памяти не было (по образцу из java или C#) ?

Добавлено через 1 минуту
однако

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

0

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

Эта фраза полностью лишена смысла.
Двойной вызов delete или free - это UB, ни на какое поведение компилятора закладываться нельзя (тем более что специально компилятор ничего не обязан убирать), нужно исправлять ошибку в программе.

0

Сообщение от DrOffset нужно исправлять ошибку в программе.

так разве это ошибка там в примере?

разницы между foo (BAR bar) и foo (BAR & бар). (Вызывается автоматическая побитовая операция копирования. Освобождение в деструкторе вызывается дважды.)

это же вроде реалии жизни... а раньше

15 лет назад они этого не сделали. (под gcc / g++ используйте setenv MALLOC_CHECK_ 0 вернуться к старым привычкам.) В результате, в соответствии с DEC UNIX, в одной и той же памяти выделяются два разных объекта.Там много удовольствия от отладки...

(перевод там хоть и кривой, но по сути примерно это)
сейчас в такой ситуации, насколько поняла, и беспокоиться не надо - можно положиться на компилятор - сам уберёт задвоение delete'a -- при передаче параметра по указателю

Добавлено через 6 минут
p.s.
или вот нормальный текст (но без вышеуказанного нюанса)

0

Сообщение от JeyCi (перевод там хоть и кривой, но по сути примерно это) сейчас в такой ситуации, насколько поняла, и беспокоиться не надо - можно положиться на компилятор - сам уберёт задвоение delete'a -- при передаче параметра по указателю

Нет, не уберёт.
delete будет вызван ровно сколько раз, сколько раз ты его вызовешь. Ты путаешь оптимизацию - когда компилятор в compile-time убирает лишние копирования объекта, например при return-value-optimization, и динамическое создание-удаление объектов в runtime.

0

Сообщение от oleg-m1973 delete будет вызван ровно сколько раз, сколько раз ты его вызовешь.

так в том то и дело, что я ничего не создаю и не удаляю...
просто передаю указатель на ЭУ progressIndicator... он сам себе даже не создаёт в данном случае (по указателю) дубль параметра, но при возврате в вызывающую сторону - вроде delete тоже сам делает, потом в деструкторе delete сам делает (я ведь ему не писала new)...
хотела убедиться, что безопасно - пока всё в одном рабочем thread'е - но работа с указателями тоже вроде бывает unsafe...
и 2 ядра всё-таки - не пойдёт ли код автоматом с одного потока для ускорения на разные ядра... или даже primary GUI-thread и secondary Worker thread не разойдутся ли, как в море, корабли... хотя тут вроде GuiLock работает для синхронизации

Добавлено через 5 минут
Декомпозирую по-тихоньку

Добавлено через 2 часа 19 минут
C PostCallback - грустно...
с GuiLock - всё OK ! - стихами
по указателю передала массив в др класс, а оттуда отразила итерирование по нему в GUI... и т. д.

0

Сообщение от JeyCi он сам себе даже не создаёт в данном случае (по указателю) дубль параметра, но при возврате в вызывающую сторону - вроде delete тоже сам делает, потом в деструкторе delete сам делает (я ведь ему не писала new)...

Ничего не понятно. Кто что делает?

Добавлено через 16 секунд

Сообщение от JeyCi C PostCallback - грустно...

С этим тоже ничего не понятно.

0

Сообщение от DrOffset тоже ничего не понятно.

не отработал из др. класса

Сообщение от DrOffset он сам себе даже не создаёт в данном случае (по указателю) дубль параметра

параметр переданный по указателю... хоть ссылка и есть всего лишь альтернативное имя указателя на память - но всё-таки она и есть 2-е имя... не знаю как ещё объяснить... согласна с oleg-m1973, это уже не мои дела, а дела компилятора... просто обратила внимание, что раньше старый компилятор имел проблемы (на вызывающей функцию стороне) с удалением параметров, переданных по указателю... - параметр - один, а удалять приходится 2 раза - поэтому это вроде руками делать надо былО...

0

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

Не, никогда не имел

1

Сообщение от JeyCi раньше старый компилятор имел проблемы (на вызывающей функцию стороне) с удалением параметров, переданных по указателю... - параметр - один, а удалять приходится 2 раза - поэтому это вроде руками делать надо былО...

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

Если "раньше имел проблемы" - это про двойное удаление, то если "раньше" программа падала на этой ошибке, а "сейчас" не падает - это не значит, что компилятор "имел проблемы". Это значит, что UB теперь проявляется по-другому. Но ошибкой это быть не перестало. И даже если программа на этом не падает, оно все равно не верно и нуждается в исправлении.

0

...

0

Сообщение от DrOffset Не знаю о чем конкретно речь, но двойное удаление

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

обязательно посмотрю потом...
пока кнопку btn_cancel опять мучаю :- из др класса того же thread'a - казалось бы проще простого, когда нет подключения к сети, но остановка request'a при обрыве соединения -- опять задумывается... Abort не очень удачно получается...
поэтому пока сама немного в зависшем состоянии... потом отвечу

0

наконец, дошли до дизайна Архитектуры
Передача указателя функции класса A в класс B (себе на память)
===
ВЫВОД:
Разбросать по потокам (Data-Level parallelism и Instruction-Level Parallelism, да и просто UI и поток его обслуживающий, я бы даже сказала Controller в MVC)
и выделить классы для их обслуживания (вообще не очень универсально пользоваться instance'ом, который в себе переваривает progressIndicator или чего ещё хуже - button_click -- я так думаю -- если от instance'a надо, чтобы он download_data)... думаю, чем всё тащить в класс, лучше из класса брать нужное... а то ведь параметром и весь UI можно затащить в класс и все потоки - как-то очень жирно по памяти будет, вероятно... имхо...
вобщем, принципы SOLID никто не отменял -- вот и просветление по теме наступило
P.S. а UML - всё-таки в помощь...
P.P.S.
- пример ТЗ -

0

Сообщение от JeyCi Передача указателя функции класса A в класс B (себе на память)

Это старая тема. используйте Upp::Function (или std::function) и лямбда-выражения.

1

Сообщение от GoshaM и лямбда-выражения.

вот такая фраза немного смущает:

[&] -> lambda: capture all by reference (passes a reference) This can be quite dangerous, depending on how it is used.

в чём могут быть опасности?

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

0

Сообщение от JeyCi в чём могут быть опасности?

есть такой термин dangling references

1

Сообщение от zayats80888 есть такой термин dangling references

Warning: Be extra careful when you capture variables by reference, especially with a default reference capture. The captured variables must outlive the lambda.

P.S.
What are the risks associated with the use of lambda functions in C++11

Добавлено через 3 минуты
Memory leaks and dangling pointers
Difference between dangling pointer and memory leak

Добавлено через 26 секунд
Lambdas: From C++11 to C++20, Part 1

0

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

0