Вам необходимо отправить файл на локальный сервер, чтобы браузер не мог напрямую получить доступ к файловой системе. Тот же вопрос был задан здесь и там
Где находится ваш Предпосылка «Программа C ++, которая использует несколько библиотек DLL и QT, должна быть оснащена заменой malloc» взята из?
В Windows, если все библиотеки DLL используют общий MSVCRT, то нет необходимости заменять malloc. По умолчанию Qt строится на основе общей библиотеки DLL MSVCRT.
Проблемы могут возникнуть, если они:
1) смешивают библиотеки DLL, которые используют статическое связывание, и используют общий VCRT
2) И также свободная память, которая не была выделена там, откуда она была получена (т. е. свободная память в статически связанной DLL, которая была выделена совместно используемым VCRT, или наоборот).
недмаллок? также NB, что smplayer использует специальный патч для переопределения malloc, который может быть направлением, в котором вы движетесь.
Q: A C++ program that is split accross several dlls should:
A) replace malloc?
B) ensure that allocation and de-allocation happens in the same dll module?
A: The correct answer is B. A c++ application design that incorporates multiple DLLs SHOULD ensure that a mechanism exists to ensure that things that are allocated on the heap in one dll, are free'd by the same dll module.
Why would you split a c++ program into several dlls anyway? By c++ program I mean that the objects and types you are dealing with are c++ templates, STL objects, classes etc. You CAN'T pass c++ objects accross dll boundries without either lot of very careful design and lots of compiler specific magic, or suffering from massive duplication of object code in the various dlls, and as a result an application that is extremely version sensitive. Any small change to a class definition will force a rebuild of all exe's and dll's, removing at least one of the major benefits of a dll approach to app development.
Either stick to a straight C interface between app and dll's, suffer hell, or just compile the entire c++ app as one exe.