tuple <int, string, int> x=make_tuple(1, "anukul", 100);
cout << x[0]; //1
cout << get<0>(x); //2
2 works. 1 does not.
Why is it so?
From Lounge C++ I learnt that it is probably because the compiler does not know what data type is stored at that index.
But it did not make much sense to me as the compiler could just look up the declaration of that tuple and determine the data type or do whatever else is done while accessing other data structures' elements by index.
Because [] is an operator (named operator[]), thus a member function, and is called at run-time.
Whereas getting the tuple item is a template mechanism, it must be resolved at compile time. Which means this can be only done with the <> templating syntax.
To better understand, a tuple may store different types. A template function may return different types depending on the index passed, as this is resolved at compile time.
The operator[] must return a unique type, whatever the value of the passed parameter is. Thus the tuple functionality is not achievable.
get<0>(x) and get<1>(x) are two different functions generated at compile time, and return different types. The compiler generates in fact two functions which will be mangled to something like
int get_tuple_int_string_int_0(x)
and
string get_tuple_int_string_int_1(x)
The other answers here address the issue of why this isn't possible to implement, but it's also worth asking the question of whether it should be possible. (The answer is no.)
The subscript operator [] is semantically supposed to indicate dynamically-resolved access to a element of a collection, such as an array or a list (of any implementation). The access pattern generally implies certain things: the number of elements probably isn't known to the surrounding code, which element is being accessed will probably vary at runtime, and the elements are all of the same observable type (thus, to the calling code, interchangeable).
Thing is, a tuple isn't (that kind of) a collection. It's actually an anonymous struct, and its elements aren't interchangeable slots at all - semantically, they are regular fields. What's probably throwing you off is that they happen to be labelled with numbers, but that's really just an anonymous naming pattern - analogous to accessing the elements as x._0, x._1, etc. (The fact you can compute the field names at compile-time is a coincidental bonus enabled by C++'s type system, and is not fundamentally related to what a tuple is; tuples, and this answer, are not really specific to C++.)
So it doesn't support operator[] for the same reason that plain old structs don't support operator[]: there's no semantically-valid use for it in this context. Structures have a fixed set of fields that aren't interchangeable or dynamically computable, and since the tuple is a structure, not a collection, it follows the same rule. Its field names just look different.
It can be supported, it just needs to take a compile-time index. Since parameters of a function cannot be made constexpr, we need to wrap the index within a type and pass that instead. (e.g. std::integral_constant<std::size_t, N>.
The following is an extension of std::tuple that supports operator[].
template <typename... Ts>
class tuple : public std::tuple<Ts...> {
public:
using std::tuple<Ts...>::tuple;
template <std::size_t N>
decltype(auto) operator[](std::integral_constant<std::size_t, N>) {
return std::get<N>(*this);
}
};
It would be used like so:
tuple<int, std::string> x(42, "hello");
std::cout << x[std::integral_constant<std::size_t, 0>{}] << std::endl;
// prints: 42
To mitigate the std::integral_constant crazy, we can use variable template:
template <std::size_t N>
std::integral_constant<std::size_t, N> ic;
With this, we can say:
std::cout << x[ic<1>] << std::endl; // prints: hello
So it could be done. One guess as to why this is currently not available is because features such as std::integral_constant and variable templates may not have existed at the time std::tuple was introduced. As to why it doesn't exist even though those features exist, I would guess it's because no one have yet to proposed it.
It's not very clean supporting operator[] given you can't vary the static return type to match the accessed element. If the Standard Library had incorporated something like boost::any or boost::variant, it would make more sense.
Put another way, if you write something like:
int n = atoi(argv[1]);
int x = x[n];
Then what should it do if n doesn't address an int member of the tuple? To even support checking you'd need to store some manner of RunTime Type Information for tuples, which is extra overhead in the executable/memory.
Containers that support the subscript operator (i.e., operator[]) like std::vector or std::array are collections of homogenous values. Whatever the index provided to the subscript operator is, the value to return is always of the same type. Therefore, those containers can define a member function with the following declaration:
T& operator[](int);
Where T is the type of every element in the collection.
On the other hand, an std::tupe is a collection of heterogeneous values. The return value of a hypothetical subscript operator for std::tuple needs to vary with the index. Therefore, its return type depends on the index.
In the declaration of the operator[] given above, the index is provided as a function argument and therefore may be determined at run time. However, the return type of the function is something that needs to be determined at compile time, not at run time.
Since the return type of such a function depends on the index but must be determined at compile-time, the solution is to define instead a function template that accepts the index as a (non-type) template parameter. This way, the index is provided as a compile-time constant and the return type is able to change with the index:
template<std::size_t I, class... Types>
typename std::tuple_element<I, tuple<Types...>>::type& get(tuple<Types...>&) noexcept;
As you can see, std::get's return type depends on the index, I:
std::tuple_element<I, tuple<Types...>>::type&
Because tuple has no operator "bracket".
Why is it so? You cannot resolve templates based only on the return value. You cannot write
template<typename T>
T tuple::operator [](size_t i) const ;
Which is absolutely necessary to be able to allow statements like x[0]
This question already has answers here:
Reason for using non-type template parameter instead of regular parameter?
(6 answers)
Closed 8 years ago.
It is known that in C++ we can have non-type template parameters like int:
template <class T, int size>
void f(){...}
I wonder how it is different from the ordinary way of passing a parameter into a function:
template <class T>
void f(int size) {...}
I think one difference is that for templates size is evaluated at compile-time and substituted as literals when instantiating the template. Thus I doubt (correct me if I'm wrong) that every different size value leads to the creation of new binary codes (the ".text"), which seems to be an overhead.
Can anyone tell when this is necessary and worthwhile?
Thus I doubt (correct me if I'm wrong) that every different size value leads to the creation of new binary codes (the ".text"), which seems to be an overhead.
This is actually the case, and this is a common source of code bloat. You need to figure out when you want to generate different functions for each N and when you want a single function in which the compiler has less information (note that this is not just for performance, also for correctness).
Since Matt already brought a simple example, lets work on a function that takes an array by reference.:
template<typename T, size_t N>
size_t operateOnArray( T (&array)[N] )
{
// Some complex logic, which could include:
for (std::size_t i = 0; i < N; ++i) {
// complicated stuff
}
}
The type of the argument is a reference to an array, the compiler will verify for you that the array truly has N elements (and it will deduce the type of the values in the array). This is a great improvement in type safety compared with some similar C style code:
size_t operateOnArray( T *array, size_t N)
{
// Some complex logic, which could include:
for (std::size_t i = 0; i < N; ++i) {
// complicated stuff
}
}
In particular, the user can mistakenly pass the wrong value:
int array[10];
operateOnArray(arrah, 20); // typo!!!
Where in the first case the compiler will deduce the size and it will guarantee that it is correct.
You hit the nail in the head when you mentioned that this can potentially add to the code size, and that it can add quite a lot. Imagine that the function is complex enough that it does not get inlined, and imagine that in your program you end up calling the function with all sizes from 1 to 100. The program code will contain 100 instantiations of basically the same code where the only difference is the size.
There are solutions around this, like mixing the two approaches:
size_t operateOnArray( T *array, size_t N); // Possibly private, different name...
template<typename T, size_t N>
size_t operateOnArray( T (&array)[N] ) {
operateOnArray(array, N);
}
In this case, the compiler will have one single copy of the complex code, in the C-style function, and will generate 100 versions of the template, but those are simple, simple enough that the compiler will inline the code and transform the program into the equivalent of the C-style approach with guaranteed type safety.
Can anyone tell when this is necessary and worthwhile?
It is necessary when the code inside the template requires the value as a compile time constant, for example in the code above, you cannot have a function argument that is a reference to an array of N elements where the N is only available at runtime. In other cases, like std::array<T,N> it is required to statically create an array of the proper size. No matter what, all examples shared that: the value needs to be known at compile time.
It is worthwhile, well, when it adds type safety to your program (see example above), or if it will allow stronger optimizations (a functor taking a function pointer/member function pointer as non-type argument can inline the function call).
And you should be aware that everything comes at a cost, in this case binary size. If the template is small enough that the code is likely to be inlined, don't worry, but if the code is quite complex, consider using hybrid approaches where you use a template argument where needed or if it provides a big advantage and regular arguments otherwise.
As well as providing for much greater optimization ability, the parameters can be involved in template deduction (unlike function arguments), e.g. this is a common one for finding how many items are in a named array:
template<typename T, size_t N>
size_t lengthof( T (&array)[N] )
{
return N;
}
Usage:
#include <iostream>
int main()
{
wchar_t foo[] = L"The quick brown fox";
std::wcout << "\"" << foo << "\" has " << lengthof(foo) - 1 << " characters.\n";
}
Probably the compiler will calculate the length at compiletime and substitute that directly into the wcout << ....... line, not even making a runtime function call.
Passing size as a non-type template parameter is necessary when f() wants to allocate a C-style array of that size (e.g., as f(){int array[size]; }). If you pass size as a function parameter, your program won't compile because the size is not known at compile time.
Compile-time dimensional analysis. This one has helped me detect errors early when implementing physics simulations.
Are the following things, considered intrinsic to FP, possible in C++?
higher order functions
lambdas (closures/anonymous functions)
function signatures as types
type polymorphism (generics)
immutable data structures
algebraic data types (variants)
adhock data structures (tuples)
partial function applications
type inference
tail recursion
pattern matching
garbage collection
Let me start by noting that most of these are not "intrinsic", or shall we say, "required"; many of these are absent from notable functional languages, and in theory, many of these features can be used to implement the others (such as higher order functions in untyped lambda calculus).
However, let's go through these:
Closures
Closures are not necessary, and are syntactical sugar: by the process of Lambda Lifting, you can convert any closure into a function object (or even just a free function).
Named Functors (C++03)
Just to show that this isn't a problem to begin with, here's a simple way to do this without lambdas in C++03:
Isn't A Problem:
struct named_functor
{
void operator()( int val ) { std::cout << val; }
};
vector<int> v;
for_each( v.begin(), v.end(), named_functor());
Anonymous functions (C++11)
However, anonymous functions in C++11 (also called lambda functions, as they derive from the LISP history), which are implemented as non-aliasingly named function objects, can provide the same usability (and are in fact referred to as closures, so yes, C++11 does have closures):
No problem:
vector<int> v;
for_each( v.begin(), v.end(), [] (int val)
{
std::cout << val;
} );
Polymorphic anonymous functions (C++14)
Even less of a problem, we don't need to care about the parameter types anymore in C++14:
Even Less Problem:
auto lammy = [] (auto val) { std::cout << val; };
vector<int> v;
for_each( v.begin(), v.end(), lammy);
forward_list<double> w;
for_each( w.begin(), w.end(), lammy);
I should note this fully support closure semantics, such as grabbing variables from scope, both by reference and by value, as well as being able to grab ALL variables, not merely specified ones. Lambda's are implicitly defined as function objects, providing the necessary context for these to work; usually this is done via lambda lifting.
Higher Order Functions
No problem:
std::function foo_returns_fun( void );
Is that not sufficient for you? Here's a lambda factory:
std::function foo_lambda( int foo ) { [=] () { std::cout << foo; } };
You can't create functions, but you can function objects, which can be passed around as std::function same as normal functions. So all the functionality is there, it's just up to you to put it together. I might add that much of the STL is designed around giving you reusable components with which to form ad-hoc function objects, approximating creating functions out of whole cloth.
Partial Function Applications
No problem
std::bind fully supports this feature, and is quite adept at transformations of functions into arbitrarily different ones as well:
void f(int n1, int n2, int n3, const int& n4, int n5)
{
std::cout << n1 << ' ' << n2 << ' ' << n3 << ' ' << n4 << ' ' << n5 << '\n';
}
int n = 7;
// (_1 and _2 are from std::placeholders, and represent future
// arguments that will be passed to f1)
auto f1 = std::bind(f, _2, _1, 42, std::cref(n), n);
For memoization and other partial function specialization techniques, you have to code it yourself using a wrapper:
template <typename ReturnType, typename... Args>
std::function<ReturnType (Args...)>
memoize(ReturnType (*func) (Args...))
{
auto cache = std::make_shared<std::map<std::tuple<Args...>, ReturnType>>();
return ([=](Args... args) mutable
{
std::tuple<Args...> t(args...);
if (cache->find(t) == cache->end())
(*cache)[t] = func(args...);
return (*cache)[t];
});
}
It can be done, and in fact it can be done relatively automatically, but no one has yet done it for you.
}
Combinators
No problem:
Let's start with the classics: map, filter, fold.
vector<int> startvec(100,5);
vector<int> endvec(100,1);
// map startvec through negate
std::transform(startvec.begin(), startvec.end(), endvec.begin(), std::negate<int>())
// fold startvec through add
int sum = std::accumulate(startvec.begin(), startvec.end(), 0, std::plus<int>());
// fold startvec through a filter to remove 0's
std::copy_if (startvec.begin(), startvec.end(), endvec.begin(), [](int i){return !(i==0);} );
These are quite simple, but the headers <functional>, <algorithm>, and <numerical> provide dozens of functors (objects callable as functions) which can be placed into these generic algorithms, as well as other generic algorithms. Together, these form a powerful ability to compose features and behavior.
Let's try something more functional though: SKI can easily be implemented, and is very functional, deriving from untyped lambda calculus:
template < typename T >
T I(T arg)
{
return arg;
}
template < typename T >
std::function<T(void*)> K(T arg)
{
return [=](void*) -> T { return arg; };
}
template < typename T >
T S(T arg1, T arg2, T arg3)
{
return arg1(arg3)(arg2(arg1));
}
These are very fragile; in effect, these must be of a type which returns it's own type and takes a single argument of their own type; such constraints would then allow for all the functional reasoning of the SKI system to be applied safely to the composition of these. With a little work, and some template metaprogramming, much of this could even be done at compile time through the magic of expression templates to form highly optimized code.
Expression templates, as an aside, are a technique in which an expression, usually in the form of a series of operations or sequential order of code, is based as an argument to a template. Expression templates therefore are compile time combinators; they are highly efficient, type safe, and effectively allow for domain specific languages to be embedded directly into C++. While these are high level topics, they are put to good use in the standard library and in boost::spirit, as shown below.
Spirit Parser Combinators
template <typename Iterator>
bool parse_numbers(Iterator first, Iterator last)
{
using qi::double_;
using qi::phrase_parse;
using ascii::space;
bool r = phrase_parse(
first,
last,
double_ >> (char_(',') >> double_),
space
);
if (first != last) // fail if we did not get a full match
return false;
return r;
}
This identifies a comma deliminated list of numbers. double_ and char_ are individual parsers that identify a single double or a single char, respectively. Using the >> operator, each one passes themselves to the next, forming a single large combined parser. They pass themselves via templates, the "expression" of their combined action building up. This is exactly analogous to traditional combinators, and is fully compile time checked.
Valarray
valarray, a part of the C++11 standard, is allowed to use expression templates (but not required, for some odd reason) in order to facilitate efficiency of transforms. In theory, any number of operations could be strung together, which would form quite a large messy expression which can then be aggressively inlined for speed. This is another form of combinator.
I suggest this resource if you wish to know more about expression templates; they are absolutely fantastic at getting all the compile time checks you wish done, as well as improving the re-usability of code. They are hard to program, however, which is why I would advise you find a library that contains the idioms you want instead of rolling your own.
Function Signatures As Types
No problem
void my_int_func(int x)
{
printf( "%d\n", x );
}
void (*foo)(int) = &my_int_func;
or, in C++, we'd use std::function:
std::function<void(int)> func_ptr = &my_int_func;
Type Inference
No problem
Simple variables typed by inference:
// var is int, inferred via constant
auto var = 10;
// y is int, inferred via var
decltype(var) y = var;
Generic type inference in templates:
template < typename T, typename S >
auto multiply (const T, const S) -> decltype( T * S )
{
return T * S;
}
Furthermore, this can be used in lambdas, function objects, basically any compile time expression can make use of decltype for compile time type inference.
But that's not what you are really after here, are you? You want type deduction as well as type restriction, you want type reconstruction and type derivations. All of this can be done with concepts, but they are not part of the language yet.
So, why don't we just implement them? boost::concepts, boost::typeerasure, and type traits (descendant from boost::tti and boost::typetraits) can do all of this.
Want to restrict a function based on some type? std::enable_if to the rescue!
Ah, but that's ad hoc right? That would mean for any new type you'd want to construct, you'd need to do boilerplate, etc etc. Well, no, but here's a better way!
template<typename RanIter>
BOOST_CONCEPT_REQUIRES(
((Mutable_RandomAccessIterator<RanIter>))
((LessThanComparable<typename Mutable_RandomAccessIterator<RanIter>::value_type>)),
(void)) // return type
stable_sort(RanIter,RanIter);
Now your stable_sort can only work on types that match your stringent requirements. boost::concept has tons of prebuilt ones, you just need to put them in the right place.
If you want to call different functions or do different things off types, or disallow types, use type traits, it's now standard. Need to select based on parts of the type, rather than the full type? Or allow many different types, which have a common interface, to be only a single type with that same interface? Well then you need type erasure, illustrated below:
Type Polymorphism
No problem
Templates, for compile time type polymorphism:
std::vector<int> intvector;
std::vector<float> floatvector;
...
Type erasure, for run time and adaptor based type polymorphism:
boost::any can_contain_any_type;
std::function can_call_any_function;
any_iterator can_iterator_any_container;
...
Type erasure is possible in any OO language, and involves setting up small function objects which derive from a common interface, and translate internal objects to it. With a little boost MPL boilerplate, this is fast, easy, and effective. Expect to see this become real popular soon.
Immutable Datastructures
Not syntax for explicit constructions, but possible:
Can be done via not using mutators or template metaprogramming. As this is a lot of code (a full ADT can be quite large), I will link you here, to show how to make an immutable singly linked list.
To do this at compile time would require a good amount of template magic, but can be done more easily with constexpr. This is an exercise for the reader; I don't know of any compile time libraries for this off the top of my head.
However, making an immutable datastructure from the STL is quite easy:
const vector<int> myvector;
There you are; a data structure that cannot be changed! In all seriousness, finger tree implementations do exist and are probably your best bet for associative array functionality. It's just not done for you by default.
Algebraic data types
No problem:
The amazing boost::mpl allows you to constrain uses of types, which along with boost::fusion and boost::functional to do anything at compile time that you would want in regards to ADT. In fact, most of it is done for you:
#include <boost/mpl/void.hpp>
//A := 1
typedef boost::mpl::void_ A;
As stated earlier, a lot of the work isn't done for you in a single place; for example, you'd need to use boost::optional to get optional types, and mpl to get unit type, as seen above. But using relatively simple compile time template mechanics, you can do recursive ADT types, which means you can implement generalized ADT's. As the template system is turing complete, you have a turing complete type checker and ADT generator at your disposal.
It's just waiting for you to bring the pieces together.
Variant based ADT's
boost::variant provides type checked unions, in addition to the original unions in the language. These can be used with no fuss, drop in:
boost::variant< int, std::string > v;
This variant, which can be int or string, can be assigned either way with checking, and you can even do run time variant based visitation:
class times_two_visitor
: public boost::static_visitor<>
{
public:
void operator()(int & i) const
{
i *= 2;
}
void operator()(std::string & str) const
{
str += str;
}
};
Anonymous/Ad-hoc data structures
No problem:
Of course we have tuples! You could use structs if you like, or:
std::tuple<int,char> foo (10,'x');
You can also perform a good deal of operations on tuples:
// Make them
auto mytuple = std::make_tuple(3.14,"pi");
std::pair<int,char> mypair (10,'a');
// Concatenate them
auto mycat = std::tuple_cat ( mytuple, std::tuple<int,char>(mypair) );
// Unpack them
int a, b;
std::tie (a, std::ignore, b, std::ignore) = mycat;
Tail Recursion
No explicit support, iteration is sufficient
This is not supported or mandated in Common LISP, though it is in Scheme, and therefore I don't know if you can say it's required. However, you can easily do tail recursion in C++:
std::size_t get_a_zero(vector<int>& myints, std::size_t a ) {
if ( myints.at(a) == 0 ) {
return a;
}
if(a == 0) return myints.size() + 1;
return f(myints, a - 1 ); // tail recursion
}
Oh, and GCC will compile this into an iterative loop, no harm no foul. While this behavior is not mandated, it is allowable and is done in at least one case I know of (possibly Clang as well).
But we don't need tail recursion: C++ totally is fine with mutations:
std::size_t get_a_zero(vector<int>& myints, std::size_t a ) {
for(std::size_t i = 0; i <= myints.size(); ++i){
if(myints.at(i) == 0) return i;
}
return myints.size() + 1;
}
Tail recursion is optimized into iteration, so you have exactly as much power.
Furthermore, through the usage of boost::coroutine, one can easily provide usage for user defined stacks and allow for unbounded recursion, making tail recursion unnecessary. The language is not actively hostile to recursion nor to tail recursion; it merely demands you provide the safety yourself.
Pattern Matching
No problem:
This can easily be done via boost::variant, as detailed elsewhere in this, via the visitor pattern:
class Match : public boost::static_visitor<> {
public:
Match();//I'm leaving this part out for brevity!
void operator()(const int& _value) const {
std::map<int,boost::function<void(void)>::const_iterator operand
= m_IntMatch.find(_value);
if(operand != m_IntMatch.end()){
(*operand)();
}
else{
defaultCase();
}
}
private:
void defaultCause() const { std::cout << "Hey, what the..." << std::endl; }
boost::unordered_map<int,boost::function<void(void)> > m_IntMatch;
};
This example, from this very charming website shows how to gain all the power of Scala pattern matching, merely using boost::variant. There is more boilerplate, but with a nice template and macro library, much of that would go away.
In fact, here is a library that has done all that for you:
#include <utility>
#include "match.hpp" // Support for Match statement
typedef std::pair<double,double> loc;
// An Algebraic Data Type implemented through inheritance
struct Shape
{
virtual ~Shape() {}
};
struct Circle : Shape
{
Circle(const loc& c, const double& r) : center(c), radius(r) {}
loc center;
double radius;
};
struct Square : Shape
{
Square(const loc& c, const double& s) : upper_left(c), side(s) {}
loc upper_left;
double side;
};
struct Triangle : Shape
{
Triangle(const loc& a, const loc& b, const loc& c) : first(a), second(b), third(c) {}
loc first;
loc second;
loc third;
};
loc point_within(const Shape* shape)
{
Match(shape)
{
Case(Circle) return matched->center;
Case(Square) return matched->upper_left;
Case(Triangle) return matched->first;
Otherwise() return loc(0,0);
}
EndMatch
}
int main()
{
point_within(new Triangle(loc(0,0),loc(1,0),loc(0,1)));
point_within(new Square(loc(1,0),1));
point_within(new Circle(loc(0,0),1));
}
As provided by this lovely stackoverflow answer
As you can see, it is not merely possible but also pretty.
Garbage Collection
Future standard, allocators, RAII, and shared_ptr are sufficient
While C++ does not have a GC, there is a proposal for one that was voted down in C++11, but may be included in C++1y. There are a wide variety of user defined ones you can use, but the C++ does not need garbage collection.
C++ has an idiom know as RAII to deal with resources and memory; for this reason, C++ has no need for a GC as it does not produce garbage; everything is cleaned up promptly and in the correct order by default. This does introduce the problem of who owns what, but this is largely solved in C++11 via shared pointers, weak pointers, and unique pointers:
// One shared pointer to some shared resource
std::shared_ptr<int> my_int (new int);
// Now we both own it!
std::shared_ptr<int> shared_int(my_int);
// I can use this int, but I cannot prevent it's destruction
std::weak_ptr<int> weak_int (shared_int);
// Only I can ever own this int
std::unique_ptr<int> unique_int (new int);
These allow you to provide a much more deterministic and user controlled form of garbage collection, that does not invoke any stop the world behavior.
That not easy enough for you? Use a custom allocator, such as boost::pool or roll your own; it's relatively easy to use a pool or arena based allocator to get the best of both worlds: you can easily allocate as freely as you like, then simply delete the pool or arena when you are done. No fuss, no muss, and no stopping the world.
However, in modern C++11 design, you would almost never use new anyway except when allocating into a *_ptr, so the wish for a GC is not necessary anyway.
In Summary
C++ has plenty of functional language features, and all of the ones you listed can be done, with the same power and expression ability of Haskell or Lisp. However, most of these features are not built in by default; this is changing, with the introduction of lambda's (which fill in the functional parts of the STL), and with the absorption of boost into the standard language.
Not all of these idioms are the most palatable, but none of them are particularly onerous to me, or unamendable to a few macros to make them easier to swallow. But anyone who says they are not possible has not done their research, and would seem to me to have limited experience with actual C++ programming.
From your list, C++ can do:
function signatures as types
type polymorphism (but not first-class like in many functional languages)
immutable data structures (but they require more work)
It can do only very limited forms of:
higher order functions / closures (basically, without GC most of the more interesting higher-order functional idioms are unusable)
adhoc data structures (if you mean in the form of light-weight structural types)
You can essentially forget about:
algebraic data types & pattern matching
partial function applications (requires implicit closures in general)
type inference (despite what people call "type inference" in C++ land it's a far shot from what you get with Hindley/Milner a la ML or Haskell)
tail calls (some compilers can optimise some limited cases of tail self-recursion, but there is no guarantee, and the language is actively hostile to the general case (pointers to the stack, destructors, and all that))
garbage collection (you can use Boehm's conservative collector, but it's no real substitute and rather unlikely to coexist peacefully with third-party code)
Overall, trying to do anything functional that goes beyond trivialities will be either a major pain in C++ or outright unusable. And even the things that are easy enough often require so much boilerplate and heavy notation that they are not very attractive. (Some C++ aficionados like to claim the opposite, but frankly, most of them seem to have rather limited experience with actual functional programming.)
(Just to add a little to Alice's answer, which is excellent.)
I'm far from a functional programming expert, but the compile-time template metaprogramming language in C++ is often seen as being "functional", albeit with a very arcane syntax. In this language, "functions" become (often recursive) class template instantiations. Partial specialisation serves the purpose of pattern matching, to terminate recursion and so on. So a compile-time factorial might look something like so:
template <int I>
struct fact
{
static const int value = I * fact<I-1>::value;
};
template <>
struct fact<1>
{
static const int value = 1;
};
Of course, this is pretty hideous, but many people (particularly the Boost developers) have done incredibly clever and complex things with just these tools.
It's possibly also worth mentioning the C++11 keyword constexpr, which denotes functions which may be evaluated at compile time. In C++11, constexpr functions are restricted to (basically) just a bare return statement; but the ternary operator and recursion are allowed, so the above compile-time factorial can be restated much more succinctly (and understandably) as:
constexpr int fact(int i)
{
return i == 1 ? 1 : i * fact(i-1);
}
with the added benefit that fact() can now be called at run-time too. Whether this constitutes programming in a functional style is left for the reader to decide :-)
(C++14 looks likely to remove many of the restrictions from constexpr functions, allowing a very large subset of C++ to be called at compile-time)
On a funny note, if there's a <functional> standard header, that means that there's at least some substantial support for functional programming.
Indeed, a great and important part of the C++ language is, in fact, template meta-programming, which is a powerful tool when one needs to write generic code. But TMP is compile-time and, most importantly, is about type computation. And types can't be changed, so once you "declare a variable holding a type", it will not hold any other type (more on the matter here); it's immutable, so you have to think in terms of functional programming principles to work with and to understand TMP. To cite Louis Dionne (from the intro to his Boost.Hana's documentation),
Programming with heterogeneous objects is inherently functional – since it is impossible to modify the type of an object, a new object must be introduced instead, which rules out mutation. Unlike previous metaprogramming libraries whose design was modeled on the STL, Hana uses a functional style of programming which is the source for a good portion of its expressiveness. However, as a result, many concepts presented in the reference will be unfamiliar to C++ programmers without a knowledge of functional programming. The reference attempts to make these concepts approachable by using intuition whenever possible, but bear in mind that the highest rewards are usually the fruit of some effort.
With reference to the list in the question, I would suggest reading Why Functional Programming Matters, which highlights that the truly fundamental features of such a programming paradigm are mainly 2:
higher order functions,
lazy evaluation.
And C++ gives you both. At least today:
That C++ has higher-order functions is not been a secret for a long time. Most if not all <algorithm>s accept a function or function object to customize their behavior, so algorithms are higher-order function. Some "standard" function objects you might want to pass to higher-order functions are defined in <functional> and with the help of lambdas you can write as many and as varied as you want.
As stated in a comment, you can do all you want with a Turing-complete language, and C++ offers tools to make lazy evaluation possible with human-level efforts (no, I'm not saying I'd been able to do it). A library which leverages a lot of C++ power to enable lazy evaluation is Range-v3 (which C++20's <ranges> is just a small part of). To give a silly example, if you were to execute
somelist = join $ map (take 1) $ chunk 2 $ drop 10 $ [0..] in Haskell
you'd have in somelist a proxy for an infinite list that would materialize to [10,12,14,16,…] if you were to try traversing it. Similarly with Range-v3 you could do the same think by writing something very similar, such as auto somelist = iota(0) | drop(10) | chunk(2) | transform(take(1)) | join; (working code for a similar example is here), where the differences are minimal, if you think about it.
Furthermore, I would suggest to refer to Ivan Čukić' Functional Programming in C++ for some practical examples of how you can write functional programming in C++.
And since I mentioned it, I would strongly suggest to read QuickStart of Louis Dionne's Boost.Hana (I'll make some reference to specific bits of the doc in the rest of the answer).
Now, some comments on some of the points in the list.
higher order functions
I'd say C++ has this since… the '90s? Having higher-order functions in a language simply means that functions are first class or, in other words, that they can be passed to and returned by other functions calls. Now, strictly speaking, properly said C++ functions are not like that: you can't a pass a function to anther one, but just a pointer to it, which in many scenarii works the same, but it's still a different thing. On the other hand C++ has operator overloading, which allows you to write a struct+operator(), and an object of that class *can be passed around and behaves just like a function. So yes, C++ has had higher-order functions for a long time; at least since operator overloading was introduced (1985, apparently).
lambdas (closures/anonymous functions)
Lambdas were introduced in C++11, but they have become more powerful with each standard. To give some examples, C++14 introduced generic lambdas, C++17 made stateless lambdas constexprable, and C++20 allowed an explicit list of template parameters. They obviously are more restricted than hand-written struct+operator()s, but as far as functional programming is concerned, they are just good. Personally, I only see them come short pre-C++20 because you can't make them accept all types satisfying a concept: you either have [](the type){} or [](auto){}. With C++20 you can have []<SomeConcept T>(T){}, so I don't know why I'd ever want to write a struct+operator().
immutable data structures
Well, I would say that mutating data structures is a choice, more than a tool. I'm happy I can mutate things if I want to, but I can still write code by adhering to functional programming principles.
partial function applications
As soon as you can pass functions around, you can write higher-order functions to curry or partially apply functions. I think there's an example in the book I mentioned above, but more practically, you can just make use of Boost.Hana's abstractions. It offers boost::hana::partial to partially apply a function, satisfying partial(f, x...)(y...) == f(x..., y...); but also reverse_partial, which satisfies reverse_partial(f, x...)(y...) == f(y..., x...). But in reality, it offers quite a bit combinators which are common to the functional programming language par excellence, Haskell, and which I list below¹.
tail recursion
I suspect this is more about how good compilers can be at understanding your code and producing the most appropriate binary.
pattern matching
Not there yet, but this talk by Herb Sutter is a "must watch"!
garbage collection
C++11 introduced std::unique_ptr, std::shared_ptr, std::weak_ptr, which have (all?) improved over time. They all together provide what you need to have a deterministic garbage collector in C++.
(¹) Here are some of the combinators offered by Boost.Hana.
filp, satisfying flip(f)(x, y, z...) == f(y, x, z...) and, if you are familiar with Haskell, corresponding to Haskell's namesake,
id, which corresponds to C++20 std::identity and to Haskell's namesake
on, which satisfies on(f, g)(x...) == f(g(x)...) and corresponds to Haskell's Data.Function.on, but is actually more general!
compose, which corresponds to Haskell's namesake
always, which corresponds to Haskell's const
demux, which I don't dare explaining in words, but which obeys demux(f)(g...)(x...) == f(g(x...)...)