Apache resigns from the Java Community Process executive committee
Apache resigns from the Java Community Process executive committee
Posted Dec 21, 2010 21:19 UTC (Tue) by cmccabe (guest, #60281)In reply to: Apache resigns from the Java Community Process executive committee by HelloWorld
Parent article: Apache resigns from the Java Community Process executive committee
Perhaps it's just me, but I think that putting "virtual" in front of a destructor is a lot more readable than implementing vtables by hand which looks like this.
You're missing the point. vtables can be useful, but you just don't need them that often. The fact that there is a special syntax in C++ encourages people to write bad code.
There are numerous examples of vtables in the Linux kernel. Usually it's just as simple as a struct with function pointers and a registration function that's called on that struct.
C++'s special syntax for vtables makes it quicker to create them, but does it make it easier to do it correctly? In my experience, most C++ programmers don't know the hidden gotchas that lurk everywhere once you first type "virtual."
For example, what's the problem here?
class Foo {
public:
virtual ~Foo() { log("destroying Foo."); }
protected:
virtual void log(const std::string & foo) { }
};
class LoggedFoo : public Foo {
public:
protected:
virtual void log(const std::string & str) {
std::cout << "logging important message " << str << std::endl;
}
};
There is no special syntax for it, but on the other hand, returning a reference isn't very verbose (and you can use a macro to make it shorter).
The minimum accessor length I can think of is something like this:
const Foo & foo() const { return _foo; }
That's a lot of typing just for one data member. The fact is, they really blew it by not having a better syntax for this-- in my opinion. Also, Java has the same problem but even worse.Well, Go may be a nice language but sometimes you don't want a garbage collector.
If you don't want a garbage collector, why not just write it in C? C++ represents the awkward, error-prone adolescence of higher-level languages, not their future.
