I'm new on here, but not a total beginner to programming. I got a book on creating a 2D DirectX game engine so I could expand my programming knowledge, however I am new to C++ and DirectX itself, so I'm afraid I'm a bit clueless on working with multiple project files and headers. I decided to develop my game engine in a proper development environment, so I got VS2013 Professional though the Dreamspark program.
As I said, I haven't worked with something like VS before, so I'm hitting issues with getting my game engine running and I'm not sure what to do. The book said that if I get all my code down correctly (in 3 .cpp source files, 3 headers and 1 main .cpp source file to initialize my engine in a blank game project) the program should compile fine, and it does. The issue is that I only get the resultant .obj files and the project's static library file to appear in my project folder. I don't know what I have to do to get the project to compile the executable needed to actually run this 'blank game' with the engine.
The actual project solution was taken from the disk which came with the book, I wrote my code on top of that solution as my own was causing linker errors. The project properties show that the project is defined as a .lib project, so how is this supposed to work?
I apologize if this is a simple problem, but I'm only used to working with 1 file console applications in C, this is a big jump for me but I'd like to understand how I'm meant to get an .exe created from this project, I would appreciate it if someone could explain to me how this sort of .lib project works. I can post the code if it's necessary, but there's 7 files of it so it's quite long. Thanks!
Solution 1:
As the project contains a main.cpp it looks like it is not meant to be a library-project.
In VS2013 you can switch the type of a project by
In your Solution Explorer (on the left side by default) rightclick onto the project
Select the item Properties from Context Menu (should be on the bottom)
Select the category General
In the section Project Defaults change the Configuration Type to Executable (.exe)
Solution 2:
It could be possible that the executable is stored somewhere else after a successful build. Check what is configured as output directory:
In your Solution Explorer (on the left side by default) rightclick onto the project
Select the item Properties from Context Menu (should be at the bottom)
Select the category General
In section General there should be an Output Directory defined (At the top of the configuration). Per default it should be something like $(SolutionDir)$(Configuration)\
I'm using VS2013 Express, but it should work with Prof too. I'm also using a German edition, hope I translated everything well.
Related
Historical context:
We have a project consisting of following parts:
Host application (C++)
Scripting Engine library (also written in C++)
A lot of C++ plugins (around 30+)
A lot of scripts that tie all the stuff together...
From version to version some plugins are added and some are removed.
Till now we used Visual Studio solution (*.sln) to contain all the projects (*.vcxproj) for Host application, Scripting Engine library and plugins (one *.vcxproj per plugin!).
To share sources/projects we use proprietary source control system, and till now once we merged updates from the server (some plugin projects are added and some plugin projects are removed) all the project tree in the VS were refreshed thanks to "reload" feature (no action was required from developer to see and build updated source tree).
The problem:
Now our senior management decided to switch to Eclipse CDT/MinGW pair and we faced the issue that Eclipse Workspace is not the same thing as Visual Studio *.sln ...
Now when some plugin project folder appears or some plugin project folders disappears corresponding workspace items do not update accordingly.
Thus from now every developer has to use File>Import...>General>"Existing projects into workspace" File/"Open Projects from File System" to add new projects to own Workspace manually once they were added by other developer to the source control.
Also one has to manually remove from own Workspace those plugin projects that were deleted from source control...
This is a great contrast with what we previously had with Visual Studio where "reload" feature automatically updated project/source tree (just bacause all the information arrived with *.sln/*.vcxproj from server).
Our first option was to place Workspace\.metadata etc stuff to source control (as we previously did for *.sln files) but "that is not the way how Eclipse Workspace is designed to be used" (this is even not possible just because paths in .metadata\* are absolute and tons of Workspace\* stuff it is not mergeable at all)
Question:
Is there some way to automatically syncronize Eclipse CDT Workspace with project set obtained from source control. Like just press some (hidden?) magic "refresh" button (in special plugin to install or something like that) and all the new projects will be automatically added to the source tree in the Workspace and deleted projects will also disappear automatically, wothout need to use all those "Import" wizards, and withot need to remove deleted projects manually?
May be there is a special "Container" project type in Eclipse to play the same role as *.sln did in Visual Studio or something like that?
May be other options available?... Overall intention is not in replacing *.sln by some Eclipse equivalent but to support similar workflow when bunch of plugin projects is managed as a whole and project set "refresh" to be simple operation that does not require from each person in the team to manually track projects appeared/disappeared in that set.
Have you looked at using CMake to generate the Eclipse project files? You can then import those into an Eclipse workspace.
Its not automatic, but if you create separate CMakeLists.txt files for each part, then you can easily comment the include of that part in the main CMakeLists.txt file and regenerate the project files when you only want to load subset of the project.
https://cmake.org/Wiki/Eclipse_CDT4_Generator
Should you ever want to change back to VS or to another IDE CMake can generate project files for that too.
I've personally only used CMake to generate VS-solutions and Unix make files so I can't vouch for how well this works.
HTH.
On side note, why did management decide that Eclipse should be used instead of Visual Studio? It sounds like a poor decision without factual grounds or impact research prior to the decision being made.
Was it because Eclipse is free? Did they consider what reduced developer productivity costs?
I am trying to learn C++ from some Stanford Course and they have a custom library which contains a bunch of header files(.h) and their associated source (.cpp) files.
I want to create new C++ projects in xcode 6.x to try out code and include those custom header files in my new projects.
I have no freaking idea how to include those files in my project so that i can peacefully #include "blahblahblah.h" and use functions from that header file without issues.
I am new to both xcode, c++(although i know some coding part) and anything else with this process.
Summary:
I have a folder Library which contains a series of .h and .cpp
files.
I have XCode 6.x.x/Eclipse installed.
I want to create a new C++ project and use #include
"OneOfThoseHeaderFiles.h" and then use a function or something from
those header files.
Also assume i have no clue how to run some command line codes that i see a lot of.
If someone can please tell me in the most simple way(preferably step-by-step) i would be so eternally grateful and sing praises to you until the day i die :)
Note: Either XCode or Eclipse is fine. I really just want to start coding.
I have spent the better part of a whole week trying out xcode, eclipse etc and trying to follow a ton of steps to get it working but i just cant get how to add the files without issues. Either the info seems to be for Xcode 4.x and every menu seems changed or the suggestions are so complicated that a novice like me cant figure it out.
First off, almost all the information for Xcode will be available on the Apple Developer's portal:
https://developer.apple.com/library/prerelease/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/start_project.html#//apple_ref/doc/uid/TP40010215-CH2-SW5
To create a simple static library on Xcode 6 you start by creating a new project, then under OS X - Framework and Library select Library, on the next window change the Framework to None (Plain C/C++ Library) and static (since that is what your are stating).
Once your project is created, add the existing headers and sources to your project, either by dragging them with the mouse or with the add files drop menu from the right click functionality, you can create a new group in Xcode if you want some order for them.
When adding the files, on the add window shown you can select to either copy them or use their current location.
If needed you might have to change the "header search path" in your target configuration under "Build Settings", if it is the first time you are using Xcode some of this will sound weird but I am sure you will find most of it on the Apple Developers portal in great detail.
If you want to test the files without having to create an external static library you could create a command line project and test them faster and easier.
I've just started working with Eclipse for C++ and I just want to clarify something that I haven't been able to figure out by searching so far. Is a project folder in eclipse only intended to have one program in it? i.e., a what is meant by project is basically a C++ program? And so you're not supposed to store many different programs in one project directory? Am I understanding this correctly?
That is correct, though they are trying to change that:
http://www.eclipse.org/eclipse/development/towards-more-flexible-projects.html
Eclipse requires that the contents of each project be stored in a
single directory on disk. Every file and folder in that directory tree
on disk must belong to the project in the workspace
Project is a project. You could divine you aplication to .dll, .exe, or other stuffs. When you are developing something that could go apart in another solution the you can put apart that piece (.dll for example). When you are developing in Visual Studio you can see that projects are in final a single file that has some own functionality, and the whole program is called solution. Didn't fired up Eclipse for a while, but it goes in the same direction. I can remember that projects in Eclipse were very poor, and meaning of the project was considered with actual language that you use (Java, C/C++, PHP, PYTHON, etc.).
Good definition is that project hold some part of application (if not all of it).
I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.
The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?
(This is all unmanaged C++, and contains specific builds for win/unix)
With no project/solution loaded, in Visual Studio 2005 I see this menu item:
File > New Project From Existing Code...
After following the wizard, my problem is solved!
Switching the "Show All Files" button shows the complete hierarchy with all directories and files within.
If the New Project From Existing Code... option isn't available, you'll need to add it in Tools > Customize...
I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.
The best option I see is actually creating the project files by some script.
Creating a single project manually (create empty project, then add the files),
Configure it as close as possible as desired (i.e. with precompiled headers, build configurations, etc.)
Use the .vcproj created as skeleton for the project files to be created
A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.
Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.
The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).
In addition, this script also contains dependencies, which feeds the actual build script.
This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.
#Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"
I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.
Pros:
Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.
Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with
Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.
Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.
Create a new empty solution and add your source code to it.
For example,
File>New>Project...
Visual C++>Win32>Win32 Console Application
Application Settings>
- Uncheck "Precompiled Header"
- Check "Empty Project"
Project is then created. To add existing code:
Project>Add Existing Item...>
- Select file(s) to add
Recompile, done!
In the "Solution Explorer" you can click on the "Show All Files" button to have Visual Studio display the files as they exist on the file system (directories and all).
In my opinion this is an imperfect workaround, but I believe it's the best available. I'm unaware of a plug-in, macro or other tool that'll import a directory into an actual project with folders that mirror the file system's.
I know this question is already marked correct, but I was able to import existing code into a project with Visual Studio 2008 by doing "File" -> "New Project from existing code". The directory structure of my code was retained.
You can always switch view from project menu
For eg. Project->Show All Files
The above will display the files in unformated raw file system order
Not sure of older versions but it works on VS 2010
I understand you, I have the same problem: many .cpp and .h files organized in many folders and subfolders with include paths written for this folder structure. The only way you can do to import this folder structure together with the source files is to use "Show All Files" and then right-click on folders and select "Import in Project". This works for me when I am using C-Sharp projects. But it does not work for my C++ Projects. I am still searching for a solution...
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.