テンプレート関数オブジェクトの戻り値の型を（コンパイル時に）決定するのに、直感的な方法がない。特に引数の型に基づいて決まる場合は顕著である。例として以下のコードを挙げる:struct clear {  int    operator ()(int   ); //引数の型と戻り値の型が同じ  double operator ()(double);};template<class Obj>class calculus {  Obj member;  public:  template<class Arg>  Arg operator ()(Arg& a) const  {    return member(a);  }};calculusクラステンプレートをclearクラスで実体化する場合（calculus<clear>として実体化する場合）、calculus関数オブジェクトはclear関数オブジェクトと同じ戻り値型を持つ。ここで、calculusクラステンプレートをconfusedクラスで実体化する場合（calculus<confused>として実体化する場合）を考えよう:struct confused {  double operator ()(int   ); //引数の型と戻り値の型が違う  int    operator ()(double);};calculusの戻り値型はconfusedクラスと同じではない（calculus<confused>.operator()の実体化に伴い、intから doubleへの変換や逆変換が起こる）。次期標準に提案されている新ライブラリで、result_ofクラステンプレートが導入され、各宣言ごとに関数オブジェクトの戻り値型の決定と使用が可能になる。これを用いて、関数オブジェクトの戻り値型を取得するようにすることでcalculusを修正した:template<class Obj>class calculus_ver2 {  Obj member;  public:  template<class Arg>  typename result_of<Obj(Arg)>::type operator()(Arg& a) const  {     return member(a);  }};このようにすることで、関数オブジェクトcalculus_ver2<confused>の実体化の際に、型変換は発生しない。関数オブジェクト呼び出し時の戻り値型の決定は、式の戻り値型を決定するという一般的な問題の一部である。将来的には、問題の起き得る箇所にdecltypeのような機能を使うことで解決されるだろう。
参照ラッパはテンプレートクラスstd::reference_wrapperのインスタンスとして得られる。参照ラッパは、C++言語の通常のリファレンス ('&') にも似ている。オブジェクトから参照ラッパを得るには、テンプレート関数std::refを使う（constな参照の場合はstd::crefが使用される）。参照ラッパはテンプレート関数と使用する場合に有用であり、特に引数としてコピーではなく参照を取る必要がある場合に便利である:#include <iostream>#include <functional>// 引数 r として int への参照を受け取り、それを増加させる関数。void inc(int& r) {  r++;}// 関数を呼び出す高階関数テンプレート。template<class F, class P>void invoke(F f, P t) { f(t); }int main() {  int i = 0;  invoke(inc, i);  // invoke<void(int& r), int> が実体化される。  // よって i の値は変更されない。  std::cout << i << std::endl; // 0 が出力される。  invoke(inc, std::ref(i));  // invoke<void(int& r), std::reference_wrapper<int>> が実体化される。  // よって i の値が変更される。  std::cout << i << std::endl; // 1 が出力される。  return 0;}この新ユーティリティは現在の<utility>に追加される。C++言語の拡張は必要としない。なお、上記の高階関数テンプレートは、のちにC++17にて可変長引数テンプレートstd::invokeとして標準化されている。
random_deviceクラスを用いて、unsigned int型の非決定的乱数を生成できる。実装には、システムから独立した入力を持つデバイス（例えば、非同期的な外部カウンタや、特殊なトランスデューサーなど）の使用や、伝統的な「結果を調節する」擬似乱数エンジンの使用が必要である。libstdc++やlibc++では、/dev/urandomを読み出す実装となっている。
コンピュータは決定的な振る舞いをするものであるが、疑似乱数による乱数列を生成することにより、（外見だけでも）非決定的な振る舞いが必要となるようなアプリケーションがある。標準に用意されている方法は、rand関数のみである。しかし、十分な定義がされていないため、そのアルゴリズムは完全にライブラリ開発者に任せられている。新たな乱数生成ユーティリティは<random>ヘッダを通して定義される。他のヘッダやC++言語への修正は必要としない。乱数生成器は、内部状態と、結果を計算し次の状態を生成するための関数をもつ。この2つの特性によって、乱数生成エンジンが定まる。他の特性として、生成結果や乱数の間隔や密度の分布も重要である。
トレヴァー＝ローパーによれば、イングランド内戦の原因としてピューリタンとアルミニアンとの対立が大きな位置を占めることは間違いないものの、しかし原因は他にもある。彼に言わせれば両者の争いは予定説か自由意思か、また聖礼典か説教のどちらが重要かなど、いずれもイングランド国教会のあり方をめぐる問題に過ぎない。ピューリタンは教会機構の地方分権化および各教会の平等化、そして平信徒に対して開かれた教会を目指したのに対し、アルミニアンは主教をトップとする堅固な職階制に基づく秩序ある教会を目指し、また王権神授説と個人の意思による救済を強調した。イギリス近世史家として、トレヴァー＝ローパーはオックスフォードの同僚であるローレンス・ストーン (en) やクリストファー・ヒルのような、イングランド内戦を史的唯物論の立場から（ある場合には「必然」として）説明する歴史学者たちを猛烈に攻撃したことで最もよく知られている。トレヴァー＝ローパーはいわゆる「ジェントリ論争」で中心的な役割を果たし、イングランドのジェントリ階層はイングランド内戦が起きる前の世紀までに経済的に勃興したのか没落していたのか、そしてそれが内戦の発端となったのかをめぐり、キリスト教社会主義者のR・H・トーニー (en) やストーンとの論戦を展開した。トレヴァー＝ローパーは官職保有者や法律家となっている大ジェントリが経済的に栄え、逆に中小ジェントリは没落して不満を蓄積していたことが1642年の内戦の発端となったと主張した。ストーンやトーニー、ヒルはジェントリ階層が経済的に成長して、このことがイングランド内戦の原因になったと主張していた。第3のグループ、J・H・ヘクスター (en) やジェフリー・エルトン (en) は、ジェントリが勃興したにせよ没落したにせよそれが内戦の原因にはならなかったと主張した。1948年、トレヴァー＝ローパーは、トーニーの学説を支持したストーンの研究論文を、憎々しげな調子の小論文で激しく攻撃し、ストーンはテューダー朝時代の貴族が抱えていた借金問題を誇張しすぎていると断じている。そしてトレヴァー＝ローパーはトーニーのジェントリの勃興と貴族の没落に関する論説を弾劾し、トーニーが史料の恣意的な選択と統計に対する誤った解釈を行ったことは罪深いと断じた。