In article <3C4EED6E.32F4EB5E@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> I mostly meant 'system()', i think it would be good if you could have a
> confirmation before executing a program.

That would be a possibility...it would have three settings: always 
execute, ask, and never execute. The code would be conditionally 
compiled, so it could be specialized for specific platforms.

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

Post a reply to this message

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

> Here it is, first alpha release.

I didn't run or compile it, I just looked at the code.  I have to say it is
nicely formatted and good to read.  Of course some comments would help
others to understand, but nevertheless, your code is still fairly clear and
in parts seems like "Java style" to me (I don't know why, and it is meant
positive).

However, there is one thing you should really start adding soon:
try-catch blocks.  As it stands your program will just terminate if it runs
out of memory...

    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 <3c4f050d@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> I didn't run or compile it, I just looked at the code.  I have to say it is
> nicely formatted and good to read.  Of course some comments would help
> others to understand, but nevertheless, your code is still fairly clear and
> in parts seems like "Java style" to me (I don't know why, and it is meant
> positive).

Good to hear...I was afraid it would be an unreadable mess to anyone 
else. ;-)
Java style? Hmm...I have "learned" the Java language, but never bothered 
to learn the API, and I haven't done anything in it. Maybe it comes from 
my working with Objective C...I've heard both were inspired partly by 
Smalltalk. Or do you mean all the inline functions in the headers? That 
was just lazyness.
BTW, now that I've done some stuff in Objective C and am back working in 
C++, I'm beginning to see why people complain about the way C++ does OOP.
I'm constantly wrestling with it, trying to get it to do things that 
should be very simple with OOP, but have to be worked around because C++ 
isn't dynamic enough. Still better than raw C, though...
Probably too soon to ask, but what do you think of the CSDL language 
itself? Do you know of any other languages that use this concept of OOP?


> However, there is one thing you should really start adding soon:
> try-catch blocks.  As it stands your program will just terminate if it runs
> out of memory...

Error handling is definitely something I need to work on...I've never 
used exceptions before, and I've been putting it off. Right now I'm 
mainly working on plugging memory leaks...there's a lot of them, mainly 
due to a lot of the code being stubbed out or simply not implemented.

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

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: BTW, now that I've done some stuff in Objective C and am back working in 
: C++, I'm beginning to see why people complain about the way C++ does OOP.
: I'm constantly wrestling with it, trying to get it to do things that 
: should be very simple with OOP, but have to be worked around because C++ 
: isn't dynamic enough.

  Could you give some examples?

  (Funnily enough, I seldom have any problems with C++, but the rare cases
where I have to code something with Java, I have to "constantly wrestle" with
it because it has so many braindead limitations which force you to make
non-modular 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 <3c4f248e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   (Funnily enough, I seldom have any problems with C++, but the rare cases
> where I have to code something with Java, I have to "constantly wrestle" with
> it because it has so many braindead limitations which force you to make
> non-modular code.)

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. 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. Templates.

I haven't done anything in Java though, I don't really know what 
limitations it has. It might be worse.

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

Post a reply to this message

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