I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they're never called, or shouldn't be). I think it behooves programmers to really think about the interfaces their code offers; don't just expose something through setters and getters because it's there, ask yourself, what is this class really offering that you couldn't get with a struct? Pass through setters and getters aren't an abstraction.

One (maybe stupid?) reason why I really like getter/setters has nothing to do with encapsulation, but that it makes it easier to search for places where a variable is changed. Often you have lots of getFoo and little setFoo functions - so just searching for "Foo" will return lots of results while "setFoo" helps me finding those faster.

Most editors with an indexer solves that automatically with "find all references". They can usually even order by "read occurrences" and "write occurrences"

VS2010 and C::B both don't seem to allow that ordering. So not a solution for me, but certainly could be other IDE's support that.

A only slightly more complicated regex can look for Foo on the left-hand side.

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

All of these are usually made by theoretical purists. Meanwhile, the people who write the code see that most variables don't need any of the above, most of the time.

I understand all of those justifications. When I mentioned changing implementation in my post, I was thinking of exactly those sorts of things. But none of them seem to be applied in the general case of "make a pass-through getter and setter for every member variable". My biggest question to the answer of universal getter/setters is "what is being abstracted?" Classes (and objects) are meant to abstract things like an "engine" so that you don't have to twiddle fuel_injector_rate, spark_plug_timing, etc, but rather just call engine.startIgnition().

I tend to not mind using getters and setters, but I don't create one for every internal variable in a class. I consider "universal" getters and setters (which I take to mean one getter and setter for every variable in every class) to be an absurd idea, like something taken to the logical extreme just to piss someone off.

Perhaps a lot of people don't like using or writing getters and setters because it's cumbersome if the only code in them is an assignment/return statement. Maybe something like providing Ruby's attr_reader/attr_writer/attr_accessor to create these boilerplate getters and setters is what is required. Also in Ruby all member variables are private, so methods are always needed to access them.

We're all consenting adults. Python gets by just fine on this principle.

The argument from the Java camp is that if you always use the getters and setters, you leave the access and modification open to extension, say, by adding a callback listener for changes to a variable.

I then just say, change it when you need it, and use that fancy "find usages" thing most IDEs and vim have.

Precisely. The real reason Python gets this right is that it the properties feature lets you write `obj.foo` but still call a `getFoo` method behind the scenes.

C++Builder and Delphi offer this too, with the '__property' declarator.

As someone who writes C++ regularly, I would love to see something like __property introduced in C++15.

For immutable objects, “setFoo()” makes no sense, and “getFoo()” is redundant. For encapsulated objects, “foo” doesn’t need to be exposed at all, not even through getters and setters. A group of fields with no behaviour is not an object—it’s data.