"Elie Nader" <elienader@sympatico.ca> wrote in message news:<5MBxb.20525$dt2.1539663@news20.bellglobal.co m>...[color=blue]
> "mescaline" <apt2003@columbia.edu> wrote in message
> news:e54f0744.0311271653.722a9205@posting.google.c om...[color=green]
> > Hi,
> >
> > Suppose a_file.cpp contains a function a_function()
> > Now to include it in main_file.cpp I just do #include "a_file.cpp" and
> > I'm all set.
> >
> > i recently came across this seemingly roundabout way to do this in 3
> > steps:
> >
> > 1. Add in main_file.cpp
> > #include <a_file.h>
> >
> > 2. Then in a_file.h :
> >
> > #ifndef A_FILE_H
> > #define A_FILE_H
> > double a_function();
> > #endif
> >
> > 3. Finally in a_file.cpp:
> >
> > #include <a_file.h>
> > double a_function(){ actual implementation of the function...}
> > ------------------------
> > My questions:
> > 1. First, I cannot get this new method to work!
> > I have these three files. Then when I compile main_file.cpp, i get
> > the message: a_file.h not found. Why does this happen?
> > Note that I'm using the plain g++ compiler here and all files are
> > in one directory (call it direct1). The book i read this method is
> > slightly unclear on
> > where I should include all 3 files in the same directory ...or
> > somewhere else...
> >
> > 2. What is the use of such a roundabout way?
> > The a_file.h seems only to be a book-keeping file. I understand HOW
> > this new method works but do not get the MOTIVATION behind this
> > apparently roundabout method -- has it got anything to do with
> > reusability or something else?
> >
> > Thanks for your answers,
> > m[/color]
>
> obviously, the code that you typed will not work for a very simple reason:
> #include <something> is used for libraries defined in C++.
> #include "A_file.cpp"
> #include "A_file.h" are used to user defined files.
> so?...you cannot include files the same way that you include libraries.
> i.e., you can't #include <A_file.cpp>
>
> the reason we split the codes this way has two dimensions;
> the first was very well explained by "David F"
> the second reason; business wise,
> say you have implemented a file for a virtual car that will be used a game.
> and you worked on this file for 1 full year. You sold this file for a
> company. now the question!! are you gonna give the company full access to
> the whole code that you worked on? they might re-use your code.
> they might modify it, and then re-sell it.....hummm...so what to do?
> you create a header file including all the function of the car, like
> acceleration, brake, turn left, turn right...and then, in an encrypted file,
> you will put all the implementation.
> in this way, you are sure that no one will mess with YOUR code.
> conclusion, this roundabout way that you didn't like will protect you file
> from being stolen AND will make it easier to change any variable in it.[/color]
You got some good information, some bad information.
The use of angle brackets around an include filename tells the system
to look for the file in the "system" directories. The use of quotes
around an include filename tells the system to first look at files in
user-defined directories, and if not found then look in the "system"
directories. These directories are defined by -I flags on the command
line (which I take it you are not using). If your files are in some
other directory (as is likely: the one you are developing in) you
would need to add a parameter to the compile command line to include
the development directory in the search list defined by the -I flag.
Alternatively, you can include the full path to your user directory in
the include statement. If you were developing in the directory
E:\mystuff you would code the include as follows:
#include "E:\mystuff\a_file.h"
The reasons for separating the header file from the source are
correct. It allows distribution of the functions by shipping the
header file and an object file containing the code -- but not
releasing the source.
--
Gary
