I have been learning c++ independently for about 3 months, and I have a question that has gone unanswered. How are the files organized within your computer so that the program knows where to look to find the files?
I know that you can save header files and source files as being separate from each other, but how does the program know where to look for these things? Where are they located? Where in the hierarchy (up or down, same folder) do they belong? Can I change where the computer looks for them?
This has been nagging at me for weeks and I have not found an answer. Does anyone know what I mean? Can you help?
Depends on the Operation System ("OS"). There's an environment variable called PATH that instructs the compiler where to look at. On Linux and Mac there are a few typical folders, so the compiler looks inside these folders.
In addition to these default searches, the compiler also looks in the same folder as the source files live. And you can always tell the compiler where to look at first.
Related
I have a C++ solution that uses several external libraries. For that to work, the compiler needs to be able to find all the header files. Currently this works by hard-coding the header locations into the various project files. But since the headers are installed in a different location on each computer, that means the project will only build on one machine.
What is the "correct" way to deal with this problem?
I feel like there should be a way to define which libraries each project needs, and then a separate file somewhere that says where those libraries are on this particular machine. But I don't know if MSBuild has anything remotely like that.
(Obviously, as well as the header files, we have exactly the same problem with the linker needing to find the object code to link in.)
It seems you can in fact fix this using environment variables. Either through the Visual Studio user interface itself, or just by editing the *.vcxproj file in a text editor, edit the include path from
D:\Libraries\Boost\32bit\include;D:\Libraries\GTest\32bit\include
to instead be something like
$(BOOST_ROOT)\include;$(GTEST_ROOT)\include
Now the project builds on any machine where the environment variable %BOOST_ROOT% is set to the right folder path. (And likewise for %GTEST_ROOT%.)
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.
I'm trying my first program in this particular environment and it seems unnecessarily complicated.
I've written a header file xxxx.h and a C++ file xxxx.cpp but there doesn't appear to be an option to compile this (where I would expect it to be in the toolbar, the run and/or compile options are greyed out and unavailable).
What am I doing wrong? Maybe I haven't saved these files in the right place or I don't know where they should have been written/created.
I know nothing about this compiler/editor so there may be loads of things that are obvious to an experienced programmer which I'm just not aware of. Do the .h and .cpp files need to be part of a project which ultimately gets compiled? If so, how do I make these files part of that project?
I feel like I couldn't even write a "Hello World" program in this environment with my current knowledge. Please help.
The IDE(Environment) might require you to make it a project type. If you can't find help or instructions in the program itself, please try the following:
select file, then new. In the drop down box, select project and just read through whatever comes up and click OK. Now, you might already have a .cpp file opened by default. If you do, you are lucky, just type your code in, and you will be able to compile it. Otherwise you have to make a new .cpp file within the project using the project window.
Please bear in mind that I'm saying this with experience only form similar IDEs, not your particular one. If you are a beginner, then probably Borland C++ IDE will be better for you. Not the embarcadero one, the older versions used in the 1998-99 period. Hope this helps. Thanks.
Just a nooby question, but I was wondering that every time I use g++ from MinGW on a Windows 8.1 command prompt, do I always have to change directories to compile it? This gets very tedious for me at least because I like to keep different assignments in folders, and cd'ing all of that address kind of gets me a little annoyed.
I've seen my professor on his Linux machine that he doesn't need to change directories and just compiles the program as he finishes writing the program.
Right now my Environment Variables are set to ...;C:\MinGW\bin;%PATH% Do I need to add anything more to this or do I have to move all my files into a certain destination? I've also tried Cygwin, but that keeps giving me errors and the other answers on this site are very confusing. In fact every answer on this site has been kind of hard to comprehend... is there a dictionary that I should be looking before I read one of the posts?
Sorry!
We are migrating our works repository so I want to do a cull of all the unreferenced files that exist in the source tree before moving it into the nice fresh (empty) repository.
So far I have gone through by hand and found all the unreferenced files that I know about but I want to find out if I have caught them all. One way would be to manually move the project file by file to a new folder and see what sticks when compiling. That will take all week, so I need an automated tool.
What do people suggest?
Clarifications:
1) It is C++.
2) The files are mixed. I am looking for files that have been superseded by others but have left to rot in the repository - for instance file_iter.h is not referenced by any other file in the program but remains in the repository just in case someone wants to compile a version from 1996! Now we are moving to a fresh repository we can safely junk all the files that are no longer used.
3) Lint only finds unused includes - not unused files (I have the 7.5 manual in front of me).
You've tagged this post with c++, so I'm assuming that's the language in question. If that's the only thing that's in the repository then it shouldn't be too hard to grep all files in the repository for each filename to give you a good starting point. If the repository contains other files (metadata, support files, resources, etc) then you're probably going to need to do it manually.
I can't offer an existing tool for it, but I would expect that you can get a lot of this information from you build tools (with some effort, probably). Typically you can at least let the build tool print the commands it would run, without actually running them. (E.g. the -n option of make and bjam does this.) From it you should be able to extract at least the used source files.
With the -MM of g++ you can get all the non-system header files for the given source files. The output is in the form of a make rule, but with some filtering this shouldn't be a problem.
I don't know if this helps; it's just what I would try in your situation.
You can actually do this indirectly with Lint by running a "whole project analysis" (in which all files are analysed together rather than individually).
Configure it to ignore everything but unreferenced variable/enum/function etc warnings and it should give you a reasonable indicator of where the deadwood lies without those issues being obscured by any others in the codebase.
A static source code analysis tool like lint might do the job. They will tell you if a piece of code will never be called.
Have you taken a look at Source-Navigator? It can be used as an IDE but I found to be very good at analyzing source code structure. For example, it can find out where and if a certain method is used in your source code.
I don't know if it's scriptable but it might be a good starting point for you.