Hacker News Reader

Comment by keveman | Hacker News Reader

Should we all take a serious look at functional programming? Absolutely. Should we start learning a functional programming language? Maybe not. C++ is a multi-paradigm language in which one can write functional programs, and it lends itself nicely to switching back to stateful imperative programming when needed.

View on HN

You can not "switch" to an imperative style in C++. You are always in imperative land by default in C++. You can "switch" to a functional island in the middle of C++, but it will forever be a foreign body in the greater C++ program, and a mere moment's inattention will quickly re-introduce imperative side-effects into your purely functional code. Or you'll use some library that re-introduces it, or somebody else on your team will use your putatively functional higher-order function to do something imperative.

C++ is a particularly awful language for trying to manage side-effects in or maintain a purely functional constraint on your code, because it offers so very, very many ways of performing side effects without meaning to, and only the thinnest possible compiler support for maintaining those constraints in the face of temptation (const). To be sure "a = b.c(d, e)" is a purely functional statement requires understanding arbitrary amounts of code to be sure that none of reams of code that can invoke accidentally violates your constraints.

I've only been using C++ for a few months, but it's my opinion that all function parameters should have been "const &" by default (except for maybe primitive types). Const correctness has helped me spot some nasty bugs, and it's too easy to accidentally forget the "&" and pass horrendously large structures by value, which must go through a copy constructor and destructor with every call. Plus, it gets really tedious typing "const Mat &src" a million times (guess which library I'm using, lol).

In C++11 "type const &name" can be simply replaced with "type name", no performance penalty involved.

That's simply not the case.. In general, the "no penalty" holds true for primitive data types, and when passing an r-value instance of a class that has a move copy constructor defined. In the case where your object is an expensively constructed l-value, it is preferable to pass by const reference rather than value (assuming you plan to use the object later... otherwise you could indeed pass using std::move semantics).

In C++11 you are supposed to use move semantics in your own classes. I'm not 100% sure but I think the standard require that the STL use move semantics.

Yes but this is one more thing you have to think about when implementing a class in C++ and one more chance to screw it up.

It makes vanilla C and raw pointers look a lot more appealing, to be honest.

Actually I think C++11 is a simpler language than C++03 or C++98. The problem is that we need to un-learn what we know and learn the new way of doing things.

C++11 is simpler for the casual user of classes but I'm not so sure it's easier if you're implementing a lot of classes yourself. I disable assignment and copying in all my classes by default unless I have a really good reason to implement them and I still pass by const & for types I define myself.

Maybe not general knowledge, but OP author wasa designer fo D language, is on a C++ subcommittee and has a lot invested in that language:

http://bartoszmilewski.com/2012/04/06/lang-next-trip-report/

Reply on news.ycombinator.com