On 17.05.2012 05:38, Pavel wrote:
> Juha Nieminen wrote:
>> Scott Lurndal<scott@slp53.sl.home> wrote:
>>> Code footprint in the icache (and memory) is the primary reason for no
>>> templates.
>>
>> And the alternative is what, exactly?
>>
>> Writing the functions for each separate type manually? Exactly how
>> would this
>> be different from the template (other than the template avoiding code
>> repetition)?
>>
>> Making the same code support different types? And how exactly would
>> this be
>> achieved? I see only two possibilities:
>>
>> (...)
>>
>> 2) Bypass type safety mechanisms and make the code handle things like
>> void
>> pointers and such. Yeah, great solution. (Not only is it completely
>> horrible
>> and unsafe code,
> Just a friendly poke, please don't take too seriously: I hope you are
> writing this post using an operating system unknown to me that is at
> least a decade old but is not fully composed of such completely horrible
> and unsafe code...
>

Makes me wonder ... according to [The Programming Languages
Beacon](http://www.lextrait.com/vincent/implementations.html) MS Windows
uses C++ (whatever that means, it's not like we have too many details
here). That means we cannot rule out that some OS components are
actually using templates.

> More seriously, in my experience template code carries more bugs and
> uglier than plain-old C-like code. I found it to be related to its
> inherent inflexibility that manifests itself after a while, e.g. as
> follows:
>

Well, my (limited) experience is the opposite.

> 1. At one moment in time we decide to use compile-time parametrization
> for a new system. We assume the arguments will always be known at
> compile time. We build the system and boast how flexible (...)
>
> 2. Sooner or later at least one "disruptive requirement" comes that
> translates to a necessity to select an algo or type based on information
> only available at run time. (...)
>
> 3. If the system is good for anything, that one disruptive requirement
> is followed by a number of others, not necessarily disruptive in
> themselves, but now they need to be implemented on top of over-bloated
> and/or ugly hacked system. (...)
>
> 4. A 1-year-ago "beautiful little system" is now known as "an ugly
> unmaintainable monster (...) Oh, yes, and compiling our system now takes
> many hours on the best available hardware (maybe as long as it used to
> take to add a new feature at stage #1).
>
> I hate to say it but the initial decision to rely on compile-time
> parametrization played a significant role in this outcome.
>

Is this FUD based on any actual experience or did you make it up on the
spot? (And do you really believe that templates played a *significant*
role?)

Just sayin' ... you *don't have to* base the whole design of something
on templates. You don't have to understand
[Boost.Spirit](http://boost-spirit.com/home/) to be using templates.

std::vector and friends is just fine, stick to the basics.

> To summarize, I do not mind templates for "programming-in-small" but it
> would be very unusual for me to base a design of a business system on
> them. Wherever possible I am trying to give a non-trivial component a
> non-template interface regardless of whether it uses templates in its
> implementation.
>

To repeat, this does seem like a prudent approach, but this doesn't
imply to not use *any* templates in a big project, and your quote from
above:

> in my experience template code carries more bugs and
> uglier than plain-old C-like code.

now more sounds like "huh, templates aren't the solution for everything,
you know", which I think noone really claims.

cheers,
Martin