Re: [Development] Question about QCoreApplicationData::*_libpaths

2016-01-16 Thread Marc Mutz
On Saturday 16 January 2016 15:44:47 Иван Комиссаров wrote: > However, in multithreaded app this won't work! Imagine, Manager will try to > modify map while someone holds pointer to it. First, pointer should be > protected with mutex both in getter and the place when manager modifies the > map. Sec

Re: [Development] Avoiding segfaults with QML and video cards which do not support OpenGL 2.0

2016-01-16 Thread Lisandro Damián Nicanor Pérez Meyer
On Friday 15 January 2016 23:27:50 Kevin Kofler wrote: > Hi Lisandro, [snip] > you just need to install this script: > http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/plain/10-qt5-check-op > engl2.sh to: > /etc/X11/xinit/xinitrc.d/10-qt5-check-opengl2.sh > and depend on glx-utils, which pro

Re: [Development] Question about QCoreApplicationData::*_libpaths

2016-01-16 Thread Иван Комиссаров
The question is not good COW or bad. The question is - can/should Qt use (for some reasons) it's own containers, or not. Yes, stl containers are complex, still *theoretically*, Qt can have standard-compatible QVector. About COW. On current work, we try to make all classes thread safe. Consider cla

Re: [Development] Question about QCoreApplicationData::*_libpaths

2016-01-16 Thread Bubke Marco
On January 16, 2016 06:08:14 Kevin Kofler wrote: > Bubke Marco wrote: >> Actually this convince is hurting you if you need performance. I would >> prefer the convenience on top of lower level api. > [and at the end:] >> It really depends what you want to do. I would prefer it we had a CoW >> wrap

Re: [Development] Question about QCoreApplicationData::*_libpaths

2016-01-16 Thread Marc Mutz
On Saturday 16 January 2016 02:40:02 Bubke Marco wrote: > I would prefer it we had a CoW wrapper around std vector. > Best of both worlds. aka std::shared_ptr> -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Ex