-1

Inside of my program I am trying to define an array of floats that are very globally accessible within the program. These are just for development purposes so I am trying to achieve this array using the fewest amount of code changes.

I do realize that this is VERY bad programming practice and style but I am on a single developer project and this code will only be there for a day or two on a separate branch of the codebase.

The array needs to be accessed from 2 parts of a very large codebase and I dont have a lot of ways for these two sections to communicate with each-other without a lot of issues.

I am considering two designs:

globalTweakingArray.h

v1

#define TWEAKING_ELEMENTS
float tweakingArray[TWEAKING_ELEMENTS];

v2

#define TWEAKING_ELEMENTS
float *tweakingArray;
// Where can I malloc this

Now my confusion comes from how these are used, what address space they are in etc etc. The goal would be that within a-couple c++ source files they can #import "globalTweakingArray.h" and all be reading and writing the same values.

I am a bit confused about the implications of global variables here so I am not certain what dangers come with the design of v1 and v2. Furthermore I am not even sure how I can malloc some space for the array in v2.

Are either of these designs the correct way to define a global array? What are the dangers that come with either? Are they even the correct way to define this global tweaking array?

Side-Note: One of the places I will be accessing this array from is objective-c source. That shouldn't matter right? A float is a float and a pointer is a pointer right?

J.Doe
  • 1,502
  • 13
  • 47
  • 1
    First question: Why a global variable? These are problematic and usually bad design, so they're best avoided. Wrapping this in a function which provides access to the underlying data gives you a thin but important layer of abstraction and can hide implementation details like this from other parts of your code. Something like `float getTweaking(size_t index)` is super easy to implement and compiles down nice and neat with optimizations. That can lazy-initialize the array, load data from a file, or whatever, it's entirely up to you. – tadman Jul 14 '19 at 22:11
  • I like that idea for sure. So if I were to implement v1 and then a getter and setter function all code importing that header would be seeing and setting the same values? – J.Doe Jul 14 '19 at 22:31
  • It gives you the latitude to change your mind about how it's done *without changing the interface*. Then the distinction between v1 and v2 is purely an implementation detail, not a decision that has far-reaching consequences. – tadman Jul 14 '19 at 22:41
  • Have you ever asked why certain variables or functions are declared [`extern`](https://stackoverflow.com/a/496476/7478597)? As you mentioned Objective C, I googled again (as I've no experience) and found [SO: Use of extern in Objective C](https://stackoverflow.com/a/1946571/7478597). ;-) – Scheff's Cat Jul 15 '19 at 05:27

1 Answers1

1

After looking into potential solutions here is the solution I ended up going for. Having the variable in the header ended up also causing some compiler issues so I have the following set up now.

Header

#define TWEAKING_ELEMENTS 10

float getTweaking(int i);
void setTweaking(int i, float val);

Implementation

float tweakingArray[TWEAKING_ELEMENTS];

float getTweaking(int i) {
    return tweakingArray[i];
}
void setTweaking(int i, float val) {
    tweakingArray[i] = val;
}

Keep in mind that if you have objective-c code referencing this c++ code the objective-c code needs to actually be objective-c++ this means the file must be named ending in .mm. This may introduce additional complications.

J.Doe
  • 1,502
  • 13
  • 47