next »

[qbproger]

I know of a few ways to end an outer loop, and don't think either are that well known.  I was wondering which of the following I should use in the parser.

finally blocks ALWAYS execute no matter what, and this takes advantage of that.

Code:

try {
for(int i=0; i<10; i++) {
 switch(i) {
  case 1:
   break;
  case 2:
   return;
 }
}
} finally {
 // execute this after the return statement
}

This is another construct, that I don't think is that commonly used, but also available.

Code:

outer:for(int i=0; i<10; i++) {
 switch(i) {
  case 1:
   break; // breaks only switch statement
  case 2:
   break outer; // breaks outer for loop
 }
}

Right now, I have the code using the try/finally method but it wouldn't be a huge deal to switch it to the named loop method.  Let me know what you think.

[Marvin Fröhlich]

"try" can be a performance issue, and should not be used, where not necessary. The named loop way is IMHO ugly.

Why not simply push the loop into a separate method. That would do the trick, wouldn't it?

Marvin

[qbproger]

And option number 3 pulls into the lead.

It'll take a bit of time, but I'll get it going now.  After this is done, I'll re-run the models.  If everything runs smoothly I'll do a commit tonight.

[Mathias 'cylab' Henze]

INHO the named loop is the way this should be handled in java - even if it looks ugly.

But I would write:

Code:

for(int i=0; i<10; i++) outer: {
 switch(i) {
  case 1:
   break; // breaks only switch statement
  case 2:
   break outer; // breaks outer for loop
 }
}

to make it look a bit better.

[qbproger]

I already re-did it as separate functions.  Only the classes that need separate functions have them though.  I liked only having one function though.

Now I have:

Code:

parser()
{
  doParsing();

  // what I wanted after the loop
}

On the ones that needed something checked.

[Marvin Fröhlich]

INHO the named loop is the way this should be handled in java - even if it looks ugly.

But I would write:

Code:

for(int i=0; i<10; i++) outer: {
 switch(i) {
  case 1:
   break; // breaks only switch statement
  case 2:
   break outer; // breaks outer for loop
 }
}

to make it look a bit better.

Wow. Strange, that this is even allowed in Java. The named mark in this example is inside of the loop construct and doesn't emphasize, that it is a mark to jump out of the loop. Even uglier IMHO .

Marvin

[Mathias 'cylab' Henze]

A label can mark arbitrary code blocks, you could write for example:

Code:

myparsercode:
{
    // do some stuff
    // (...)

    if( breakoutOfThisBlock ) break myparsercode;

    // if not break out do some other stuff
    // (...)
}

// code that will be executed after break myparsercode;

Even uglier IMHO .

hehe

[qbproger]

So, I guess separate functions is the best way to go.

[Marvin Fröhlich]

So, I guess separate functions is the best way to go.

I don't think, there's a general best way. But it's the way, that I would go .

Marvin

['n ddrylliog]

I'd have to agree with Mathias here (no offence intended, Marv). Creating a new function for outer loops that should be "broken" probably reduces performance (function call, passing arguments, etc.)
Labelled loops are here precisely for this purpose, and I don't think they are so ugly. Just make their name meaningful!

[qbproger]

I'd have to agree with Mathias here (no offence intended, Marv). Creating a new function for outer loops that should be "broken" probably reduces performance (function call, passing arguments, etc.)
Labelled loops are here precisely for this purpose, and I don't think they are so ugly. Just make their name meaningful!

Already changed this to the way Marvin suggested.  I'd prefer not to change it again...

I haven't had much time to work on the Collada Loader lately. I'm hoping in December my life becomes less hectic, and I have time to work on it.

qb

[Marvin Fröhlich]

I haven't had much time to work on the Collada Loader lately. I'm hoping in December my life becomes less hectic, and I have time to work on it.

That's good news .

['n ddrylliog]

I'd prefer not to change it again...

Ok, ok.
I should really take a look at this loader's code one day =) curious how far you've gotten. Maybe you can join me in the "COLLADA specs haters" league ?

[qbproger]

I'd prefer not to change it again...

Ok, ok.
I should really take a look at this loader's code one day =) curious how far you've gotten. Maybe you can join me in the "COLLADA specs haters" league ?

Actually, of the formats I've had to work with, COLLADA is one of the more pleasant ones.  I've only worked with 3 or 4 3D file formats extensively, and most have been binary with a proprietary API.  While the spec is huge, the parts that need to be implemented to cover a good number of models doesn't seem to be.

The one thing that I do really hate about it, is the lack of LODs.  It's nice that it's in XML.  It'd be a real pain to write a Java API for a binary format. >.>  I really wish Java had unsigned types.

[Marvin Fröhlich]

The one thing that I do really hate about it, is the lack of LODs.  It's nice that it's in XML.  It'd be a real pain to write a Java API for a binary format. >.>  I really wish Java had unsigned types.

Certainly the lack of unsigned types is a mess. But writing a loader for a well documented binary format is IMHO much simpler and more straight foreward than using some strange XML API and messing around with a bloated XML format.

Marvin