"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3b71858f@news.povray.org...
>
>  I usually write operators like *, /, + outside the class.

    I've seen this done in many places, but have never understood why -
these operations are properties of the class and therefore, surely, the
correct place for them to reside is within the class ?

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <52a3ntc43mlkpp85jvf1g18pmian504003@4ax.com> , Peter Popov 
<pet### [at] vipbg>  wrote:

> Unfortunately, no. Even if I remove any and all transformation code
> from CBox::Intersect (or CSphere::Intersect) and only use
> untransformed primitives, they render incorrectly.

You are scaling vectors to unit length in some places.  You should really
not have such side effects in your code.  If you remove it at least
debugging should be easy.  After all, a sphere/ray intersection isn't that
hard to debug if you are sure your vectors work without side effects.


    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

In article <3b71c0ef@news.povray.org> , "Scott Hill" <nos### [at] nospamthanks>
wrote:

>     I've seen this done in many places, but have never understood why -
> these operations are properties of the class and therefore, surely, the
> correct place for them to reside is within the class ?

It is strongly suggested by Stroustrup in his books.  He never really
explains why it is so beneficial.  Most of the STL follows it.  I can't
think of many (non-philosophical) reasons that would make a huge difference
(i.e. in speed), but in general such code is much easier to comprehend and
that is enough for me to use it...

    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

In article <da53ntov8fnpb02dcs15kgcfm3ompe7u9e@4ax.com> , Peter Popov 
<pet### [at] vipbg>  wrote:

> This is up to the compiler, I guess. I will do some performance tests
> when I fix them nasty bugs.

No, you should define the function as "inline".  A compiler doesn't have to
inline functions automatically, and many compilers won't except you
explicitly tell them to use auto-inlining.

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
: No, you should define the function as "inline".  A compiler doesn't have to
: inline functions automatically, and many compilers won't except you
: explicitly tell them to use auto-inlining.

  Note that a compiler doesn't have to inline anything even if "inline" is
used.

  Sometimes a function _can't_ be inlined even if you wanted.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Scott Hill wrote:
> 
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:3b71858f@news.povray.org...
> >
> >  I usually write operators like *, /, + outside the class.
> 
>     I've seen this done in many places, but have never understood why -
> these operations are properties of the class and therefore, surely, the
> correct place for them to reside is within the class ?
> 
The reason for this is notation convenience. Consider class Complex with
operators *, /, +, - defined in class scope
class Complex{
  public:
    const Complex operator *(const Complex & c1){
      //...
    }

};
Now you can do this:
Complex c1, c2;
c1=c2*5;
but can't do this:
c1=5*c2;
as there is no operator *(const Complex & c) for type int. If you define
it outside of class:
const Complex operator *(const Complex &c1, const Complex &c2);
and have constructor for Complex, which allows object creation from int,
then second statement compiles OK.

Post a reply to this message

SLAP! <fx: hand slaps on forehead>
    BING! <fx: lightbulb illuminates over head>

    I was sure there must be some reason for it - I guess I've just never
come across that situation/problem... Makes perfect sense... Cool... Another
little gem for my personal 'good OOP practices' list... Cheers...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message