[KiLLeR.]

PHP Code:

const test = 3
new const test = 3 


When should use const without 'new' in front of it?

[Natsheh]

New const for arrays i guess and const for integers and bitsum as far iknow but im not so sure

[klippy]

You can use "new const" for anything basically, even single cell values. It looks like the difference is that "const" alone functions like it is a define, so these two are equal:

PHP Code:

#define myValue 1337
const myValue = 1337; 


these values are replaced at compile-time and in run-time are actually constants embedded into the assembly itself. By the way, always use const in this case because they have tag safety.
Values defined with "new const" on the other hand are found in DATA section of a plugin, and accessing those values is slower. The thing is that "const" alone can only be used with single cell values, which means that arrays have to be defined with "new const".

To test it yourself, try defining a cell value in your plugin with "const", then "new const". The second time you compile it you will see that your plugin will grow by 4 bytes.

[Depresie]

Thanks for the answer Klippy, it is good to know

You should create a tutorial some day explaining this kind of things around here...

[addons_zz]

Code analysis:

Source code used:

#include <amxmodx>

#define VERSION "1.0"

public plugin_init()
{
    new const var = 1;
    
    server_print( "%d", var );
}

Assembly code for proof:

Originally Posted by KliPPy these values are replaced at compile-time and in run-time are actually constants embedded into the assembly itself. ... Values defined with "new const" on the other hand are found in DATA section of a plugin, and accessing those values is slower.

Yeah, we can see it on the assembly code, using 'new const' we have to move the stack,
and pass the address of the variable 'fffffffc' when loading the 'pri' register.
But when using only 'const' we do not used its address, we loaded straight 1 on the 'pri' register.

While using only 'const' is faster because we do not need to move the stack,
neither load the value by its memory address 'fffffffc'.

Here on this image below, we can see how the memory is organized. On it, we can note that
our stack variable ''fffffffc' was really on the stack, as its address started on from the top to down.

Originally Posted by KliPPy To test it yourself, try defining a cell value in your plugin with "const", then "new const". The second time you compile it you will see that your plugin will grow by 4 bytes.

This is valid for global variables, for local function variables, it is not only 4 bytes,
as we could see on the assembly code, it grow a little more (16 instead of 4) when using new const.

                    const           new const        Differences
Header size:               0 bytes         0 bytes       0
Code size:                96 bytes       112 bytes     +16
Data size:                12 bytes        12 bytes       0
Stack/heap size:      16.384 bytes    16.384 bytes       0
Total requirements:   16.492 bytes    16.508 bytes     +16

While, it would grow 4 bytes on the 'Data size' when using global scope.

                    const           new const       Differences
Header size:              0 bytes         0 bytes           0
Code size:               92 bytes        92 bytes           0
Data size:               12 bytes        16 bytes          +4
Stack/heap size:      16384 bytes     16384 bytes           0
Total requirements:   16488 bytes     16492 bytes          +4

Source code used:

#include <amxmodx>

#define VERSION "1.0"

new const var = 1;

public plugin_init()
{
    server_print( "%d", var );
}

Assembly code for proof:



Note that when using 'new const' was done 'load.pri 0', where 0 is the address of the first variable on the heap.
While when using 'const' was done 'const.pri 1' which directly load the constant 1 on the 'pri' register.