Everyone knows that global variables are bad and should be avoided wherever possible.\u00a0 Why?\u00a0 Because each global variable is, in effect, an implicit argument to every function that can see the global variable.\u00a0 The same thing is true of any non-local state.<\/p>\n
And the presence of non-local state means that you can’t reason locally about your code.\u00a0 That makes your code more complex, and complex code is likely to have more defects.<\/p>\n
And the thing I hate about C++ (and other object-oriented languages) is that it vigorously encourages non-local state.<\/p>\n
First, of all, C++ encourages (nay, forces) non-local state within classes, because all class methods have access to all fields within a class, even the ones they don’t need to.\u00a0 In other words, every class field is an implicit argument to every class method.\u00a0 This can work well for, let’s say, a “Date” class, because the number of fields is small, and most class methods will access most fields.<\/p>\n
But problems appear when classes grow larger, when they start to look like what would be a whole module in a non-OO language like C.\u00a0 For example, Nanojit, the compiler core in TraceMonkey, contains a class called Assembler, which encapsulates the translation of Nanojit’s low-level intermediate representation (called “LIR”) to assembly code.\u00a0 If you exclude members that are only included when debugging is enabled, there are 18 data fields and 102 methods.\u00a0 And some of those 18 data fields are pointers to objects that are themselves complex.<\/p>\n
Let’s consider a single field, _thisfrag, which holds a fragment of LIR code. It gets set via an argument passed into the method beginAssembly().\u00a0 It then gets overwritten — but with the same value! — via an argument passed into the method assemble().\u00a0 It is accessed directly in only 7 of those 103 methods:<\/p>\n
And that’s just one example, which I chose because I’d been thinking about this problem and then just this morning I had to hunt down all those uses of _thisfrag in order to understand its purpose and whether I could change some related code safely.\u00a0 I’m sure a similar story will hold for a lot of the fields in this class.<\/p>\n
Just imagine, if you were writing Assembler as a C module, would you make _thisfrag a (module-level) global variable?\u00a0 Almost certainly not, you’d pass it only to the functions that need it;\u00a0 actually you’d probably only pass parts of _thisfrag around.\u00a0 But C++ encourages you to make everything a class, and stick everything a class ever needs in as a data field, creating lots of non-local state that complicates everything.<\/p>\n
(An aside:\u00a0 Assembler probably also isn’t a very good basis for a class because it’s a *process*.\u00a0 I figure that if you’d write something as a struct in C, then it makes for a good class in C++.\u00a0 But I need to think about that some more.)<\/p>\n
But it gets even worse.\u00a0 Good C++ practice encourages everyone to create private fields and use public get\/set methods to access class data fields from outside the class.\u00a0 But get\/set methods are just lipstick on a pig; all too often you end up with something like this example, again from the Assembler class:<\/p>\n
\u00a0\u00a0\u00a0 private:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AssmError\u00a0\u00a0 _err;\r\n\r\n\u00a0\u00a0\u00a0 public:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 void\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 setError(AssmError e) { _err = e; }\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AssmError\u00a0\u00a0 error() { return _err; }<\/pre>\nOh great, I feel much safer now.<\/p>\n
It would be better to just make _err public and avoid the get\/set obfuscation;\u00a0 at least then it would be obvious how exposed _err is.\u00a0 It also saves you from having to check the definitions of error() and setError().<\/p>\n
Even better, in this case _err gets set from various places within class Assembler, but also from various places outside class Assembler.\u00a0 I’ve tried twice to simplify this, by passing error codes around explicitly instead of implicitly through this quasi-global variable, but both times I was defeated by the complexity of the control flow governing how _err is accessed, in particular the fact that’s it’s set on some control paths but not others.\u00a0 This is a big part of the reason why out-of-memory handling in Nanojit is a total nightmare.<\/p>\n
The end result<\/h3>\n
Currently Nanojit has a number of large, complex classes, and many of them link to other large complex classes.\u00a0 At many points in the code there is a bewildering amount of accessible non-local state.\u00a0 (And I haven’t even mentioned how this can complicate memory management, if you end up with multiple pointers to objects.)\u00a0 The complexity caused by this is a tax on development that we are all paying daily.<\/p>\n
A better way<\/h3>\n