Yes, it's a noob question...
I have been using Dev-C++ for all my projects so far, but it is incredibly outdated, and so where the libraries. So I opened up my copy of Visual C++ and copied the code. When I compile, a million errors pop up, as if every second line of my code is shit. I would hate to start the project again from scratch.
Question: Why is it that Dev-C++ and VC++ compile differently??? I've heard they use different compilers, but its still C++. The first error I looked at was an invalid comparison between a const char* and a std::string.
Anyway, is there any way to make VC++ less strict on programming, as is Dev-C++. Or are there a few major differences between Dec-C++ and VC++ compilers that I should know about.
Most of the errors seem to be std::string related, or LPCWSTR (i can fix that myself).
Sorry about this very broad and useless topic, I'm knew.
-Alex
First, a few notes, because many Dev-C++ users are confused (I used to be)
Dev-C++ is not a compiler. The compiler is GCC (or, more precisely, a modified version of GCC so that it runs on Windows : MinGW). Dev-C++ is an IDE : a text editor with an additional button which calls MinGW with the appropriate parameters when clicked.
Nothing more.
Same thing for Visual Studio : Visual Studio is the IDE, which calls the Visual Compiler (vc.exe), which implements VC++, which is Microsoft's implementation of the C++ standard.
Second : It's not a noob question. You have discovered portability issues, which is a great area of frustration in C and in C++. A lot of questions on StackOverflow are due to portability problems (a code that works on Windows but not on Linux, etc).
The general rule of thumb is to 1) set your compiler's warning level to the maximum and 2) develop in parallel on all the platforms you're targetting.
Hope this helps.
This will not answer everything, but it might help.
By default, VC++ uses unicode while MinGW (on which DevCpp is based I believe) uses ansi.
This might explain your issues regarding strings: you're basically passing char* strings where most of the functions require something like wchar*.
I suggest that either you fix your code so it becomes unicode compliant, or that you undefine the UNICODE macro in your VC++ project, if unicode is not required.
As you stated, your old code was C++ and the code is C++ as well, so there shouldn't be that much work... as long as you don't rely on compiler specific behaviors.
Could you give us some samples of things that go terribly wrong ? We might be able to help more accurately.
Are the project settings the same? Perhaps you need to link in additional .libs or add similar preprocessor directives as you had in Dev-C++. If you just copy and paste the code to a project, you're effectively re-setting the project settings all to default, which for many projects, would break the build.
Apart from that - try adding one of the most common errors you receive to the question, with the line of code, and maybe we can comment.
Dev-cpp uses mingw as its compiler. Perhaps you will have more luck using an updated version of mingw, through another IDE. This will help with external dependencies (mingw uses gcc which uses *.a files to link to, VC++ uses *.lib files).
As you mentrion string and LPCWSTR, see ereOn's answer. Make sure you have UNICODE and _UNICODE properly defined (in build flags as -DUNICODE or in VC++ project options).
Related
I'm a bit stuck on trying to port my code from Windows to Linux. I created a Bluetooth based program, which seems to work in Windows well, that I need to get working in Ubuntu.
Unfortunately the computer with Linux on isn't mine, so I can't have any easy hacks using Wine or other massive compiler altering methods, I really need some advice on porting my code across so it'll be recognised and work in the different OS.
The computer does have code::blocks installed, which from what I understand is fairly useful in converting some things for cross-OS compiling, but I'm not getting too far.
The original code was written in Visual Studio 2013 and understandably it doesn't play nice in code::blocks. I'm getting a lot of 'can't find header' errors, but I don't think simply finding all the missing headers and copying them across will work (will it?).
I need some suggestions on the easiest, stand alone solution for my situation. By standalone I mean I want to get as much of the needed changes and libraries in my project, rather than change/install lots of things on the Linux machine.
I don't really know where to start and searches online don't seem to be too helpful.
Thanks!
First of all, I suggest you examine your Windows code, and use the PIMPL idiom (also here, here, ...) in your classes to isolate all platform-dependent code to separate windows and linux class implementations. Your main platform-independent class then will simply delegate to each implementation at compile time using preprocessor macros to include the appropriate platform implementation header and cpp files.
Beyond this, many runtime functions, as implemented in Visual Studio as either Microsoft-specific, or have been 'modified' and are no longer compatible or even have the same names as the standard ones you will find in linux. For these, you'll need to use a platform.h and platform.cpp file, with separate sections for the two operating systems, containing the missing functions in either macro-defined form (i.e. windows: strnicmp(), linux: strncasecomp() ), or write the missing ones yourself. Example:
// Linux section ...
#ifdef LINUX
#define strnicmp strncasecmp
#endif
The final work involved depends on how many windows-specific calls you have in your code.
Our project uses VC++9 with VS2008, and we want to make the switch to VC++10 with VS2010 to use the new features. Unfortunately, some of our dependencies were built with VC++9, and recompiling them with VC++10 is not possible at the moment for various reasons. Since we really want to make the switch, is there was a way to simply link with those libraries, or is there no compatibility between VC++10 and VC++9 binaries?
EDIT: The actual dependencies are BWAPI and BWTA. In the case of BWAPI, it's not a problem, but BWTA depends in CGAL, and that's what's giving us trouble. Trying to link with it yields a bunch of linking errors.
In general you are out of luck unless the dependencies are COM modules or dlls that export only "pure" C functions.
Visual Studio releases are allowed to break ABI compatibility. This means the exported and internal signature of C++ classes is different, and passing for example a std::string from a binary compiled with one version to a binary compiled with a different version might not have the expected result. In short: do not rely on this working. If it does, you're lucky, but in "undefined behavior" territory at the runtime level. Just fix your code to build with VS2010. It's probably broken to start with.
well in the case of a 3rd party lib that you cannot change, the typical answer is to wrap them with a simple dll that is built with VC2008 and calls the 3rd party for you. You then have control over what is exposed, so you can fall back to a 'standardised' mechanism that works with both linkers. This is almost always C function calls as C is very standardised.
The problem is MS changing the ABI of compiled C++, and I guess with the standards committee not providing a standard way of calling C++ binaries.
Looking at GCAL this doesn't seem to be a good answer for you, the best you can do in such cases is to contact GCAL and wait for a rebuilt binary.
But I just checked - its open source, rebuild it yourself. Not only that, it already supports VS2010 so rebuild should be easy.
Thinking of using MinGW as an alternative to VC++ on Windows, but am worried about compatibility issues. I am thinking in terms of behaviour, performance on Windows (any chance a MinGW compiled EXE might act up). Also, in terms of calling the Windows API, third-party DLLs, generatic and using compatible static libraries, and other issues encountered with mixing parts of the same application with the two compilers.
First, MinGW is not a compiler, but an environment, it is bundled with gcc.
If you think of using gcc to compile code and have it call the Windows API, it's okay as it's C; but for C++ DLLs generated by MSVC, you might have a harsh wake-up call.
The main issue is that in C++, each compiler has its own name mangling (or more generally ABI) and its own Standard library. You cannot mix two different ABI or two different Standard Libraries. End of the story.
Clang has a specific MSVC compatibility mode, allowing it to accept code that MSVC accepts and to emit code that is binary compatible with code compiled with MSVC. Indeed, it is even officially supported in Visual Studio.
Obviously, you could also simply do the cross-DLL communication in C to circumvent most issues.
EDIT: Kerrek's clarification.
It is possible to compile a large amount of C++ code developed for VC++ with the MinGW toolchain; however, the ease with which you complete this task depends significantly on how C++-standards-compliant the code is.
If the C++ code utilizes VC++ extensions, such as __uuidof, then you will need to rewrite these portions.
You won't be able to compile ATL & MFC code with MinGW because the ATL & MFC headers utilize a number of VC++ extensions and depend on VC++-specific behaviors:
try-except Statements
__uuidof
throw(...)
Calling a function without forward-declaring it.
__declspec(nothrow)
...
You won't be able to use VC++-generated LIB files, so you can't use MinGW's linker, ld, to link static libraries without recompiling the library code as a MinGW A archive.
You can link with closed-source DLLs; however, you will need to export the symbols of the DLL as a DEF file and use dlltool to make the corresponding A archive (similar to the VC++ LIB file for each DLL).
MinGW's inclusion of the w32api project basically means that code using the Windows C API will compile just fine, although some of the newer functions may not be immediately available. For example, a few months ago I was having trouble compiling code that used some of the "secure" functions (the ones with the _s suffix), but I got around this problem by exporting the symbols of the DLL as a DEF, preparing an up-to-date A archive, and writing forward declarations.
In some cases, you will need to adjust the arguments to the MinGW preprocessor, cpp, to make sure that all header files are properly included and that certain macros are predefined correctly.
What I recommend is just trying it. You will definitely encounter problems, but you can usually find a solution to each by searching on the Internet or asking someone. If for no other reason, you should try it to learn more about C++, differences between compilers, and what standards-compliant code is.
I have been using the gcc compiler with code::blocks ide, and have noticed there are some things missing in the commctrl.h which are:
PBS_MARQUEE and PBM_SETMARQUEE to set a progress bar to marquee animation style.
LVS_EX_DOUBLEBUFFER for a double buffer on a list view...
there are probably a lot more missing, but these are the ones i've noticed, and i need them!
i have downloaded the latest mingw libraries and they are still not in, the only place i can find them is in visual studios headers, but i don't want to use that
is there any way i can get them in gcc?
GCC does not do a good job of supporting Windows. This is a prime example of why. It's an excellent compiler. and on Unix boxes there's nothing else I'd ever use, because it's an excellent compiler, but...
MinGW simply does not include a few of the Windows headers, and for those that they do, they aren't always as up to date as the ones in the Windows SDK.
Finally, in order to support some bits of COM, GCC would need to be able to parse IDL, is not typically used on non-Windows systems is not currently supported by GCC.
Visual C++ Express (as well as it's compiler included in the Windows SDK) is free. What is your aversion to it?
The best way would be to contact either mingw.org or mingw-w64, which is a fork also supporting x64 targets. The latter are known to respond quickly and friendly to "missing features" requests. you can contact them on either the mailing list or forums or IRC (see link).
.... Scratch that. It seems my copy of the mingw-w64 commctrl.h header include these macros. I don't know if they work as expected, but give it a try. Downloads are linked on the page I linked to above. I would recommend personal builds by Sezero for completeness and ease of use. You should be able to replace your mingw folder with the one from the archive (make sure the gcc.exe et al match up).
Do you have the correct _WIN32_WINNT macro defined? It looks like they all need _WIN32_WINNT >= 0x0501.
How do you port C++ programs with makefile made from GNU C++ in Linux to Visual C++?
One thing I can suggest is to use CMake. If you implement your build system with CMake to auto-generate the makefiles for GCC on Linux, it takes only minor modifications to auto-generate projects and solutions for VC++.
Of course, this means learning a whole new build tool, so it may not be for you. It's only a suggestion.
I don't know about an easy way to simply convert from one to another, but..
Assuming you use only ANSI C/C++ features, usually you don't need to convert the makefile, just look which .c/.cpp files are in it and add them to the VS project; you'll also have to check about compiler options and defined macros, to put them inside the VS project. I've done this to compile libs like expat, freetype, agg and others, without problems.
Porting the build system: You could use a Windows port of GNU make, and change the makefile to invoke the Visual C++ command line tools (cl.exe, link.exe, lib.exe, etc.) when building on Windows and the GNU compiler tools when building on Linux. The difficulty of this approach depends on the complexity of the makefiles.
Porting the code: This depends on what APIs and libraries you are using, and what compiler warnings/errors/quirks you will encounter. For a more specific answer, ask a more specific question.
CMake was mentioned. I have used CMake and successfully compiled the resulting Visual Studio project. I found the CMake documentation very unhelpful -- I had to ask an existing user -- and the official manual (which costs money) was out of print at the time. Further, the Visual Studio project it produced was very rigidly formatted according the template preferred by whoever wrote the converter. I was unable to figure out how to customize project options or group source files.
I regularly cross-compile on Visual Studio and G++. For the most part, you just need to add all of the source files and header files into a Visual Studio project ('Add Existing Files', and add your entire source tree) and then compile it. Usually you'll get errors, so you start fixing bugs from there. If you used platform-specific libraries, you may be stuck porting to an alternative or removing features.
One further word of caution: Visual Studio and G++ have different compiler quirks. For the most part, they both conform excellently to the C++ standard, but slightly off-standard code which works in one may not work in the other. I have found this to be particularly true when dealing with templates, with Visual Studio being bizarrely permissive of syntax errors in many cases.
CMake has the nicety of generating visual studio project.
If you do not need that, I suggest Meson build system. Much nicer, similar proposal. Requires python3 and ninja, but noone is perfect. :)