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

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

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

ответ: нет.
шаблоны используются только на этапе компиляции.
впрочем, если подождать лет так пять.... в последних дискуссиях по стандарту С++14 вроде как обсуждалось динамическое использование шаблонов

заюзай Google Breakpad. хорошая штука. её использует Мозилла и многие другие крупные компании. мы её на работе тоже пользуем на серверах.

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

Думаю, это может оказаться кому-то полезным:

Computer Science Center запускает онлайн-курсы.

15 сентября 2014 года, CSC запустит три новых онлайн-курса для начинающих программистов:

Алгоритмы и структуры данных.
Программирование на языке C++.
Введение в архитектуру ЭВМ. Элементы операционных систем.

Данные три онлайн-курса являются «джентльменским набором» начинающего программиста, преподаются на русском языке и бесплатны для всех желающих.

Computer Science Center – это совместная инициатива Академии современного программирования, Computer Science клуба при ПОМИ РАН и Школы анализа данных.

Основная цель Computer Science Center – дать возможность желающим получить востребованные современной наукой и промышленностью знания в дополнение к университетскому образованию.

>>> Подробности

(взято отсюда)

по моим наблюдениям, SQLite работает довольно шустро с базами размером до 300 Мб. базы большего размера начинают вызывать тормоза, вне зависимости от настроек (не знаю, чем это вызвано, память или другие ресурсы при этом особо не пожираются).
при загрузке больших объёмов, если при этом не нужно ничего читать из базы и не нужна синхронизация и транзакционность, можно включать настройку через PRAGMA: synchronous=off, count_changes=off и другие.
Вообще, про оптимизацию большой загрузки данных (bulk load) можешь почитать тут, например:
http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/

почитай про CURLOPT_WRITEFUNCTION - там можно задать callback для записи и писать куда хочешь.

я пока вижу, что у тебя ui удаляется до ua, в то время как ua подключен к layout внутри ui. это вряд ли имеет отношение к ошибкам компиляции, но это ошибка программы.

а ошибку компиляции, скорее всего, вызывает невиртуальный деструктор в твоём классе MainWindow.

почитай про dynamic_cast. он возвращает NULL при преобразовании, если тип не совпадает.

P.S. кстати, тему надо перенести в вопросы по С/C++, к Qt это не имеет отношения.

ты устанавливал на машине redist пакет библиотек от MSVS2010? таскать две dll-ки может быть недостаточно. у них могут быть другие связи.

на самом деле, если бы это был С++11 совместимый компилятор и там бы стояла такая конструкция:

QDataStream & QDataStream::readBytes ( char *&& s, uint & l ) поэтому

то есть rvalue reference вместо lvalue reference, то тогда бы компилятор сожрал это без всяких преобразований.
я не знаю, компилится ли Qt под стандарт С++11 и используются ли там rvalue reference параметры.

во-первых, надо писать, под какую систему собираешь.
во-вторых, в гугле с полпинка находится:
http://marc.info/?l=kde-commits&m=1388...0328771&w=2

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

переменные окружения.
CXX=бла-бла-бла.

это фича для защиты кернела от возможных атак:
https://wiki.ubuntu.com/SecurityTeam/Roadma...race_Protection
можно временно разрешить подключение:

или навсегда его разрешить, выставив ptrace_scope равным нулю в файле /etc/sysctl.d/10-ptrace.conf

я подозреваю, что надо сессию открывать с BEGIN IMMEDIATE, но как это делается в Qt подсказать не могу.

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

да, выше Юрий правильно заметил, что работа с классами есть самое обычное дело. экспортируется весь класс и проблем нет. более того, можно даже наследоваться от классов, объявленных в других библиотеках. я тут где-то про такой случай писала.
единственная возможная проблема - это не будет работать с разными компиляторами. то есть, если основная программа скомпилена одним компилятором, а библиотеки - другим. а у мелкософта иногда даже разные версии компиляторов не совместимы. так что тут надо понимать, как это потом будет эксплуатироваться. если предполагается, что другие программисты будут собирать какие-то внешние модули, то получится ограничение на выбор компилятора.
и ещё видимость классов у GCC и MSVC разная. но обычно это не представляет проблемы.

Наступила тут на интересные грабли в GCC.
Проверка работы с граничными значениями int64 выявила, что GCC на такую строку

int64_t i64 = -9223372036854775808LL;  // -9223372036854775808 == 0x8000000000000000

выдаёт ворнинг, что число слишком большое, и может быть сохранено только как uint64_t.
Хотя формально всё валидно.
Нашла объяснение тут: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55540
Это не баг, это фича. Просто GCC воспринимает число -X, как X, к которому применён унарный оператор минус. А в данном случае +9223372036854775808 действительно выходит за пределы int64_t и он не может с ним работать.
Вот такой простой трюк позволяет обойти эту странность:

int64_t i64 = (-9223372036854775807LL -1);

И компилятор доволен

есть там это. не помню где, но есть. посмотри всякие readme в самом архиве сорцов. может, там это. но по-моему, на сайте тоже было.
cборка GCC, да ещё и с кросскомпиляцией - занятие дюже геморройное. это делается в несколько отдельных шагов. сначала собирается простой компилятор без glibc, потом glibc, потом - основной компилятор, со всеми наворотами. если хочешь дохрена теории - можешь почитать про LFS (Linux From Scratch), например. там подробно написано, как его собирать. обычно такая сборка занимает много часов. то есть, это непростой процесс, но вся документация в сети есть.

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

обычно такое бывает только в венде, при сборке разными компиляторами. например, при попытках скрестить MinGW и MSVC.
для таких проблем существуют специальные утилиты, которые выкусывают это подчёркивание из библиотек. сейчас уже не помню, как называются, ибо давно уже не работаю с вендой.
ещё такая проблема возникает в MSVC, если битности библиотек не совпадают. подчёркивание - это 32-битный MSVC. 64-битные библиотеки не имеют подчёркивания в экспорте.

если же всё собирать одним компилятором и с одинаковой битностью, то проблем возникать не должно.
под никсами я с таким не сталкивалась, там все более-менее современные компиляторы совместимы по генерируемым именам функций.

возможно, С-библиотека импортирует какие-то функции. тогда они тоже должны вызываться с порядком передачи параметров типа "C". то есть, надо extern "C" ставить на всё, что она импортирует.


посмотрела внимательно код библиотеки.
там стоит

#ifdef __cplusplus
  extern "C" {
#endif

так вот, если ты это собираешь разными (C и C++) компияторами, то никакого ifdef там быть не должно. просто extern "C". иначе С++ компилятор это компилит по своим правилам и ищет не те функции.

сериализация не работает с указателями. хранить указатели в файле - это безумие. сериализация работает только с объектами. поэтому сериализовать/десериализовать нужно сами объекты, а массив указателей создавать параллельно этому процессу, добавляя указатели на десериализованные объекты по мере их создания.

можно тупо сделать так.

#define Lib::

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

просто переставляет байты в массиве справа налево и помещает их в некую переменную типа Type.

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

если нет понятного места, где нужно удаление объекта, используются автоматические указатели.