C++ [LWN.net]

C++

Posted Nov 14, 2008 8:48 UTC (Fri) by mjthayer (guest, #39183)
In reply to: C++ by MisterIO
Parent article: Things that go Clang in the night: LLVM 2.4 released (ars technica)

> They use a sane subset of C++, so that's not a bad choice.

C++ is a brilliant language which makes for efficient and readable code. C++ is an awful language which makes for incomprehensible, broken code. It all depends on what subset of the language you use. I personally think that the best way to "fix" C++ would be to decide on a sane subset of the language and make the compiler produce warnings if anything else is used. Unfortunately, neither getting people to agree on what constitutes a "sane subset" nor parsing code to make sure that it sticks to it would be an easy job.

to post comments

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 11:37 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

It's easy to declare some subset of C++ "sane" and everything else forbidden in a corporation: it does not even matter of some useful stuff will be forbidden as there are usually path to infrequently allow exceptions. With free software it's almost impossible. That's why C++ is an Ok language for corporate programming and bad for LLVM... May be they have authoritative enough core to cope?

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 12:27 UTC (Fri) by mjthayer (guest, #39183) [Link] (8 responses)

One way to do this would be to make it a compiler flag (e.g. -Wsane-subset). You could even have different flags if people differed as to which subset should be considered sane. People would use the flags if they wanted guidance from the compiler as to what is sensible to use and what not, and the choice would not be forced on them.

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 22:44 UTC (Fri) by salimma (subscriber, #34460) [Link] (7 responses)

Or one flag, but with loadable definitions, so large collaborative projects can define their accepted subsets and have it enforced at compile time.

It's doable in corporate enviroment, but in free software world

Posted Nov 15, 2008 7:33 UTC (Sat) by njs (subscriber, #40338) [Link] (6 responses)

Or people could just catch bad ideas during code review, and inoculate against them through development culture -- just like they already have to do for all languages.

At least, that's seemed to work for the C++ projects I've been involved with. We've even sometimes used horrible nasty constructs, because the horrible nastiness was technically superior and could be tucked away behind a simple interface. (My favorite: a macro "M" that "marked" an object as being interesting for debugging data-dependent crashes -- you just put M(myobj); on a line in your code, and then if an assertion fails in that function or anywhere under it in the stack, the contents of myobj are dumped to the log. Implementing this is a neat puzzle for keen students, and probably impossible in any other common language.)

It's doable in corporate enviroment, but in free software world

Posted Nov 15, 2008 7:50 UTC (Sat) by njs (subscriber, #40338) [Link]

Right, forgot to finish with my main point: it would be nice if "sane code" mapped nicely onto the use or non-use of specific language constructions, or indeed there were any simple algorithm for distinguishing code that was sane from code that was otherwise; indeed, this idea is so seductive that the search for such algorithms in various domains has driven thousands of years of philosophy and mathematics. But, alas, code -- like life -- is not so simple, and seductive ideas don't always give the payoff you hope for.

It's definitely doable in the free software world.

Posted Nov 16, 2008 10:25 UTC (Sun) by Ze (guest, #54182) [Link] (4 responses)

I mean really why does the whole C++ isn't suitable for free software thing stand up?

C++ is good precisely because it's so flexible. Personally I find operator overloading common sense.

Just like how you can't tell what's happening in non-operator overloaded languages for functions,methods,procedures without looking at the API , the same applies to C++.

When you look at the alternatives to templates , you throw out type safety with it and end up with something that is worse. When it comes to error messages yes gcc error messages suck , that doesn't mean that c++ sucks. Personally I'll be quite happy when clang c++ is well advanced. When I get time I'll contribute to it. I wouldn't be surprised to see LLVM approach the number of languages and architectures that gcc supports in 5 years.

When it comes to the free software world GTK+ with it's Gobject crap is horrible and I hate the thought of using QT with it's non standard extensions using it's own preprocessor. If the GTK people were sane they'd make GTK 3.0 using C++ with bindings for C instead of the other way around.

It doesn't matter whether you write C,C++,Java,Lisp,Python,Perl,Haskell,O'Caml,Scheme or any other language you need to document your code and API thoroughly from the point of someone new to the library/application otherwise there will be errors. You need to make sure that all the developers have roughly the same mental model and have it explained succinctly and coherently for new users.

I think the reason why scripting languages go through phases of being popular is because of their large libraries of modules all in one spot along with the libraries being relatively easy to use. There is no reason why C++ can't do the same thing (and it has started with boost).

It's definitely doable in the free software world.

Posted Nov 16, 2008 22:22 UTC (Sun) by Ed_L. (guest, #24287) [Link] (3 responses)

The choice of C vs. C++ for GTK+ was made by the GTK+ developers. Its only relevant to some one else if that some one wants to actually hack GTK+ code. I've been using the GTKmm C++ wrapper for five years now, it works quite well. Given that one of the design goals for GTK+ was a requirement that GTK+ be wrappable by many different languages, I'm not absolutely certain C was the wrong choice. Yes, Gobj() is ugly, but to make the library wrappable would require a C API to all its exposed public methods anyway, because of (I suppose) different object and inheritance models in different languages. So I'm not certain having allowing C++ under the covers would have bought them a great deal. That, and I suspect the GTK+ team shares many of this threads sentiments r.e. C++. Their choice. GTKmm certainly fills my needs, so I don't worry about GTK+ much one way or the other.

It's definitely doable in the free software world.

Posted Nov 17, 2008 14:53 UTC (Mon) by cortana (subscriber, #24596) [Link] (2 responses)

I like gtkmm a lot, but I find not being able to use exceptions a real pain in the arse. :(

It's definitely doable in the free software world.

Posted Nov 17, 2008 23:45 UTC (Mon) by Ed_L. (guest, #24287) [Link] (1 responses)

Not sure what you mean. I use Glibmm exceptions extensively throughout my code, they work pretty much the same as C++ exceptions. I haven't tried mixing C++ exceptions into this environment, so I can't comment on what would happen then. But Glibmm exceptions throw just fine.

It's definitely doable in the free software world.

Posted Sep 1, 2009 12:40 UTC (Tue) by cortana (subscriber, #24596) [Link]

Whoa, oooold thread. But I thought I'd refer to the gtkmm documentation:

Can I use C++ exceptions with gtkmm?
Yes, it is possible but it is not a very good idea. The official answer is that, since plain C doesn't know what a C++ exception is, you can use exceptions in your gtkmm code as long as there are no C functions in your call stack between the thrower and the catcher. This means that you have to catch your exception locally.
You will be warned at runtime about uncaught exceptions, and you can specify a different handler for uncaught exceptions. Some gtkmm methods do even use exceptions to report errors. The exceptions types that might be thrown are listed in the reference documentation of these methods.

It's the typical C++-code-called-by-C-code hooplah that I have to go through that makes use of gtkmm more annoying than it could have been.