LWN.net Logo

Apache resigns from the Java Community Process executive committee

Apache resigns from the Java Community Process executive committee

Posted Dec 16, 2010 4:39 UTC (Thu) 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

Just so people don't think I only criticize C++, here are some subtle errors in C code:

> char buf[80];
> fgets(user_str, sizeof(buf), stdin);
> printf(user_str);

> extern int *my_array;
> /* "zero the array" */
> memset(my_array, 0, sizeof(my_array));
Anyway, to reiterate. C++ was never designed to be safer than C. Every time the designers of C++ had to choose between execution speed and safety, they chose execution speed. C++ is almost like a rapid application development kit for C.

The problem is, when you select execution speed and short development time as your two highest priorities, readability and code quality suffer. For a lot of applications (for example, the Linux kernel), that's simply not acceptable. C++ is still appropriate for many applications. For example, the computer games industry loves C++, despite all the new languages that have come out in the last few years.

> What kind of "fancy syntax" for composition do you have in mind?

At a minimum, C++ should offer something like Ruby does: the ability to create accessors for elements by adding a quick attribute in the variable declaration. For example:

> class Foo {
>  int bar : attr_reader
>  int baz : attr_reader, attr_writer
> }
>
> cout << my_foo.bar() << endl; // look ma, no boilerplate!
Personally, I'm going to explore Google Go a little bit more. It doesn't even have the concept of inheritance. Go just has "specifications" that say what methods a type must provide to meet the specification. Any type that has such methods can be used. Sort of like duck typing, but enforced at compile time and safe! And there is no "static type" vs. "dynamic type" misery, and no base classes teleporting random variables into the middle of your code.


(Log in to post comments)

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 0:54 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Anyway, to reiterate. C++ was never designed to be safer than C. Every time the designers of C++ had to choose between execution speed and safety, they chose execution speed.
When you design a systems programming language, then that seems like a sensible thing to do.
The problem is, when you select execution speed and short development time as your two highest priorities, readability and code quality suffer.
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.
At a minimum, C++ should offer something like Ruby does: the ability to create accessors for elements by adding a quick attribute in the variable declaration.
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).
Personally, I'm going to explore Google Go a little bit more. It doesn't even have the concept of inheritance. Go just has "specifications" that say what methods a type must provide to meet the specification. Any type that has such methods can be used. Sort of like duck typing, but enforced at compile time and safe! And there is no "static type" vs. "dynamic type" misery, and no base classes teleporting random variables into the middle of your code.
Well, Go may be a nice language but sometimes you don't want a garbage collector.

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 21:19 UTC (Tue) by cmccabe (guest, #60281) [Link]

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.

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 23:07 UTC (Tue) by HelloWorld (guest, #56129) [Link]

You're missing the point. vtables can be useful, but you just don't need them that often.
The funny thing is that you wrote the rebuttal to this statement yourself only a few lines later: "There are numerous examples of vtables in the Linux kernel".
The fact that there is a special syntax in C++ encourages people to write bad code.
Limiting the language in order to prevent programmers from writing bad code never worked and it never will, since bad programmers will find other ways to write a bad program. On the other hand, you're making life harder for the people who are able to use advanced features in the language sensibly. This looks like a very bad tradeoff to me.
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;
  }
};
I don't know what you expected the program to do, so how am I supposed to know what you consider to be a problem? Perhaps you meant that ~Foo will call Foo::log and not LoggedFoo::log. I believe that this is a Good Thing. LoggedFoo may have introduced a new meber variable x, and if LoggedFoo::log would use x somewhere, it'd blow up when called by ~Foo, as x would already have been destroyed at that point.
If you don't want a garbage collector, why not just write it in C?
Because C doesn't offer me the features I want. I want type-safe containers (read: templates), I want OOP, I want exceptions and I want destructors. C doesn't have those, and I actively hate C for this (amongst other things).
C++ represents the awkward, error-prone adolescence of higher-level languages, not their future.
No, C++ was never meant to rival high level languages. When it was designed, high-level languages like Smalltalk existed, and Bjarne deliberately designed C++ differently, because he wanted to do low-level work.
Of course, C++ has its share of problems, many of which are either due to its low-level nature or inherited by C (weak type system, bad syntax, horrible preprocessor), so I'd certainly pick a higher-level language over C++ when that is possible. But if the choice is between C and C++, I know what to choose.

Apache resigns from the Java Community Process executive committee

Posted Dec 22, 2010 11:43 UTC (Wed) by cmccabe (guest, #60281) [Link]

> The funny thing is that you wrote the rebuttal to this statement yourself
> only a few lines later: "There are numerous examples of vtables in the
> Linux kernel".

I think we both know that the real question is not how many X the Linux kernel source has, but how many X per lines of code. By that measure, vtables are used sparingly and tastefully.

> Limiting the language in order to prevent programmers from writing bad
> code never worked and it never will, since bad programmers will find other
> ways to write a bad program. On the other hand, you're making life harder
> for the people who are able to use advanced features in the language
> sensibly. This looks like a very bad tradeoff to me.

My point wasn't about limiting the language. I think we all know that C can be used to do anything C++ can do, and vice versa. The question is, what does the feature set of the language encourage you to do? Is it in good taste? Does it encourage you to write things in a readable way, or in an unnecessarily complex and formal way? Do the features work well together, or are there some that can't safely be used in combination (or even separately?)

> [snip discussion of virtual function calls in base constructor/destructor]

Congrats, you know the solution to this one. Now be careful, because the behavior is different in Java and C#.

Apache resigns from the Java Community Process executive committee

Posted Dec 22, 2010 14:43 UTC (Wed) by paulj (subscriber, #341) [Link]

To be fair, non-virtual methods are, we now know, extremely dangerous and inconsistent with the type-safety of inheritance (some of which was developed with and even after the development of C++). That C++ even allows them is perhaps a historical curiosity. One of a number of misfeatures in C++, where new language features were added before they were fully understood, leaving vestigial dangers waiting to trip up programmers. I like the other commentator's description of C++ being "the awkward, error-prone adolescence of higher-level languages".

Apache resigns from the Java Community Process executive committee

Posted Dec 25, 2010 4:46 UTC (Sat) by foom (subscriber, #14868) [Link]

> To be fair, non-virtual methods are, we now know, extremely dangerous [...]. That C++ even allows them is perhaps a historical curiosity.

Absolutely not a historical curiosity! I can't imagine using a C++-like language that didn't allow non-virtual members. Being able to do OOP with *zero* runtime overhead is a killer feature!

There's certainly place in the world for languages like Python too (which I do like, despite its horrific slowness), but C++ without non-virtual methods would just be sad.

Apache resigns from the Java Community Process executive committee

Posted Dec 25, 2010 10:50 UTC (Sat) by paulj (subscriber, #341) [Link]

It's a killer feature in terms of weird bugs, yes. If non-virtual methods were also not overridable, then perhaps it'd be a useful thing...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds