Hacker News Reader

Comment by btmorex | Hacker News Reader

Whenever I read something like this, I'm reminded of that Winston Churchill quote "It has been said that democracy is the worst form of government except all the others that have been tried".

I think C++ usage is one of those things that you don't truly understand until you've decided to start a new project in C++ even in 2013. For a reasonably common feature set in real project (i.e. not a side project for fun), C++ is the only option.

Specifically most alternatives exhibit one or more of the following:

* automatically managed memory (enough said)

* not expressive enough (I would throw C in this category even though C is a fine choice and often times the best choice for many projects)

* not nearly mature enough in terms of compiler/toolset/language in general (often, it's unclear whether the language will ever achieve that necessary maturity)

* not fast enough, usually for one of the above reasons, but sometimes for other reasons

View on HN

Automatically managed memory is almost always a good thing. Aside from preventing a huge class of bugs, it also is often more performant. Why disparage it?

And I'd hardly label C++ as the epitome of expressiveness. A broad, haphazard feature set doesn't necessarily imply it's expressive.

I think he's talking about garbage collection, which is often perceived as slow.

But you can certainly have automatic memory management in C++ as well. Stack-allocated objects manage themselves, for dynamically allocated objects one can use scoped/shared pointers. One added perk is that you can extend this approach to deterministically manage not only memory, but any other resource that can be acquired and released (e.g. locks). I actually like this approach very much. The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. But in a garbage-collected language that doesn't expose pointers, the heap can be defragmented during runtime, which is nice.

> The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers.

The biggest downside is not really efficiency but that you lose the memory safety of a managed language doing this.

True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers when you can't), etc. Of course, these don't make the language safe, but they do help alleviate the problem a great deal.

I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. I mean, we already can detect some problems using static code checking tools (i.e. PVS-studio), so it must be feasible.

> I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages.

Rust does this. :) It is not easy to get right—the borrow checker required a lot of design work to achieve the right balance between expressiveness and practicality—but I think we've shown that it is possible.

(Disclaimer: I work on Rust.)

Like most languages in the Pascal family.

Arrays are bounded. You can usually disable bounds checking locally if you really need the extra ms, for cases the compiler is not able to optimize them.

Proper strings instead of char pointers that might be null terminated or not.

Var parameters and unbounded vector parameters to handle arguments that need to be changed.

Oberon family has already proven it is possible to write desktop operating systems in GC enabled systems programming languages.

Now as you say, many of these things are possible in modern C++. The problem is getting everyone on board, specially when dealing with old code bases littered with C like constructs.

No, automatic memory is always easier to use. It also always has a performance cost.

Garbage collection has a ton of problems in systems applications (off the top of my head: unreasonable and unpredictable delays, incapability of dealing with a large amount of heap-allocated memory efficiently). Reference counting is better in many ways, but is not always appropriate and definitely has a cost (and I say this as someone who uses shared_ptr quite often).

This is missing something though: "new" and malloc() are just like managed memory: convenient, but sometimes (and often unpredictably) slow.

Some people eschew Java and the JVM due to the spectre of garbage collection ruining their quasi-realtime system. But others embrace the JVM, organizing their programs to avoid garbage collection during critical times (which could last for hours or days).

With C and C++ it is the same, but backward: people flock to these languages for the predictable performance. Yet once there, they discover they must avoid the default allocator, for it is a source of unpredictable delays. Pooled allocators are created, and the end result is much the same as for the JVM folks.

The funny thing is that most of STL gives no realtime guarantees either, even if you use a custom realtime allocator with it. E.g. vector.push_back takes O(n) time sometimes. Running a chain of destructors caused by reference count dropping to 0 can be unpredictable as well.

I once had to re-implement the pieces of the STL I wanted in a real-time embedded system, for precisely this reason (well, that plus the fact that STL's use of allocators is broken, and I wanted to be able to allocate from fixed-size pools to avoid non-O(1) trips through an allocator at run-time).

But you can be sure of when those "sometimes" will be with e.g. std::vector::reserve

http://en.cppreference.com/w/cpp/container/vector/reserve

If you want realtime guarantees, you have a lot more unpredictable problems, like CPUs having cache.

Yep, but exactly the same applies to Java. Just preallocate all your objects statically and you're never going to have GC problems :P

If you don't want the occasional O(n) copy on growth, use an stl list with a custom allocator.

reserve can be very easily misused. For example, let's assume a function append_10_items_to_vector. Since we're adding 10 items, we may get a better performance if we call reserve() before 10 push_back()s. Right?

Not always. If we have a loop that calls our append_10_items_to_vector N times (on the same vector), then your reserve() just transformed the loop into O(N^2) code. Without reserve, it would be O(N).

As a rule of thumb, use reserve only if you are really sure that nobody's ever going to add anything more to your vector in the future.

If you are writing code that, essentially, is taking some data from a database and formats it nicely or takes user input and puts it into a database then managed memory is awesome.

However, almost always, somebody has to write that database code and the code that displays the nicely formatted data (like in actually lighting pixels on the screen instead of filling out some css properties) and even the code that takes the user input. And for these purposes managed memory is a disaster and C++ is the most expressive language available.

There are database systems written in Java and they have no problems competing in performance with database systems written in C++. Sure, there is probably more effort required with getting memory management right in case you're using Java (pooling / using off-heap memory), but Java has some other strengths, like superior concurrency support.

IMHO, managed memory for system-level code is nowhere near being a "disaster". It might be sometimes tricky to get right, but not any harder than getting manual memory management right in C++ (and smart_pointers aren't a silver bullet, neither). Additionally, there are some Java extensions that let you write real-time code in it and guarantee GC won't kick in when you don't want it to.

This, of course, depends on your definition of "compete" and "system-level" (e.g. I have no problem competing with professional athletes too, I just have a very serious problem winning against them but the competition is no problem at all).

I write code that I consider system level (it talks to the hardware directly) and "tricky" is quite an understatement. Starting from the fact that there are half a dozen types of memory (not even talking about memory-mapped I/O) and just one "heap" in Java. Not to mention the hardware is not aware about the awesomeness of JVM and is trying to read/write actual memory pointers. I can imagine that you could get around this (as well as the lack of bit-fields and unsigned types) through some kind of memory-mapped-as-a-file trick but at this point you are not using the memory management at all. And IMHO this is very far from being "not any harder" than using pointers in C++.

When directly talking to hardware, C is enough. Noone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is wrong, too). I was refering to database systems or other software that is very close to system, e.g. application- or web-servers. In this area Java is excellent choice and performance-wise it often beats C++ because of superior concurrency support. And you can always code the low-level pieces in C, if you really need those unsigned arithmetic or bitfields.

Nobody is talking about C's insufficiency for programming. When doing anything C is enough just like any other Turing-complete language.

You'd been saying that in your humble opinion system programming in Java is no harder than in C++, which is something very alien to my experience of actually programming on the system level (as same as your performance claims but I am not even going to get into this one. Last time I did a Java programmer told me that a Java program that is measuring as 4 times slower is running "on the same level", whatever that means).

Is Netty system-level enough? Or Cassandra? Or Tomcat? Or Apache Spark? Or Hadoop? Or Akka? For some reasons devs chose Java to implement them, not C++.

As of performance, they are doing extremely well. Last time I checked Netty vs Nginx was a tie; Tomcat vs Apache HTTP were also extremely close; Apache Spark (pure Java) is generally much faster than Impala (using C++); and Cassandra has no direct competitors written in C++ so far (not counting 1000 toy databases here), but it is definitely one of the top performant NoSQL stores out there.

Sorry, I don't know what any of these does. When I went to school it was common convention that system level is the OS kernel, drivers and anything else that talks to the hardware.

While I do agree with you, how do you implement such features in fully pure ISO/ANSI C++ compliant compiler?

All the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there the bulk of work is creating control structures in memory and then kicking them through a port or a coprocessor instruction). C/C++ are perfect for the memory manipulation even in their purest standard form. I imagine your concern is about deriving the addresses for register apertures or emitting specific opcodes?

For the concrete addresses you just link with the symbols defined outside of your C code. Special ops cannot be done in pure standard, but this is not an issue in practice as there are no pure standard compilers. Even for app development you want intrinsics just for the vector, cache and bit instructions.

No, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler.

You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs.

There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.

I guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).

I was just playing devil's advocate a bit, because many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard.

Many mainstream languages, with AOT native compilers would be as usable.

Most developers never read the standard in the first place. I don't see how is this important though. We did not have a standard till 1998, yet somehow managed to use C++. Same as with C, which had been used very successfully standard-less for almost two decades.

> Most developers never read the standard in the first place. I don't see how is this important though.

Do you write portable code in C and C++ across disparate systems and OSs, using multiple compilers?

I used to do that between 1994 and 2001. Don't miss those days of hit-and-miss about compiler support.

> We did not have a standard till 1998, yet somehow managed to use C++.

Yes we did. It was called the Annotated Reference Manual, used as basis for the standard, coupled with articles from The C++ Report, The C Users Journal (latter The C/C++ Users Journal).

> Same as with C, which had been used very successfully standard-less for almost two decades.

It works if you only care about one specific compiler. On those days the standard was the AT&T UNIX compiler.

Obviously, you cannot write portable system code. You can do conditional compilation to target multiple platforms though. And when you do that you realize two things: 1. No compiler is fully compliant with any standard. 2. Every compiler has bugs so even the compliant parts can be unusable.

And then you realize it's not a big deal. Changes between platforms are greater than changes between compilers. When your targets have different endianness or, even better, mixed endianness between different PUs - the standard compliance of your code is the least of your worries.

>It works if you only care about one specific compiler.

Also works if you care about a finite number of specific compilers and architectures.

>On those days the standard was the AT&T UNIX compiler.

There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.

> Obviously, you cannot write portable system code..

Sure, but the goal is to minimize system dependencies as much as possible.

Relying on language extensions works against it.

> There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.

Yes, I do remember variants like Small C.

Java does support memory manipulation by DirectByteBuffers.

"many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard."

Excuse me but what??? Please give an example. Except for maybe setting up an isr vector table and the odd coprocessor command in assembler, all other peripheral functionality is usually memory mapped and perfectly accessible in C and C++.

Like vector instructions or doing memory mapped access in a processor with MMU.

Right. Now show me some widely used OS kernel written in C++. No, not some research thing. Becaue I hear all the time C++ is a system level language, yet it is most widely used to write games and desktop apps, not systems.

Console games are system level software, accessing hardware directly. But if you want specifically the OS kernel then XNU should satisfy you.

Console games are just applications like any other PC game. They access hardware by communicating with OS services. The only difference is in consoles you exactly know your hardware and you can make better use of it and OS provides less than a full blown PC OS. But this is not related to Java vs C++ debate. Java is capable of accessing hardware directly. There is even some hardware that directly runs Java or some low-end embedded systems running Java.

As of XNU, it is mostly pure C. There are a few C++ files there but they are very far from what we call "modern C++". No templates, no use of standard library, no exceptions, const char* everywhere. Just C with classes.

It appears you are either trolling or simply don't know what are you talking about. Either way there is nothing to be gained from this discussion for either of us.

Noone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is wrong, too)

You are correct, C++ is a bad choice for low-level device drivers. But it's getting better [1]!

[1] http://msdn.microsoft.com/en-us/windows/hardware/gg487420.as...

You're right, it is generally desired, even Stroustrup (author of C++) doesn't want you to manually manage memory unless you really have to. That's why there are smart pointers and why you should work with values as much as you can. You can even plug a garbage collector in in C++.

But when you're working in a constrained environment, you need the option to control all this in much detail. C++ is one of the very few options you have for that.

smart_pointers in C++ are dead slow compared to Java's GCed pointers. And full featured GCs for C++ are unicorns. There are a few, but noone actually uses them in production, except a few experimental language runtimes.

unique_ptr, the default smart pointer in C++ is no slower than direct pointer access. If you require data sharing, then shared_ptr offers you that feature at the cost of reference counting.

unique_ptr is not a replacement for Java's GC. It simply doesn't do the same. shared_ptr is much closer, but at the cost of reference counting, which, if you start using it excessively, is much higher than cost of Java GC.

I agree that if your memory management is dead simple and you are fine with using only unique_ptr everywhere, C++ solution is superior. You obviously don't need GC, so why pay for it. Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls.

However, there are some domains where GC enables completely different ways of programming. E.g. lockless concurrency / immutable structures / functional programming etc. Poor shared_ptr performance and scalability is prohibitive in those areas.

> Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls.

I don't believe such a static analysis tool can exist without being a different language (e.g. Cyclone). There just isn't enough information about ownership semantics in C's type system.

Cough, cough, Rust?[1]

[1] http://static.rust-lang.org/doc/0.8/rust.html#memory-boxes

In cases, where unique_ptr is enough, ownership is simple and statically pairing all mallocs with frees is easy. The whole problem with memory management is sharing ownership. Then things start getting hairy.

> Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls.

While it helps, it can only cover the code you have access to.

No way to take care of third party libraries delivered in binary form.

I assume you mean ref counted smart pointers, not all smart pointers are ref counted.

Java's pointer might be faster than shared_ptr. But, in Java, all objects are held by pointers. C++ gives you more options. It's not like we're going "Damn, I just can't figure out the ownership here. I'll just use shared_ptr and be done with it" every day. In my experience, usage of shared_ptr is quite limited.

It is definitely going to change at some time, IBM already has a prototype of JVM supporting object packing and fine-grained alignment control.

shared_ptr use is limited because shared_ptr is slow and people learned to avoid it at all cost. But having to think about ownership influences design choices and often makes things more complex and less performant that needed (e.g. it often forces to copy objects instead to just pass a pointer).

Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices. We (C++ programmers) don't avoid shared_ptr at all costs and the primary reason for avoid it is because it muddles ownership semantics. In other words: if a magical zero-cost shared_ptr implementation appeared, we wouldn't start using it everywhere.

You can keep extolling the virtues of Java performance, but fact remains that Java doesn't see much use in areas where performance is critical. It doesn't mean Java doesn't have a use, it's just not there.

> Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices

Maybe this is the reason C++ guys always complicate things: http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make...

As of Java being not-performant enough: that's why Java is used as one of the most popular language for implementation of modern NoSQL databases systems. Everyone knows performance doesn't matter in databases. ;)

to a good approximation every memory management problem i've had involved a garbage collector, a reference count or a fancy stl pointer type.

without these i have very few leaks or problems - and when i do they are trivial to find and fix. i see the advantage for RAD, but for performance and memory critical code these things are actually dangerous and stupid imo. measurably so...

I would say that even the side projects deserve C++! I have written much code on the side in C++. Like a real language, the more you use it the better you understand it. Everyone should try it - I know some will dislike it but rubbishing it without really throwing yourself into is foolish, much like hating a food without trying it (as children do).

I do use it on side projects, but on the job I am pretty happy to be on JVM/.NET land for our enterprise projects.

Mastering C++ is like playing guitar, but most corporate developers only know how to play Kazoo.

I'm a little unclear on how you include,

"not nearly mature enough in terms of compiler/toolset/language in general (often, it's unclear whether the language will ever achieve that necessary maturity)"

in that list. One of my perennial complaints about C++ is that it seems to be a moving target[1], more so than I really want to expose serious work to.

[1] https://news.ycombinator.com/item?id=6888366

It is funny how slow moving target it is, yet the compiler/tool writers can't catch up.

Add good concurrent lockless programming support and this rules out C++ and leaves us with Java.

Reply on news.ycombinator.com