> One of the things I dislike about C++ template is code bloat.  This is 
> the
> undiscussed cost of templates.  So you make a template foo<type>.  You

   ...

Specializations aren't the only reason C++ templates cause significant 
code growth.  Another is that they (in the case of the most commonly 
used HP/SGI STL, at least) use inlining very heavily, so each 
instantiation is big and a lot of inlined code is instantiated several 
times all over the place.

For some cases, inlined handling of data structures is good.  Consider 
the performance of the STL sort vs. anything based on a callback or 
virtual method.

I'm not a big fan of C++ templates, but I don't think they're a very 
good argument against all specialization.

> And this applies to Ocaml even more so.  I mean, consider the function:

Less so, I would think, since most types are compatible.

> let f x = ...
>
> OK, so to specialize it for unboxed ints vr.s pointers takes two
> implementations of the function, f_pointer and f_int, right?  So now
> consider the function:
>
> let f x y z w = ...
>
> Do we need 16 different specializations for this function?

Not if they're generated at the point where they are first used(*), in 
which case a maximum of 16 specializations are created - compared to 
C++, where there is no maximum, and you often end up having things like 
std::map<std::string, my_object *> and std::map<std::string, 
my_other_object *> which are in fact identical.

(*) Obviously this requires some adjustments to the compilation model.

A quick grepping through .mli files in the OCaml source distribution 
reveals that there are zero instances of the string 'd but quite a few 
instances of 'c, which would seem to indicate that four variables is 
not common.

-------------------
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