Try putting the default after the two cases? *shrug* Got me beat on that one...
This kind of thing would be better done with object superclasses than templates, though. Generates less code, in any case. But that has nothing to do with your error...
Only thing that I can think of is that the two lower statements do not have break statements, and the compiler is having issues with it. Don't know how a switch statement deals with continue(even though we know the continue is for the loop and would break out of the switch anyways). Do you need breaks after the continues? It will never execute, but the compiler flag may require it and not take into consideration a continue statement.
That could be it, although I'd be a little surprised if the compiler was so 'silly' as to not "see" the default case. But, it's worth a try. But then will it generate unreachable code warnings? :P
No, it didn't generate unreachable code warnings. And I had the default case under the other two before I posted. I've even changed the continue; statements to break; statements with no change. Maybe a compiler bug? :P
You mentioned this being better done with an object superclass. Could you explain that and provide an example?
So putting in breaks worked? Funky. :) What version of gcc do you have?
Well, my guess is that you're trying to unify the handling of oprogs, mprogs and rprogs. What could be done is to have all three of those structures inherit from a single 'prog' structure, one that contains all common variables e.g. arglist, proglist, fileprog...
It's not a big deal, really. Personally I try to do that kind of thing just because it makes things more organized (IMO, at least).
No, putting in breaks didn't change anything, it still complains.
As far as the superclass thing, ok, so you're talking about inheritence then. I haven't messed with that yet, but this looks like a good time to try I suppose. :)
EDIT:
Er... nevermind. I just remembered why this was done this way. mud_prog_data is all common to mobs/objs/rooms. It's the lists on each, mob_index, obj_index, and room_index that caused me to write this template.
prog_target is either a mob, obj, or room index. And if you look at how mprog_file_read is working, the function will attach multiple scripts to one of these from a single file, so intereting won't really help here.
I guess I'll just leave this warning switch out now that I've fixed all the other legitimate places it was complaining.
Yeah, I was talking about inheritance. There are some potential headaches but for this kind of relatively simple setup, it's not too bad.
As for the original problem, it's hard for me to replicate your situation exactly, but I tried the following:
Quote:
#include <iostream>
using namespace std;
int main()
{
int arr[10] = {1,2,3,4,5,6,7,8,9,10};
int i = 0;
for ( ;; )
{
switch ( arr[i] )
{
default:
cout << arr[i] << endl;
break;
case 1:
case 2:
case 3:
case 4:aybe your version of gcc is confused?
case 5:
case 6:
case 7:
case 8:
case 9:
cout << "woot" << endl;
continue;
}
i++;
}
return 0;
}
I also tried with the pedantic flag, no difference. This template is the only thing it's complaining about. Your test isn't using a template, so I'm not surprised it worked. Take out your default: tag and retest, it should complain.
This may seem an odd place to ask this, but what would it take to convert C to C++? I'm thinking of moving over to C++ myself. Sorry this may be an odd place to ask, but since you're talking about it...
#include <iostream>
using namespace std;
template <typename ArrayType>
void foo( ArrayType * arr )
{
int i = 0;
for ( ;; )
{
switch ( arr[i] )
{
default:
cout << arr[i] << endl;
break;
case 1:
case 2:
case 3:
case 4:
case 5:
case 6:
case 7:
case 8:
case 9:
cout << "woot" << endl;
continue;
}
i++;
}
}
int main()
{
int arr[10] = {1,2,3,4,5,6,7,8,9,10};
foo<int>(arr);
return 0;
}
continue (as opposed to break) is not a valid statement inside of a switch body. (why would you put a continue in there anyway?)
I'll bet the problem is with GCC expecting to see default after all the rest of the cases, which is customary, but (apparently) not required by the standard.
If it's a switch statement in isolation, then sure, it's not valid... but this is a continue statement inside a switch inside a for loop, so it's perfectly valid.
It might just be a gcc bug that was fixed in later versions. I can't reproduce the error, but that doesn't necessarily say a lot since I didn't reproduce the entire situation.
Oh, right, but still, why would you put a continue there, when a break would work just as well? There's nothing after the switch statement, does it compile better?
Anyway, the 'more correct' way to use continues would be to include a break after the continue, for each case; this way if you want to remove the continue statement (for debugging, or if you want to do something after freeing memory) you'll still have the correct behavior (as opposed to deleting it once for ERROR_PROG and again for IN_FILE_PROG.
The original function I modified had the continue statements there, I changed it after realizing they looked silly. It didn't make any difference at all with regard to this error.
I am using GCC 4.0.1 right now, so I guess I need to get this tested under an older version to see what kind of results come back from it. I do have to wonder if I've stumbled onto some kind of odd compiler bug :P
Interesting. I assumed (more out of hope than anything else) that you had an older version of gcc. I tried it on 4.0.1 and can confirm getting the same error, with the exact same code I posted. I tried putting the default: below the case: statements, but no luck.
It very well could be a bug. When I remove the template, it generates no error. Template support causes headaches and it wouldn't surprise me if there were an error, somewhere... Chances are that if "someone" ( :-) ) goes looking on their bug list, this might already be there.
Heh, I have no problem going over their bug list, and submitting the case if need be. You have a much shorter testcase to illustrate the problem than I do :) This would technically fall under a regression since it worked in previous versions of the compiler.
In the event someone more knowledgable than I cares to have a look, I submitted a bug to gcc about this issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23959