Browse thread
[Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-09-26 (01:39) |
From: | Jon Harrop <jon@j...> |
Subject: | Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features |
On Saturday 25 September 2004 23:52, Vasili Galchin wrote: > I am reluctantly learning C++ STL (Standard Template Library) and the > notion of templates. Templates don't seem to be that great ... just > parametric plymorphism done in a somewhat heavy handed way when compared to > the same in OCaml, Haskell, etc. A beneficial (although inelegant) advantage of templates is the ability to partially specialise programs by performing arbitrary compile-time computation. This is not available in OCaml. This will be addressed (in a much more powerful and elegant way) by MetaOCaml just as soon as Taha at al. stop reading this mailing list and start working harder. ;-) > However, teh STL notion of containers and > available operations allowed on containers does seem to be be very powerful > and not available in OCaml. Is the last statement true? That last statement is only true in the absence of higher-order functions. Therefore, it does not apply to OCaml. In functional languages, like OCaml, the operations on containers are much more productively factored into higher-order functions which are then container-type independent. In particular, the ubiquitous map and fold functions. For example, to sum the floating-point elements of a container in C++, one might write: #include <iostream> #include <list> #include <vector> template<typename IT> double sum(IT begin, IT end) { double ans=0.; for (IT it=begin; it!=end; it++) ans +. *it; return ans; } int main(void) { list<double> A; A.push_back(0.); A.push_back(1.); A.push_back(2.); A.push_back(3.); A.push_back(4.); vector<double> B; B.push_back(0.); B.push_back(1.); B.push_back(2.); B.push_back(3.); B.push_back(4.); cout << sum(A.begin(), A.end()) << endl << sum(B.begin(), B.end()) << endl; } The OCaml equivalent would be: let sum fold_left c = fold_left ( +. ) 0. c sum List.fold_left [0.; 1.; 2.; 3.; 4.] sum Array.fold_left [|0.; 1.; 2.; 3.; 4.|] If you have more time than sense then you'll prefer the C++ version (which is vastly more verbose and a bit quicker). If, on the other hand, you can see the forest for the trees then you'll want to be using OCaml because, given the same time, you can write OCaml programs which are both faster and smaller than equivalents written in virtually any other language. Not to mention that compilation of equivalent programs is typically between one and two orders of magnitude faster using ocamlopt rather than g++. Believe it or not, the previous example favours C++ more than most others. Check out this example of function composition from SGI's STL manual: list<int>::iterator new_end = remove_if(L.begin(), L.end(), compose2(logical_and<bool>(), bind2nd(greater<int>(), 100), bind2nd(less<int>(), 1000))); L.erase(new_end, L.end()); In OCaml: let l = List.filter (fun x -> not (100<x<1000)) l These days, when I read fancy statements in the STL manual, like "function object adaptor", I just roll around laughing. The STL does have some contructs which do not have direct equivalents in OCaml. Type traits, for example, allow templates to carry information on concrete types such that more highly type-specialised functions can be used to perform a given task, chosen at compile time. However, OCaml errs on the side of run-time polymorphism rather than compile-time. Cheers, Jon. PS: I made several errors when writing that C++ code. Even if you just put "A()" instead of "A" when declaring a list, you get a page full of STL errors. God its nice to be writing OCaml... :-) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners