I'm a hobbyist developer and have a background with Java (IDE of choice was Eclipse). I'm using Visual Studio Express 2010 and wanting to learn C++.
Few questions:
I create a "HelloWorld" in C++ and compiles/runs in VS/Windows. When I try to compile it under Linux/GCC, it obviously throws tons of errors. Default windows console project includes windows specific files; but if just create an "Empty Project" it throws tons of linker/build errors. What's the best practices here to keep my code portable?
Why is it creating 47 files for 8 lines of code?
How do you format code? You can do Edit->Format Selection, but the hotkeys don't work?
How do I output to VS's 'Output' Window? ( like eclipse does when you run a console java app )
It keeps reverting my "Project Location" to my "home directory" every time I restart. How do you change it? Is it a bug? Because it's Express edition?
Is there a way to keep it from switching to Debug view when it runs?
I create a "HelloWorld" in C++ and
compiles/runs in VS/Windows. When I
try to compile it under Linux/GCC, it
obviously throws tons of errors.
Default windows console project
includes windows specific files; but
if just create an "Empty Project" it
throws tons of linker/build errors.
What's the best practices here to keep
my code portable?
For portable code, avoid VS wizards entirely. Use Make/NMake if you're starting with rocks and sticks, or the portable build system of your preference (Ant, CMake, etc.) Some of these will spit out a VS solution/project file for you to use.
Why is it creating 47 files for 8
lines of code?
Wizards are magical like that.
How do you format code? You can do
Edit->Format Selection, but the
hotkeys don't work?
Ctrl-K Ctrl-F (under Edit, Advanced)
How do I output to VS's 'Output'
Window? ( like eclipse does when you
run a console java app )
Lookup OutputDebugString() for the debug window. Output window should get all cout/cerr output.
It keeps reverting my "Project
Location" to my "home directory" every
time I restart. How do you change it?
Is it a bug? Because it's Express
edition?
Probably hidden in options somewhere - don't know that one, sorry.
Is there a way to keep it from
switching to Debug view when it runs?
Launch using Ctrl+F5 to run without the debugger attached.
Have fun!
I create a "HelloWorld" in C++ and compiles/runs in VS/Windows. When I try to compile it under Linux/GCC, it obviously throws tons of errors. Default windows console project includes windows specific files; but if just create an "Empty Project" it throws tons of linker/build errors. What's the best practices here to keep my code portable?
It's fairly difficult to keep your code truly portable if you're writing Windows applications. Standard C++ will obviously work on either platform, but Linux can't run Windows applications, and vice versa. Remember that console applications are also considered Windows applications. They're not any more "pure" just because they are text-based, rather than graphical. Windows applications have their own entry point, different from the standard main function found in ANSI C++ (technically, main is still there, but it's hidden and called internally by the Windows libraries).
The best thing to do is not to link to any of the Windows headers. Unfortunately, you won't be very satisfied with the results. About all that you'll be able to generate is library code. You can't get a UI on the screen unless you use the Windows functions to do it.
An "Empty Project" is just what it says—empty. I assume the build errors are because you're trying to call functions that aren't defined anywhere. You'll find that you need to include windows.h to get off the ground, which instantly makes your code non-portable.
Why is it creating 47 files for 8 lines of code?
This is obviously an exaggeration; none of the wizards produce anywhere near that many code files. Especially not the "Empty Project", which doesn't create any at all.
A Win32 console application includes the following 5 files:
stdafx.h and stdafx.cpp — these files are used to enable "precompiled headers", meaning that Visual Studio will compile all of your headers once, and only recompile them when they change, rather than recompiling them each time you build the project. This used to provide enormous speed boosts, and still does on large projects. You probably don't need or care about this for small projects, but it's not a bad idea to get familiar with their usage if you're going to be developing in Visual Studio.
A targetver.h file, whose only purpose is to specify the earliest version of Windows that you want your application to run on. This is necessary because later versions of Windows add additional functionality that wasn't available in previous versions. Your app won't run if you link to functions or libraries that don't exist. Set this up once and then forget about it.
A <projectname>.cpp file, which is the implementation code for your application. This is pretty standard stuff—it includes the _tmain function, which is the entry point for a console app.
A ReadMe.txt file, which you can immediately delete. It contains some introductory information and describes the files that have been added to your project. (Yes, reading this yourself could have answered this question.)
A Win32 application would have a few more files, but most of the same ones as well. In particular, you'll see a resource file (with the extension .rc) that contains the icons, dialogs, bitmaps, cursors, etc. used in your program.
If you don't like this structure, you can either forgo the use of a wizard, or modify it yourself. There's nothing set in stone about it.
How do you format code? You can do Edit->Format Selection, but the hotkeys don't work?
Formatting code works fine. I'm not sure why people are telling you that Visual Studio doesn't support this, or that you'll need a third-party plug-in. There's no "Format Document" command as there is in C#, but the "Format Selection" command works just fine. The only difference is, you have to select something in order for it to be enabled.
The default keyboard extension for that command is CtrlK, Ctrl+F. It also works fine, right out of the box. My typical workflow is to hit Ctrl+A first to select all.
How do I output to VS's 'Output' Window? ( like eclipse does when you run a console java app )
I don't know what Eclipse does, nor do I know anything about Java. What do you want this to do? When and what things do you want to get written to the "Output" window? A console application will run in a console window, not in the "Output" window. That's not what it's for.
It's intended for debugging purposes. The OutputDebugString function is one way of utilizing it. The output of the standard cerr keyword should be automatically redirected to the "Output" window.
It keeps reverting my "Project Location" to my "home directory" every time I restart. How do you change it? Is it a bug? Because it's Express edition?
This isn't a bug, it's a feature. Visual Studio is designed for working with projects and solutions, not one-off code files. So by default, it prompts you to specify a project folder, a location to store your files. And what better place for the default location than your home folder?
If you don't like that location, you can change it. Under the "Tools" menu, select "Options". Expand the "Projects and Solutions" category, and click the "General" item. Then, change the path of the "Projects location" (the top textbox). Couldn't get much simpler than that.
Is there a way to keep it from switching to Debug view when it runs?
I frankly don't understand how this question makes any sense at all. When you run an application with the debugger attached, Visual Studio switches to a different window layout specifically optimized for debugging. I just answered a similar question. The upshot is that there's no way of telling Visual Studio to use the same window layout for both design and debug view, but I also can't imagine why you'd want to, either. Different things are useful, depending on what you're currently doing.
The two window layouts are customizable, and your changes are remembered. I've customized mine heavily from the defaults; it's very likely that your tastes vary as well. There are lots of great features, like the "Locals" window, which shows a listing of all the values of the local variables in scope at the point where you break into your program's execution.
Also remember that the default "Debug" and "Release" build configurations have nothing to do with whether or not Visual Studio automatically attaches the debugger to your application's process. If you want to start your app without the debugger attached, select "Start without Debugging" from the Debug menu, or press Ctrl+F5. There are lots of side effects to this though, and it's probably not what you wanted. Without the debugger attached, you lose most of what Visual Studio provides to you as an IDE. You might as well just run the app from Windows Explorer without even launching VS.
Finally, if you prefer Eclipse (or at least are already accustomed to its nuances and prefer not to learn Visual Studio's), you can still use it for C++ development. Download it here.
If you're just wanting to learn C++ and you don't necessarily care about the platform, I would probably avoid using Visual Studio to start with. Visual Studio provides some functionality for managing projects and builds, but honestly, I think you're better off learning how to manage code files and use the compiler on the command line first, then working up from there.
If you're on Windows, I'd recommend installing Cygwin and getting the GNU compiler tools through the Cygwin setup utility (gcc or g++).
This is a bit of an opinionated answer, but my experience with C++ on Windows leads me to believe that you'd be better served trying to learn C++ from more of a unix-like angle. Windows C++ adds a whole layer of crap that will just confuse you when you're getting started.
Related
I'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
The dev environment in question consists of:
Windows 7
MinGW (g++)
CMake
Qt Creator
The problem is that Qt Creator, a lovely IDE as far as I can tell, does not display programs' command-line output. It seems to have its own proprietary debug pane, but it doesn't give me, for example, runtime errors. It just tells me that the program has failed and gives me the exit code. I'm using Creator only for its C++ capabilities, and not using Qt in any way, so the proprietary pane is useless to me.
So I ask this: Can something be done? Am I missing something really, stupidly obvious like a built-in command line? Or, if not, can I at least use some filthy and/or repulsive hack to get it to display the Windows command prompt upon running a program?
Last thing; I did do some research, and found a way to edit the Qt project file to display the prompt, but... I'm using CMake, not Qt projects. So that doesn't answer my question. If I can do something similar with CMakeLists.txt, that would be wonderful. But Google has failed me on that front, so I'm not holding out too much hope.
EDIT:
I'm specifically worried about runtime errors. cout and printf are rerouted to Qt Creator's window, so that's fine. I don't get runtime errors unless the debugger catches them, and the frequency of that is less than ideal.
Windows GUI programs don't have standard output.
In Windows there are two possible entry points in the standard runtime. The console one and the windows one. The console one will inherit console window from parent process or create a new one and connect the standard input/output/error streams to it, while the windows one will leave them unconnected unless they were explicitly redirected by the invoking process. A Qt application is (probably; you could have console Qt-Core application) a GUI application and Qt Creator (nor any other Windows IDE) does not redirect the output explicitly. Therefore the standard output is not open at all and the writes are being discarded.
However windows have separate logging facility for debugging purpose. This is what you see in the debug window. You can write to it using the native OutputDebugString API. I am sure you can also direct the Qt debug log there.
Note, that when it tells you the program has exited with status 0, it means the program ran, which in turn means it compiled successfully and thus there were no errors from g++. There may have been warnings, in which case you should see them in the appropriate other window. Compiler and program output are different things; the IDE does read the compiler output.
I have a project which I created in Eclipse c++. The project invokes a function that does a lot of loops (Thousands) to calculate the result.
When I run it in Eclipse it takes 1 minute (~70 seconds).
I wanted to add a GUI to the project so I opened a WinForm (Win32) project in VisualStudio2010 and moved all files of the project from the eclipse directory to the new directory (created for VS2010).
Now, when I run the form, the function takes 4-5 minutes. I tried to cancel the progress bar but it wasn't the problem, so I understood that long time is not because of the GUI.
I think the problem is in the compilation in VS2010. I tried to change some Optimizations properties, but the project couldn't be compiled...
How can I reduce the run time?
Thanks!
Basically you answered your own question:
I think the problem is in the compilation in VS2010. I tried to change
some Optimizations properties, but the project couldn't be compiled...
however, it's hard to answer it, since there is a lot of optimization options in both of compilers, it's hard to tell what option makes it much faster/slower. It's also possible (and most probably is) that MS compiler just cant produce exactly the same or similar code to that of Eclipse's compiler.
Your options is to "play" with optimization switches of the VS compiler and see if it helps. You can try to compare it's options to ones of the Eclipse to find differences, but most likely they will be just too different.
As #Zuljin correctly mentioned also check you selected Win32 project, not CLR (Windows Forms) application. If you are using CLR project, then it's natural it will possibly run slower than Native program type.
My bet would be the debugger in VS2010
Build with your optimized settings but then start the generated file from the explorer, not from Visual Studio. You can also deactivate the debugger attachment in the project settings.
See if the run time is any different.
I know the title makes little sense, mostly because it's hard to explain in just one line. So here's the situation:
I have a program who's binary is targeted at Windows 2000 and newer. Now, I went ahead and added some code to check if the user is running under Vista/7, and if so then check if Aero/DWM is enabled. Based on this I'll disable some stuff that isn't relevant to that particular platform, and enable some other features. My main problem is that in order to call DwmIsCompositionEnabled from Visual C++ 2008 I have to add the dwmapi.lib file and compile against it. Running the binary in anything other than Vista or 7 gives the "Unable to locate component. The application failed to start because dwmapi.dll was not found" error. This, of course, is expected to happen since DWM is new and not available for older platforms.
My question is then: will it be possible for me to somehow manage to pull this off? One binary for all OS versions AND include that DWM check code? This program was written under Visual Studio 2008, Visual C++ using MFC.
Turns out I can just tell the linker to delayload the dwmapi.dll.
I'd like to thank ewanm89 because something he said sort of resonated and led me down the path to finding the actual answer.
The normal solution is to use LoadLibrary() and GetProcAddress(). Both can be done after your program started. But still +1 for the DelayLoad solution, which does the same for you behind the scenes.
Coming from a different development environment (Java, mostly) I'm trying to make analogies to habits I'm used to.
I'm working with a C++ project in Visual Studio 2005, the project takes ~10 minutes to compile after changes. It seems odd that if I make a small syntactical error, I need to wait a few good minutes to get a feedback on that from the compiler, when running the entire project build.
Eclipse gave me the habit that if I make some small change I will immediately get a compiler error with an underline showing the error. Seems reasonable enough that VS should be able to do this.
Is this something I can enable in VS or do I need an external plug-in for this?
The feature you are asking for will be available in Visual Studio 2010. Here is a detailed link of the feature details that will be available.
For now, as others have suggested, you can use Visual Assist which can help a little bit.
These are called Squiggles BTW.
You can try the following:
install a plugin like Visual Assist: it will notify you about most of the errors;
if you want to check yourself, use Ctrl-F7 to compile the file you are currently editing - in such case, you will not need to wait for all project to compile. If you are editing a header file, compile one of the .cpp files it is included in.
Yes, C++ is notorious for its build times. Visual Studio cannot perform on-the-fly syntax checking (in case of C++), but you can install Visual Assist to help with that:
(source: wholetomato.com)
10 minutes is quite a long time to wait, are you doing a full build every time? There are a lot of techniques you can use to speed this up, for example using precompiled headers. I try to organise my code so that I do all of my significant changes in the code file instead of the header, then just do a build of that one file (ctrl F7) to check for errors.
You have the "error list window" that will list your errors and warnings after compilation. If you double click on the error it will directly go to the problematic line of code in your source. It's in the menu Display, sub menu "Other windows".
Keep in mind that compiling C++ is a much more difficult task than compiling Java, which explains the increased time.
Visual Assist X is very cool but only detects typos.
It cannot be compiled "on the fly" which explain the feature you ask is not possible. If you have a multicore machine, you can enable parallel building.
Tools -> Options -> Projects and solutions -> Generate and Execute -> maximum number of parallel compilation.
Resharper for C# has it. But for c++, maybe visual assist x ?
Eclipse gave me the habit that if I make some small change I will immediately get a compiler error with an underline showing the error. Seems reasonable enough that VS should be able to do this.
Eclipse has implemented their own Java compiler, and run that in the background every time you type a word to be able to detect and underline errors. I don't know if I'd call that "reasonable". ;)
It's a lot of work to implement that feature, even in a simple language like Java.
In C++, where, as you've discovered, compiles may take minutes, it's harder still.
Visual Studio 2010 is going to implement this feature (again, using a separate compiler, which is much stripped down, and won't always provide correct results -- that's the compromise necessary to ensure that it's fast enough to compile on the fly).