"breaking up" your application

Reply

Join Date: Nov 2006
Posts: 202
Reputation: n.aggel is an unknown quantity at this point 
Solved Threads: 10
n.aggel's Avatar
n.aggel n.aggel is offline Offline
Posting Whiz in Training

"breaking up" your application

 
0
  #1
Nov 20th, 2007
hi lets say you have a big application and you want to break it up to many files... The ideal would be if you can have the application in one .c {i.e main.c} file your types and includes in another file {types.h} and your functions in a seperate file {functions.c} and their declarations in their own header file{i.e. functions.h}.... So we have these files for a simple application:

types.h
  1. //here i would also put all the includes my main application needs
  2. //i am not sure this is a good practise...
  3.  
  4.  
  5. //let tA be a seperate type...
  6.  
  7. typedef int tA;

func.h
  1. #include "func.c"
  2.  
  3. #ifndef FUNC_H
  4. #define FUNC_H 1
  5.  
  6. void fadd(tA, tA);
  7.  
  8. #endif

func.c
  1. void fadd(tA x, tA y)
  2. {
  3. printf("%d\n", x+y);
  4. }

main.c
  1. #include <stdio.h>
  2. #include "func.h"
  3. #include "types.h"
  4.  
  5. int main()
  6. {
  7. tA a=5;
  8. tA b=6;
  9.  
  10. fadd(5,6);
  11.  
  12. return 0;
  13. }

i think that the benefit from this seperation would be:: extra readability + being able to alter the main application without recompiling the functions{just relink them} or alter the functions without recompiling the application{just re-link}....

The problem is that i can't get the seperation to work...and i haven't been able to find a source to address this problem...
Two roads diverged in a wood, and I— I took the one less traveled by, and that has made all the difference.

by Robert Frost the "The Road Not Taken"
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,851
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 749
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: "breaking up" your application

 
0
  #2
Nov 20th, 2007
1. Don't #include C files, otherwise you end up with "multiply declared" errors from the linker.

2. If you have multiple source files, as in this example, the command line would be something like
gcc main.c func.c In an IDE environment, you would add the two source files to your project.

3. func.c would include func.h, so that when func.c is compiled, the prototype and definition get checked.

4. func.h needs types.h, for the prototype.

Splitting things up is one of those easy things which comes with practice.
Having some design ideas sketched out to being with will give you a lot of ideas on how the various modules will be structured and the interfaces between them.
Reply With Quote Quick reply to this message  
Join Date: Dec 2006
Posts: 1,089
Reputation: vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all 
Solved Threads: 164
vijayan121 vijayan121 is offline Offline
Veteran Poster

Re: "breaking up" your application

 
0
  #3
Nov 20th, 2007
one of the great classics of c++ deals with this topic in depth; 'Large-Scale C++ Software Design' by John Lakos. http://www.amazon.com/Large-Scale-So.../dp/0201633620

'More C++ Gems' by Stanley Lippman (F), Robert C. Martin (E) http://www.amazon.com/More-Gems-SIGS...745891-8300801 has three articles by John Lakos. these are a compact version of his seminal work.

note: the book is dated as far as c++ standards go; the issues it deals with are timeless.
Reply With Quote Quick reply to this message  
Join Date: Nov 2006
Posts: 202
Reputation: n.aggel is an unknown quantity at this point 
Solved Threads: 10
n.aggel's Avatar
n.aggel n.aggel is offline Offline
Posting Whiz in Training

Re: "breaking up" your application

 
0
  #4
Nov 20th, 2007
thank you for your replies and for the book recommendations{because frankly i haven't bumped in a book that treats this subject}... the problem is that i am in greece so the books are a bit hard to find{i must order from amazon}... so i would like some more help...

I don't use an IDE and my goal is to learn how to do this code "break up" in order to build a makefile...

from i what i understood i made the following changes:::
types.h
  1. //here i would also put all the includes my main application needs
  2. //i am not sure this is a good practise...
  3.  
  4. #ifndef TYPES_H
  5. #define TYPES_H 1
  6. //let tA be a seperate type...
  7.  
  8. typedef int tA;
  9.  
  10. #endif

func.h
  1. #include "types.h"
  2.  
  3. #ifndef FUNC_H
  4. #define FUNC_H 1
  5.  
  6. void fadd(tA, tA);
  7.  
  8. #endif

func.c
  1. #include "func.h"
  2. #include "types.h"
  3. #include <stdio.h>
  4.  
  5. void fadd(tA x, tA y)
  6. {
  7. printf("%d\n", x+y);
  8. }

main.c
  1. #include <stdio.h>
  2. #include "func.h"
  3. #include "types.h"
  4.  
  5. int main()
  6. {
  7. tA a=5;
  8. tA b=6;
  9.  
  10. fadd(5,6);
  11.  
  12. return 0;
  13. }

i compile using gcc main.c func.c

what i can't uderstand is the following::

1) if i include in func.c the file func.h and then in my main application i include the func.h file where does the compiler know where to look for the function definition {there is no link to func.c}

2) is it possible to avoid certain inclusions for example the types.h is included both in func.h and both func.c

3)if i make a makefile i would have a rule for the func.c and another rule for the main.c {which would have as a dependecy the rule for func.c}?

Originally Posted by salem
Splitting things up is one of those easy things which comes with practice.
i imagine your are right, the problem is that i haven't found any solid examples to learn from... so everytime i make a programming project{2-3 times so far--i am new!}, it takes time to find the "correct" split...and basically it comes from trial and error so this time i decided to settle with this problem once and for all...

thanks again for your posts,
nicolas
Two roads diverged in a wood, and I— I took the one less traveled by, and that has made all the difference.

by Robert Frost the "The Road Not Taken"
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,851
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 749
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: "breaking up" your application

 
0
  #5
Nov 20th, 2007
> where does the compiler know where to look for the function definition
The compiler doesn't. It only needs to know what things look like, not where they are. It's the linker (the next step, which is usually invisible) which combines everything together to produce a runnable program.

> is it possible to avoid certain inclusions for example the types.h is included both in func.h and both func.c
You can leave types.h out of func.h, but then you have to remember to include types.h in all the places that include func.h.
Whether or not this is a "good thing" is open to debate. On the one hand, it's very easy to see in any source file exactly what the dependencies are. On the other hand, if func.h suddenly needs stuff.h as well, then you have a massive edit job on your hands.

> if i make a makefile i would have a rule for the func.c and another rule for the main.c
There would be 3 rules
main.o depends on main.c (and some headers)
func.o depends on func.c (and some headers)
prog.exe depends on main.o and func.o

> i compile using gcc main.c func.c
Try
gcc -v main.c func.c And you'll see all the steps which the compiler goes through.

When you do this via a makefile, it will look something like this
gcc -c main.c
gcc -c func.c
gcc -o prog.exe main.o func.o
You can even type these by hand (with -v if you want) to see what happens.
Reply With Quote Quick reply to this message  
Join Date: Nov 2006
Posts: 202
Reputation: n.aggel is an unknown quantity at this point 
Solved Threads: 10
n.aggel's Avatar
n.aggel n.aggel is offline Offline
Posting Whiz in Training

Re: "breaking up" your application

 
0
  #6
Nov 21st, 2007
thanks for all the details ... One last question if i have some globals {i.e. a file pointer} that they are used in main and in some of the functions, where is the right place to put them...Is it the types.h or somewhere else?
Two roads diverged in a wood, and I— I took the one less traveled by, and that has made all the difference.

by Robert Frost the "The Road Not Taken"
Reply With Quote Quick reply to this message  
Reply

This thread is more than three months old.
Perhaps start a new thread instead?
Message:


Thread Tools Search this Thread



About Us | Contact Us | Advertise | DaniWeb | Acceptable Use Policy | RSS Feed

©2003 - 2009 DaniWeb® LLC