Indeed! I fixed it, thanks Mark.

Ooops, misspoke since Nicholas Wirth specifically did not allow GVs in Pascal for that very reason.

That’s an good point, and I can only agree with it. The scope of a global variable makes it harder to deal with, and conversely the smaller the scope of an object, the easier it is to work with it. Thanks for presenting this.
You’ve also brought up an interesting issue about class member functions. On this specific topic, I think that member functions not showing their inputs and outputs is problematic. Especially their outputs, because this makes them perform silent side effects. One way to go about this is to have const member functions. I’m preparing a special post to talk about that.
Thanks again for sharing Steve.

Isn’t scope what makes a global variable a global variable? So it is all about scope: specifically, how the global scope impacts visibility and lifetime.

Global constants might be a good thing in some applications, at least as long as they are properly contained in namespaces. But what distinguishes these constants from the “bad” global variables is constness, which is also a key factor here.

> “Some people answer that global variables should be avoided because they cause multithreading issues. They do cause multithreading issues, because a global variable can be accessed from any function, and could be written and read simultaneously from several threads, but I don’t think this is the main issue. Because, like everyone knows, global variables should be avoided even when there is only a single thread in a program.”

The potential for multithreading issues is one concern with global variables, but that is again tied to scope: global variables persist beyond the lifetime of a function scope and thus can be accessed by multiple threads. But this is not unique to globals. Any non-constant data which persists beyond the lifetime of a function call can introduce multithreading issues, including non-const class data members and non-const static data. So impact to multithreading is not the crucial issue here.

> “I think that global variables are a problem because they break functions. Functions are useful to decompose a program (or another function) into simpler elements, and for this reason, they reduce complexity, and are a tool to improve expressiveness of the code. But to do this, functions must respect certain rules. One of the rules to respect stems from the very definition of a function: A function takes inputs, and provides outputs. It sounds simple, because it is. And to keep it simple, the important thing to understand is that a function must clearly show what its inputs and outputs are. This is where global variables break functions. As soon as there is a global variable, every function in its scope can potentially have this global variable as input and/or output. And this is hidden from the function declaration. So the function has inputs and outputs, but does not tell exactly what they are. Such functions are dysfunctional.”

Indeed, a function should clearly show its inputs and outputs, and abstractly it is helpful if it appears as if there are no external inputs or outputs. But only some functions have no inputs or outputs beyond the ones visible in the function declaration: functions which have no dependencies or effects on external entities or impact to object state. Regardless, a global variable is only one example of something that can introduce external inputs and outputs to a function. Class data members have a similar effect (they persist beyond the lifetime of the function call and are used to input and/or output data in the function), as does any stateful data/property used by the function within its body (such as a file or another object used by the function).

(By the way, wouldn’t all class member functions that use class member data be dysfunctional by the “function must clearly show what its inputs and outputs are” rationale above? Such functions have hidden inputs and/or outputs.)

So it doesn’t appear we’ve hit the mark yet.

Isn’t it specifically scope (when combined with variability) that is what makes global variables undesirable? After all, scope is what makes a global variable different from any other variable–and scope impacts visibility and lifetime. By making variables global, we make them visible outside of the scope of a function or class or source file, killing all of the well-known benefits of name scope. We also make the variables persist for the lifetime of the program, which introduces difficult problems such as static construction and destruction issues and unit testing complexity. These are the properties that make global variables bad.

I tend to encounter 1) more often than 2), but I cannot sacrifice performance too. Therefore, I think I need to use a custom allocator to make memory allocation quicker.

Thanks for the clarification Vincent, I think I see your point now: in the case where you repeatedly call a function and are able to pass the same instance of the results vector, you’d waste performance by making the function rebuild a new vector every time. This is an interesting case which I hadn’t considered and I’m not sure how to keep the function functional then.

Do you encounter this situation often?

The case of the article is where you don’t hold the same instance of vector every time you call the function, in which case function1 and function2 cause the same number of dynamic alloc, either before or within the function (my previous comment was unclear btw, function2 doesn’t make an alloc but _causes_ an alloc to be made beforehand).

So to recap, 1) if there has to be one alloc per call, the code is clearer if the function takes care of making it. 2) But if you can pass the same vector to be reused for each function call, you can save performance by passing it to the function (we’d profile it to make sure it’s worth it though). Do you tend to encounter 2) more often than 1) ?

how about std::any ?

Hi Jonathan, function1 need dynamic allocation whenever it is called, function2 need no dynamic allocation whenever it is called. huge performance difference for small vectors. http://quick-bench.com/QhDHBqlVkk_1FmXP-4wWIF9pHCw

My question is how to make functions functional if I need to avoid dynamic memory allocation inside functions because of performance concern?

Thank you for your reply in advance.

It seems to me that function1 and function2 make exactly the same number of heap allocations (which is, 1 each). And function1 is more readable, both for in prototype and at call site. Do you agree with this?