Mercury13

Первое и главное. Удивительно, что у вас программа заработала, ведь text.sentences не инициализировано. У меня вылет.

Ну и извечная ошибка начинающего «плюсовика»: память выделяется, непонятно, кто чем владеет, и, разумеется, память «течёт». Для чего, извините, в Си++ сделали инкапсуляцию, конструкторы и деструкторы?

Уничтоженный unique_ptr уничтожит ваш объект.

«Уничтожит» — это значит, вызовет деструктор и сделает память доступной менеджеру памяти. Теперь другие указатели, которые смотрят на этот объект, будут «висячими», и при их разыменовании программа может сделать ЧТО УГОДНО.

А теперь посмотрим, что именно ей угодно. Ваша функция foo() невиртуальная и не имеет дела с полями, ей нужен только this (указатель на объект), который даже не разыменовывается. Она в принципе не может вылететь, даже если десять раз занулить этот объект!

То, что вы хотите сделать — это семантика std::shared_ptr/weak_ptr.

std::shared_ptr<ttt> sh1 = std::make_shared<ttt>();
std::weak_ptr<ttt> we = sh1;
{
  std::shared_ptr<ttt> sh2 = sh1;
  sh1 = nullptr;
}
std::cout << we.expired();  // должно быть true

UPD. Вот для таких, как ты, и ввели в C++14 функцию std::make_unique, по аналогии с std::make_shared. Просто чтобы было меньше таких ошибок.

// считать строчку
std::string s;
std::getline(std::cin, s);
// …и разбираем её потихоньку через поток-строку
std::istringstream is(s);
int i;
std::vector<int> v;
while (is >> i)
  v.push_back(i);

Examp ex = new Examp ();
Неверный код, надо Examp* ex = new Examp;

В случае статического определения (Examp ex2;) — в той памяти, где обычно располагаются объекты. То есть:
• Если это поле объекта — то в теле объекта, которое может быть где угодно (куча, сегмент данных, стек).
• Если static/глобальный — то в сегменте данных.
• Если локальный — в стеке. Конкретно тут локальная переменная, и она будет в стеке.

В случае динамического определения (Examp* ex = new Examp;) — в «куче».
В этом примере, кроме операции new, которая заводит объект в куче, видим ещё и указатель, который располагается «там, где обычно» — в теле объекта, сегменте данных или стеке.

Надо long long n;
Дело в банальном переполнении, но profesor08 дал явно неверный ответ.

1. RAW есть несколько штук: RAW CHDK, CRW Canon, NEF Nikon, платформонезависимый, но мало кем используемый DNG…
2. Если у вас графической редактор общего назначения, крайне не советую. Для «проявки» RAW нужен особый инструментарий, которого в редакторе общего назначения нет. Плюс куча очень умных вещей, вроде дебайеризатора и шумодава. Оставьте это лайтрумам!
XnView, допустим, смотрит, но получается дрянь — в CHDK RAW все эти дебайеризации и кривые яркости сделаны как попало, и шумодава никакого. Хотя формат, признаться, редкий, Adobe его берёт только через промежуточный платформонезависимый DNG.
В Nikon NEF, по-видимому, смотрит превьюху: нет никакой разницы с Medium JPEG — любая программа проявки хоть где-то да проявит свой характер. Впрочем, одна есть: адовы искажения, присущие пережатому JPEG. К тому же снял в ч/б — он и вывел ч/б, в отличие от DxO, которому надо ещё указать, что формат с матрицы надо ещё в ч/б конвертнуть.
(Других фотоаппаратов у меня не было.)
Но XnView — просмотрщик, ему позволительно, он должен поддерживать как можно больше форматов и показывать их, пускай как попало.
Фотошоп открывает, но там этот инструментарий в каком-то виде есть, и под капотом нечто очень умное, на голову превосходящее внутрикамерную проявку мыльниц Canon (зеркалку Nikon не проверял). Но и они собрали все свои наработки по RAW и сделали отдельную программу специально для проявки цифрофото — Lightroom.
3. Обратно в RAW в принципе не стоит. Это файл с матрицы фотоаппарата, и точка. Вы что, хотите снимки подделывать?

UPD. Ясно, вы решили именно проявлять несколько кадров в один HDR…
Тогда задача библиотеки — дебайеризовать, возможно, подавить шум, И ВСЁ. Вам нужны картинки в ЛИНЕЙНОМ цветовом пространстве с 16-ю битами на канал. Обычная проявка в JPEG (BMP, TIFF) НЕ КАТИТ, у них по умолчанию ГАММА-СКОРРЕКТИРОВАННОЕ пространство и единица около нуля не равна единице около 255. Скажем так: на экране, чтобы выделялось на чёрном фоне, надо осветлять почти на 60 единиц, на белом — затемнять на 16.

Остальную магию вы уж как-то сами проведите. 1) Подправьте искажения объектива (как геометрические, так и цветовые). 2) Склейте три кадра в один с дробным цветовым пространством. 3) Придумайте, как всё это чудо свести в узкий диапазон экрана. 4) Наладить все эти гамма-коррекции и прочие кривые. 4) И только тогда преобразовать в целое [0…255].

У меня всё сработало. Может, зависит от библиотеки Си? Какой компилятор?

UPD. Сработало на MinGW.

Заводим структуру-сумматор. Изначально она 0/1. Что-то типа

typedef struct {
  int num, den;
} Fraction;

…

Fraction sum = { 0, 1 };

Дальше пишу псевдокодом, НОД и НОК разберись, как реализовать самому.

для каждой очередной дроби
  ввести(дробь)
  новыйЗнам = НОК(сумматор.знам, дробь.знам)
  множСумм = новыйЗнам / сумматор.знам
  множДробь = новыйЗнам / дробь.знам
  новыйЧисл = сумматор.числ × множСумм + дробь.числ × множДробь
  сокрНод = НОД(новыйЧисл, новыйЗнам)
  сумматор.числ = новыйЧисл/сокрНод
  сумматор.знам = новыйЗнам/сокрНод

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

И ещё. Одна из известных ошибок в написании НОК — произведение аргументов не влезает в свой тип, а НОК влезает. Поймёшь, как в такой ситуёвине избавиться от переполнения?