Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy is the C++ STL is so heavily based on templates? (and not on *interfaces*)
    primarykey
    data
    text
    <p>I mean, aside from its obligating name (the Standard Template Library)...</p> <p>C++ initially intended to present OOP concepts into C. That is: you could tell what a specific entity could and couldn't do (regardless of how it does it) based on its class and class hierarchy. Some compositions of abilities are more difficult to describe in this manner due to the problematics of multiple inheritance, and the fact that C++ supports the concept of interfaces in a somewhat clumsy way (compared to java, etc), but it's there (and could be improved).</p> <p>And then templates came into play, along with the STL. The STL seemed to take the classical OOP concepts and flush them down the drain, using templates instead.</p> <p>There should be a distinction between cases when templates are used to generalize types where the types themeselves are irrelevant for the operation of the template (containers, for examples). Having a <code>vector&lt;int&gt;</code> makes perfect sense.</p> <p>However, in many other cases (iterators and algorithms), templated types are supposed to follow a "concept" (Input Iterator, Forward Iterator, etc...) where the actual details of the concept are defined entirely by the implementation of the template function/class, and not by the class of the type used with the template, which is a somewhat anti-usage of OOP.</p> <p>For example, you can tell the function:</p> <pre><code>void MyFunc(ForwardIterator&lt;...&gt; *I); </code></pre> <p><strong>Update:</strong> As it was unclear in the original question, ForwardIterator is ok to be templated itself to allow any ForwardIterator type. The contrary is having ForwardIterator as a concept.</p> <p>expects a Forward Iterator only by looking at its definition, where you'd need either to look at the implementation or the documentation for:</p> <pre><code>template &lt;typename Type&gt; void MyFunc(Type *I); </code></pre> <p>Two claims I can make in favor of using templates: compiled code can be made more efficient, by tailor-compiling the template for each used type, instead of using vtables. And the fact that templates can be used with native types.</p> <p>However, I am looking for a more profound reason why abandoning classical OOP in favor of templating for the STL? (Assuming you read that far :P)</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. COYou might to check out http://stackoverflow.com/questions/31693/what-are-the-differences-between-generics-in-c-and-java-and-templates-in-c. The accepted answer is an excellent explanation of what templates offer you over generics.
      singulars
    2. CO"compiled code can be made more efficient, by tailor-compiling the template for each used type, instead of using vtables." Yeah, but you get redundant code filling up the instruction cache. In modern CPU architectures, you're typically constrained on (cache) memory rather than clock cycles. But don't trust me: do the experiment. Err, well, except that it takes reimplementing g++ ;-)
      singulars
    3. CO@Jonas: That doesn't make sense. The constraint on cache costs clock cycles, which is why it is important. At the end of the day, it is clock cycles, not cache, that defines performance. Memory, and cache is only important in so far as it affects the clock cycles spent. Moreover, the experiment can be done easily. Compare, say, std::for_Each called with a functor argument, with the equivalent OOP/vtable approach. The difference in performance is *staggering*. Which is why the template version is used.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload