In article <4038aea6$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
wrote:

> that person should be dragged out into the street and shot*. So, ON THAT
> PREMISE, if you have decided to write an inline function there will be an
> "overhead of it being a function (i.e. several instructions) rather than a
> simple instruction", by which I mean you have decided to write a function 
> that is more than one instruction.

__normal_iterator& operator++() { ++_M_current; return *this; }

That's the ++ operator for one of the STL iterators. And it does make 
sense to do it this way...other operators have to do more complex 
things, but it still makes sense to have a ++ operator.


> What I'm saying is, quite simply, we like to make a distinction 
> between "+" and any more elaborate function. Because doing so 
> prevents people writing lines like a = b + 3*(c-d), which looks 
> perfectly innocent, but could be a major bottleneck.

All the coder has to do is look at the types being worked on. And this 
still isn't an argument against the existance of operator overoading.


> We like the clunkier syntax *because* it is harder to use and requires more
> thought from the programmer. In our situation this is a good thing.

But it requires more thought about the wrong things...I don't see how it 
can help.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

> > Interfaces are not obsolete. As for abstract classes...what are you 
> > talking about?
> 
>   Interfaces are obsolete of you can make abstract classes. And why
> wouldn't you (unless you want to make the language so that it does
> not support virtual functions, which would limit its OO capabilities
> by a whole lot).

Argh...forget about virtual functions. They are an artifact of C++, 
which does everything statically by default. I specifically said no 
static binding. No virtual functions, because everything is dynamically 
bound.


>   A class is abstract if it has pure virtual functions (that is,
> the class does not implement the virtual function(s) and thus cannot
> be instantiated because of this; it can only be used through
> inheritance so that the derived class implements the virtual
> function(s) in question).

Again, I'm talking about single inheritance. Multiple inheritance is not 
necessary, and is needlessly complex. Abstract classes are not as useful 
in single inheritance models, interfaces cover their functionality. 
Interfaces render multiple inheritance + multiple abstract root classes 
obsolete, not the other way around.


> > Sorry, but I don't. I've never accidentally tried to access a private 
> > member.
> 
>   That's right. *You*. But that's ok only for as long as you don't
> distribute that library of yours containing public member variables...
> Someone will inevitably use it in the wrong way and his code can then
> break with an updated version of the library.

That's their fault for screwing around with stuff that's not documented 
as the public interface. They could do the same thing with preliminary 
code that may eventually be public interface, but which isn't nailed 
down yet. But I've seen enough people trying really hard to do really 
stupid things to get your point...fine if they are the only victims of 
their stupidity, but if I have to work on their code or use their 
software...


>   Well, that's just a question of implementation of the interpreter/compiler.
> If you can implement the interpreter so that the private part does not need
> to be specified at the same place as the public part, good thing. (In C++
> this is not possible for technical reasons, but in an interpreted
> scripting language it may very well be possible.)

Oh, it's possible for C++, just more complex to compile. The compiler 
would have to collect both definitions before it could compile anything 
using more than a pointer or reference to the type. Probably be best to 
have special directives specifying the files that have the 
implementation and interface. Or tie the class names to the file names, 
like Java.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <n8ag309hemfhpmj8jnt5j5s3k8gr66rm62@4ax.com>,
 Andreas Kaiser <aka### [at] nurfuerspamde> wrote:

> This might be a 'learning' problem if you aren't aware of the
> operators 'hidden' complexity. 

Only if the code is poorly designed. You shouldn't have to care about 
the hidden complexity. It doesn't matter one bit how the = operator 
copies a string, only that it does so.


> >So do functions.
> 
> Yes, same problem here. There's no correlation between length of
> function name and complexity. 

It's not a problem. It's a feature. Code written without functions is 
called spaghetti code, it ain't pretty and it is very inefficient and 
unmaintainable. Or should functions that do more have longer names? How 
long should POV-Ray's main() function be?


> If you call a Trace() function you should know why.
> May be to write a trace record to a log file, may be to start a render
> that will be finished some months later.

And when it's in a raytracer, and when you're giving it ray information 
and receiving a color from it, which do you think it is? This is an 
English language issue, not a programming language one.


> The macros required to do trivial colour/vector arithmetic are
> 'information hiding' in the worst sense. They blow up source code and
> add visual noise which makes it sometimes almost impossible to see
> what's going on.

Agreed. They hide what the code is really doing by bloating up each 
little operation.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <40389d5e$1@news.povray.org>,
 Andrew C on Mozilla <voi### [at] devnull> wrote:

> > IMHO this comes down to 'pov ain't oo' - I don't think anyone denies 
> > that oo capabilities in pov wouldn't be at the very least interesting, 
> > but that's not the issue....
> 
> POV sure ain't OO. No doubt about it ;-)

Actually, it comes close in many ways. You transform all shapes and 
textures. You can texture all shapes. You can use the solid ones in CSG. 
It's a fixed heirarchy, but you could express it in terms of objects.

object

transformable:object

shape:transformable

solid_shape:shape


finite_solid_shape:solid_shape
sphere:finite_solid_shape
box:finite_solid_shape


infinite_solid_shape:solid_shape
plane:infinite_solid_shape


patch_shape:shape
bicubic_patch:patch_shape
triangle:patch_shape


pigment:transformable
solid_pigment:pigment {color}
patterned_pigment:pigment {pattern, color_map}


texture:transformable
patterned_texture:texture {pattern, texture_map}
plain_texture:texture {pigment, finish, normal}

and so on...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

> Which you have to call no matter what.

No you don't, there is always another way to write the code. That's my entire
point. If people have to think more when performing an operation which is more
complex than a simple "+" then hopefully they might some way to do something
simpler.

That is the nature of optimisation, doing the same things in a different way.

> Just be aware of what you're adding. It's no harder than keeping track
> of a bunch of methods named add(), mult(), etc, and the code is much
> easier to read.

The standards we use would be more like matrixAdd(), vectorAdd(), etc. That way
it is easier to keep track of because you are using different function names
according to what the back end is doing. This means you can search for them in
the code, which is a very useful feature.

> How is this so? If you need to add two matrices, you need to add two
> matrices.

Do you? What if you're adding two vectors? What if you're adding two vectors
before computing a dot product with another vector? it may be possible to do
this more efficiently by computing the dot product with each of the vectors and
then adding the results.

Code is malliable, nothing needs to be written a certain way. Our aim is to
write it in a more efficient way, and to write it in a way that makes it easier
to optimise later.

> > Heck, if were even remotely
> > feasible we'd write everything in assembler...
>
> No...then you run into the "can't see the forest for the trees" problem.

Uh, I did say "if it were remotely feasible". Obviously it isn't for the reason
you state there. However there is such a thing as too high level for any given
application, and the consensus amongst people I've worked with is that operator
overloading is a little too high level for the kind of code we write.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

> Why is this harder than "your webmaster was a fool. How do you find all
> the links to pages that don't exist?"

It's not, but our way's easier than that: You just search for the name of the
function (thereby getting cases that the compiler might not complain about
because it gives up early or some code might depend on a #define'd switch)

-- 
Tek
www.evilsuperbrain.com

"Darren New" <dne### [at] sanrrcom> wrote in message
news:4038f420$1@news.povray.org...
> Tek wrote:
> > How do you do that?
>
> You use the right tools. Heck, the compiler can tell, can't it?
>
> The trivial method is to change the name of the matrix multiply routine
> and see all the places where the compiler complains of missing functions.
>
> Why is this harder than "your webmaster was a fool. How do you find all
> the links to pages that don't exist?"
>
> -- 
> Darren New, San Diego CA USA (PST)
>    I am in geocentric orbit, supported by
>    a quantum photon exchange drive....

Post a reply to this message

>   You need to know about how a library function is implemented anyways,
> regardless of how it is called, if you want to make as optimal code as
> possible.

Which is easier to keep track of if it has a different name to all the other
library add functions. You can glance at the code and see what it's calling.

>   If you are using class instances you know that calling the operator+
> for them will (potentially) generate a function call. If you don't know
> that, you don't have business making highly-optimized hacker code.

But if you're looking at unfamiliar code how do you know if you're looking at
class instances? They could just be typedeffed ints. You need to find the
definition of the class, which takes longer than simply seeing what function
it's calling.

However, I note you have dodged my question, which I think is the crux of the
issue:

Right, lets say your product ships in two weeks time, and you've discovered that
the physics guy who got sacked last week was a moron. Hey, it happens. You need
to go through his code and find everywhere that he's performing a matrix*vector
multiply, in order to replace it with a more efficient piece of code.

How do you do that?

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

In article <4038f266$1@news.povray.org> , Darren New <dne### [at] sanrrcom>  
wrote:

> And in real languages, you don't even have to tell the compiler to do
> that. ;-)

You don't need to do in C++ either.  "inline" is only a hint to the compiler
just like the "register" keyword.  Most modern compilers will inline
whatever they see fit, and some will even completely ignore the "inline"
keyword and find a better selection of functions to inline.

    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

"Warp" <war### [at] tagpovrayorg> wrote in message news:4038bb04@news.povray.org...
> Tek <tek### [at] evilsuperbraincom> wrote:
> > We like the clunkier syntax *because* it is harder to use and requires more
> > thought from the programmer. In our situation this is a good thing.
>
>   Good luck trying to maintain and enhance such code in the future then.

What the heck do you think I've been doing for the last 5 years?!

I'm not talking about some nice theory on a strategy for writing code, I'm
telling you the way that we actually do it. You can disagree all you like, but
this approach *does* work.

In terms of maintenance, this approach again makes it easier to optimise code
(even code you're not familiar with) because you can always see at a glance what
functions are being called where. This is ugly and confusing information if you
are thinking purely in terms of theoretical algorithms, but in our world the
reason you are looking at the code is precisely to see that very information! We
put this extra info there not because it clutters the code, but because it is of
use to us.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:4038be6e$1@news.povray.org...
> If you write games, you don't have to, I suppose.  All you need is a few
> patches later on when bad coding style produced plenty of bugs in the
> initial release version ;-)

I write console games, so actually we have to release stuff with less bugs in
than people in most fields of development (possibly banking and military
applications need even less bugs, but most fields get away with shoddy code).

We use this coding style because it helps us, not hinders us.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message