Functional programming has the great feature of scaring the shit out of n00bs who avoid it and don’t even know where to start. The advantage of this is that the n00bs have to learn before they get a chance to make a mess of it.

You’re right that this problem is OO-specific, not C++ specific. (I mentioned that briefly at the start.)

And yes, it may just be that nanojit needs refactoring, and that C++ is not to blame. But if I’d written “what I currently hate about Nanojit” I wouldn’t have got so many comments

But I suspect this problem crops up in a lot of OO programs. TraceMonkey has some large awful classes too, and I bet the rest of Firefox does as well. It’s easy to blame bad programmers or bad OO design, but I suspect that OO programs tend in this direction if the programmer’s aren’t very disciplined. And if a language or programming paradigm requires you to be really disciplined to avoid pitfalls, then it arguably deserves some blame when those pitfalls occur.

I am looking at ways to refactor the code, but it’s going to be a long, slow process.

I haven’t seen the code and how it came to be in what appears to be a real mess. Maybe the class can’t be refactored into a dozen classes because of performance limitations? Maybe the code really has to do so much in one class (and has accumulated so many tweaks and hacks that it’s impossible to de-entangle it without it breaking). But from the sound of it, it just sounds like badly written object oriented code (C with classes, instead of idiomatic C++).

In any case – complaining about state in C++ classes is not really about C++, but about OOP in general. Virtually all OOP languages (from Smalltalk to Java) do it like this.

Coming from a functional world where you don’t have state that is the result of code with side effects (and are just used to passing everything you need as parameters), it’s understandable to blame a particular language, but in this case, it really looks like it’s just bad code (you can write more “functional” code using objects too).

I really recommend reading Martin Fowler’s book on refactoring.

Another good language sharing the same space as C++ is D: http://www.digitalmars.com/d/
It’s like a vastly improved, safer C++ but it also lets you get down and dirty if you want to. I would love it if all C++ programmers took a good hard look at D.

Could you please tell me if I can access the rendering engine(Gecko) of Firefox. My main task is to see the dimensions of a HTML element from a Java/Perl program.

Thanks.

You say that if you were writing C, you’d pass this state as function arguments. Then why don’t you in C++? It’s not only perfectly valid, but actually highly encouraged to put local state into arguments. Class variables are for the class state.
What gives you the idea that C++ forces, or even encourages, non-local state? Just because the possibility of misuse exists, doesn’t mean it’s encouraged. Nothing in the C++ standard says you have to do it this way, and that’s the only authorative source on what C++ does. If you go beyond the language, no book on C++ best practices I’ve ever seen encourages making local state non-local by putting it into classes. (I’ve seen some misguided OOP guides do this, but that’s not a C++ problem.)

“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(). It then gets overwritten — but with the same value! — via an argument passed into the method assemble().”

That sounds like a class design problem to me. But class design is mostly language-independent. The problem would be exactly the same in Java, Python, Smalltalk, or any other object-oriented language you care to name. In fact, it would even be exactly the same in Mercury, OCaml, Haskell or Lisp if you decide, for whatever reason, to bundle up all that state into a single record type (or your language of choice’s equivalent) and only pass that around instead of lots of free variables – suddenly you exposed state to functions that shouldn’t have seen it, and thus you’ve increased coupling and decreased maintainability. But the reason is still insufficient separation of state, not any particular language or any particular design method.

“Good C++ practice encourages everyone to create private fields and use public get/set methods to access class data fields from outside the class.”

That’s just nonsense. No respectable guide on C++ will ever encourage direct access to state (be it in raw member variables or via get/set) where it isn’t necessary. (Unlike Java, where the Beans specification comes very close to doing that.)

“It would be better to just make _err public and avoid the get/set obfuscation; at least then it would be obvious how exposed _err is.”

Also wrong, for reasons mentioned by other commenters.

So in summary, you’re frustrated about the poorly designed classes in Nanojit, but for some reason you chose to formulate your blog post in a way that blames C++ for this. But C++ is just a general-purpose language that supports object-oriented programming. There is no way you can blame it for poor class design.

As someone already mentioned, C++ doesn’t force you to do anything. You can really program referentially transparent. Do it all with static members and pass all arguments as you like them, no pointers, only copy by value and you are rid of all the stuff. Of course its not the way its meant to be.

By the way one can view classes as solution to the massive argument passing: aggregate common data that is worked on by a set of methods and pass them altogether – just getting rid of passing a million arguments 500 times – which sucks by the way too.

C++ does not force/encourage you to make anything a member, you didn’t seem to mention that. It is simple aggregation, you want a data type composed of this and that and you choose yourself.

I think the problem isn’t with C++ or oo languages but with software engineering how to structure and divide programs into modules/classes.

Also, you argue with non-local state and reasoning about that. But within a large software product you build up layers to reach higher levels and it becomes obvious that the state needs to be nonlocal and local reasoning will not suffice.

Lets take some procedure like: loadMachine() { moveRobotTo( pos ); openGate(); moveIn(); startCalibration(); moveOut(); startProcessing() }

Now tell me how you keep state local with robot and machine modules composed of thousands of ministates of sensors and actuators. Of course there is no total view of the affected data because of the high layer you are working.

RT
http://www.privacy-web.tk