Darren New <dne### [at] sanrrcom> wrote:
> http://www.kevinbeason.com/smallpt/

  A small pitty that it's not 100% standard C++, as erand48() is not part of
the standard (it's a glibc extension). OTOH, better use erand48() than rand(),
as the latter is just plain horrible in quality.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> 44:  double n=sizeof(spheres)/sizeof(Sphere);
> >>
> >> Well... that's... one way to figure out how big an array is. :-.
> > 
> > That's the usual way to figure out how big an array is in C and C++.

> It is surprising to me that this actually works. I was under the 
> impression that C does not actually distinguish between pointers and 
> arrays (and integers and booleans and...)

  There is a big difference between a pointer and an array in C (and hence
in C++).

  Basically each array is a type of its own, defined by the element type
and the number of elements. What makes an array distinctly a type of its
own is that sizeof() always returns the number of bytes that a type
requires when allocated in memory, and an array is no different: sizeof()
for an array returns the amount of bytes taken by the entire array. This
is drastically different from a sizeof() of a pointer, which will always
return 4 or 8 (depending on whether you are compiling a 32-bit or 64-bit
program).

  Since sizeof() of an array returns the total amount of bytes taken by
an array, if you divide it by the amount of bytes of one element, you get
the total number of elements.

  For example if in C++ you instantiate a template using an array as a
template parameter, a distinct instanstiation will be made for each specified
type and size of array.

  Of course what makes this confusing is that an array implicitly casts to
a pointer of the element type. In other words, wherever a pointer of the
element type is required, you can give an array of that type instead (there
will be an implicity cast to the pointer type).

  Also the syntax of indexing an array and indexing memory using a pointer
is identical, adding to the confusion.

  It can sometimes be difficult to distinguish between an array and a
const pointer (a pointer which cannot be changed to point somewhere else).
sizeof() is one thing which makes the distinction.

> >> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
> >> places, but I can't find a definitions.
> > 
> > Line 48. It's an argument to the function.

> No, it's an argument in the radiance() function, I meant where is it 
> defined in main().

  Line 82.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   There is a big difference between a pointer and an array in C (and hence
> in C++).

Really?

>   Since sizeof() of an array returns the total amount of bytes taken by
> an array, if you divide it by the amount of bytes of one element, you get
> the total number of elements.

This is plain. What surprises me is that sizeof() can give you an 
accurate size in the first place.

>   Of course what makes this confusing is that an array implicitly casts to
> a pointer of the element type. In other words, wherever a pointer of the
> element type is required, you can give an array of that type instead (there
> will be an implicity cast to the pointer type).

Ah. I didn't know that. All the books I've seen claim that they are *the 
same type*.

This makes more sense now...

>>>> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
>>>> places, but I can't find a definitions.
>>> Line 48. It's an argument to the function.
> 
>> No, it's an argument in the radiance() function, I meant where is it 
>> defined in main().
> 
>   Line 82.

Yes, we've established that now. I wasn't aware that you could actually 
define more than one variable in a loop initialiser...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >   Since sizeof() of an array returns the total amount of bytes taken by
> > an array, if you divide it by the amount of bytes of one element, you get
> > the total number of elements.

> This is plain. What surprises me is that sizeof() can give you an 
> accurate size in the first place.

  Why wouldn't it? The compiler has to know the size of the array if it
wants to allocate it in memory.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Also the syntax of indexing an array and indexing memory using a pointer
> is identical, adding to the confusion.

Plus, you can't pass an array to a function, at least in C.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

>>>   Since sizeof() of an array returns the total amount of bytes taken by
>>> an array, if you divide it by the amount of bytes of one element, you get
>>> the total number of elements.
> 
>> This is plain. What surprises me is that sizeof() can give you an 
>> accurate size in the first place.
> 
>   Why wouldn't it? The compiler has to know the size of the array if it
> wants to allocate it in memory.

All that stuff about "C does not know the size of an array at run-time, 
and does not check array bounds". But then, this is from the same books 
that claim that pointers *are* arrays... Certainly if you asked for 
sizeof() on a pointer, you wouldn't get the size of the array it points to.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >>>   Since sizeof() of an array returns the total amount of bytes taken by
> >>> an array, if you divide it by the amount of bytes of one element, you get
> >>> the total number of elements.
> > 
> >> This is plain. What surprises me is that sizeof() can give you an 
> >> accurate size in the first place.
> > 
> >   Why wouldn't it? The compiler has to know the size of the array if it
> > wants to allocate it in memory.

> All that stuff about "C does not know the size of an array at run-time, 
> and does not check array bounds".

  That talks about dynamically allocated arrays, not statically allocated
ones. They are different.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Also the syntax of indexing an array and indexing memory using a pointer
> > is identical, adding to the confusion.

> Plus, you can't pass an array to a function, at least in C.

  Not directly, but you can do it indirectly if you enclose the array inside
a struct (in that case the array (inside the struct) is truly passed by
value rather than by-pointer).

-- 
                                                          - Warp

Post a reply to this message

>> Plus, you can't pass an array to a function, at least in C.
> 
>   Not directly, but you can do it indirectly if you enclose the array inside
> a struct (in that case the array (inside the struct) is truly passed by
> value rather than by-pointer).

...you really have been doing this for a long time, haven't you?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> Plus, you can't pass an array to a function, at least in C.
> > 
> >   Not directly, but you can do it indirectly if you enclose the array inside
> > a struct (in that case the array (inside the struct) is truly passed by
> > value rather than by-pointer).

> ...you really have been doing this for a long time, haven't you?

  Well, it's rather basic C.

-- 
                                                          - Warp

Post a reply to this message