compiler icon indicating copy to clipboard operation
compiler copied to clipboard

static constant as Array size

Open samphunter opened this issue 9 years ago • 16 comments

const Size = 5; new data[Size]; // Works fine

static const Size = 5; new data[Size]; // error 008: must be a constant expression; assumed zero

samphunter avatar Jun 19 '15 11:06 samphunter

The compiler treats static constants as "variables". Since, it is considered to be a variable instead of a constant, you are getting that error.

Static constants are declared as variables. https://github.com/Zeex/pawn/blob/master/source/compiler/sc1.c#L4976 https://github.com/Zeex/pawn/blob/master/source/compiler/sc1.c#L2160

non-static constants are declared as constants. https://github.com/Zeex/pawn/blob/master/source/compiler/sc1.c#L5050

findconst does not consider static constants as constants which is causing the problem.

YashasSamaga avatar Dec 26 '16 18:12 YashasSamaga

Thanks to @VVWVV's work, starting from release 3.10.2 it's possible to use static enumerations to define constants with a scope limited to a single file.

static enum { ARRAY_SIZE = 20 };
new a[ARRAY_SIZE];

@Southclaws, you probably want to close this.

Daniel-Cortez avatar Jan 05 '18 20:01 Daniel-Cortez

@Southclaws @Daniel-Cortez In my opinion, the issue is still not resolved. As const non-static variables can be used as array length, static const should also be allowed. Yes, there is another way out but the ability to use static const as an array argument isn't resolved.

As a matter of fact, we still can't create local static constants. Using a static enum would pollute the global namespace of the file when you just want the constant to remain visible just within a function or a block.

YashasSamaga avatar Jan 06 '18 11:01 YashasSamaga

Ah I misread the post from Daniel and thought static const was resolved.

Southclaws avatar Jan 06 '18 11:01 Southclaws

@YashasSamaga, so how do you imagine "fixing" this? Treat all identifiers defined with static const as compile-time constants instead of read-only variables? Such change can probably break existing code.

Daniel-Cortez avatar Jan 06 '18 11:01 Daniel-Cortez

If const works, surely static const isn't much different? The only difference is the access constraint to the section/file it's in.

Southclaws avatar Jan 06 '18 11:01 Southclaws

@Daniel-Cortez Hmm, I get your point. I think my own code will get screwed if static const is treated as compile-time constants because I access it through assembly.

Why not simply use the value of the static const variable as a compile-time constant and leave the variable as it is?

EDIT: I see. The fix is pretty complicated: will have to make a new entry or use an existing entry in the symbol structure to store the initialization value for local static constants.

YashasSamaga avatar Jan 06 '18 13:01 YashasSamaga

If the fix is complicated, is this really worth the work? Symbolising constants with #define is good enough, right?

Southclaws avatar Jan 06 '18 13:01 Southclaws

Not sure if there is a better solution but the solution I mentioned is awfully bad as it involves adding a new member to the symbol structure just for the sake of static const variables so that they can be used to set the size of an array.

YashasSamaga avatar Jan 06 '18 13:01 YashasSamaga

Also it would be pretty strange to the same identifier acting as both a variable and a compile-time constant at the same time, IMHO.

Daniel-Cortez avatar Jan 06 '18 13:01 Daniel-Cortez

@Southclaws Well you would have to use #undef at the end of the file to simulate static. But in a way, yes. You can use the enum trick now, as was mentioned before. Fixing this at this point would just allow for slightly nicer code and would make constants more consistent.

It is up to you to decide, whether making constants behave consistently (currently, const behaves differently from static const, which it probably should not) is worth the effort or not.

I mostly wanted this fixed, because static enums were not a thing back then.

samphunter avatar Jan 06 '18 14:01 samphunter

Also it would be pretty strange to the same identifier acting as both a variable and a compile-time constant at the same time, IMHO.

Global consts already do that, as they are compile-time constant. IMHO anything static should work like the global equivalent, just with reduced scope - be that file level or function level; if global consts can declare array sizes (TIL), then IMHO so should static consts. "It breaks #emit code" is not really a great argument against things, and I say that as someone aware that it might break their own code. Writing #emit is already beyond the scope of PAWN, and is generally used to bypass language constraints.

Y-Less avatar Jan 06 '18 14:01 Y-Less

strings with just const cannot be declared (because plain const makes the symbol a compile time constant but strings cannot be compile time constants) but static const can declare an array

If we make static const behave like compile-time constants, it would break code.

YashasSamaga avatar Jun 24 '18 03:06 YashasSamaga

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Oct 26 '18 16:10 stale[bot]

I know this issue is kind of old, but since it's still not fully resolved, what if we introduce a static const const combination of class specifiers, which would allow us to tell the compiler we want an actual constant and not an immutable variable? Even though we have static enumerations now, they're still not the same thing, as their syntax is completely different from single constant declarations.

Daniel-Cortez avatar Dec 23 '20 13:12 Daniel-Cortez

This issue has been automatically marked as stale because it has not had recent activity.

stale[bot] avatar Jun 22 '21 17:06 stale[bot]