how to organize my main file ?

[pereges]

By main file, I mean the one which contains the main routine. Can some
one please provide suggestions as to how I can improve the
organization of main file ? I have just though about a rough skeleton.

In my ray tracing project, I have to carry out following task (in
sequence)

1. Read the mesh from an ascii file and store it in the mesh data
structure.
2. Create a ray list and store it in a ray list.
3. Create the binary space partitioning tree for fast mesh traversal.
4. Trace all the rays and calculate the scattered and incident
electric fields.

I'm thinking of writing a function for every task.

#include "main.h"

static mesh *m; /* pointer to the mesh */
static bsptree *tree; /* pointer to the bsp tree */
static ray *raylist; /* pointer to the ray list */

/* function prototypes */

int read_mesh(char *);
int init_plane_wave (void);
int create_bsp_tree (void);
int calc_e_fields (void);
/* Provide the name of the ascii file(from which mesh is to be read)
as a command line argument eg. main sphere.dat */

int main(int argc char *argv[])
{
if(argc < 2)
{
fprintf(stderr, "Insufficie nt argumens\n");
return -1;
}

if(argc 2)
{
fprintf(stderr, "Too many arguments\n");
return -1;
}

if(read_mesh(ar gv[1])
return -1;
if(init_plane_w ave())
return -1;
if(create_bsp_t ree())
return -1;
if(calc_e_field s())
return -1;

return 0;
}

/* I decided to make the above data structures as static global
because they are needed throughout the program */

int read_mesh(char *filename)
{
FILE *fp;

fp = fopen(filename, "r");
if(fp == NULL)
{
fprintf(stderr, "Error while opening the file %s\n", filename);
return -1;
}
m = malloc(sizeof *m);
if(m == NULL)
{
fprintf(stderr, "Couldn't allocate memory for the mesh\n");
return -1;
}
/* parse_dat_file returns -1 if error occured while parsing file */
if(parse_dat_fi le(fp, &m))
return -1;
}

/* This function will initiailize the plane as in read the
specification related to a plane wave like frequency, electric field
at reference point, direction of the plane wave etc. It will allocate
memory for the ray list. After this it will call init_rays which
initializes a set of parallel rays. A plane wave is being simulated by
a dense grid of parallel rays */

int init_plane_wave (void)
{
...
...
}

/* This function will read the maximum allowable depth for the tree ,
allocate memory for it*/

int create_bsp_tree (void)
{

}

/* This function will call the raytrace function and after that it
will perform some calculations to find out the scattered and incident
electric fields */

int calc_e_fields (void)
{

}

[pereges]

I have another question: Is it ok to write a function to destroy all
the objects(Its not just a simple 'free' call btw, there are lists
within objects which must be destroyed first)

[Walter Roberson]

In article <66************ *************** *******@y22g200 0prd.googlegrou ps.com>,
pereges <Br*****@gmail. comwrote:

>I have another question: Is it ok to write a function to destroy all
the objects(Its not just a simple 'free' call btw, there are lists
within objects which must be destroyed first)

Sure, why not? As long as the objects are dynamically allocated, that is.
--
"MAMA: Oh--So now it's life. Money is life. Once upon a time freedom
used to be life--now it's money. I guess the world really do change.
WALTER: No--it was always money, Mama. We just didn't know about it."
-- Lorraine Hansberry

[Mike Wahler]

"pereges" <Br*****@gmail. comwrote in message
news:3d******** *************** ***********@z24 g2000prf.google groups.com...

So, EXIT_FAILURE and EXIT_SUCCESS can be used in any function other
than main.

That's not what I said, but they could be. They are
intended to be used to communicate a program's completion
status (i.e. success or failure) to the host system, thus
typically used only with 'main()' or 'exit()'. I've never
seen them used for anything else, but that doesn't mean
someone never did. :-)

Mostly I have seen that they are not used outside main.

True.

-Mike

[Mike Wahler]

"pereges" <Br*****@gmail. comwrote in message
news:5c******** *************** ***********@c19 g2000prf.google groups.com...

On Jun 17, 11:12 pm, santosh <santosh....@gm ail.comwrote:

>I assume you will be calling such a function either just before program
termination or after a major task has been completed.

just before the termination. The last function to be called.

>As long as it
does not free memory still in use, or try to free nonexistent memory,
it should be functionally okay. Whether such a strategy will suit your
application depends on many other factors.

like for eg. ? mine is a pretty straight forward numerical computation/
simulation program. I was also wondering what is the point in freeing
the dynamic memory just before the program terminates because the
objects will be destroyed once the program terminates anyways.

Most modern operating systems will indeed reclaim allocated memory
upon termination of an application, but the language does not
guarantee this (it cannot, since C can be implemented on a platform
with no OS ('free-standing implementation' ). IMO the best practice
is to do as my mother used to tell me, "put things back the way you
found them." IOW if you allocate a resource, free it when you're done.

-Mike

[santosh]

pereges wrote:

[ ... ]

I was also wondering what is the point in freeing
the dynamic memory just before the program terminates because the
objects will be destroyed once the program terminates anyways.

It will reduce the number of false positives that memory checkers like
Valgrind will report. It's also better form, even though it may not be
necessary under modern operating systems.

[Malcolm McLean]

"pereges" <Br*****@gmail. comwrote in message
news:66******** *************** ***********@y22 g2000prd.google groups.com...

>I have another question: Is it ok to write a function to destroy all
the objects(Its not just a simple 'free' call btw, there are lists
within objects which must be destroyed first)

Inital task:
1. Read the mesh from an ascii file and store it in the mesh data
structure.
2. Create a ray list and store it in a ray list.
3. Create the binary space partitioning tree for fast mesh traversal.
4. Trace all the rays and calculate the scattered and incident
electric fields.

Do it like this

int main(int argc, char **argv)
{
MESH *mesh;
RAYLIST *raylist;
BSP *bsp;
IMAGE *img;

/* turn the ascii input file into a mesh */
mesh = createmesh(argv[1]) ;
if(!mesh)
{
fprintf(stderr, "Cannot create mesh\n");
exit(EXIT_FAILU RE);
}
/* create everything else we need */
raylist = creatraylist(me sh);
bsp = createbsp(mesh, raylist);
img = createimage(102 4, 1024);

/* do the work here */
raytrace(img, raylist, bsp);

saveimage(img, "image.bmp" );
/* destroy everything */
killimage(img);
killbsp(bsp);
killraylist(ray list);
killmesh(mesh);

return 0;
}

Your main function creates all the objects you need, prints out an error
message if any of them fail, calls a high level function to do the work,
then destroys all the objects and returns. Other modules actually manage the
objects. Clearly the mesh and image objects are highly reusable. Only you as
program designer know exactly what goes in the "raylist" and binary
separating tree, and how these objects are passed to the renderer. However
the scope for design is reduced to these three highly specific modules.

In a real program you also need to print out a usage message, and probably
parse some options. This adds only a bit of complexity to main().

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Tor Rustad]

pereges skrev:

By main file, I mean the one which contains the main routine. Can some
one please provide suggestions as to how I can improve the
organization of main file ? I have just though about a rough skeleton.

In my ray tracing project, I have to carry out following task (in
sequence)

1. Read the mesh from an ascii file and store it in the mesh data
structure.
2. Create a ray list and store it in a ray list.
3. Create the binary space partitioning tree for fast mesh traversal.
4. Trace all the rays and calculate the scattered and incident
electric fields.

I'm thinking of writing a function for every task.

I assume, you have no need for sophisticated error handling, then there
is no need to propagate error codes all over the place, just log error
and die.

So, this would be my initial main:

#include <stdio.h>
#include "ray_track. h"

int main(int argc, char *argv[])
{
struct ray_track rt;

ray_open( &rt, argc, argv);
ray_fload_mesh( &rt, fname_mesh);
ray_create_rayl ist (&rt);
ray_create_bsp_ three(&rt);
ray_calc_scatte ring (&rt);
ray_close(&rt);

return EXIT_SUCCESS;
}
The header file would look something like:
#ifndef RAY_TRACK_H
#define RAY_TRACK_H

struct ray_track
{
const char *fname_mesh;

struct mesh *mesh;
struct ray *raylist;
struct bsp_three *bsp_three;

/*! logging & error handlers */
void (*trace) (const char *msg);
void (*err_warn ) (int err, int line, const char *msg);
void (*err_fatal) (int err, int line, const char *msg);
};

/*! Ray track function prototypes */
void ray_open (struct ray_track *, int argc, char **argv);
void ray_create_mesh (struct ray_track *, const char *fname_mesh);
void ray_create_rayl ist (struct ray_track *);
void ray_create_bsp_ three (struct ray_track *);
void ray_calc_scatte ring (struct ray_track *);
void ray_close (struct ray_track *);

#endif /* !RAY_TRACK_H*/
--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[Richard Heathfield]

Mike Wahler said:

"pereges" <Br*****@gmail. comwrote in message
news:66******** *************** ***********@j33 g2000pri.google groups.com...

<snip>

>

>>I usually use

#define SUCCESS 0
#define FAILURE -1

Don't Do That. You've redefined standard macros.

Neither SUCCESS nor FAILURE is a standard macro.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pereges]

On Jun 18, 1:45 am, Tor Rustad <tor_rus...@hot mail.comwrote:

I assume, you have no need for sophisticated error handling, then there
is no need to propagate error codes all over the place, just log error
and die.

I do need a good error handling mechanism. Right now, I just check for
error condition and use fprintf to report the messages to stderr. It
tends to get a little verbose sometimes.

So, this would be my initial main:

#include <stdio.h>
#include "ray_track. h"

int main(int argc, char *argv[])
{
struct ray_track rt;

ray_open( &rt, argc, argv);
ray_fload_mesh( &rt, fname_mesh);
ray_create_rayl ist (&rt);
ray_create_bsp_ three(&rt);
ray_calc_scatte ring (&rt);
ray_close(&rt);

return EXIT_SUCCESS;

}

The header file would look something like:

#ifndef RAY_TRACK_H
#define RAY_TRACK_H

struct ray_track
{
const char *fname_mesh;

struct mesh *mesh;
struct ray *raylist;
struct bsp_three *bsp_three;

/*! logging & error handlers */
void (*trace) (const char *msg);
void (*err_warn ) (int err, int line, const char *msg);
void (*err_fatal) (int err, int line, const char *msg);

};

/*! Ray track function prototypes */
void ray_open (struct ray_track *, int argc, char **argv);
void ray_create_mesh (struct ray_track *, const char *fname_mesh);
void ray_create_rayl ist (struct ray_track *);
void ray_create_bsp_ three (struct ray_track *);
void ray_calc_scatte ring (struct ray_track *);
void ray_close (struct ray_track *);

#endif /* !RAY_TRACK_H*/

Can you please given an example of these three functions ? what are
they used for ? :

void (*trace) (const char *msg);
void (*err_warn ) (int err, int line, const char *msg);
void (*err_fatal) (int err, int line, const char *msg);

How to differentiate between a fatal error and a warning ?

[Mike Wahler]

"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:7N******** *************** *******@bt.com. ..

Mike Wahler said:

>"pereges" <Br*****@gmail. comwrote in message
news:66******* *************** ************@j3 3g2000pri.googl egroups.com...

<snip>

>>

>>>I usually use

#define SUCCESS 0
#define FAILURE -1

Don't Do That. You've redefined standard macros.

Neither SUCCESS nor FAILURE is a standard macro.

Oops. Now I'm seeing things. :-)

-Mike