Hacker News Reader

Comment by CrLf | Hacker News Reader

What I would like to see is a (convincing) list of why use C++ (in new projects) at all.

In my opinion (and experience) when you need the performance advantages of C++, you are usually within the domain where C is good enough (and perhaps a better choice for its simplicity). When you need the features of C++, you are probably better off with something like Python (not specifically, but in the same "league").

Seeing how easy it is to use a higher-level language combined with C for critical sections, I just don't see the point of C++ anymore.

Disclaimer: I don't really like C++. The only pleasant experience I had with it involved ignoring the STL completely and using Qt (http://qt.nokia.com/). I like C though.

View on HN

let's say you write a search engine, a route planning system, a database, rule-based NLP (for most ML-based approaches fast, native math libs + python may be great enough because nearly all the time is spent in the math part) on HUGE datasets, etc, etc

pretty much any system involving long list- or set-like types with a decent level of complexity. Most other languages enforce far too much indirection, padding et. al for collection types. Especially generics fail miserably compared to templates for that particular matter. C, on the other hand, will make everything MUCH harder. Especially proper use of RAII and (const) references allow (almost) zero overhead and almost no error-prone pointers (especially zero pointer arithmetic) in the whole system.

I wasn't saying that C++ had no use. I'm saying that its domain is narrower that what's commonly believed.

It is false that C "will make everything MUCH harder". How hard something is to implement in a particular language depends on the problem and the people doing the implementation. C is only perceived to be much harder because people have become overly-dependent on language features (aka "syntactic sugar") and cannot reason about problems in terms that do not require those features.

I'm not talking about using assembly here. It is not a matter of an unstructured language vs. a structured one. I'm talking about features. This is particularly relevant because in many places where C++ is used, the coding standards prohibit the use of more than a limited subset of the language, effectively transforming it into "C with classes".

I don't think that C "will make everything MUCH harder," but with C you'll end up spending a lot of time just getting the groundwork in place before you even start to work on the problem at hand.

C is good and simple but C is not expressive. There are a whole hosts of situation where code has to be duplicated or slightly modified. For instance, it's really hard to do good generic data structures in C without ending up with casts everywhere. Polymorphism is even worse.

For me, that really is the edge that C++ holds over C.

I agree. I kind of wish there was a middle ground between C and C++. C++ is bloated but C is not enough.

Objective-C?

It seems that C++ really requires one to be subtle in his coding style.

Stroustrup discusses this here:

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

Does D not aim to fill this niche? (I suppose in terms of exposure and infrastructure, D is lacking relative to C and C++).

No, it's closer to a garbage collected Algol but with way more features.

People generally master and commonly use only a subset of C++, i.e. C+.

Like the old saying, "you can write cobol in any language".

Polymorphism and "good generic data structures" (in the sense you are implying) are not a necessary requirement of elegant and maintainable code. It is part of the problem that programmers have taken OO concepts as the end-all of good code, and must apply those concepts everywhere even if that means implementing them from scratch at the cost of (unnecessary) complexity.

Large systems have been written in C. Many large open-source projects use C. There is no evidence that these are less maintainable (in general) because of language choices.

Some of these graft OO concepts onto C. GTK is noticeable for this (although it doesn't seem to be too bad for application developers, I'm afraid for those tasked to maintain the libraries themselves).

Procedural programming is not a sin (if "procedural programming" exists at all today, as most of the simplest object concepts have become common practice and are now though as an integral part of it).

Like the old saying, "you can write cobol in any language".

As far as I know, there is no such 'old saying'.

However, The determined Real Programmer can write FORTRAN programs in any language.

Parametric polymorphism (i.e. generics) is not an object-oriented concept.

The problem never was the lack of OO, the problem is that you have to repeat yourself. There will come a type when you have a type that behaves a certain way (certain members, argument of certain functions) and then you will make a type that is mostly the same thing, but then slightly different (maybe one attribute is replaced by something else). You'll have to adapt everything you reproduce a lot of your logic or jump trough very annoying hoops to have your existing logic work with this new type.

If from OO, I could have only Java-like interfaces, it would probably be enough. Implicit type conversions could also work I suppose.

> There is no evidence that these are less maintainable (in general) because of language choices.

I have an example. The Squid proxy code used calling via function pointers everywhere as DIY polymorphism. That made it quite difficult for me (ymmv) to follow the code.

Things like ctags would have worked if they'd used "real" C++ polymorphism.

IMHO. YMMV.

Linux kernel has lists, etc. that can be used as generic data structures. IMO they are good enough for most purposes.

Well the trouble is really polymorphism, and I was actually thinking more about polymorphic data structure: i.e. data structures where the elements are required to have certain methods callable on them. I agree this is typical OO design and could be approached in other ways, but none I know of are satisfactory.

> What I would like to see is a (convincing) list of why use C++ (in new projects) at all.

C is my obvious choice, but...

When it comes to deciding between C and C++, C++ beats C in one aspect: templates. For example, quick sort in C++ performs a lot better than C because templates enable lots of compiler optimizations. (Rest of the C++ features are just garbage for my purposes.)

I just hope next C revision adds some form of template support into the language.

I've had good luck with python and cython when I need to get close to the metal. I'd really like to see a comparison between C++ and that kind of arrangement, some time.

Reply on news.ycombinator.com