In article <39a03553@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I have never looked into the source code of any STL implementation, though.

You don't want to!  POV-Ray source code is better commented and organised
;-)    But it varies a bit from STL to STL...

>   References are pointers.
>   The syntax for references usually doesn't allow you to make so many things
> with them than with pointers, but basically they are the same thing.
>   So it doesn't matter if we call them references or pointers. The important
> thing is what do we allow and what we don't to do with them.

They do not have to be, at least in ISO C++.  Section 8.3.2 paragraph 3 of
ISO/IEC 14882:1998(E) states:

"It is unspecified whether or not a reference requires storage (3.7)."

Effectively this rule seems to exist to allow a compiler to optimise the
code much better.  And this rule also explains why there can't be references
to references, but of course there can be pointers to pointers!

>   In C++ pointers are very free (and thus dangerous) and references are very
> strict. For example, you can't assign a new value to a reference. In Java
> references are more free than in C++ because you can assign the references
> to point to new objects. This is an important feature because without it
> it wouldn't be possible to make lists and so on.

If I am not completely wrong, in other languages like Java the same rule
applies, and a reference could be something for more abstract than a simple
pointer, for example a index to a table of pointers.  This would allow very
effective memory management as memory could be compacted easily.

>   I have always said, that "it's not true at all that there are no pointers
> in Java, all the contrary: In Java _everything_ is a pointer".

Nope, it does not have to be.

> : Great argument!  Who cares if someone can read a POV scene and learn from
> : it, why should there be new novice users of POV-Ray?
>
>   So you say that we shouldn't give powerful tools to people who wants them
> only because newbies can't read the code?

Yes, if this excludes every person who is not a computer scientist or with a
strong background.  After all, POV-Ray is for artists creating interesting
images, but programmers creating complex programs that generate data for
another complex program (POV-Ray) that generates images.

I have to admit that I am not far from the argument for the need for a
modeller here...

>   No, I still think that it doesn't matter. Features are not left out because
> they are slow to parse.

That might be one of the problems of POV-Ray when talking about certain
_parser_ features  :-(

>   Yes, there's a cost in designing a OO-pov language. But that's not a cost
> for the user. The users will probably not notice much difference. Someone
> may sometimes post a weird OO-pov code in text.scene-files, but they are
> usually hard to read anyways ;)

People be able to understand how something works. Increasing the complexity
over a certain limit, it will scare people away instead of encouraging them
to try for themselves.   And why should we exclude the 99.9% of non-computer
scientists from being able to _understand_ even a single POV scene
description?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message