joystick code

[DarkDragon]

What is this block supposed to do in zc_sys.cpp:

bool b[joy[joystick_index].num_buttons+1];
    
for(int i=1; i<=joy[joystick_index].num_buttons; i++)
    b[i]=joybtn(i);

First, this is not legal C++ since the array size is not a constant expression.

Second, it seems like the block is dead code anyway since b is never read anywhere later in the function.

[Gleeok]

What I want to know is how the compiler can figure out what to do with that when it's not allowed to optimize it away. -_` ...Does it still compile if you add the volatile keyword?

As far as the code goes, I have no idea. Just rip it off like a smelly band-aid. :) Actually, I hate all the joystick code in ZC. If porting ever goes somewhere I volunteer to rewrite it.


[edit]
Ah wait a minute - variable length arrays in c++! Cool. Saffith: What compiler are you using?

[ZoriaRPG]

What I want to know is how the compiler can figure out what to do with that when it's not allowed to optimize it away. -_` ...Does it still compile if you add the volatile keyword?

As far as the code goes, I have no idea. Just rip it off like a smelly band-aid. :) Actually, I hate all the joystick code in ZC. If porting ever goes somewhere I volunteer to rewrite it.


[edit]
Ah wait a minute - variable length arrays in c++! Cool. Saffith: What compiler are you using?

He's using gcc via MSYS/MinGW. Same as me, now.
@DarkDragon There's plenty of unused rubbish floating in there. I believe that variable-length arrays are legal in some C++ standards. They are defined in C99, for instance, and IIRC some extensions supported them for a while (?).

[Saffith]

Could've sworn VLAs were allowed by the standard, but, yeah, seems to be compiler-specific. Maybe better not to do that, then. I've only tried it on GCC on Linux.
There are two or three arrays like that. They used to be fixed-size, but they were too small, and I found lots of buttons not responding. I didn't really look at what the code was doing beyond the array size.

[ZoriaRPG]

Could've sworn VLAs were allowed by the standard, but, yeah, seems to be compiler-specific. Maybe better not to do that, then. I've only tried it on GCC on Linux.
There are two or three arrays like that. They used to be fixed-size, but they were too small, and I found lots of buttons not responding. I didn't really look at what the code was doing beyond the array size.

Well, does VC2015+ not support it? All recent builds of gcc should. How about code::blocks?

It's probably goin to be supported more readily in coming years, so maybe adding some compiler definitions could work, too, but IDK. It depends how important it is.

I read up on this three years back, as it was something that I wanted to be able to do. (In fact, I'd love to add variable-sized arrays to the scripting language, as it's very useful, IMO.)
@Gleeok : I would be willing to help, if I can. I wanted to add some other joystick code to 2.54 anyway. I think our present input support leaves much room for improvement, new back end, or otherwise.

[Gleeok]

VLA's in general were considered to be a bad idea in C99, and the itty-bitty-shitty-commitee for c++ only seems to care about non core language things, templates, stl crap; they would never put in something as type-unsafe as VLAs.

I took about 20 minutes today to try and improve upon VLAs and alloca(), and came up with this:

void Proc() {
  LOCAL_STACK(4000); // No way to emit this without compiler support.

  Foo* foo = stackalloc Foo();
  Bar* bar = stackalloc Bar[64];
  u8* buffer = (u8*)stackalloca(MEGABYTES(8)); // Perfectly safe! Fall back to backing allocator.

  //cleanup if any
}

The coolest thing is actually stuff like this though;

StackArray<char*> ScanDirectory(const char* path)
{
  StackArray<char*> filenames;
  //get all the files in the directory without allocating memory

  return filenames; //no local sp, does not reset from scope.  // no deep copy
}

Which (to me at least) is better and safer than VLAs and alloca(). Of course I'd have to benchmark this in actual code, but I suspect it's only 4 asm instructions overhead over the fixed "char buf[2048]" approach.