Nicolas Calimet <pov### [at] freefr> wrote:
>         Maybe the usual problem in such cases is the staight "No." answer.

  That "No." was only symbolic, for shortness. Of course it meant a
proper negative answer.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> 
>>>"int i = int(some_double);".
> 
>>     int i = (int)some_double;
> 
>   Well, POV-Ray is compiled with a C++ compiler currently. May as well use
> the C++ way.
> 
    Ah OK, sorry. I'm not a C++ expert, I'm to old for this modern
    technology :)

-- 
http://tth.vaboofer.com/Cette/

Post a reply to this message

Thierry Boudet <oul### [at] chezcom> wrote:
> >   Well, POV-Ray is compiled with a C++ compiler currently. May as well use
> > the C++ way.
> > 
>     Ah OK, sorry. I'm not a C++ expert, I'm to old for this modern
>     technology :)

  There's a reason for the new syntax. It has to do with abstract types
(classes and template parameters). However, I don't think anyone is
interested in another C++ lecture of mine... :P

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

Post a reply to this message

>   There's a reason for the new syntax. It has to do with abstract types
> (classes and template parameters). However, I don't think anyone is
> interested in another C++ lecture of mine... :P

On the contrary, I like reading them =)

Wouldn't the real C++ way be something like

reinterpret_cast<int>(some_double)

Or something like that? Not sure what type of cast it would be.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:

>> (classes and template parameters). However, I don't think anyone is
>> interested in another C++ lecture of mine... :P
> 
> On the contrary, I like reading them =)
> 
> Wouldn't the real C++ way be something like
> 
> reinterpret_cast<int>(some_double)
> 
> Or something like that? Not sure what type of cast it would be.
> 
The "correct C++ way" would be to use static_cast<int>(). 

This is because reinterpret_cast<>() will not change the binary 
representation while doing the cast (and is hence meant for potentially 
dangerous casts). Since casting a double into an int does require 
a change in the binary representation (usually 8 byte floating point 
into 4 byte integer), reinterpret_cast<>() cannot be applied. 
The compiler should give an error in this case. 

Wolfgang

Post a reply to this message

> The "correct C++ way" would be to use static_cast<int>().
>
> This is because reinterpret_cast<>() will not change the binary
> representation...

Yeah, that's why I said "Not sure what type of cast it would be."

My point was, isn't "something_cast<int>()" the C++ way instead of "int()"?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Wolfgang Wieser <wwi### [at] nospamgmxde> wrote:
> The "correct C++ way" would be to use static_cast<int>(). 

  static_cast is actually the only "clean" casting type. All the three
other casts are more or less ugly casts which usually shouldn't be
used in well-designed code. Usually if you need to use the other casts,
it's a sign that there's a flaw in your design (even though there are
a few exceptions, but as a rule of thumb).

  static_cast performs a cast between compatible types. Although
casting between compatible types does not usually need an explicit
cast (implicit casting is usually ok), it's usually recommended to
do the cast explicitly when the cast is done from a "larger" type
to a "smaller" one (eg. from int to char, or from double to int, etc).
It can be thought as a kind of "documentation" which says "yes, I really
want to cast even at the risk of losing significant digits".
  static_cast should fail (ie. give a compiler error) if the cast is
performed between inompatible types (for example trying to convert
an int to a pointer).

  There's actually one situation more where static_cast can be used:
When downcasting a base-class type pointer to a derived-class type.
The compiler will not complain about this, but it's a bit dangerous
because you must be sure that the base-class type pointer really points
to the derived-class type you are casting to or else malfunction will
follow. There are a few cases where this is ok, but usually if you need
to downcast at all, you should use dynamic_cast instead.

  dynamic_cast converts between class pointers, but it checks at runtime
that the cast is valid. If the cast is invalid, it returns a 0 pointer.
This is usually done for downcasting a pointer and checking that it
succeeded.
  Usually, though, if you need to downcast, it's a sign of bad OO design.

  const_cast casts a const pointer to its non-const version. If you need
to use it, there's a flaw in your design. (The only place you should be
forced to use it is when having to use someone else's library which is
badly designed.)

  reinterpret_cast casts between incompatible types (eg. from an int to
a pointer or between pointers to completely unrelated types). Usually
only needed if you are making low-level hacker code, usually not needed
for high-level OO code.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> My point was, isn't "something_cast<int>()" the C++ way instead of "int()"?

  Sometimes the latter cast is necessary.
  Consider this:

template<typename Type1, typename Type2, typename TypeConverter>
void foo(Type1 v)
{
    Type2 v2 = TypeConverter(v);
    ...
}

  Now, 'TypeConverter' can be an inner type (eg. 'int'), an abstract
type (eg. a user-defined class), a function or a class instance (for
which the 'operator()' is defined).

  For example, you could call the above function like this:

int convertDoubleToInt(double d)
{
    return some_complex_conversion_from_d_to_int;
}

...
    foo<double, int, convertDoubleToInt>(xyz);

  In this case foo() makes a convertDoubleToInt() function call.
  However, of you do it like this:

    foo<double, int, int>(xyz);

what foo() will do is a cast (that is: "int v2 = int(v);").

  Since specially in template functions a xyz() call can be many things
(function call, operator() call, typecast), that's the reason why the
'type(value)' casting is necessary.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

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

>   dynamic_cast converts between class pointers, but it checks at runtime
> that the cast is valid. If the cast is invalid, it returns a 0 pointer.
> This is usually done for downcasting a pointer and checking that it
> succeeded.
>   Usually, though, if you need to downcast, it's a sign of bad OO design.

I don't think one can generalise that using dynamic_cast suggests a bad
design somewhere.  Without dynamic_cast a less-static binding of objects
would not be possible at all.  The only real problem with dynamic_cast is
that it has a (by newbies unexpected) runtime overhead that cannot be
predicted very well...

    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

I would like to see a port to amiga
good on yous :)

Post a reply to this message