I've become interested in porting POV-Ray to AmigaOS 3.1+ but I'm a bit 
concerned that I'll be either break some legalities or be re-inventing 
the wheel because somebody else is doing it. If not, is there any 
dissent if I port POV-Ray 3.5 unofficially to the AmigaOS and link this 
to my main page?

The following link is not linked off the main site:
http://<broken link>/amiga/povray.shtml


-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

> I'll be either break some legalities or be re-inventing 
> the wheel

	Probably both would not be a problem, but the best remains
checking povlegal.doc and google  :-)

> The following link is not linked off the main site:
> http://<broken link>/amiga/povray.shtml

	The status shows you're currently fixing the code to work
with gcc/g++ 3.3.  Could you mention precisely what you have/had
to fix ?  Since the source code of POV-Ray 3.6 will be released
within a few weeks and that it is know to compile with gcc 3.3.x
and 3.4.0 on various platforms, it'd be worth waiting a bit longer
before tweaking a two-years-old code.
	As mentioned on the www.povray.org/beta page, the UNIX
source distribution will be beta-tested, most likely starting this
month.  If you are willing to test it, I'd be glad to see what the
reworked build system could give on the AmigaOS  :-)

	- NC

Post a reply to this message

Nicolas Calimet wrote:
>> I'll be either break some legalities or be re-inventing the wheel
> 
>     Probably both would not be a problem, but the best remains
> checking povlegal.doc and google  :-)

Absolutely -- didn't seem that anyone else was interested (this scares 
me, actually, because AmigaOS 4 is coming out and it looks da bomb) and 
povlegal.doc will be my bible for a while (to whom do I pray, though?)

>> The following link is not linked off the main site:
>> http://<broken link>/amiga/povray.shtml
> 
>     The status shows you're currently fixing the code to work
> with gcc/g++ 3.3.  Could you mention precisely what you have/had
> to fix ?  Since the source code of POV-Ray 3.6 will be released
> within a few weeks and that it is know to compile with gcc 3.3.x
> and 3.4.0 on various platforms, it'd be worth waiting a bit longer
> before tweaking a two-years-old code.
>     As mentioned on the www.povray.org/beta page, the UNIX
> source distribution will be beta-tested, most likely starting this
> month.  If you are willing to test it, I'd be glad to see what the
> reworked build system could give on the AmigaOS  :-)
>     - NC

Instead of messing around with the configure, I just started to build 
the Makefile from scratch (I wanted to understand how the files 
interrelated and, as a way to do that, I rolled up my sleeves and dug 
into the code -- sometimes I'm not lazy enough, maybe, for my own good). 
I didn't realize that it was made for gcc (actually, I should have; I 
was thinking, when I was driving home salivating about getting to work 
on it, that the "configure" script should have been a clue). I was also 
compiling with g++, not gcc; didn't even think to change that, if that 
was what was up.

Aside from a lot of warnings that arose because of implicit casting from 
a double to a long or int (which I resolved using (int) floor() just 
because I'm very, very strict about treating warnings as errors) I found 
that, in the file "povmsgid.cpp", the enumerations were assigned to 
static strings surrounded by single quotes, which is something I have 
never seen before -- first, I thought enums had to assign to ints, and 
second, I thought single quotes were for characters, not strings). The 
compiler agreed on both counts and gave me quite a lashing about 
what-for about it. So, I created a PERL script to grab each of those 
strings and generate a file with defines called "povtypes.h" and made 
those defines with unique IDs starting from 1000. Then, I went to 
"povmsgid.cpp" and got rid of those double-quotes and dealt with the 
strings like '****' by making it 'AAAA' and 'NULL' by making it 'NuLL'. 
When that compiled, I started tracing the include hierarchy and building 
the Makefile. Sore fingers later, and a lot of clean-compiles and 
thank-Gods later, I still waswondering what the "goal" of those defines 
was and if there is something fundamental that I'm missing about the 
whole affair that is going to bite me in the cheeks later.

So, it looks like, from what you are saying, I should just unpack the 
thing and enter in the goodies to make the configure script work 
properly with an AmigaOS entry. Probably the best thing to do, but my 
goal was just on getting it to work first and dig in and understand it 
and then prettify later and stress-test it with the provided test suite. 
After it is running on command-line, it just seems silly not to start 
building a GUI around it, like Windows or Mac has. I mean, this /is/ 
that Amiga after all.

Here's a screen-shot of my directory listing so far:
http://<broken link>/images/amipovfiles.jpg

Since, aside from those warnings, that really seems to be the only thing 
it complained about, would someone venture to clue-me-in on what happens 
with povmsgid.cpp? Is there some program in-between that turns those 
happy 'strings' into numbers?

I'm really excited -- 3.5 on the Amiga will do great things for the 
Amiga and excite a lot of new POV-Ray users. I just want to make sure 
I'm Kosher in this pickle. In fact, I'm willing to put in the effort to 
coordinate an official version with you guys if you think I'm sane 
enough to help with it. I dream of seeing povray.programming.amiga happen...
-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

> Nicolas Calimet wrote:

<snip />

>>     The status shows you're currently fixing the code to work
>> with gcc/g++ 3.3.  Could you mention precisely what you have/had
>> to fix ?  Since the source code of POV-Ray 3.6 will be released

At first, I thought to think myself an idiot, but then I thought and 
thought and realize -- it wasn't obvious and I was lucky to figure it 
out. When I ran "sh configure", it failed because it couldn't find a 
"/tmp" directory. It occurred to me how the AmigaOS uses the assign 
command and did this:

mkdir tmp
assign tmp: tmp
sh configure

It is configuring now rather happily. g++ is notoriously slow on the 
Amiga, so I'm going to let it run for a while. That's not the fault of 
the Amiga but, instead, the build for the OS. The emulator I'm running 
is running full-speed and runs many programs faster than Windows XP. I 
have an Amiga 3000T coming soon to do testing on a real Amiga.

Pending compile...
-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Dan P wrote:

> <snip />

> It is configuring now rather happily. g++ is notoriously slow on the 
> Amiga, so I'm going to let it run for a while. That's not the fault of 
> the Amiga but, instead, the build for the OS. The emulator I'm running 
> is running full-speed and runs many programs faster than Windows XP. I 
> have an Amiga 3000T coming soon to do testing on a real Amiga.
> 
> Pending compile...

So far so good. Now I have to compile all those "POV-Ray Absolutely 
Needs these Libraries" libraries. I have a good feeling about this...
-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Dan P wrote:

> Dan P wrote:
> 
>> <snip />
> 
> 
>> It is configuring now rather happily. g++ is notoriously slow on the 
>> Amiga, so I'm going to let it run for a while. That's not the fault of 
>> the Amiga but, instead, the build for the OS. The emulator I'm running 
>> is running full-speed and runs many programs faster than Windows XP. I 
>> have an Amiga 3000T coming soon to do testing on a real Amiga.
>>
>> Pending compile...
> 
> 
> So far so good. Now I have to compile all those "POV-Ray Absolutely 
> Needs these Libraries" libraries. I have a good feeling about this...

Installed libjpeg6b -- successful

Still requires tiffio.h -- the documentation does not note that this is 
a required library. I'll download it, but this is something you might 
want to note in the README.

Using tiff library from http://www.libtiff.org/build.html#Other

-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Milestone! After porting libtiff to the Amiga (I'm thinking of 
contributing it to Geek Gadgets) and removing the version number from 
the output for the PNG library (must have an old library that did not 
include the function -- will look into it) and setting the define to say 
that there is no X Display (this isn't X-Windows!), I've managed to 
successfully compile and install POV-Ray 3.5 on the Amiga! I have yet to 
run the tests, but this m68k executable should work. When I get my 
3000T, I'll make sure to run tests on a native platform.

Next step: Make an icon, have it spawn a shell that lets the user just 
type 'povray' without having to do any special setup, package the proper 
files using lharc, and link it to the web-site. Then, I'm ambitious 
enough to learn programming Intuition to port over the interface from 
Windows/Mac to the platform. Seems like it is a great way to learn it 
since it is really just a text editor with some special menus and a 
window display that captures the output and displays it progressively.

If an when I get to a point where you are thinking me serious enough to 
do an official distribution, know in advance that I'm willing to do what 
it takes to bring POV-Ray 3.5 officially to the Amiga. I have a dream: 
to see povray.programming.amiga be a newsgroup where the ten or so 
people who use it find a home :-) With the other effort, AmiZilla, Amiga 
just might come back. It should. It is the operating system we all 
actually want today. I'm going to bet the last Amiga team said something 
similar.

Here is the latest screenshot:
http://<broken link>/images/amipovray2.gif

I haven't actually compiled a scene yet (I'm so excited to get to this 
point!) There are lots of warnings in the code, so I'm a little worried 
about some of it. I'll feel a lot better when it passes all the tests.

PS: I used the actual 'configure' script to compile this, so yes: 
gcc/g++ works! There were minor Amiga-specific tweaks I had to made, but 
nothing that a more seasoned Amiga programmer would even notice.
-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Bah. It looks like it is trying to free an invalid memory block on my 
test file. It could be a bug in the linked ixemul library, but 
intuitively, I doubt it. Looks like I have some tracing to do. That's 
okay; things that are easy aren't worth doing. If there is anything this 
effort may yield to the team, it is at least a different perspective on 
the code that might help make it more stable.

Screenshot:
http://<broken link>/images/amipovray3.gif

Those warnings bug me, so I'm going to fix them. As a rule, I use 
floor() and cast it to an int when I'm going from a double to an 
integer. I think that is the default behavior anyway so I'm going to add 
the necessary code to make it compile cleanly (at least, on this platform).
-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

In article <40bebe43$1@news.povray.org> , Dan P <dan### [at] yahoocom>
wrote:

> Those warnings bug me, so I'm going to fix them. As a rule, I use
> floor() and cast it to an int when I'm going from a double to an
> integer. I think that is the default behavior anyway so I'm going to add
> the necessary code to make it compile cleanly (at least, on this platform).

Argh!  Don't do something like that, it is plain wrong!  If you compiler
issues nonsensical warnings, the right thing to do is to disable them, not
to destroy your source code!

    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 <40B### [at] yahoocom> , Dan P <dan### [at] yahoocom>
wrote:

> Aside from a lot of warnings that arose because of implicit casting from
> a double to a long or int (which I resolved using (int) floor() just
> because I'm very, very strict about treating warnings as errors)

You should really learn to know the difference between a warning and an
error.  A warning is not an error and as such, it is very likely the machine
informing you about something possibly unintentional is wrong.

> I found
> that, in the file "povmsgid.cpp", the enumerations were assigned to
> static strings surrounded by single quotes, which is something I have
> never seen before --

Get a book about C or C++ programming...

> first, I thought enums had to assign to ints, and
> second, I thought single quotes were for characters, not strings). The
> compiler agreed on both counts and gave me quite a lashing about
> what-for about it. So, I created a PERL script to grab each of those
> strings and generate a file with defines called "povtypes.h" and made
> those defines with unique IDs starting from 1000. Then, I went to
> "povmsgid.cpp" and got rid of those double-quotes and dealt with the
> strings like '****' by making it 'AAAA' and 'NULL' by making it 'NuLL'.
> When that compiled, I started tracing the include hierarchy and building
> the Makefile. Sore fingers later, and a lot of clean-compiles and
> thank-Gods later, I still waswondering what the "goal" of those defines
> was and if there is something fundamental that I'm missing about the
> whole affair that is going to bite me in the cheeks later.

Argh - lkjxfsliaejkisddjhfsuikufdfkljhfkljapsdauojsdl - my brain hurts when
I even read about somebody doing pure nonsense this!

    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

Dan P <dan### [at] yahoocom> wrote:
> Those warnings bug me, so I'm going to fix them. As a rule, I use 
> floor() and cast it to an int when I'm going from a double to an 
> integer.

  By doing that you will be slowing down the code.

  This: "int i = some_double;" is equivalent to this:
"int i = int(some_double);".
  However, you are adding an additional 'floor()' call which will
slow down the conversion needlessly.
  It will also probably give a different result with negative numbers.

-- 
#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

> because I'm very, very strict about treating warnings as errors) I found 
> that, in the file "povmsgid.cpp", the enumerations were assigned to 
> static strings surrounded by single quotes, which is something I have 
> never seen before [snip]
> I still waswondering what the "goal" of those defines 
> was and if there is something fundamental that I'm missing about the 
> whole affair that is going to bite me in the cheeks later.

	Answer is much shorter than you think: yes you're running into
big trouble messing up with the code like this.
	Search google for "multicharacter constant" and look through
the gcc manpage for the -Wno-multichar warning option.

	- NC


PS: you should really-really wait for the 3.6 UNIX source code  :-)

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> first, I thought enums had to assign to ints

  And since when 'abcd' has not been an int?

> and 
> second, I thought single quotes were for characters, not strings).

  No, 'a' is not a character, it's an integer. 'ab' is also an integer.

  Just try: std::cout << 'ab' << std::endl;

> The compiler agreed on both counts

  If enumerated types can only be assigned with integers (which is true)
and 'abcd' is not an integer (which is false), then the compiler would
give you an error. However, the compiler did not give you an error and
thus the compiler is disagreeing with you.

> So, I created a PERL script to grab each of those 
> strings and generate a file with defines called "povtypes.h" and made 
> those defines with unique IDs starting from 1000.

  What for? What is the current code doing wrong?

> Is there some program in-between that turns those 
> happy 'strings' into numbers?

  They are not strings. Learn C, will you?

-- 
#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

On Thu, 03 Jun 2004 18:17:24 +0200, Nicolas Calimet <pov### [at] freefr> wrote:
> Search google for "multicharacter constant"

No need for google. Searching this in povray.programming is enough.

ABX

Post a reply to this message

> Argh - lkjxfsliaejkisddjhfsuikufdfkljhfkljapsdauojsdl - my brain hurts when
> I even read about somebody doing pure nonsense this!

	Aouch !  Thorsten's got broken(*) !!
	It's Armaggedon right before the 3.6 release !!!
	HELP !!!!

	;-)

	- NC


(*) sounds like a top-ten hit in pop music  :-)

Post a reply to this message

Warp wrote:
> Dan P <dan### [at] yahoocom> wrote:
> 
>>Those warnings bug me, so I'm going to fix them. As a rule, I use 
>>floor() and cast it to an int when I'm going from a double to an 
>>integer.
> 
> 
>   By doing that you will be slowing down the code.
> 
>   This: "int i = some_double;" is equivalent to this:
> "int i = int(some_double);".
>   However, you are adding an additional 'floor()' call which will
> slow down the conversion needlessly.
>   It will also probably give a different result with negative numbers.
> 

That makes sense.

-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Warp wrote:

<lots of crap that drains another's enthusiasm />

Right; this is what I expected when I posted to this group. That initial 
post threw me off. I thought maybe you and TF weren't listening. Okay, 
listen; I didn't know about the MultiCharacter constant thing. There's a 
lot I didn't know about. So, kiss my ass.

-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Thorsten Froehlich wrote:

> In article <40bebe43$1@news.povray.org> , Dan P <dan### [at] yahoocom>
> wrote:
> 
>>Those warnings bug me, so I'm going to fix them. As a rule, I use
>>floor() and cast it to an int when I'm going from a double to an
>>integer. I think that is the default behavior anyway so I'm going to add
>>the necessary code to make it compile cleanly (at least, on this platform).
> 
> 
> Argh!  Don't do something like that, it is plain wrong!  If you compiler
> issues nonsensical warnings, the right thing to do is to disable them, not
> to destroy your source code!
> 
>     Thorsten

Warnings warn you of when your code may behave differently on other OS's 
as well. I'm not saying that is true in this case -- it makes sense not 
to call another function there if we don't have to -- but I didn't think 
it was "nonsensical".

Oh, and if your code was so damn good, TF, it wouldn't have crashed 
using a straight-up clean compile on this OS so step-off.

-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Warp wrote:

> Dan P <dan### [at] yahoocom> wrote:

<snip />

>   They are not strings. Learn C, will you?

You know what? I've decided against doing this port after all. I've got 
other plans. With this kind of attitude, and any of you who think this 
is a way to act as a team, you all can kiss my ass, not just Thorsten. 
The last thing I need is to deal with premadonnas like you.

I'm out.

-- 
Respectfully,          "Leave it to the coward to make a religion
Dan P            of his cowardice by preaching humility."
                                    - George Bernard Shaw
http://<broken link>

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> There's a lot I didn't know about. So, kiss my ass.

  When you don't know, the first thing to do is to ask, not to go and
"fix" someone else's code and make a post with a tone of voice which
sounds like you know better than the original code and that the current
code sucks.

  So, it should be: "Hey, there's some odd code which I don't understand
and which looks wrong to me. Is it wrong?" "No." "Ah, ok, never mind."

  Not: "Hey, there's some odd code which looks wrong to me so I went
and fixed it, even though I don't really understand what's going on."

  If you don't understand how a code works and why it is done as it is
done, ask.

-- 
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

Program ended abnormally on 03/06/2004 19:29, Due to a catastrophic Dan P 
error:
> Warp wrote:
> 
>> Dan P <dan### [at] yahoocom> wrote:
> 
> 
> <snip />
> 
>>   They are not strings. Learn C, will you?
> 
> 
> You know what? I've decided against doing this port after all. I've got 
> other plans. With this kind of attitude, and any of you who think this 
> is a way to act as a team, you all can kiss my ass, not just Thorsten. 
> The last thing I need is to deal with premadonnas like you.
> 
> I'm out.
> 

Calm down.  Try to get over their tone and listen to their advise, it's usually 
pretty good.  Warp and Thorsten can be abrasive at times, but that's why we like 
'em.  ;-)

FWIW, I've suffered worse from Thorsten, and I lived to tell the tale.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Warp wrote:
> 
>   This: "int i = some_double;" is equivalent to this:
> "int i = int(some_double);".

     int i = (int)some_double;

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

Post a reply to this message

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

> Dan P <dan### [at] yahoocom> wrote:
>> There's a lot I didn't know about. So, kiss my ass.
>
>   When you don't know, the first thing to do is to ask, not to go and
> "fix" someone else's code and make a post with a tone of voice which
> sounds like you know better than the original code and that the current
> code sucks.
>
>   So, it should be: "Hey, there's some odd code which I don't understand
> and which looks wrong to me. Is it wrong?" "No." "Ah, ok, never mind."
>
>   Not: "Hey, there's some odd code which looks wrong to me so I went
> and fixed it, even though I don't really understand what's going on."
>
>   If you don't understand how a code works and why it is done as it is
> done, ask.

Exactly!!!

    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 <40bfb232$1@news.povray.org> , Dan P <dan### [at] yahoocom>
wrote:

> Oh, and if your code was so damn good, TF, it wouldn't have crashed
> using a straight-up clean compile on this OS so step-off.

Given what you have done to the code and probably the makefile, this is
hardly surprising!  Get a clue, then start to mess with the source code, not
the other way around.  As it stands, you wasted tons of your time to "fix"
something that you simply did not understand.

> Warnings warn you of when your code may behave differently on other OS's
> as well. I'm not saying that is true in this case -- it makes sense not
> to call another function there if we don't have to --

Making fairly random changes all over the code is not the correct approach
to try to fix a problem in a program.  A debugger is!

> but I didn't think it was "nonsensical".

It is because you assume you know so much better than the original authors
and that those tens of individuals were all so stupid that we needed you to
come along and fix our code.  Did it occur to you that this is not likely?

    Thorsten


PS: You are not the first person to not understand what a multicharacter
constant is, it has been discussed in this group before, so I will add a
note to that file to help all those people understand.  Never expected
something like this would be necessary <sigh>

____________________________________________________
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

On Thu, 03 Jun 2004 18:18:00 -0500, Dan P <dan### [at] yahoocom> wrote:
> Right; this is what I expected when I posted to this group. That initial 
> post threw me off. I thought maybe you and TF weren't listening. Okay, 
> listen; I didn't know about the MultiCharacter constant thing. There's a 
> lot I didn't know about. So, kiss my ass.

I think I started at the same point as you so I think I have some reference.
Note, nobody said "kiss our ass if you do not know what multicharacter is." I
didn't know multicharacter issue too when I started reading 3.5 sources. And I
went through fixing warnings too, but I never asked for favour to my ass
because it's clear that before bothering some team about used rules you have
to understand them before you start to fix them. Even unofficial port is not
welcome by community if it is done wrong, that's clear. There _is_ experience
in POV Team Members, think about them like about teachers. You ask teacher:
"hello, I want to make another unofficial nuclear power plant by playing with
atoms in my room". Teacher answer "Doing it this way is wrong and it's
illegal, there are some rights and conventions. My brain is hurt because of
your will". "Then kiss my ass" you answer to your teacher. Childish.

ABX

Post a reply to this message

>   So, it should be: "Hey, there's some odd code which I don't understand
> and which looks wrong to me. Is it wrong?" "No." "Ah, ok, never mind."

        Maybe the usual problem in such cases is the staight "No." answer.
Giving a slightly more informative answer could in the end save a lot of
time, which is otherwise "wasted" answering complaints as in this thread.

        Well, I also know that time is precious, especially at the moment.

        - NC

Post a reply to this message

Thierry Boudet <oul### [at] chezcom> 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.

-- 
#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

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:
>>   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.
> 
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