Немного толку от перехвата общего "в программе произошла ошибка". Ну перехватили и что будете делать? Данные уже наверняка искалечены, остается показать окно с извинениями и выйти (да и то неизвестно живы ли еще окна).  Имеет смысл перехватывать на каком-то участке, для этого есть try catch на любой платформе. Хотя перехват обращения по неверному адресу и возможен, это ошибка в программе которую надо исправлять, а не перехватывать

В С/C++ не существует способа проверить валидность указателя, надо полагаться на то что все операции с ним были корректны. В данном случае Вы перестарались и удаляете дважды    Одно из удалений надо убрать

Вариант 1
        PotokThread * Pt=new PotokThread((QObject*)this);
   connect(Pt , SIGNAL(finished()), Pt , SLOT(deleteLater()));

Не делайте Pt членом класса, если deleteLater его грохнет, Вы остаетесь с уже удаленным указателем

Вариант 2 (по-моему лучше)
       // connect(Pt , SIGNAL(finished()), Pt , SLOT(deleteLater()));  

Т.е. просто уберите/отключите эту строку. Остальное как у Вас, только в деструктор неплохо бы добавить

Potok::~Potok()
{
        if (Pt->IsRunning())
           Pt->exit();

   delete Pt;
}

Здравствуйте, Сергей
Не знаю что Вы имеете ввиду. Лично для меня (новичка в Qt) все эти moc и qmake пока больше геморрой чем выгода. Да, это сэкономит мне сотню строк, но для меня это не великая проблема, руками напишу, не переломлюсь   Но вот торопиться с выводами  по-моему не стоит. Поюзаем, посмотрим, а дальше - жизнь покажет 

Это первое с чем и я столкнулся  Если имеете Q_OBJECT - нужен "moc_.."  файл который надо получать через qmake (в общем расплата за "крутизну"  )

Здравствуйте
Просто интересно - шо это за синтаксис? Кто такой "b" и как/где он описан? Кто кого вызывает?

Edit: перепутал, я у себя вижу

 insert(interface->getTitle(), interface); // Правильно???

Наверное это просто ошибка в отображении на web Все равно не пойму - чей insert?

Спасибо, Юра, нашел (panter_dsd). Нужен класс - значит нужен. Понимаю - везде так и глупых претензий не имею 

Добрый день

Осваиваю понемногу ихний слот-сигнал механизм  Мне надо чтобы 2 QSplitter сайзились синхронно: пользователь двигает верхний - нижний вслед за ним, и наоборот. Сделал по букварю, нормально. Но получается что 2 QSplitter бесконечно посылают сигналы друг другу. Решил так:


Вопрос(ы): верно ли я мыслюсь или есть что-то лучше/проще?  Можно ли сделать то же, но не создавая новый класс только для этого?

Спасибо

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

delete(ptr);
ptr = 0;

Чтобы полностью исключить его дальнейшее использование. Любые действия с уже удаленным указателем ведут к очень тяжелым последствиям (просто вылет = самое лучшее из них).  Ваш текст будет работать как Вы описали если, например, если вы вызвали delete второй раз для того же указателя. Использование exception в данном случае ничего не даст а только запутает: ptr может быть "корректным адресом" но данные по этому адресу уже разрушены, хуже того - этот адрес может уже используется для совершенно других данных.

Чтобы найти ошибку надо смотреть все что делается с указателем начиная с его создания (обычно new). Это может быть очень непросто но других методов нет.

Но этого никак не видно без лазания по h файлам  И чем держать это в памяти, для меня лучше написать virtual и быть уверенным что любое delete (хоть из parent хоть как) такой деструктор позовет.

Нет такой задачи "триангуляция полигона" - это я для наглядности так сказал  Если простые полигоны (3 или 4 вертекса) то надо говорить о триангуляции поверхности (часто называют mesh), разбивать ребра и делать новые полигоны из них. Если N-sided полигон - то это триангуляция контура (часто с font'ами). Этим тоже приходилось заниматься. Конечно, не с нуля. Обычно сначала погуглил и полистал десяток pdf по теме. Исходники попадаются и бывают даже хорошие. Но "взять что-то готовое и прикрутить" мне лично ни разу не удалось. Это возможно но потом будет себе дороже

1) Почему бы просто не написать

LS theL(this);

Т.е. просто локальная переменная вместо указателя. Деструктор вызовется автоматически при выходе из функции.

2) Если деструктор все-таки нужен - его объявление  должно быть virtual.

Edit: пардон, не увидел страниц 2 и 3  Ответил что уже отвечено

Ну, в знании стандартной библиотеки мне в Вами не тягаться  Понимаю, что Вы бы сделали за час (если не меньше) то над чем я сидел несколько дней. Но зато я свой алгоритм знаю досконально, могу поручиться за скорость и не завишу от всяких has_iterator_debugging, _SECURE_SCL  и т.п. На мой взгляд "изобретать велосипед" значит "думать своей головой" и ничего плохого в этом нет 

Сделал, рассказываю  

1) Данные: из стандартной библиотеки используем только функцию qsort. Работаем только списками.

struct Polygon {
  Polygon * mNext;
 .....
};

Банальное добавление в список:

p->mNext = listHead;
listHead = p;

2) Алгоритм: на каждом шаге имеется селектор - N списков, каждый из которых сортирован по убыванию. Выбор кандидата осуществляется прямым перебором (на максимум) всех "голов" N списков. После выбора голова одного из списков продвигается, если NULL - пустой список удаляется из селектора. Разбитые полигоны линкуются в выходной список outList. Если выбранный кандитат имеет меньшую площадь чем максимальный в outList, то тогда сортируем outList,  добавляем его в селектор, обнуляем outList и повторяем выбор кандидата.

3) Детали:

а) сортировка списка

- выделяем память под массив указателей
- проходим по списку и заполняем массив указателей
- сортируем массив указателей (qsort)
- проходим по массиву и заполняем mNext
- удаляем массив указателей

б) Селектор: здесь можно использовать все что угодно, на мой вкус тоже список

struct Selector {
 Selector * mPrev;
 Selector * mNext;
 Polygon * mHead;
};

4) Ну а не получится ли что N (число списков для выбора) будет расти и расти? Нет, практически N очень мало (я не смог достичь даже 10  ) Если площади всех полигонов одинаковы - то вообще 1 список который затем замещается новым. Если есть большие полигоны - то они быстро породят новые списки, но эти же списки первыми попадут под деление и будут быстро исчерпаны.

Ну, лучше уж сказать "STL гарантирует"  Проверять не проверял но полагаю что по скорости он никак не лучше. С  log2 N все в порядке, но ведь он позовет malloc при каждом добавлении в дерево и free при каждом удалении. А по памяти памяти просто хуже потому что сожрет байт 20 на каждый нод. Конечно, для игровых моделей (до 50K полигонов) все будет работать прекрасно. Но не там где память используется "до упора". Тут даже new надо использовать аккуратно, например

polygon * p = new Polygon();  // нехорошо если полигонов действительно МНОГО
polygon * p = new Polygon[POLY_CHUNK_SIZE];  // так лучше хотя потом прийдется написать немного больше

Хммм.... в этом что-то есть. У меня появилась идейка, сделаю - расскажу