How much do you guys 'need' statics?

[avasopht]

I'm currently on a platform without statics of any sort and you cannot call new / delete during during DSP render and I'm wondering how much of an issue the lack of statics is in general.

Personally I and many others can cope, but a static -> scoped transpiler is a potential project of mine.

[Miles1981]

static as global variables ? We should not use them anyway.
If we can preallocate the vectors we need (and ensure that you would never callt he DSP code with an array bigger than a given amount), if we have enough room in the stack for temporary variables, I don't see an issue, it's close to what we have to do already.

[matt42]

static as global variables ? We should not use them anyway.

Well, unless you have large amounts of data and you want to share that data between all instances of a DLL. Image data for example or large wavetables. Stuff like that.

But yeah, using static data as a way around allocation during a DSP render/process loop seems like a bad idea.

[Urs]

We use static data for

shared coefficent tables
shared bitmap data
shared preset lists
parameter lists
user preferences
copy/paste among instances
probably much more

We could live without non-const static data, but we can't live without

const static blah something = blahFactory::makeBlah(someCase)

... which may not be allowed where non-const statics aren't

[Zaphod (giancarlo)]

We are using them for
- Shared gui elements
- Shared ir/kernels/data! Pretty everything which is constant and does not change

[avasopht]

Thanks for the replies. Just for clarification, I'm working with a particular platform that handles instances differently to typical VSTs, so there is no shared data between instances other than set data files with read only access. Copy / paste is handled by the host and there is no scope for user preferences!

Code: Select all

const static blah something = blahFactory::makeBlah(someCase)

This is the sort of case I imagined being the most common. In short, a static -> scoped transpiler could be lots of fun to write and it's well within my remit, I was just curious to know exactly how people are using and needing it as the word on the street is that it's not commonly needed in DSP (probably because all DSP is done in C right ).

The other use case was the use of smart pointers. Although they'll likely never be deallocated during the lifetime of the plugin, it would be of benefit should the code be used in another context where destruction was going to happen, say test cases or some other different type of usage.

[Big Tick]

Definitely need them in VIP, as all instances share a ton of things... plugins cache, database cache, UI resources, ....

[Miles1981]

I forgot that I'm using lots of static const int as constants (instead of C macro definitions). They should be converted by the compiler as constants, but I'm not sure what the compiler does if it thinks they should be exported.

[camsr]

I forgot that I'm using lots of static const int as constants (instead of C macro definitions). They should be converted by the compiler as constants, but I'm not sure what the compiler does if it thinks they should be exported.

Applies a VAT?
The preprocessor defines for constants are just parsed as the value in text, so it's no different to writing it as a constant the normal way. The same rules apply for datatype as well.

[Miles1981]

There is a difference, which is why I'd rather use static consts than defines: type safety. Another is better compiler messages.

[PurpleSunray]

Applies a VAT?
The preprocessor defines for constants are just parsed as the value in text, so it's no different to writing it as a constant the normal way. The same rules apply for datatype as well.

Not always.
static const int MAX_VAL = 5;
..
if (n > MAX_VAL) { ... }
Leads to MAX_VAL being stored on data segment, so the if leads to a cmp n, MAX_VAL_address
#define MAX_VAL 5
..if (n > MAX_VAL) { ... }
Does not add MAX_VAL to data segment, but the if becomes a cmp n, 5

(no clue if recent compiler still act like that, but I think they have to because you actually define that datatype, so it needs memory to store it (unlike with the #define))

[Max M.]

Not always.
static const int MAX_VAL = 5;
..
if (n > MAX_VAL) { ... }
Leads to MAX_VAL being stored on data segment

What compiler? All modern C++ compilers optimize this in release mode...

but I think they have to because you actually define that datatype, so it needs memory to store it...

No. Compilers do not have to store any data (even non constant) in memory until you actually use the address of that data (and even in that case it still can optimize a copy of that value to use no memory).

[PurpleSunray]

What compiler? All modern C++ compilers optimize this in release mode...

I will check later with current gcc and msvc, but I think this will be hard to optimize.
What happens if that type is no int, but has a constructor?
What does &MAX_VAL return if MAX_VAL is not on memory, but a compile time constant only? (what's the address of a compile-time defined constant? )

[camsr]

Not always.
static const int MAX_VAL = 5;
..
if (n > MAX_VAL) { ... }
Leads to MAX_VAL being stored on data segment, so the if leads to a cmp n, MAX_VAL_address
#define MAX_VAL 5
..if (n > MAX_VAL) { ... }
Does not add MAX_VAL to data segment, but the if becomes a cmp n, 5

(no clue if recent compiler still act like that, but I think they have to because you actually define that datatype, so it needs memory to store it (unlike with the #define))

Have you tried declaring the static const int inside a struct that is also a class member?
No idea if it's any better, never tried it, but structs are good.

[PurpleSunray]

Not always.
static const int MAX_VAL = 5;
..
if (n > MAX_VAL) { ... }
Leads to MAX_VAL being stored on data segment, so the if leads to a cmp n, MAX_VAL_address
#define MAX_VAL 5
..if (n > MAX_VAL) { ... }
Does not add MAX_VAL to data segment, but the if becomes a cmp n, 5

(no clue if recent compiler still act like that, but I think they have to because you actually define that datatype, so it needs memory to store it (unlike with the #define))

Have you tried declaring the static const int inside a struct that is also a class member?
No idea if it's any better, never tried it, but structs are good.

Not yet
I switched to use unnamed enums like: enum { CONST_VAL1=1, CONST_VAL2=2, }, but it was not really because of statics aded to data segment, but because of the nice 'goodies' of an enum like being unable to use same value twice, auto-completion/intellisense working properly (if that enum is inside a struct), ect pp