 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I see that at least we agree on something: mutually disagreeing on
everything ;-)
Bye!!!
Alessandro Coppo
a.c### [at] REMOVEiol it
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alessandro Coppo <a.c### [at] iolit> wrote:
: Well, I see that at least we agree on something: mutually disagreeing on
: everything ;-)
I disagree.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c4ffa14@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
My application is a finite state machine (I guess it's a virtual machine
of the type used by Java), and relies on data of various types being
placed on a single stack. I've implemented a data wrapper class,
subclasses of which contain the actual data. The subclasses "own" the
data they contain, they allocate it and delete it, and have a secondary
purpose of implementing reference counting so several symbols can exist
for the same data. However, I sometimes need to copy them...the stack
only has base class pointers, and the code for copying them doesn't care
what type they are, only that they are data that needs to be copied, so
a virtual Copy() method is the logical choice. The data wrapper classes
still take care of allocation and deallocation, the outside world only
has to keep track of the wrappers.
> It's always better to do "downcasting" with a virtual function call instead
> of doing it "by hand".
Unfortunately, a function with a different return type hides the
original instead of overriding it, so casting is necessary. The code
usually knows by context what type it is, and sometimes uses
dynamic_cast when there are several possibilities. Virtual functions are
used when possible.
I could make functions for every possible data type and put them all in
the base class, overriding specific ones for the subclasses, but I don't
think anyone would claim that's good design.
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
> : PS: I am sorry, but it looks like you lost this argument...
>
> Then by all means continue making unsafe code which can leak memory if
> the user of the library forgets to do something that he shouldn't really
> have to do.
> I myself will continue to make safe code.
Warp, Warp, be careful, you will never enter the POV Team if you
continue telling them they don't know how to code !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Warp, Warp, be careful, you will never enter the POV Team if you
> continue telling them they don't know how to code !
ROFL!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
