Re: problem with output of the program on different OS
- From: Richard Heathfield <rjh@xxxxxxxxxxxxxxx>
- Date: Sat, 10 May 2008 12:24:42 +0000
pereges said:
What text editors do you personally prefer while working
on linux ?
vim
What about vi ?
On my machine, 'vi' is an alias for 'vim'.
On windows machine, I use Qeditor
gvim
<snip>
And it would
not hurt to initialise index to -1 at this stage. If it remains -1 after
the loop, the original program was clearly assuming that the loop was
always setting this value,
<snip>
I think this is not the problem.
Your code has many problems. This may be one of them.
It is possible that index will be -1
for many rays and its perfectly normal. The index value is just there
to indicate which triangle the ray has hit. It is possible that the
ray does not hit any triangle. I have a member in the intersectresult
data structure called 'hit'. If the ray does not hit any triangle,
then hit will remain FALSE. index will probably contain some garbage
value.
In your original code, its value is indeterminate under those
circumstances, and evaluating an indeterminate value means undefined
behaviour. It's almost certainly not causing your problem, but "almost
certainly" != "certainly"! Fix all the bugs, not just the ones that you
think are important. By all means fix the important ones first, but don't
ignore things you know are wrong but guess aren't a problem - your guess
could be wrong.
You asked for hints on coding style, and that's one of them - *always* make
sure that a value is determinate before accessing it.
But that's irrelevant
That's a guess, and it could be a wrong guess.
<snip>
Second fix to this file: in the raytrace() function, i is unused, so I
removed it.
Do you think its dangerous to have such declarations in bigger
projects ?
No, but I think it's poor style. The less code you have, the less code you
have to read and understand. Removing dead code is good housekeeping, and
will leave you with less clutter to wade through. This makes your life
easier.
Well, I had to dig through three layers of #include before finding an
include for math.h. Not funny. Still, it's there somewhere.
My idea was to have such declarations at one place. Hence, I included
it in common.h.
That's not a new idea, but whether it's a /good/ idea is a matter of
opinion. Some people, no doubt, will agree with you about this. Maybe even
some experts will agree with you about this. Personally, I'd rather see
the standard headers included in the source where they're needed.
Otherwise, the reader has to either trust that you've remembered to
include them or go looking to make sure. Neither is comfortable.
<snip>
I recommend that you plug this version in, and re-test. Do any of the
assertions fail? If so, that may well be your problem.
Yes, there is some problem while compiling radar.c.
The problem is with the assert(*numpoints >= 0) statement on line
number 32 of radar.c as reported by pellesC compiler:
Building radar.obj.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
warning #2130: Result of unsigned comparison is constant.
Oh, it's unsigned long *. I didn't notice that. Fair enough - the assertion
is unnecessary in that case, since *numpoints can't be negative. So /that/
assertion can be removed.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
fatal error: Internal error: 'Access violation' at 0x004083f3.
Interesting. That suggests that the pointer is NULL or indeterminate. But
it can't be NULL because I inserted a check: assert(numpoints != NULL);
So it must be a bad pointer. Check the calling code.
<snip>
BartC has obtained similar results using the PellesC compiler but he
is getting different result when using dmc, lccwin, gcc on
windows( all the three results using dmc, lccwin, gcc are same though
for the above input). Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.
--
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
.
- Follow-Ups:
- References:
- problem with output of the program on different OS
- From: pereges
- Re: problem with output of the program on different OS
- From: Bart
- Re: problem with output of the program on different OS
- From: pereges
- Re: problem with output of the program on different OS
- From: Richard Heathfield
- Re: problem with output of the program on different OS
- From: pereges
- Re: problem with output of the program on different OS
- From: Richard Heathfield
- Re: problem with output of the program on different OS
- From: pereges
- problem with output of the program on different OS
- Prev by Date: Re: c program
- Next by Date: Re: unrolling nested for-loop
- Previous by thread: Re: problem with output of the program on different OS
- Next by thread: Re: problem with output of the program on different OS
- Index(es):
Relevant Pages
|