Christopher James Huff <chr### [at] maccom> wrote:
: Having to duplicate essentially the same code for every subclass (for a 
: Copy() function) just so I can make a copy of an object from a 
: base-class pointer.

  I'm not completely sure what you are talking about, but that sounds a bit
like very dubious coding.
  Do you mean that your Copy() method allocates dynamically a new instance
of its own type, copies itself to it and then returns a pointer to this new
instance?
  That really badly breaks modular OO design.

: Having to return void pointers and cast them to the 
: correct types.

  I never have to do this. It also breaks badly modular OO design.

: Mostly having what I can do with an object being 
: determined by the type of pointer to it I have, instead of what the 
: object can do.

  I don't understand this one.
  Are you sure you fully understand object-oriented design?

  You are also talking too much about pointers. Sounds like you are using
pointers for almost everything.
  This is C++, not Java. Here you can use true references and local instances,
true member instances. You don't need to use dynamic allocation for everything,
as in Java (in fact, it's usually a good idea to not to use it unless it's
justified).

: Templates.

  What about them?

-- 
#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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Having to duplicate essentially the same code for every subclass (for a
> Copy() function) just so I can make a copy of an object from a
> base-class pointer.

Well, while I admit the lack of this being available via the language can be
annoying in some cases, it is also important to not have a copy always
create something one didn't ask for.

And you don't need to duplicate any code at all.  Simply make your copy
function virtual.  That way by default the copy function of the subclass
will be called.  In that function simply write "return new SubClass(*this);"
and all your problems are gone.

> Having to return void pointers and cast them to the
> correct types. Mostly having what I can do with an object being
> determined by the type of pointer to it I have, instead of what the
> object can do.

Hmm, this really should not happen.  You can always avoid this problem with
a common base class.  Even if there are some problems in your class design
this at least allows you to not have to store void pointers, which is an
indication of some problem in the class design.  Try to get access to a copy
of "Design Patterns - Elements of Reusable Object-Oriented Software", it
illustrates some good designs.

> Templates.

Well, keep in mind that the most powerful feature of templates, the "export"
keyword is not supported in any compiler yet.  Once it will be available
templates have a potential far greater than what i.e. Java offers for
reusable containers.  Basically the export keyword has the power to
completely delegate the choice of code reuse to the compiler.  Current
compilers will duplicate a lot of similar code, and some will then hope for
the linker to cleanup the mess.  Of course, this way a lot of potential
using the available information for optimization is lost :-(

    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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Probably too soon to ask, but what do you think of the CSDL language
> itself?

I am sorry, I only looked at the source code to find out more about your
basic programming skills.  There isn't enough time in the foreseeable future
to do anything else.

    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:
: return new SubClass(*this);

  Uh. That hurts my eyes.

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

>   I'm not completely sure what you are talking about, but that sounds a bit
> like very dubious coding.
>   Do you mean that your Copy() method allocates dynamically a new instance
> of its own type, copies itself to it and then returns a pointer to this new
> instance?
>   That really badly breaks modular OO design.

And how else am I supposed to get a copy?
That isn't exactly what it does, it relies on the constructor to copy 
the information, but a virtual Copy() method is the only way to make 
sure the correct constructor is called when I don't know the exact type.


> : Having to return void pointers and cast them to the 
> : correct types.
>   I never have to do this. It also breaks badly modular OO design.

Which is why I don't like it. I'll probably move to casting the data 
wrapper type to the right subclass, and having the subclasses return the 
data intact...that isn't really any prettier of a solution, but will let 
me get rid of the void pointers, which make me nervous.


> : Mostly having what I can do with an object being 
> : determined by the type of pointer to it I have, instead of what the 
> : object can do.
>   I don't understand this one.
>   Are you sure you fully understand object-oriented design?

In C++, if you have a derived object that implements a certain method 
not in its base class, but only have a base-class pointer to it, you 
can't call that method unless you cast to that type. It's a pain that 
produces ugly code, that's all. In Objective C, the methods you can call 
are determined by what the object itself responds to, at runtime, not by 
the type of pointer you have.


>   You are also talking too much about pointers. Sounds like you are using
> pointers for almost everything.

Pretty much.


>   This is C++, not Java. Here you can use true references and local 
> instances, true member instances. You don't need to use dynamic 
> allocation for everything, as in Java (in fact, it's usually a good 
> idea to not to use it unless it's justified).

I've been avoiding using references, I don't like them for the simple 
reason that a call passing a variable by reference looks exactly the 
same as one passing a variable by value, and I have a pointer most of 
the time anyway. Pointer syntax isn't that hard to figure out.
And I have to use dynamic allocation because the objects are going to 
stick around for an indefinite amount of time, they can't be deleted 
when the function goes out of scope. Local instances aren't that useful 
in this program, though I use them when I can.


> : Templates.
> 
>   What about them?

They make my head hurt. ;-)
They're fine unless there's a problem. If there's a problem, it's often 
very difficult to figure out what it is from the error messages. And the 
syntax looks like something just tacked onto the C language, but my 
complaint is mainly about the error messages they give. Fortunately, 
they haven't been causing me any trouble in CSDL...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Hi Warp, you recently wrote in povray.general:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> : return new SubClass(*this);
> 
>   Uh. That hurts my eyes.
Why? That's the standard way of cloning an object (standard in the
sense of widely used). Simply invoke the copy constructor on the
current instance. How else would you write a Clone() or Copy()
function?

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

On Wed, 23 Jan 2002 17:54:07 -0500, Christopher James Huff wrote:
> In C++, if you have a derived object that implements a certain method 
> not in its base class, but only have a base-class pointer to it, you 
> can't call that method unless you cast to that type. It's a pain that 
> produces ugly code, that's all. In Objective C, the methods you can call 

Only if you let it.

Clearly Warp hasn't asked the right question.  The right question is, why
do you have a base-class pointer if you want a derived-class pointer?  

The reason for all this is pretty simple.  If all you have is a base-class 
pointer, how do you know that it's a pointer to an instance of the right 
derived class?  Without more information, you don't.  The cast is how you 
tell the compiler that it's all right, you've thought of that, and you 
really do want to do what you're doing.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

In article <3c4f3723@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> And you don't need to duplicate any code at all.  Simply make your copy
> function virtual.  That way by default the copy function of the subclass
> will be called.  In that function simply write "return new SubClass(*this);"
> and all your problems are gone.

That's what I do, that was the duplicate code I was talking about...I 
just get tired typing that stupid one-liner in every time, when a 
subclass only needs to change one method.


> > Having to return void pointers and cast them to the
> > correct types. Mostly having what I can do with an object being
> > determined by the type of pointer to it I have, instead of what the
> > object can do.
> Hmm, this really should not happen. 

Yeah, I can get around it, but the code's not really any better. I'm 
going to redesign that portion of the code to use templates and get rid 
of the void pointers for the next alpha...


> Well, keep in mind that the most powerful feature of templates, the "export"
> keyword is not supported in any compiler yet.  Once it will be available
> templates have a potential far greater than what i.e. Java offers for
> reusable containers.  Basically the export keyword has the power to
> completely delegate the choice of code reuse to the compiler.  Current
> compilers will duplicate a lot of similar code, and some will then hope for
> the linker to cleanup the mess.  Of course, this way a lot of potential
> using the available information for optimization is lost :-(

I'm not sure quite what you mean...though if no compilers support it 
yet, I guess it doesn't really matter.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> In C++, if you have a derived object that implements a certain method
> not in its base class, but only have a base-class pointer to it, you
> can't call that method unless you cast to that type. It's a pain that
> produces ugly code, that's all. In Objective C, the methods you can call
> are determined by what the object itself responds to, at runtime, not by
> the type of pointer you have.

Not really.  dynamic_cast<> does exactly the same, with the only difference
that you have the choice of the object you actually want to respond.  It
protects you from getting a pointer to a base and then calling some method
by accident also you never wanted to call that method of that object.  In
C++ you are protected from this because you have to explicitly say _what_
you want rather than having the system take a guess and possibly giving you
something you never asked for.

Most important, dynamic_cast<> is fully type-safe, which seems to be what
you are missing.  Further, it is significantly more efficient because you
only do the dynamic casting once (by casting the first time you need to
access that particular object and storing the it in a local pointer of the
correct type), while in Objective C, for repeated calls to various functions
the compiler would have to employ (nearly) impossible analysis of the code
to turn it into just one call.  Thus it has to run the dynamic casting code
every time, which is extremely inefficient.

Apart from this, without dynamic_cast<>, multiple inheritance would be far
more difficult to use.

    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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> They make my head hurt. ;-)
> They're fine unless there's a problem. If there's a problem, it's often
> very difficult to figure out what it is from the error messages. And the
> syntax looks like something just tacked onto the C language, but my
> complaint is mainly about the error messages they give. Fortunately,
> they haven't been causing me any trouble in CSDL...

Like these two (yes, *two*)?  The errors were so simple, I don't even
remember what they were, and I am not going to track them down from this
message again!

Error   : function call 'insert(std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>)' does not match
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>>>>::insert(const
std::pair<const std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>> &)'
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>,
std::allocator<char>>>>>>>::insert(std::__tree<std::pair<const
std::basic_string<char, std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>>,
std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>>>>::value_compare,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>>>>::iterator, const
std::pair<const std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>> &)'
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::list<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>>>, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>,
std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>>>>>::insert<...>(T1_0, T1_0)'
povdocgen.cpp line 195   attributelists.insert(attribute, entries);


Error   : function call 'insert(std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor *)' does not match
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor *>>>::insert(const
std::pair<const std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *> &)'
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor
*>>>::insert(std::__tree<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor *>,
std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor
*>>>::value_compare, std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor *>>>::iterator,
const std::pair<const std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *> &)'
'std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, Processor *, std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, Processor
*>>>::insert<...>(T1_0, T1_0)'
povdocgen.cpp line 858   processors.insert(processor, this);



____________________________________________________
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