Printable View
What is this block supposed to do in zc_sys.cpp:
First, this is not legal C++ since the array size is not a constant expression.Code:bool b[joy[joystick_index].num_buttons+1];
for(int i=1; i<=joy[joystick_index].num_buttons; i++)
b[i]=joybtn(i);
Second, it seems like the block is dead code anyway since b is never read anywhere later in the function.
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.Quote:
Originally Posted by Gleeok
@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 (?).
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?Quote:
Originally Posted by Saffith
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.
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:
The coolest thing is actually stuff like this though;Code: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
}
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.Code: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
}