 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz Kretzschmar <lut### [at] stmuc com> wrote:
: Generally, I agree, but not in this case. And you failed to answer my
: question. How do create a copy of an object to which you have a base
: class pointer.
I would probably not design the program at all in a way that I will be
needing copying objects behind base class pointers. If nothing else, I would
probably make a more abstract "handle" to that resource which safely takes
care of creating, copying and destroying it.
:> The whole class hierarchy should be designed so that this kind of copying
:> is not needed (ie. not in this way).
: Very funny. There is no amount of design that can avoid this.
Well, I have coded tens of thousands of lines of object-oriented C++ code
as my work, and I have never needed to do this.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alessandro Coppo <a.c### [at] iolit> wrote:
: Well, the whole thing about garbage collection, reference counting, etc.
: etc. is just meant for NOT bothering about these details. I am working in
: Java since 2000 (and in C++ since 1990..) and I find myself 10 times more
: productive by just calling clone() on an object to create a copy than
: messing around with templetazied smart pointers, idioms to ensure correct
: destruction etc. etc.
The main problem with Java's garbage collection scheme is that it destroys
the concept of class destructors, which is a very important concept in OO
programming.
Destructors take care that everything that the object has allocated gets
freed when the object is destroyed (and this doesn't only mean memory!).
Destructors are safe because they are always called when the object is
destroyed, so the resource will certainly be freed when the object itself
is destroyed (either explicitly or because it goes out of scope).
In Java this concept has been destroyed. Classes do have destructors, but
they may not get called at all, and even if they are called, there's absolutely
no guarantee of when and in which order they are called.
This means that if a resource allocated by an object needs to be freed
immediately after the object is not needed anymore, you have to make your
own method for this and you have to remember to call this method. If you
forget to call this method, then bad luck.
This means that if you have, for example, a window class, you can't put
the window closing routine in its destructor, but you have to make a proper
method for closing and then remember to call it everywhere it's needed (because
it's not called automatically by the compiler).
This is just one example of a "feature" of Java which forces you to make
non-modular code.
I find myself 10 times more productive with C++ than with Java.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
#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 <3c4ffea4@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> 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.
Look up the following keywords and their function:
explicit, private, protected
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:
: Look up the following keywords and their function:
: explicit, private, protected
I know what they do.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I see that at least we agree on something: mutually disagreeing on
everything ;-)
Bye!!!
Alessandro Coppo
a.c### [at] REMOVEiolit
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
|
|
| |
| |
|
|
|
|
| |
|
|
