Every time I create headers I have to manually rename their extensions from .h to .hpp.
And when I create C++ Projects with wizards, header files get created with the .h extension.
Is there any way to change C++ Headers' default file extension in Visual Studio 2013?
I know, it's a matter of personal preference, but I want to do it anyway.
The Visual Studio world uses ".h" extension, that's just the way it is and it makes no difference whatsoever the extension you use. They all become part of your ".cpp" files anyway when the are "included", they are literally copied in in-place of the "#include" line when the compiler runs. They can have any extension at all. It also doesn't matter if the source files are ".c" or ".cpp", the compile mode is set in the project properties, and will be C++ unless you deliberately change it, which would render most of the SDK unusable anyway.
Related
i just started learning c++ lately and i am using visual studio 2015. But i have to manually remove the #include stdafx.h in my cpp file before upload it to the test server for my class, or it just sends back an error like this:the error from test server
I would like to know why this issue is happening. My guess is that this thing is exclusive to windows and x86 based OS?
Any help would be appreciated. :D
You'll need to upload all your sources. stdafx.h isn't special in that regard. Of course, if your course restricts you to one .cpp upload, then you can't use stdafx.h for that course
stdafx.h is the default name of a precompiled header for a Visual Studio project. However, you can certainly have a file named this on other environments. Note that the Visual Studio compiler processes this header slightly differently than it does other headers, if it is specified as the precompiled header in your project's property pages (C/C++ -> Precompiled Headers - see here for more details). For example, multiple includes of this file with different preprocessor defines will be ignored when it is the precompiled header (which isn't that common, but something to be aware of).
If you want to make portability to non-Visual Studio environment easier, it's usually easier to disable precompiled headers in your Visual Studio project. If you continue to use the stdafx.h file in your code, you will obviously need to upload it to your test compilation server, and may need to modify it and/or its inclusion into your code.
when we have resources in our project, Visual Studio creates two files: "resources.rc" and "resources.h". Now, every change in rc file (in visual editor), changes header file also.
Sometimes I need to add something manually to resource.h, but after any change in visual editor, my header changes may be even deleted.
I've noticed that VS uses some kind of comments that steers its behaviour. So maybe there is a way to say to VS: "Hey, don't touch this part of file" ?
I have folder contain a Visual Studio project and contain lots of .h and .cpp file I want to put all of this .h and .cpp file into just one main.cpp file is there any way to do that with Visual Studio or any other things??
Depending on the functions and libraries you are using it can/can't be done. if all the functions are compilable in Turbo and the project isn't that professional which I think it isn't based on you saying you want it for your course project you can simply copy everything in a cpp and convert the header files into simple classes. anyway Turbo C++ is Dead!
You cannot do this trivially. You would have to refactor, as merging source files can introduce semantic problems. It's best to not do this at all.
I've got a program written in c++ and have to make some modifications to it. Howerver, I haven't got any solution file or a like, just a bunch of .h, .cpp, .obj, .dpb, .dll, .mdi, .dfm, .res, .tds, .bpl files and an .exe file.
So I can start an application, see what it's doing and what the controls are, but when it comes to adding changes trying do to map behaviour of UI to source code files seems just to tedious.
Is it possible to recreate some kind of solution file or just to simply the process? (I am using VS 2012 and an app was written in 2002).
These file extensions indicate the source is from a Borland IDE. That .mdi file I think signifies Borland's multiple-document-interface... I'll venture to guess this project would be quite difficult to "recompile" using Visual Studio. I don't even see a .rc (resource file) in your list. Rewriting may be the easiest path, depending on the complexity of the application...
I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.
Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.
Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.
There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.
I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.
What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.
For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.
Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using /pragma hdrstop is solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.
Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.
Precompiled headers aren't too bad if you use them properly.
Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.
You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.