 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
> >
> > Of those, only case 3 looks like possibly decent use. Case 1 and 2
> look very
> > problematic.
>
> Java handles case 1 with a labeled break, doesn't it?
>
> Johannes.
Yes. Which is a bit different. Personally I try to avoid that also.
Among other things you might get a problem of buried meaning. Usually I
code first for correctness and clarity. Then if I get a performance
bottleneck, I go in, but only after measuring actual performance.
But also I usually don't do intense mathematical algorithms, so that may
be another factor.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ij net>
> wrote:
> > So what is the difference other than a different syntax? The 123
> > ways to create a loop? They all do the same thing in the end.
> > Even step = 3 with I=I+3.
> > Introducing additional syntaxes raises more problems than it
> > solves. With one elementary syntax that can do everything there
> > isn't nearly as much to read and a hundred fewer places for
> > parser differences to creep in.
> The only difference is syntax. But that is a meaningful difference.
> Although a for loop could also be implemented as a while loop, it can
> sometimes be easier to write and understand if written as a for loop.
Actually I would say it is usually more famliar which makes it
appear easier to understand.
> And what do you mean by "a hundred fewer places for parser differences
> to creep in"? I don't think the modifications would be very extensive,
> and there is only one parser.
I mean implementation differences. On an i++ while you can get a
debate started among purists as to while i < 5 should bail out or
4 or 5 in that should the < be checked before or after evaluating
and changing the variables in the loop.
You can get another debate on permitting i to be both integer
and float.
This stuff may be OBE since the late 70s when was being paid to
look into it perhaps due to the dominance of C or the later
developments of Wirth after Pascal.
> > Next, complex conditional if then else statements. Can GOTO be
> > far behind?
> Umm, we have if-then-else statements. And switch statements. And goto is
> a bad idea for many reasons.
Without GOTO all branches are conditional to another routine.
Permitting GOTOs to exist after falling out of a routine simply
because it is sequencial is what we called spaghetti code. If you
have GOTO you have unconditional GOTOs.
They are nasty little buggers when they show up in late night
sessions. Never want to meet on in the dark.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
> In "The Art of Computer Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.
Does he use it in TWO algorithms? or just one?
And what is his overall opinion of it?
BTW: I think I went through that once and don't remember it.
I do remember going through someone's Atari BASIC code once
trying to make sense of it. It was good. I even approached the
author with money for markeing if he could clean it up.
He said he could not clean up his own code as the GOTOs were
workarounds of things "too hard" to correct rigorously. And the
problem with that the possibility of added functionality was as
dependent upon his memory as his ability.
If his mind were off of it for a month, it was frozen code.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> You are right.
> However I think there are some places where the use of goto (at least in
> C and C++) is more or less reasonable:
To rephrase Case 1
> - Case 1:
label1: for(cond1)
label2 for(cond2)
while(cond3)
if(skip) goto end_loops elseif (cond1) goto label1
then goto label2;
end_loops:
Real quick and I won't swear to it, that should be look for kbd
'L' and then 'ogin'
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In all seriousness, object oriented would work very well for POV-Ray, since it
> models... objects!
Jon,
You havn't raised XML in this thread - I think it is quite an
appropriate opportunity to talk about it. People are used to
the HTML idea generally, but HTML has evolved into a bit of a
mess, so it may not be a great idea to suggest XML from this
viewpoint... (sigh)
Anyway, XML is a way of passing data which avoids the need
for a hard-coded parser in the application. The "file format"
is editable, meaning that it can be extended quite easily
and that new tags for specific purposes do not crash parsers
that don't know what to do with the information. Also,
somthing using XML would be familiar to anyone who's used
HTML or XML for something else.
An example of what code may look like?
sphere {
<0, 0, 0>, 1
pigment { Blue }
translate -0.5*x
}
Perhaps:
<POVSCENE>
<SPHERE>
<POSITION> 0,0,0 </POSITION>
<RADIUS> 1.0 </RADIUS>
<PIGMENT>
<COLOR> BLUE </COLOR>
</PIGMENT>
<TRANSLATE> -0.5*x </TRANSLATE>
</SPHERE>
</POVSCENE>
The question is, I suppose, whether all these TAGS would be
intimidating to a new user, or someone who has spent a lot
of time learning the current scheme.
One thing to keep in mind is that editors could be a lot
smarter using XML than would be possible with a custom
file format. It would be very easy to allow a tree-edit
style, rather than flat text. It would also be easy to
guarantee a well-formed scene without running it through
POV to see if it parses alright.
I guess that XML would imply something of a hybrid mode
of editing between flat text and 3D modelling, which could
possibly unify these two ways of doing things. (I think
I could edit a tree-based editor without a mouse, but I
think a lot of the time I'd rather point-click and select
a colour, rather than typing "Orange", at the other extreme,
die hards that want to edit XML tags, are always free to
do so, without loosing the niceness of drag-and-drop, and
gatgets like that.)
What happens if we want to add new attributes to
a sphere? For example, for a gravity similation
system we also want the mass of the sphere...
In this situation, you extend the definition for
POV XML, add a tag <MASS> which is allowed to
occur in the scope of <SPHERE>, and on the programming
side, add a field to store the mass and initialise
it from the XML intermediate data in the XML parser.
POVray without support for the <MASS> tag, simply
ignores it.
One implication is that there are probably other efforts
to figure out generic DTD's (XML based file formats) for
3D objects, which could form the basis for a POV DTD.
In fact, by making all of the POV specific stuff optional
extensions, you have a good chance of importing and
exporting without running you files through conversion
tools.
I'm no XML expert, but it seems to me that it should at
least be considered, considering the advantages of it.
A few limitations of XML that come to mind - the typing
scheme is limited to "weak typing" which means that really
any text can be inserted between tags, whether it's supposed
to be a floating point number, radius, vector, or whatever.
So POV would probably still barf sometimes.
Nigel
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> One implication is that there are probably other efforts
> to figure out generic DTD's (XML based file formats)
Check out http://www.vrml.org/x3d.html, the working group
who are figuring out how to migrate VRML to XML.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Giwer wrote:
> Nieminen Juha wrote:
> >
> > You are right.
> > However I think there are some places where the use of goto (at least in
> > C and C++) is more or less reasonable:
>
> To rephrase Case 1
>
> > - Case 1:
>
> label1: for(cond1)
> label2 for(cond2)
> while(cond3)
> if(skip) goto end_loops elseif (cond1) goto label1
> then goto label2;
> end_loops:
>
> Real quick and I won't swear to it, that should be look for kbd
> 'L' and then 'ogin'
<shudder>
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote in message <38cb9a68@news.povray.org>...
> Also this new syntax would be very handy sometimes:
>
>#do
> ...
>#until(whatever)
>
> There really are times, where you want to execute the body of the loop at
>least once before the ending condition is tested (for example the condition
>is calculated in the body of the loop).
> With the current #while-loop you would have to calculate the condition
>in two places: First before the loop, and then inside the loop. Copying the
>same code to several places is not a good thing.
Adding this to the parser would be pure hell. EVERY other code block in the
language ends with "#end", making it impossible to mismatch block the start
and end of a block. However, a "#do...#until()" would allow constructs such
as:
#do
/* Do something */
#if(1 = 2)
#until(a = 3)
#end
or
#do
/* Do something */
#if(1 = 1)
#until(a = 3)
#end
The parser would need to be able to recognize this sort of construct and
then recognize that the first case will cause serious problems, but the
second one is fine.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > One implication is that there are probably other efforts
> > to figure out generic DTD's (XML based file formats)
>
> Check out http://www.vrml.org/x3d.html, the working group
> who are figuring out how to migrate VRML to XML.
>
Arrrggg!!! Heelllppp!!!!
Run Away! Run Away!!!
Ok. sorry. it's not really all that bad. It's just that for many things,
VRML seems reaaaaaaaaaly ugly. Especially things like needing to
actually create a visible object before being able to reuse it, etc.
But, the big point of there being 3D XML efforts underway is a good one.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Matt Giwer <jul### [at] ijnet> wrote:
> : Introducing additional syntaxes raises more problems than it
> : solves.
>
> I don't think so.
> A more compact and clearer syntax makes the code more readable and minimizes
> the possibility of errors.
> For example, suppose you have this:
>
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
> ...
> (30 lines of code)
> ...
> #declare XLoopindex1 = nextValue();
> #end
Make weird_indexname
mark and copy weird_indexname
<CR><CR>
#declare weird_indexname - weird_indexname + whatever
Then go back to the <CR><CR> and insert code. One does know what
one intends before writing one hopes.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
