Очередь на std::list

@Optimus11 · Регистрация: 10.01.2017

Студворк — интернет-сервис помощи студентам

Здравствуйте,

Подскажите, как вы думаете или использовали бы очеред задач на основе std::list ?

В моем случае std::list нужен потому что:

-Удаление самой задачи происходит из самой задачи.

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

Поэтому при вставке и удалении мне нужна гарантия валидности итератора. Вроде бы все удобно, но тут вспомнил про фрагментацию.

А так как задачи будут помещатся и удалятся в std::list непрерывно на протяжении всей работы приложения, то похоже в итоге теоретически это приведет к сущесвенному замедлению работы приложеня ?

@SmallEvil · 10.04.2024, 12:43

Сообщение от Optimus11

Еще одно без соновательное заявление, да еще и подкрепленое оскорблением.

Ещё один "опытный" программер которому нужно всё разжевыва, да ещё и с подробным доказательством.
А пойти самому изучить то что вам говорят, не судьба.
Можно же просто поныть ))

@Undisputed · 10.04.2024, 12:47

Сообщение от Optimus11

Значит к методу удаления задачи я добавлю запись о времени удаления в БД.

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

1) вы меняете класс задачи, хотя сама задача не поменялась, к ней ничего не добавилось и ничего не убавилось от нее.. зачем вы меняете класс задачи? все что изменилось это то что появилась необходимость сделать какие-то действия после выполнения задачи, так почему менять саму задачу, если она никак на самом деле не поменялась?

2) предположим, что вашу обработку задач потребуется поместить в DLL, которую в будущем должны использовать еще и другие программы, но они должны будут сохранять свои логи не в БД, а один в файл, а третий вообще в удаленном (remote) диске. Ваши действия?

@Optimus11 · 10.04.2024, 12:55 **[ТС]**

Сообщение от mashmed135

Твоя проблема в том, что ты не можешь чётко объяснить, что тебе нужно. Эксперты также не могут донести свою позицию(либо просто повторяют пару заученных фраз).

Я же выше написал:
Задача получить данные с сервера, на каждые данные своя задача, после получения данных задача должна быть удалена, до тех пор должна крутится проверка получены ли данные или нет.

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

С чего вы вдруг приписали мне в данном случае проблему ?

Сообщение от mashmed135

задача не знает про то, где хранятся контекст и прочие связанные данные.

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

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

Сообщение от Undisputed

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

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

@Undisputed · 10.04.2024, 12:55

Сообщение от Optimus11

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

Здесь нет ответов на мои вопросы

@Optimus11 · 10.04.2024, 13:02 **[ТС]**

Сообщение от Undisputed

Здесь нет ответов на мои вопросы

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

По второму пункту вопросов - тоже не очень понятно.
Я использую свою очередь именно из DLL - и что мне требуется то она и выполняет. Если нужно что то изменить я измению. У вас поведенеи кода меняется без изменения кода ?

@mashmed135 · 10.04.2024, 13:08

Сообщение от Optimus11

Я же выше написал: ... до тех пор должна крутится проверка получены ли данные или нет.

Да, в целом пойдёт. Значит я не увидел.

Сообщение от Optimus11

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

Ну это мало смысла имеет. Передать один int всегда проще.

@Undisputed · 10.04.2024, 13:14

Сообщение от Optimus11

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

Помоему все ясно. Но попробую перефразировать. У вас есть класс задачи (назовем его Task). У него могут быть какие-то поля (предположим, функция выполнения задачи, время запуска/завершения задачи) и есть определенные методы, например run(), который эту задачу запускает (это, надеюсь, понятно?). Идем дальше. Когда появилась необходимость логирования, вы полезли менять класс Task, тогда как понятие "задача" никак не изменилось. Нет новых атрибутов задачи, нет новых методов связанных с самой задачей (например, приостановить выполнение stop()). Так если само понятие (Task) задачи осталось неизменным, в чем смысл редактировать это понятие (класс Task)?

Сообщение от Optimus11

По второму пункту вопросов - тоже не очень понятно.
Я использую свою очередь именно из DLL - и что мне требуется то она и выполняет. Если нужно что то изменить я измению. У вас поведенеи кода меняется без изменения кода ?

Думаю вы спешите и не вникаете должным образом в то, что я вам пишу. Говорю, допустим ваша программа называется "А". Программа "А" использует "lib.dll", в которой работает ваша очередь и сохраняет после удаления задачи данные в БД. Теперь нужно в программе "Б" тоже использовать "lib.dll" для работы с очередью. Но программа "Б" не хочет сохранять данные в БД после удаления задачи, а хочет сохранять данные в файл. Что будете делать?

@eva2326 · 10.04.2024, 13:18

Сообщение от Undisputed

Ок, и это даже будет работать.

Нет, не будет.
Принципиально невозможно зафиксировать время само-удаления.

В момент X объект ещё не может указать время собственного удаления, потому что он ещё не удален.
А в момент, Y, когда объект уже удален, он уже вообще ничего не сможет сделать, потому что его уже не существует.

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

@Optimus11 · 10.04.2024, 13:22 **[ТС]**

Сообщение от Undisputed

Помоему все ясно. Но попробую перефразировать. У вас есть класс задачи (назовем его Task). У него могут быть какие-то поля (предположим, функция выполнения задачи, время запуска/завершения задачи) и есть определенные методы, например run(), который эту задачу запускает (это, надеюсь, понятно?). Идем дальше. Когда появилась необходимость логирования, вы полезли менять класс Task, тогда как понятие "задача" никак не изменилось. Нет новых атрибутов задачи, нет новых методов связанных с самой задачей (например, приостановить выполнение stop()). Так если само понятие (Task) задачи осталось неизменным, в чем смысл редактировать это понятие (класс Task)?

Сообщение от Undisputed

Думаю вы спешите и не вникаете должным образом в то, что я вам пишу. Говорю, допустим ваша программа называется "А". Программа "А" использует "lib.dll", в которой работает ваша очередь и сохраняет после удаления задачи данные в БД. Теперь нужно в программе "Б" тоже использовать "lib.dll" для работы с очередью. Но программа "Б" не хочет сохранять данные в БД после удаления задачи, а хочет сохранять данные в файл. Что будете делать?

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

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

Сообщение от eva2326

Нет, не будет.
Принципиально невозможно зафиксировать время само-удаления.

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

@Undisputed · 10.04.2024, 13:23

Сообщение от eva2326

Нет, не будет.
Принципиально невозможно зафиксировать время само-удаления.

Речь идет о вызове условного logger->log(...) после удаления объекта, странно что мне приходится разъяснять такие мелочи достаточно опытным программистам

@eva2326 · 10.04.2024, 13:27

Сообщение от Undisputed

Речь идет о вызове условного logger->log(...) после удаления объекта а не о фиксации наносекунд

Я ничего ни о каких наносекундах не писала.

Я писала о том, что объект сам не сможет выполнить:

Сообщение от Undisputed

logger->log(...) после удаления объекта

@Undisputed · 10.04.2024, 13:31

Сообщение от Optimus11

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

Ну вот, теперь вы немного приблизились к правильному решению

Только менять нужно не сам Task, а некоторый менеджер задач (контейнер задач). Аналогия такая: есть например тип int, и есть контейнер этого типа который реализует работу по списком этого типа (как например тот же std::list<int>). Вы ведь не требуете, что бы внутри int была реализация удаления этого int из std::list. Все действия связанные с добавлением/удалением и т.д реализует сам контейнер и управляется вне типа который используется в качестве типа элемента контейнера. Такой подход например позволяет использовать тип с разными контейнерами, интерфейсы которых отличаются. Вопросы остались ?

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

Сообщение от eva2326

Я писала о том, что объект сам не сможет выполнить:

Может

C++
1
2
3
4
5
6
7
8
9
10
11
12
struct task
{
    // ...
    void run()
    {
        m_fn();
        // задача завершена, пора логировать
        m_logger->log(...);
    }
    // ...
    std::function<...> m_fn;
};

Уточню, что так делать не нужно

) Но возможность такая есть

@Optimus11 · 10.04.2024, 13:32 **[ТС]**

Сообщение от Undisputed

Ну вот, теперь вы немного приблизились к правильному решению

Только менять нужно не сам Task, а некоторый менеджер задач (контейнер задач). Аналогия такая: есть например тип int, и есть контейнер этого типа который реализует работу по списком этого типа (как например тот же std::list<int>). Вы ведь не требуете, что бы внутри int была реализация удаления этого int из std::list. Все действия связанные с добавлением/удалением и т.д реализует сам контейнер и управляется вне типа который используется в качестве типа элемента контейнера. Такой подход например позволяет использовать тип с разными контейнерами, интерфейсы которых отличаются. Вопросы остались ?

У меня класс Task и условный менеджер задач - это одно и тоже.
А очередьь состоит из std::function<void()> - что позволяет поместить в нее задачу любого типа. Хоть на примем данных с сервера, хоть рендер кадра.

@eva2326 · 10.04.2024, 13:35

Сообщение от Undisputed

Может

Чушь.

Вы зафиксировали время:

Сообщение от eva2326

объекты отчитываются в том, что они по факту уже выполнили какие то возложенные на них задачи

А вовсе не время:

Сообщение от Undisputed

удаление

Вот здесь вы фиксируете время завершения задачи, а не время когда задача была удалена:

Сообщение от Undisputed

// задача завершена, пора логировать
m_logger->log(...);

@Undisputed · 10.04.2024, 13:40

Сообщение от eva2326

а не время когда задача была удалена

а говорили что не считаете наносенкунды...

Сообщение от eva2326

Чушь.

ок

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

Сообщение от Optimus11

У меня класс Task и условный менеджер задач - это одно и тоже.

не должно быть так... возвращаю вас к примеру с list<int>

@Optimus11 · 10.04.2024, 13:40 **[ТС]**

Сообщение от Undisputed

а говорили что не считаете наносенкунды...

ок

Если я правильно понял, Eva имеет ввиду, что есди задача вызывает не интефейс обьекта класса, а удаляет себя физически сама, то есть условно через переданный в задачу указатель на контейнер в котором находится задача и сам указатель на элемент контейнера в котором эта задача находится, то при прямом вызове .erase(iterator) - функция логирования не вызовется.

@eva2326 · 10.04.2024, 13:40

Сообщение от Undisputed

а говорили что не считаете наносенкунды

Я нигде ни о каких наносекундах не писала.

Я писала о том, что:

Сообщение от Undisputed

logger->log(...) после удаления объекта

Можно выполнить только после удаления объекта

Такое впечатление, что вы не различаете понятия: "объект удален" и "объект выполнил свою бизнес-логику"

@Optimus11 · 10.04.2024, 13:42 **[ТС]**

Сообщение от Undisputed

а говорили что не считаете наносенкунды...

ок

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

не должно быть так... возвращаю вас к примеру с list<int>

У меня класс задачи не щаблонный класс, которому можно "назначит" тип обьекта.
Меня std::list<std::function<void()>> или std::deque<std::function<void()>> как контенер для задачи вполне устраивает. ПО крайней мере на данный момент.

@Undisputed · 10.04.2024, 13:49

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

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

Сообщение от Optimus11

У меня класс задачи не щаблонный класс, которому можно "назначит" тип обьекта.

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

@eva2326 · 10.04.2024, 13:58

Сообщение от Undisputed

можно удалить объект а потом уже логировать

Тогда это уже не будет фиксацией времени само-удаления.

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

Сообщение от Undisputed

не считаю эту деталь принципиальной.. не в этом была суть.

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

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

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915

	Очередь на std::list 09.04.2024, 17:07. Показов 3723. Ответов 56 Метки нет (Все метки) Здравствуйте, Подскажите, как вы думаете или использовали бы очеред задач на основе std::list ? В моем случае std::list нужен потому что: -Удаление самой задачи происходит из самой задачи. -Выполненная задача взятая из первого элемента помещается в конец списка, до тех пор пока опять не дойдет до начала, и опять не выполнется или пока не будет удалена из самой задачи. Поэтому при вставке и удалении мне нужна гарантия валидности итератора. Вроде бы все удобно, но тут вспомнил про фрагментацию. А так как задачи будут помещатся и удалятся в std::list непрерывно на протяжении всей работы приложения, то похоже в итоге теоретически это приведет к сущесвенному замедлению работы приложеня ? 0