 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c4f5132@news.povray.org> , Warp <war### [at] tag povrayorg> wrote:
> I have used multiple inheritance. I haven't needed dynamic_cast<> (nor
> any other cast for that matter).
>
> dynamic_cast<> is one of those casts which you just shouldn't use (ok,
> not that; what I mean is that you should almost never use downcasting;
> downcasting is generally bad).
> The other casts you should never use are const_cast<> (used just as a hack
> for dealing with old bad-designed libraries) and reinterpret_cast<> (which
> is mainly used for low-level hacking).
Not sure if you can access it, but if you have access to the
/povray/tools/povdocgen/ directory in Perforce, could you explain to me how
to design classes so that they can contain and access an HTML (or XML to be
more general) parse tree - or (almost) any parse tree for that matter -
without having to use casting?
Or, to be more precise, you have two kinds of classes that have nothing in
common expect that they can be turned into text and back (thus those
functions are in the common base class).
However, one class only stores plain text while the other class has
attributes and stores no plain text at all. Yet objects can be nested inside
the class with attributes, which needs to store a list with any number of
objects of either class.
So one either uses casting or one class which contains a list and a string
and only uses either. The first way is the proper design, the second is the
worst possible design.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Warp, you recently wrote in povray.general:
> It may be a standard way in Java.
I wouldn't know, I've never written any. I've been doing C++ the last
7 years.
> Making a module which allocates a resource, returns a handle to this
> resource outside and hopes that someone else will hopefully free it somewhere,
> is a *really* bad module design (and OO design).
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. As Thorsten said, since there are no virtual
constructors, you can't do it any other way. The design of the module
has nothing to do with this. The way the return value (the new object)
is handled is part of the module design. To make sure there are no
leaks.
> 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.
> Making efforts for a good design now can save you a lot of trouble later.
Now that I agree with :-)
- Lutz
email : lut### [at] stmuccom
Web : http://www.stmuc.com/moray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> writes:
> > 3. Demand that all use of foobar-0.1 comply with the new license.
> >
> > As long as you're only doing 1 & 2 there's no problem (well, depending
> > on your point of view there might be some moral problems, and people
> > are likely to complain...), but you can't legally do 3.
>
> If I understand things properly, #3 is legal if the old license
> specifically stated that the license could be changed, so anyone using
> the software has warning.
Hm, I wouldn't be too sure - I don't think it would stand in court.
But I don't really know, fortunately I'm not a lawyer. :-)
> But I worry about people *not* using it because it is GPL...some people
> apparently don't like GPL, which is why I'm looking on information about
> licensing.
Ah, see. I felt like that once too, but since I switched to Linux,
I've changed my mind. Richard Stallman's arguments begin to make sense. :-)
I'm beginning to like the fact that some of my code perhaps will be
able to persuade others to release their software as free software,
just like it was the case with me.
> If someone is willing to invest the time/money to make a product that
> uses CSDL, I would have nothing against them charging for their product
> or withholding the source code for their work, as long as they make any
> changes/enhancements to CSDL available. People will only buy it if it is
> better than the free stuff, and if the developer makes something better,
> I'll thank them.
Follow your heart. :-)
But I think it would be wise to choose a GPL-compatible license.
--
Ole Laursen
http://sunsite.dk/olau/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It may be a standard way in Java. In C++ it's a standard way of getting
> sure that you will get a high chance of a memory leak (specially if
> there's more than one person using the library which does that). (And no,
> the way Java handles object allocation and freeing is not always good.)
>
> As I already said in another article, one of the basic principles of
> modularity is that if a module (class, whatever) allocates a resource, the
> same module takes care that the resource gets freed (and gets freed only
> once).
> Making a module which allocates a resource, returns a handle to this
> resource outside and hopes that someone else will hopefully free it
> somewhere, is a *really* bad module design (and OO design).
>
> The whole class hierarchy should be designed so that this kind of
> copying
> is not needed (ie. not in this way). This usually can be done much better
> and much more nicely (and specially much more safely).
> Making efforts for a good design now can save you a lot of trouble
> later.
>
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.
ANY modern language (Java, C#, Perl, Python) and some not so modern
(LISP...) have AT L:EAST reference counting.
Bye!!!
Alessandro Coppo
a.c### [at] REMOVE_MEiolit
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The main problem with downcasting is that it destroys abstraction quite
effectively.
The whole idea of having a base class is abstraction: A base class describes
a general set of objects (in a more or less abstract way), and every inherited
class is by definition a base class as well.
This means that if a function/method takes a base class handle (handle =
reference or pointer), this function/method is at the same abstraction level
as the base class itself. That is, this function/method works for *every*
object which has been inherited from the base class (the function/method
doesn't need to know any inherited object type and still work with them).
You can create new classes inherited from the base class (or from its children
classes), and this function/method will work fine with them.
Now, if this function/method performs downcasting and relies on it in order
to function properly, this abstraction is effectively broken. Now you are
saying that this function/method works just for this, this and that inherited
object, and nothing else. If you later want to add a new inherited class,
you'll have to modify this function/method in order to support the new class
(and this might not always be even possible if you don't have access to its
source code). This is not very modular.
If there's a functionality which is specific to a certain class, that
functionality should be implemented in that class. If several classes with
a common base class have similar functionalities (but which are implemented
in a different way), then there should be an abstract way of calling this
functionality in the base class.
It's always better to do "downcasting" with a virtual function call instead
of doing it "by hand".
(Yes, I know, there might be hundreds of exceptions to this generic rule,
but I have noticed in my work that they really are *exceptions*, and that they
are not common at all.)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz Kretzschmar <lut### [at] stmuccom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
