In article <3fdb73ab@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>>         POV is currently and will be like this for a while...
>
>   I know, but I don't blame the pov-team for that. It's not a bunch of
> C-coders trying to make a C++ program, but a 10-years old gigantic C program
> where some C++ has been added for certain features, not for the intention
> of being the final thing, but for being an updated bugfix release before
> the complete rewrite in C++ with good OO design.

It should not be forgotten that "good OO design" is a far from trivial
thing.  Especially when it comes down to the ugly little details that look
great in the UML diagram, but are much harder to implement an second sight
... especially if the primary goal is raw performance the temptation to
"just use C" is always around.  And in the end it will always be the wrong
decision.

On the other hand, to master all C++ features well takes years of practical
experience and a gentle growths of abilities:  It would be irrational to
expect to be able to teach anybody a language as complex as C++ from any
number of books or in a classroom.  Far too many teachers make the mistake
of treating "programming" as just a necessary evil of computer science, and
assume programming languages can be used interchangeably!

Of course, this just shows a serious disconnection from any practical
experience at all - and far too many who teach in my home part of Europe
have not realised this yet at all, and I know it happens almost everywhere
else, too...

Or would you rather understand 20 languages - be they for inter-human
communication or computer programming - a little than speak two or three
fluently?  Of course, as many computer scientists have never been made to
realise this very simple fact in school, they never applied it in the real
world, and hence you end up with the majority of computer scientists being
just terrible programmers.  Yet, they start as just that in most jobs, and
hence software quality did not improve despite huge advances in programming
languages in the past 25 years.  To the contrary, system complexity and size
increased by at least three orders of magnitude, but most still program like
25 years ago, desperatly trying to solve their problemsby creating a
mountain of design specifications and other formal methods :-(

    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 <3fd9c437@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Actually the step from C to C++ is much much larger than you might
> believe. Much larger than for example from Java to C++.

Java and C++ are really not interchangeable or compareable.  The only thing
they have in common is that they offer language support for OO programming.

Yet, while Java as a language is neat, the libraries that come with it are
just a big piece of hacked together junk and patchwork resulting from
marketing needs rather than rational thinking.  C++ on the other hand has
careful design (for the most and major part), and its library was designed
as a whole integrated component.

It also turns out that no matter what you do, a Java program will always be
a fat, slow thing that tends to misbehave and corrupt your data rather than
just crash and leave your data alone.  C++, on the other hand, if, and only
if, used properly, will result in a fast, lean and extraordinary stable
piece of software.

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

>>  I know, but I don't blame the pov-team for that. It's not a bunch of
>>C-coders trying to make a C++ program, but a 10-years old gigantic C program
>>where some C++ has been added for certain features, not for the intention
>>of being the final thing, but for being an updated bugfix release before
>>the complete rewrite in C++ with good OO design.
> 
> 
> It should not be forgotten that "good OO design" is a far from trivial
> thing.  Especially when it comes down to the ugly little details that look
> great in the UML diagram, but are much harder to implement an second sight
> ... especially if the primary goal is raw performance the temptation to
> "just use C" is always around.  And in the end it will always be the wrong
> decision.

Can you tell what are/were the reasons for deciding to rewrite the whole 
POV-Ray in C++? Performance wise I think it doesn't mean much nowadays, 
but do you think OO suites POV-Ray better than plain ol' procedural C? 
It will be a huge task but do you think it will pay the effort as easier 
code maintenance and further development?

Severi Salminen

Post a reply to this message

In article <3fdb9898$1@news.povray.org> , Severi Salminen 
<sev### [at] NOT_THISsibafi>  wrote:

> Can you tell what are/were the reasons for deciding to rewrite the whole
> POV-Ray in C++? Performance wise I think it doesn't mean much nowadays,
> but do you think OO suites POV-Ray better than plain ol' procedural C?
> It will be a huge task but do you think it will pay the effort as easier
> code maintenance and further development?

I outlined the answers to your questions in the second half of the last
paragraph of my message.

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

>>Can you tell what are/were the reasons for deciding to rewrite the whole
>>POV-Ray in C++? Performance wise I think it doesn't mean much nowadays,
>>but do you think OO suites POV-Ray better than plain ol' procedural C?
>>It will be a huge task but do you think it will pay the effort as easier
>>code maintenance and further development?
>  
> I outlined the answers to your questions in the second half of the last
> paragraph of my message.

Indeed, I hadn't read that. You wrote: "a fast, lean and extraordinary 
stable piece of software". But doesn't Pov-Ray allready meet these 
goals? Or is this simply about it being _easier_ to achieve those goals 
with C++ than with C? (My knowledge of C++ is _very_ limited). Just curious.

Severi S.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> It should not be forgotten that "good OO design" is a far from trivial
> thing.  Especially when it comes down to the ugly little details that look
> great in the UML diagram, but are much harder to implement an second sight

  This is certainly true.

  Thinking that you can make good object-oriented programs after having
been in a UML course is like thinking that you can drive a F1 car right
after you have got your driver's license. However, I'm afraid that too
many people think this way.

  Background theory is extremely important, if not mandatory, but only
experience (lots of it) will give you the qualification. And not whatever
programming experience at free, but expressly object-oriented programming
experience.
  10 years of "hacker" C programming experience will (at least at first)
probably be more a burden than a benefit (even though that experience can
become very handy once you have assimilated good OO principles and got
some experience about it). This is because C teaches very, very bad
habits which are a real burden in good object-oriented C++.

  In the project I'm working at we are at the third generation of our
major file I/O library. It has gone through two complete re-designs
because the previous designs resulted to be cumbersome in practice (even
though they looked nice in paper). The current third design is starting
to look like what it should. :)

  This is a very common phenomenon I have noticed: In any bigger project
the first OO design of the system will most probably be flawed and will
probably need at least one major re-design with more practical experience
before it becomes usable.

> ... especially if the primary goal is raw performance the temptation to
> "just use C" is always around.  And in the end it will always be the wrong
> decision.

  The sad thing is that sometimes the "C-way" will be slower and less
efficient than the "C++-way". For instance, compare C and C++ strings.
(Most operations are much faster in C++, not to talk about C++ strings
being a lot more secure with regard to memory leaking. C++ strings are
also a lot easier to use.)

  (It's really sad that C++ streams are still slower than C streams in
most compilers. When will they make an implementation which is at least
as fast?)

> On the other hand, to master all C++ features well takes years of practical
> experience and a gentle growths of abilities:  It would be irrational to
> expect to be able to teach anybody a language as complex as C++ from any
> number of books or in a classroom.

  Some books really help. For instance "Effective C++" and "More Effective
C++"... :P
  (Of course these books are aimed to those who already have experience
about C++ and want to learn more.)

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

> Take it off :)
<snip>

Oh, OK. Feeling slightly less stupid now. ^_^

Still... Wouldn't it be awesome, once POV gets rewritten in C++, to have a
documentation of the source that not only focuses on things at the
instruction level, but that takes on the POV source as a whole? Kind of an
intro to the hierarchy and structure, what the basic files are, what they
contribute, and how each additional object or functionality fits into this
core. Perhaps an explanation of how one would go about adding, say, the
torus object, or the brick pigment. Something along those lines, which would
allow someone who has never seen the source to grasp in broad strokes how it
all works and fits together -- someone like me, who might want to add
something (or dare I say, hope to improve something)...

> >PS: I just finished my Operating Systems
>>final today... This means I'm done.
>
> Congratulations.

Thanks! My final grade was a B. I may be able to improve it (I found an old
homework that he had marked down as a 0 for me), but at least I passed, so
I'm very happy. ^_^

-- 
Anthony Bennett

Post a reply to this message

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

> It also turns out that no matter what you do, a Java program will always
be
> a fat, slow thing that tends to misbehave and corrupt your data rather
than
> just crash and leave your data alone.  C++, on the other hand, if, and
only
> if, used properly, will result in a fast, lean and extraordinary stable
> piece of software.

Unfortunately, after a while, even the best designed C++ program, if
sufficiently large and complex,  will turn into an ugly,
crash prone, unmaintainable corruption factory maze of lines of code,
because it is SO easy to go this route
(with operator overloading, multiple inheritance and pointers as the main
tools)

--
Pascal.

Post a reply to this message

In article <3fdc4e58@news.povray.org> , "Pascal" <net### [at] freesurffr> 
wrote:

> Unfortunately, after a while, even the best designed C++ program, if
> sufficiently large and complex,  will turn into an ugly,
> crash prone, unmaintainable corruption factory maze of lines of code,
> because it is SO easy to go this route
> (with operator overloading, multiple inheritance and pointers as the main
> tools)

Anybody who still uses raw pointers in C++ deserves to be shot!

    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 <3fdbce98@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> ... especially if the primary goal is raw performance the temptation to
>> "just use C" is always around.  And in the end it will always be the wrong
>> decision.

You are the second person I am not sure understood what I wrote they way I
meant it, and I am sure it is due to my bad choice of sentence structure:
"And in the end it will always be the wrong decision." is supposed to refer
to the "just use C" in case it wasn't clear.

    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