Здравствуйте, TailWind, Вы писали:

A>>Тогда через пустой список и потом slice – std::list Сохранить позицию
TW>Да я видел ваше решение — интересное

TW>У меня, к сожалению, не получится применить
TW>Так как функции, которые добавляют новые элементы анализируют значения существующих

А что на счет exception safety?
Это не логично — вносить изменения в объектную модель без возможности откатить неудачную транзакцию, если провалился один из этапов.

A>А что на счет exception safety?
A>Это не логично — вносить изменения в объектную модель без возможности откатить неудачную транзакцию, если провалился один из этапов.
Такого не должно быть

Если выполнились все условия, код добавляет элементы в лист и возвращает true
Если не выполнились, ничего не делает, и возвращает false

Здравствуйте, TailWind, Вы писали:

A>>А что на счет exception safety?
A>>Это не логично — вносить изменения в объектную модель без возможности откатить неудачную транзакцию, если провалился один из этапов.
TW>Такого не должно быть

TW>Если выполнились все условия, код добавляет элементы в лист и возвращает true
TW>Если не выполнились, ничего не делает, и возвращает false

Каковы гарантии безопасности по исключениям?
Каким образом возвращать список в изначальное состояние при досрочном завершении его обработки (из-за выскакивания исключения в каком-либо месте)?

Пример №1.
Есть библиотечная функция/процедура добавляющая какие-то элементы в список. Если она споткнется на каком-то этапе, то ее выполнение завершится досрочно — из нее вылетит исключение. В список она при этом успеет добавить лишь некоторые из элементов, но далеко не все, какие должна была бы. Каков сценарий развития событий дальше? Программа аварийно завершается прекращая какую-либо работу?

Пример №2.
Библиотечная функция отработала благополучно, но споткнулся тот код, отвечающий за завершающие действия (зная в какое место списка эта функция добавляла элементы). Список опять получился не в том состоянии, в каком должен был бы отработай все штатно. Тогда вся программа целиком подлежит аварийной остановке?

A>Каковы гарантии безопасности по исключениям?
A>Тогда вся программа целиком подлежит аварийной остановке?

Вы интересную тему поднимаете
Но я, не настолько хороший программист чтобы её поддержать

Скорее всего сюжет будет следующий: функция была вызвана по нажатию кнопки или во время отрисовки окна. Там я забыл поставить try-catch. Исключение пойдёт в модуль с winapi, где будет поймано, выведено на экран и программа благополучно исчезнет с экрана

Здравствуйте, TailWind, Вы писали:

A>>Каковы гарантии безопасности по исключениям?
A>>Тогда вся программа целиком подлежит аварийной остановке?

TW>Вы интересную тему поднимаете
TW>Но я, не настолько хороший программист чтобы её поддержать

TW>Скорее всего сюжет будет следующий: функция была вызвана по нажатию кнопки или во время отрисовки окна. Там я забыл поставить try-catch. Исключение пойдёт в модуль с winapi, где будет поймано, выведено на экран и программа благополучно исчезнет с экрана

Это так называемый «fail fast» — терпимо и актуально не для всех приложений.
Используется в тех случаях, когда проще быстро перезапустить софтину после «падения». Иногда дешевле/проще именно так, чем реализовывать корректную работу с исключениями в плане транзакционности изменений объектной модели внутри софтины (во избежание некорректных, частичных состояний).

Здравствуйте, TailWind, Вы писали:

TW>Есть list<ULONG>

TW>В нём от нуля до любого числа элементов
TW>Нужно запомнить текущую позицию
TW>Потом вставить рандомное число элементов
TW>И в конце получить итератор на первый рандомный вставленный элемент

TW>В процедуру, которая вставляет рандомное число элементов у нас нет доступа
TW>Как?

Извиняюсь за поздний ответ!

Для списка целых чисел использовать std::list — накладно по памяти.
Нужна какая-то страничная структура. Возможно, подойдёт одностраничная — std::vector!
Для коротких списков операции вставки-удаления из середины — для вектора не так уж дороги. А для длинных — мы будем платить цену за хранение, и ещё неизвестно, что выйдет дешевле.