I'm developing a C++ application that needs a GUI. I would like to use the Windows 7 Ribbon Framework, so I'm not interested in having my app compatible with OS different that windows. I would like to also use my preferred IDE, Visual Studio 2010 and obviously I would like to use standard C++ things like std::string, etc. I saw that there is Qt, it seems cool but as I understand I shoud use it with their own compiler because they provide some things that are not part of the standard c++ (slots keyword for example). Plus, I saw that I can use a QWinHost to host win32 controls but I'm not sure if I can host the ribbon control. Should I implement myself a little library to simply manage native win32 controls or should I go with Qt?
but as I understand I shoud use it with their own compiler
Nope, that's incorrect. You'll use your compiler - be it microsoft compiler, mingw-g++ or something else, as long as it is supported by Qt.
Qt provides their own additional preprocessor, called moc. Moc takes input files and based on their contents produce additional *.cpp files which contains standard c++ code. Those files are in turn fed to your "normal" compiler. All necessary build rules are handled automatically, as long as you use qmake to generate project.
Should I implement myself a little library to simply manage native win32 controls or should I go with Qt?
It is your code, and your decision to make. However, to me writing "little library" sounds a lot like reinventing the wheel. If I were you, I'd first tried to make the control work with Qt - because this way I won't have to reinvent the wheel - there are too many GUI toolkits already, so making another one alone is quite pointless.
Related
I am going to be making a project with OpenCV and (probably) Qt for GUI and I was just wondering what kind of project I should create in visual studio? Would it be the Win32 Project or Win32 Console Application or just an Empty Project? A lot of them are quite obvious as I am not making a Dll or makefile but do not know the difference between the others. Thanks in advance.
Which type of project you decide to pick in Visual Studio depends what will best fits your needs. Since I do not know your exact needs, the best answer I can give is explain the difference between the types of Project Options and give examples when you would choose to use the given project:
Win32 Project: A Win32 Project is one of the options Visual Studio provides to you, and if chosen will provide the user with template code that generates a "window", that window being just like any other window (browser window, folder window, etc), but one that your program controls.
Examples: Making a calculator, making an application that needs a window with buttons for the user to communicate with the program, etc.
Win32 Console Application: In this option, Visual Studio provides a Command Prompt interface where the user can input data and also where output can appear. Basically it's the black window where you can input commands and receive information of what is happening in your program.
Examples: When testing out code (it makes debugging easier in some cases), when the program really doesn't need to be too elaborate, etc.
There are other options available, thou these two were mentioned in your post and are probably the most popular among developers.
After installing Qt and maybe a Qt-VisualStudio-Plugin you have some new options when creating a New Project:
You should choose Qt Application in most cases. Not sure if you can use a GUI with Qt Console Application, but you'll get a terminal/console in that case.
After choosing project name, you can easily choose the Qt Modules you'll need. This adds them to your project settings, so you don't have to add the manually (but I guess you can do so later if you need more modules).
The project will create a .ui file which you can open/edit with QtDesigner. The project will perform all the moc and uic compile steps automatically and you don't have to add those things manually.
I think this is the easiest way to use the combination of Qt and Visual Studio.
Adding OpenCV to Visual Studio is easy:
Just add the include directories and the correct OpenCV libraries.
The question whether to use a consolse application or not depends on your needs.
Personally, I like printing development output to a console, but maybe you don't want that in your final project ;)
I'm trying to write my first game in c++, and I want it to dynamically load everything from files. This includes the enemies, and I was wondering if there was a way to dynamically include their code at runtime, instead of linking the on compile, so that the levels are easily interchangeable. Lua might be an option but I have no clue where to start, and dll seems to be Windows-only (and I wouldn't know where to start there anyway). Can anyone help with this?
tl;dr I want to link in code to my c++ game at runtime.
For the Lua approach you first need to choose the version first. Right now there is the major version 5.1 and 5.2. My previous work was using 5.1 and for my new project I decided to update to 5.2, however I found that my favorite script wrapping tool (SWIG) does not work with 5.2. Just something to decide at the beginning, because you do not want to get a version working and then have to change it.
Lua comes with makefile build environment. My first experience of trying to build on Windows was a bit of a nightmare, did not appear to just run out-of-the-box, so I opted to create my own Visual Studio project at the time, and just include all the .C files in the project. There are two files which need to selectively included/excluded depending on how you intend to compile: lua.c and luac.c. If you are planning to embed Lua in your app, then exclude both of these files; they both contain a main() function and are designed to build console apps. Include all the rest of the C files in your project.
You should be able to compile easy from this point.
When you include the headers of Lua, keep in mind that the functions are C functions so if you are including them from C++ you need to wrap the file inclusion inside of: extern "C" {} - example: C++ Lua 5.1 Issue
Wrapping your interfaces in another topic and there are lots of resources available. My favorite is SWIG but there are lots of options, including hand coding the conversion of your C/C++ -> LUA -> C/C++ code. Would recommend just focusing on getting the first part working first, get the interpreter embedded so that you can run a "hello, world!" script from Lua inside your app.
So going by your requirement of crossplatform use and dynamic linking, what you're probably looking for is an environment like QT which has QLibrary: https://stackoverflow.com/a/9675063/453673
But https://softwareengineering.stackexchange.com/questions/88685/why-arent-more-desktop-apps-written-with-qt
MingW is the open-source equivalent for Visual C++, so it can help you writing code for Windows (though if I had a choice, I'd directly use Visual C++). The way dll's are loaded in Windows is somewhat similar to the way they're loaded in Linux, so you'll be able to write code with #ifdef's to do conditional compilation. I've written one such program a couple of years back.
To load a shared library(always with .so as suffix) under Linux, you could use dlopen(), dlsym() and dlclose()
I want to use simple plotting functions in my C++ code. Presently I am using Qt5 with VS2010 c++ compiler. I came across this library called koolplot. But I cannot buid it with VS2010 from its source files. I am opening vs2010 cmd and running nmake...It shows winbgim.h missing..I copied that header in MinGW include folder and ran it ...now it shows "Plotdata.h:warning: 'typedef' was ignored in this declaration" Please help...if any one knows a simple plotting library running with VS2010 please suggest..
According to its website, Koolplot is designed for the MinGW/gcc toolchain - you'll have to do a bit of leg work to get it to compile on Visual Studio, though I don't know specifically what you'd have to do without taking a closer look.
Also, the library seems to do its own window management and the like, so I'm not sure how well you'll be able to integrate it with Qt.
koolplot needs WinBGI library (BGI = Borland Graphics Interface?).
I have changed it to use native Win32 using VS2008:
http://www.tu-chemnitz.de/~heha/hs/koolplot-heha.zip/
It's still incomplete as a good Win32 implementation would implement koolplot in a DLL which self-registers a Window class, and has both C and C++ interface. Moreover, koolplot as-is doesn't support multiple scales, finer plotting options, GDIplus, and fast data update, so it's not the right thing to write an oscilloscope program.
It's C++ code is also outdated as there are lambda functions available now.
However, good integrating into Qt is another task.
I have inherited an old C++ (MFC) project and will have to add new functionality.
The new functionality will mostly not conflict with the existing C++ code, like additional dialogs etc.
Having limited experience with C++ MFC, I would very much prefer to do the additional functionality in Delphi, create a DLL and use the DLL in the C++ project.
I guess this is generally possible, similar to using C++ DLLs in Delphi?
Are there limitations on what can be done this way?
Basically, there are no issues. But if you're going to use dialogs and so on, your application will be using two frameworks, MFC and the VCL, and they may not play very well together.
Delhi if I recall my history should create Dll's happily. See here 'Calling delphi DLL from MS Visual C++' for an example
We have a not very complicated but big (i.e. lots of files) Visual Studio C++ Win32 Console written in C++0x standard in VS2010.
It does not use any non standard code or anything (Hopefully!).
I now wanna port it to Linux.
Which way is the quickest way to do it?
autoconf?
old-fashioned make file?
any other solution?
I would use regular make but keep it simple with default rules as much as possible. Add in dependencies as you go along.
EDIT: As in interim step, build it with mingw so that you can avoid the whole API porting issue until you have a working build in your new build mechanism.
If your console app calls win32 API functions then you have a choice between modifying all the source where it is used or writing a module that implements those functions.
In prior porting efforts of this type I tried it both ways and the latter was easier. I ended up writing only about 18 to 20 shim functions.
It was successful enough that I ended up writing an OS abstraction layer that was used on many projects that simply let me compile on Windows native, cygwin, Linux, VxWorks, etc. with trivial changes to one or two files.
(p.s. Any interest in an open source version of a C++ based OS abstraction layer? I was thinking of releasing an unencumbered version of it to the world if there's sufficient interest. It's mostly useful where BOOST is too heavy -- i.e. embedded projects.)
Most probably you don't need autoconf (and I suggest you don't touch it, unless you love pain), because you are not trying to be portable to a dozen of Unix flavours.
Roll your Makefiles manually. It shouldn't be too difficult if you have a set of shared rules and have minimal Makefiles that just specify source files and compile options.
Use GCC 4.5 as it supports more C++0x features.
You can export a make file from Visual Studio.
Update: Actually you can't anymore, unless you have VC6 lying around
STAY AWAY FROM AUTO* and configure. These are horrible IMHO.
If you can somehow get a VS 8 or 9 vcproj/sln, you can use this. I have not used it, so I can't give any advice.
If you're up to manual conversion, I would suggest something like CMake, as it's pretty easy to get ready fast enough, even for large projects.
If the project has a simple layout, you could have success using Qt 4's qmake like this:
qmake -project
It will output a qmake .pro file, which can be converted into a makefile on many platforms (using qmake). This should work okay, but not perfectly. Alternatively, you can install the Qt plugin for VS, and let it generate the pro file from an existing VS project. It will make your build system depend on Qt4's qmake, which is probably not what you want.
There are of course other things like cmake, but they will all require manual intervention.
The fastest way to do it?
g++ *.cpp -o myapp
Seriously, depending on your needs, even generating a makefile might be overkill. If you're just interested in a quick and dirty "let's see if we can get a working program on Linux", just throw your code files at g++ and see what happens.