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

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

Сообщение от 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 выход из функции потока + join. Этого достаточно.

видела (иногда позакрывать сокеты, освободить память и т.д. ещё может понадобиться)... но в классе Thread U++ - join() нет, а ShutdownThreads() как-то пока никак, но, думаю, что волшебные строки из кода от GoshaM
надо как-то покрутить...
спасибо за советы!

0

Сообщение от JeyCi но в классе Thread U++ - join() нет

Есть. Он называется Wait().

1

теперь поняла, почему в скобках

Waits for started thread to finish. ("join").

0

И в чем проблема создать к примеру отдельный поток в котором задачи пускать в пул и ждать когда пул завершит работу?

0

но в void MyAppWindow::btn2_Click() - он (Wait) у меня не получался... this->work.Wait(); ...
ок, буду думать

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

Сообщение от Avazart И в чем проблема создать к примеру отдельный поток в котором задачи пускать в пул

пока речь не о пуле, а об одном thread'e... чтобы по-быстрому отменять то, что пока без пула есть...

Добавлено через 1 минуту
код приложила... - доп. вопросы уже, наверно, излишни

0

Где код? Я по прежнему не вижу ссылку на гихаб с проектом ...

0

Сообщение от Avazart Где код?

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

0

0

Сообщение от Avazart Удачи!

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

Добавлено через 9 минут
один совет на заметку стоит, наверно, взять для U++ Thread

I won't recommend using Thread::Run routine because 1) Each call creates a new thread which is expensive system operation (especially in Windows). So if you call it frequently, you create unnecessary heavy pressure on OS kernel. 2) You can't detect the moment your routine is finished. This is very bad because you should wait for thread and delete it correctly if user wants to quit your app. This is also bad because you must know when some internal variable was changed by parallel routine. There are different approaches and I recommend designing your inter-threading interactions first. What will be changed? How is main thread is affected on this change? How this data will be safely delivered to calling thread? If you answer this questions, you may choose the best implementation.

хотя в принципе для MT уже оговорили, что thread_pool лучше, когда надо более одного доп. потока

Добавлено через 16 минут
По поводу Отмены (и там же примерно WorkQueue)

1.Terminating - wrong idea (becouse of allocated resources by threads) Telling thread to stop via some variable - is good idea 2. Comunicating betwen threads for example with ThreadSafeQueue when one thread do somting for other thread

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

Сообщение от JeyCi вот только ноги откуда ростут - неясно?...

возможно, что-то где-то мьютексами защитить надо?

0

Сообщение от JeyCi он (Wait) у меня не получался... this->work.Wait(); ...

Как это проявляется?

0

Сообщение от DrOffset Как это проявляется?

никак... следующая строка кода по смене status="Stopped" не выполняется в #289

Добавлено через 51 секунду
и переменные (если вставить в код) типа int nn=Thread::GetCount(); - до и после НЕ изменяются =1

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

0

JeyCi, а если вот это
из функции потока убрать совсем?

Добавлено через 2 минуты
И вот это тоже, временно:
Потом смотрите завершается ли поток. Код в обработчике оставьте прежним:

0

Сообщение от DrOffset из функции потока убрать совсем?

удивительно... увидела Stopped...
говорю же - ноги какие-то странные и растут странно... и при таком процесс (сохранённых файлов) в status'e не видно

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

Сообщение от DrOffset Потом смотрите завершается ли поток.

???? всё равно n=Thread::GetCount(); == nn=Thread::GetCount(); т.е. до==после (количество потоков)

0

Сообщение от JeyCi ????

Ну раз wait у вас отпустил ожидание, и вы stopped увидели, значит завершился.

Сообщение от JeyCi говорю же - ноги какие-то странные и растут странно...

Ничего странного. У вас был deadlock.
Когда вы находитесь в обработчике кнопки, то у вас уже есть лок на GUI. В потоке у вас тоже делается lock:
в него вы войдете только если обработчик кнопки завершился, но сделать этого он не может, потому что ожидает на Wait.

1

Сообщение от DrOffset Когда вы находитесь в обработчике кнопки, то у вас уже есть лок на GUI.

но ведь я вышла из зоны видимости {}, а struct GuiLock - отменяет блокировку сам?.. но в принципе не лазила в библиотеку...
вот тоже думаю, как-то по другому надо расставить блокировки

Сообщение от JeyCi возможно, что-то где-то мьютексами защитить надо?

или PostCallback использовать - но ещё с ним на вы...

0

JeyCi, в общем случае - это не очень хорошая идея дергать GUI из другого потока напрямую, даже под локом. Лучше, когда библиотека дает возможность отправить "запрос" на изменение GUI. Т.е. в вашем поточном методе вы могли бы создать "событие" изменения GUI, и отправить его основному потоку. А тот уже когда это возможно и безопасно выполнил бы его на своей стороне. Тогда лочить GUI не пришлось бы, и проблемы бы вашей не возникло.

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

Сообщение от JeyCi но ведь я вышла из зоны видимости

Вышли, да. Но GuiLock для своей эффективности должен работать на обеих сторонах. Я тоже не лазил в библиотеку, но это просто следует из того поведения, которое вы описывали и общей логики построения программы. Чтобы GuiLock работал, методы, которые являются обработчиками элементов GUI тоже должны быть защищены этим локом. Библиотека сама выставляет лок, чтобы это обеспечить. Поэтому, когда вы находитесь в обработчике кнопки, то лок уже выставлен самой библиотекой на стороне главного потока, и соответственно ваш второй поток не может зайти в лок на своей стороне. При этом главный поток у нас меняет переменную состояния, для выхода, и переходит в ожидание этого выхода, но т.к. второй поток висит на ожидании своего лока, то ничего не происходит. В итоге - deadlock.

1

Сообщение от DrOffset создать "событие" изменения GUI, и отправить его основному потоку. А тот уже когда это возможно и безопасно выполнил бы его на своей стороне

наверно, не вариант - когда надо видеть процесс, например, в status'e... (то, что вы предложили закомментировать)... а после выполнения всего потока - мне уже инфо (закомментированная нами) не нужна - только в процессе... имхо

0

Сообщение от JeyCi или PostCallback использовать

Это вот похоже именно то, о чем я говорю:

Сообщение от DrOffset Лучше, когда библиотека дает возможность отправить "запрос" на изменение GUI.

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

Сообщение от JeyCi наверно, не вариант - когда надо видеть процесс, например, в status'e..

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

Сообщение от JeyCi а после выполнения всего потока

Кто сказал, что после?

0

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

у меня пока нет очереди... я её потом буду пилить... пока просто цикл for без всяких мер предосторожности запущенный в WorkerThread, которая запускается с кнопки... пока чтобы работало хоть как, чтобы не терять текущую инфо...
обязательно подумаю над вашими идеями... спасибо!

Сообщение от DrOffset Кто сказал, что после?

здесь

Сообщение от JeyCi progress.WhenAction = [&]{if(icounter < 10) icounter++; status.Set(IntStr(icounter));} ;удивил -

такой синтаксис - это одно и тоже (ну по какому ЭУ - не важно):

button <<= THISBACK(buttonCb); // = progress.WhenAction = [&]{if(icounter < 10) icounter++; status.Set(IntStr(icounter));} ;

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

0

Сообщение от JeyCi у меня пока нет очереди...

Она уже есть внутри библиотеки.

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

Сообщение от JeyCi здесь

Это?

static void Call(Function<void ()> cb) Executes a callback in the main thread (the one responsible for GUI). It works by posting callback into timer queue (with zero delay), then waits its completion using Semaphore. Main GUI thread has to run timer queue management for callback to be executed (by running event-loop (TopWindow::Run) or ProcessEvents). Warning: Call temporarily unlocks GuiLock (if locked) so that the main thread can run on GUI, this is possible source of race-conditions (GuiLock is relocked after call completes). Be prepared that some other code can run on GUI between call to Call and cb being executed!

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

1