On Tuesday, 25 January 2022 at 12:07:31 UTC, Ola Fosheim Grøstad wrote:

Yeah but what if it makes sense for these places to mutate it? For example, I'm making a parser for my language and each different statement will be parsed from a function that will be in a different file. It makes sense for those files to be able to mutate some global variables.

I don't know about most of this terms and I know only a little about multi-threading programming. So thank you, I will make my research and this info will come in handy!

Actually the example I made with the parser will explain that too. I want some specific files to be able to access the global variables. If they are only local to a file then they don't help me a lot and I still have to use pointers to modify that specific data.

Thanks! Why talking about allocations tho? We will not need to allocate any memory to pass a pointer to a function and then deference it. Of course if you think that you will push it to the stuck in your main function and then you will call all the other functions in the top.

Well yeah! However, embedded programming is an advanced topic so I suppose different rules apply there anyways...

Thanks a lot!!

I think it's especially important for compilers to not use global state because you want to be able to localize every single issue right away to a specific unit in the compiler.

That's not the reason. Global variables are hard to control and review. That is, if a variable is global, how do you know it's not misused? The point of not using global variables is to reduce the surface area of the program that needs review to ensure it's correctly used.

In some cases, they make sense, and in those cases, I'd recommend at least guarding the direct access to the variable through properties so you can control how it's used.

1. Declare the variables in a function, then run your algorithms inside inner functions. They all now have access to the variable. I'm surprised at how many complex problems and APIs become super-straightforward when you start using local functions (even templated ones).

2. Enclose the data and methods in a struct, even if that struct is a struct inside a function. This is a necessity if you have mutually recursive functions, since a local function cannot call another local function that hasn't been defined yet.

-Steve

I don't think it's common that you need global variables in D. If you want to share a variable among several functions, use a struct. But if a global is the best solution, use the global.

If you've ever had the joy of working with FORTRAN 77 or earlier versions of FORTRAN (back when it was in all caps) you understand why working with globals can be a traumatic experience. For instance, multiple functions in multiple files will sometimes change the same global variable.

On Wednesday, 26 January 2022 at 08:49:02 UTC, bauss wrote:

I would think that you sometimes can gain a bit of performance by making the symbol table global (as you don't have to rebuild it for every source file), but it can become rather large so there is a trade-off.

On 1/25/22 01:53, rempas wrote:

The situation is much better in D because I suspect what you call global is D's module-scope and thread-local.

(Note: I don't want to argue whether thread-local by default was a good decision or not but I certainly take full advantage of the ease of thread-local variables in D.)

So, module-scope variables are just fine: std.parallelism uses a default ThreadPool object, std.stdio functions use stdout, in this case a truly global object, etc.

I've used that method once, which I mentioned at this point during a presentation:

https://youtu.be/dRORNQIB2wA?t=2946

Both you and I realize that a module is an object and in our case there is a single object of it. That works.

When you need more than one object (more than one context), then you move all those variables to a user-defined type and they become proper member variables.

Otherwise, as everybody else told, global variables can be very dangerous:

https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/

That report mentions "thousands of global variables", all of which I bet started as "what can go wrong?"

Ali

Because purity is convenient. When I call a function, let's say field.initializeUnit(12, 15) it's so much nicer and tidier if I can rest assured it won't affect anything else than field, and if I know it acts the exact same way every time, when the arguments are similar.

Now consider if field was a global variable. Okay, initializeUnit(12, 15) is shorter than field.initializeUnit(12, 15). But I have to set the field I want to manipulate in advance, theField = /*whatever*/. And when reading code that acts like this, I do not know what affects what without peeking what each of the called functions do. Did the initializeUnit use theField or thatOtherField? With the pure version I can instantly see it's the field variable I'm using. The non-pure version is much uglier and harder to read after all, despite having a shorter argument list.

If the argument lists get lengthy, it is sometimes worth to collect the argument sets into structs or classes that have most of the needed data in one place. You might also consider the with statement. But globals just plain blow.

// ---

module test;
import std;

int x = 0;

void main()
{
writeln(foo);
}

int foo()
{
int x = 10;

if(x) // ooh. you sure this was your intention??
    return x;
else
    return .x;

}

// ---