I know that Qt has signals, using them in the library, you can make the implementation of any application tasks. Does VS have any analogues? Or maybe C++ in general?
Boost.Signals2 is a very good portable library that implements functionality similar to Qt signals and slots.
Here is the link to the library:
http://www.boost.org/doc/libs/1_57_0/doc/html/signals2.html
Related
Is is necessary to use the Qt toolchain (pro files, qmake, etc...) in order to link against a library that was implemented and built with Qt, but itself exposes only a C style API? None of the Qt specific classes are used in the library.
The question applies to both static and dynamic libraries.
Is is necessary to use the Qt tools in order to link against a library that was implemented with Qt.
Absolutely not.
The Qt tools that generate code are moc and rcc; if your API doesn't use this then it is quite possible just to use normal 'C' tools.
moc is a tool for signals and slots and even C++ code doesn't need to use the Qt tools to link against a Qt library. You can scan a 'header' for the MOC macro with grep, etc in a make rule to know if the moc program should be run on the executable. Following a convention that class.cc has a declaration in class.h makes this easy.
rcc is a feature that bundle resources with an application. However this would be for the Qt application/library and in your case, you just want to link with it.
So, it is even possible to make Qt applications/libraries without qmake, etc. However, your makefile will need to fulfil all the portability issues that qmake, etc do or you may not care about this.
There are trade-offs to not using the Qt tools. However, a large majority of Qt features can be used without the tools.
I require zlib library for the development of Windows Store app.
Has anyone converted Win32 zlib project to WinRT yet?
Can anyone please describe the steps to convert the existing win32 static lib project to winRT?
Visual C++ is already a supported language for WinRT development, if you wan't to use zlib, just compile it together with your solution. There is nothing that is preventing you from reusing standard ISO C and C++ libraries from within the WinRT, if you are using the C++ language, you might have to expose certain aspects of your library as WinRT Components but only if you need to interface with facilities like XAML or other WinRT languages but that should be a walk in the park. Not something which is tremendously difficult to do.
The whole point of supporting C++ in the WinRT is to allow an existing ecosystem of largely native applications to be ported to the Windows Store. zlib is not an exception. Non-standard ISO C and C++ such as sockets are not supported but there you have alternatives that you can plug-in to, just check that the library you're using has some kind of portability support.
WinRT is very limited with regards to C library functions which are present. What this means is that virtually all cross-platform C libraries are (AFAIK, I'm not a WinRT dev) unusable for that target.
For the case of zlib, there is an alternative: see this question
EDIT: to clarify what I'm saying above, I dug up a list of all CRT functions that are absent for WinRT, which you can find here. As long as zlib or any other C library does not depend on these function calls, you should be able to use the WinRT tools to build that C library. I even found a project file for zlib on winrt by the Ogre team here, not sure how useful it is to you.
You could take a look into this WinRT (Un)Zip component. Its used in production code already.
See the unit tests inside on how to use the component. It compiles on all WinRT architectures including ARM. It has no custom asm for ARM though.
There exists CEGUI, which is a nice GUI library, useable for SFML. The issue is now that there are C# bindings for SFML but not for CEGUI available -as it seems...
Is there any other GUI library out there, working together with SFML, which I could use in C#?
I'd like to avoid to jump to c++ only for the reason that there is no GUI library available...
Thanks
I can't vouch for it, but I stummbled across this one in my search for a GUI library to use with the SFML .Net bindings: gwen-dotnet
Anybody have an idea of best CrossPlatform Multiprocessing and Multithreading Library for C++. The one i can find by google is OPEN MP. is that the only one and standard library for multiprocessing in C++?
OpenThreads is a good option.
Boost.Thread is an cross platform, multithreading library and it will be an part of upcoming C++11 standard. Boost.Process exists, but is not yet part of the official boost library.
Also, QThread/QProcess from Qt is another good option. It is available on platforms: Linux, Mac OS X, Windows, Embedded Linux, Windows CE, Symbian, Maemo.
SFML has it's sf::Thread class(also has synchronization classes).http://www.sfml-dev.org/tutorials/1.2/system-threads.php to compile this link -lsfml-system with gcc and sfml-system.lib with vs.
POCO library. Has a lot of things including thread and thread synchronization classes, thread pool, work queues, active objects and activities, task management, and timers. Well written code, well integrated with other library classes.
Well worth a look.
I have a codebase that makes extensive use of pthread.h. On a windows visual studio project, this obviously doesn't work since pthreads is a unix utility.
I know there exists pthread-win32 or something of the sort, but is there a way to have a codebase use this, without replacing all of the pthread code?
edit: I'd prefer to not have to go through and replace all the pthread calls. This is my question
Try http://sourceware.org/pthreads-win32/. While I've never used that particular library, I've had luck using some windows ports/abstraction layers of POSIX APIs.
I would recommend boost as a library that contains a platform-independent thread abstraction. I don't think you'll find any attempt to call the pthread functions themselves to be satisfying. It's also not very hard to map pthread to Win32 for yourself.
If the code is very heavily *nix-based, you'll probably have the best luck compiling it with Cygwin+GCC. If pthreads is the only *nix dependency and you'd like to avoid the Cygwin dependency, then you should go with Pthreads-win32.