Suppose I have the following:
*****************************************
//file main.cpp
struct point {double x; double y;}; //...Structure def
point assign_pts(double x, double y); //...Fcn prototype
// Main function:
int main
{
double x1 = 2.5;
double y1 = 3.5;
point p1 = assign_pts(x1,y1);
)
// Other functions:
point assign_pts(double x_, double y_)
{
point q;
q.x = x_;
q.y = y_;
return q;
}
// End of file main.cpp
********************************************
Ok, now if I want to move the function "assign_pts" into a separate file
(eg. "other_fcns.cpp") rather than defining it in "main.cpp", do I
also need to create a header file (eg "other_fcns.h") for the structure
definition (point) so I can "include" that at the top of
"other_fcns.cpp" file? I ask because I tried it without the header and
got an error (saying point wasn't defined in that scope). So I think I
need the header to resolve that, but I thought I had seen examples
where that wasn't needed.
Thanks for any help. -Pat
<snip>
> Ok, now if I want to move the function "assign_pts" into a separate
> file
> (eg. "other_fcns.cpp") rather than defining it in "main.cpp", do I
> also need to create a header file (eg "other_fcns.h") for the
> structure definition (point) so I can "include" that at the top of
> "other_fcns.cpp" file?
Yes. You will also want to put the function prototype for assign_pts
into the same header:
#ifndef HPP_OTHER_FCNS
#define HPP_OTHER_FCNS 1
struct point
{
double x;
double y;
};
point assign_pts(double x, double y);
#endif
Then #include that header in main.cpp and other_fcns.cpp.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Missing a ()?
> {
> double x1 = 2.5;
> double y1 = 3.5;
>
> point p1 = assign_pts(x1,y1);
> )
>
> // Other functions:
> point assign_pts(double x_, double y_)
> {
> point q;
> q.x = x_;
> q.y = y_;
>
> return q;
> }
>
> // End of file main.cpp
> ********************************************
>
> Ok, now if I want to move the function "assign_pts" into a separate file
> (eg. "other_fcns.cpp") rather than defining it in "main.cpp", do I
> also need to create a header file (eg "other_fcns.h") for the structure
> definition (point) so I can "include" that at the top of
> "other_fcns.cpp" file? I ask because I tried it without the header and
> got an error (saying point wasn't defined in that scope). So I think I
> need the header to resolve that, but I thought I had seen examples
> where that wasn't needed.
Short answer, yes, because you are returning an instance of point and
the compiler has to be able to figure out how big it is.
Just off the top of my head, with not enough whitespace maybe something
like:
However, I suspect you'd be better off writing a ctor for Point:
file point.h
--------------------------------------
#ifndef POINT_H_
#define POINT_H_
struct Point {
double x, y;
Point(const double xArg, const double yArg);
};
#endif
and file point.cpp
--------------------------------------
#include "point.h"
Point::Point(const double xArg, const double yArg)
: x(xArg), y(yArg)
{}
and then in main.cpp
...
Point p1(x1,y1); // or whatever.
...
LR
Ok. That's what I thought. Thanks.
Now for a slightly more complicated case. What if I had multiple *.cpp
files that each contained functions using the structure "point". Would
I just include the one header file (that contains the declaration for
point) in each of those? If so, then I assume that means the name of
the header file is arbitrary (ie does not need to match the name of
function file as I had showed above). Is that right?
Also, what about the function prototypes -would all of those need to be
listed in the header as well (even if some of the files didn't require
certain functions)?
Yes, my bad!
Ok. So define the structure like you would a class. Does that make the
structure easier to reference in other files (ie do you still need to
write a header file, etc)?
> Now for a slightly more complicated case. What if I had multiple *.cpp
> files that each contained functions using the structure "point". Would
> I just include the one header file (that contains the declaration for
> point) in each of those?
Yes.
> If so, then I assume that means the name of
> the header file is arbitrary (ie does not need to match the name of
> function file as I had showed above). Is that right?
It doesn't have to match. You could have a file called large.h that has
a function prototype for small(). But that gets confusing.
> Also, what about the function prototypes -would all of those need to be
> listed in the header as well (even if some of the files didn't require
> certain functions)?
Typically related prototypes go together and separate include files
aren't tailor made for each cpp file. As always there are some
exceptions to this for various reasons.
LR
> Ok. So define the structure like you would a class. Does that make the
> structure easier to reference in other files (ie do you still need to
> write a header file, etc)?
You still need a header file.
Easier is a bit more difficult to answer in this case. I think using
ctor is more idiomatic and probably has a little less overhead, if
that's important.
Personally, I think that
Point p1(x1,y1);
is easier to read than,
Point p1 = assign_pts(x1,y1);
But perhaps I don't understand why you want assign_pts to be a function
at all when a ctor would probably be better.
LR
<snip>
> Now for a slightly more complicated case. What if I had multiple
> *.cpp files that each contained functions using the structure
> "point".
> Would I just include the one header file (that contains the
> declaration for point) in each of those?
Yes. Think of foo.cpp as being the implementation of <whatever it is>,
and foo.hpp as being the interface. You should #include "foo.h" in
foo.cpp and in any other .cpp file that needs to call the functions,
or use the structures, that foo.cpp implements and foo.h declares.
> If so, then I assume that means the name
> of the header file is arbitrary (ie does not need to match the name
> of function file as I had showed above). Is that right?
The name is arbitrary as far as the language is concerned. But there's
a good reason why they call the new primary school - you know, the
one on Wheat Street - Wheat Street Primary School rather than Maize
Street Primary School. They want people to be able to find it easily.
> Also, what about the function prototypes -would all of those need to
> be listed in the header as well (even if some of the files didn't
> require certain functions)?
Publish all the information that needs to be public. Needs change. A
module that doesn't need access to point_foo() today may well need it
tomorrow. If other modules are already using point_foo(), then
there's no point in hiding its declaration from one particular
module.
The best thing you can do is read up in a textbook how to declare and
define classes (or structs if you want to use 'struct').
Find out what to put in the .h file, and what in the .cpp and how to use
a guard (#ifndef POINT_H ...) in the .h.
From your earlier messages, you need a Point class and you'd better
bite the bullet and learn how to make one and how to use it.
Before, you mentioned that you had three textbooks; what are they? Get
some of the experts here to recommend a good textbook and work your way
up to the chapter on classes. Apart from a learning textbook, I'd advise
you to have Stroustrup, C++ Programming Language --- as a reference. I
say that because I think that, in spite of the great advice you are
getting from others, progress towards your goal seems rather sporadic.
An incidental, maybe covered before (but certainly covered recently on
comp.programming, though in a rather long-winded manner) ... strictly it
does not make sense to add Points, nor multiply them by a scalar. Those
are Vector operations. A Point can be defined as the result of adding a
Vector (a displacement) to a chosen reference Point called the Origin.
Vector + Vector -> Vector;
scalar*Vector -> Vector;
Point + Vector -> Point;
You may get away with your model of Point, but I mention this because
the problem may come back to bite you at some time.
>
> // Main function:
Another incidental, comments like this and those above are not worth the
space they occupy. Choose your class, function, and variable names well
and you can minimise the need for comments.
Best regards,
Jon C.
--
Jonathan Campbell www.jgcampbell.com BT48, UK.
Actually, I have done everything you mentioned above, and have a "point"
class that I developed. What I posted above (with the point structure)
was just meant as simple example to base my question on. I wasn't
certain whether structure or class declarations needed to be provided to
every file that used them (I now know that they do).
> Before, you mentioned that you had three textbooks; what are they? Get
> some of the experts here to recommend a good textbook and work your way
> up to the chapter on classes. Apart from a learning textbook, I'd advise
> you to have Stroustrup, C++ Programming Language --- as a reference. I
> say that because I think that, in spite of the great advice you are
> getting from others, progress towards your goal seems rather sporadic.
The three texts I have are:
1. "You Can Program in C++" by F. Glassborow.
2. "Accelerated C++" by Koenig and Moo.
3. "C++ Primer Plus" by Prata.
(3) is the most detailed of the bunch, and the one I've been referring
to the most. Between those and info available on the web, I've been
able to answer most of my questions. But to be honest, sometimes it's
just easier to post the question than try to dig it out of a book (ref 3
is almost 1200 pages!).
>
> An incidental, maybe covered before (but certainly covered recently on
> comp.programming, though in a rather long-winded manner) ... strictly it
> does not make sense to add Points, nor multiply them by a scalar. Those
> are Vector operations. A Point can be defined as the result of adding a
> Vector (a displacement) to a chosen reference Point called the Origin.
>
> Vector + Vector -> Vector;
>
> scalar*Vector -> Vector;
>
> Point + Vector -> Point;
>
> You may get away with your model of Point, but I mention this because
> the problem may come back to bite you at some time.
Yes, technically you're right. But conceptually it's convenient for me
to think of them as points since my code is modeling 2D closed profiles
and the points represent "keypoints" of the line and arc elements that
make up a profile. Mathematically though, they're treated like 2D
vectors, and my "point" class includes operations for vector addition,
subtraction, multiplication (dot product), and multiplication/division
by a scalar. These operations a useful in computing profile points as
it avoids a lot a messy trig relations. I probably could have used the
Vector template to do this also, but it wasn't that hard to write the
class myself and proved to be a good learning exercise. :^)
Thanks for the feedback. I may tried to find that discussion on vectors
that you mentioned above.
Pat
Actually, I don't. That point structure was just meant to be a simple
example to base my question (on header files) on. What I'm actually
using for this is a point class (with constructors, etc) similar to what
you show.
Most of my programs have been single file (or a couple of small files)
up until now, so I still had some gaps in my understanding of how to
handle the multi-file case. But between the responses I've received on
this, and additional reading I've done, I think I now understand how it
works.
Thanks for your help.
Pat
class something; // declares 'something' as a type name
something & foo();
Is fine. But the .cpp file in which foo is defined almost certainly will
need to see the definition of 'something.'
>
>
>> Before, you mentioned that you had three textbooks; what are they? Get
>> some of the experts here to recommend a good textbook and work your
>> way up to the chapter on classes. Apart from a learning textbook, I'd
>> advise you to have Stroustrup, C++ Programming Language --- as a
>> reference. I say that because I think that, in spite of the great
>> advice you are getting from others, progress towards your goal seems
>> rather sporadic.
>
> The three texts I have are:
>
> 1. "You Can Program in C++" by F. Glassborow.
> 2. "Accelerated C++" by Koenig and Moo.
> 3. "C++ Primer Plus" by Prata.
The last of those is a little unfortunate. I would have suggested the
latest edition of 'The C++ Primer' by Stan Lippman, Josee Lajoie and
Barbara Moo (with Andrew Koenig lurking in the background). It is
authoritative and well written. The book was originally written by Stan
Lippman who has a wealth of understanding of the practical use of C++.
In the 3rd edition Josee Lajoie joined in and added more quality to an
already good book. Finally Barbara Moo (and outstanding programmer and
writer as well as Andrew Koenig's partner) was added to the mis for the
4th edition. You would have to go a long way to match the overall
quality of this book (though perhaps Bjarne Stroustrup's Programming:
Principles and Practice using C++ might qualify as just such a book.)
So are you saying the file which contains the line
something & foo();
would not need a header file referencing the declaration of the class
"something"? I wouldn't have guessed that, if so, but good to know.
Thanks.
>>
>>
>>> Before, you mentioned that you had three textbooks; what are they?
>>> Get some of the experts here to recommend a good textbook and work
>>> your way up to the chapter on classes. Apart from a learning
>>> textbook, I'd advise you to have Stroustrup, C++ Programming Language
>>> --- as a reference. I say that because I think that, in spite of the
>>> great advice you are getting from others, progress towards your goal
>>> seems rather sporadic.
>>
>> The three texts I have are:
>>
>> 1. "You Can Program in C++" by F. Glassborow.
>> 2. "Accelerated C++" by Koenig and Moo.
>> 3. "C++ Primer Plus" by Prata.
>
> The last of those is a little unfortunate. I would have suggested the
> latest edition of 'The C++ Primer' by Stan Lippman, Josee Lajoie and
> Barbara Moo (with Andrew Koenig lurking in the background). It is
> authoritative and well written. The book was originally written by Stan
> Lippman who has a wealth of understanding of the practical use of C++.
> In the 3rd edition Josee Lajoie joined in and added more quality to an
> already good book. Finally Barbara Moo (and outstanding programmer and
> writer as well as Andrew Koenig's partner) was added to the mis for the
> 4th edition. You would have to go a long way to match the overall
> quality of this book (though perhaps Bjarne Stroustrup's Programming:
> Principles and Practice using C++ might qualify as just such a book.)
Thanks for the suggestion. I'll definitely check it out (perhaps an
early Christmas present! ;^)
You need the declaration but not the definition of 'something'
class something;
is a declaration whereas
class something {
// whatever
};
is a definition. If you only use references or pointers to a type the
compiler only needs the declaration. I.e for these uses it only needs to
know that the name (something) is the name of a class.
In Ref. [1] separate compilation is first discussed on p. 104 (of
368). In Ref. [2] the same topic is discussed on pp. 66-67 (of 336).
Both books are relatively short (in relation to the C++ Primer or
Stroustrup's TC++PL - though the 4th edition of C++P is considerably
shorter than the 3rd one). Of course Refs. [1] & [2] do not cover all
aspects of C++, but one can learn many very important things in a
relatively straightforward manner. The main point is: for the average
beginner it is important to read introductory books linearly. Good
authors put a lot of effort into covering topics in an order that
makes sense.