These template things are good...right?

[Steven T. Hatton]

Perhaps I'm just a bit frustrated, and I will soon realize the clear truth
of the matter, but right now I have some serious misgivings about the value
of investing a lot of time and effort into template programming. I just
finished reading the first 12 chapters of _C++ Templates: The Complete
Guide_. One thing that struck me as I read these chapters is how much I
didn't know about C++. I _know_ the core language specification is
contained in a finite document, but I sometimes get the sense that C++
requires an infinite amount of learning.

The primary C++ language (without templates) is substantial and quite
powerful in itself. There are many aspects of that which I have yet to
fully master. While I will grant that working with templates can help
shore up some of those skills, I have to wonder how useful templates really
are. I have discovered that code using templates can frequently not behave
as I expect or want. An example is the std::for_each algorithm. I use the
for-each idiom frequently in other languages, and also use the Cpp
implementation provided with Qt (though that has significant limitations in
its own right). The std::for_each, however, has proved virtually useless
to me.

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

 

[Noah Roberts]

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

Yes.

 

[Victor Bazarov]

[.. gripe, gripe ..]
Will a programmer who knows how to use templates very well be
significantly more productive than one who sticks to the traditional
OOP aspects of C++?

In what team, doing what? IOW, yes, if using templates is what is
required from that programmer. No, if using templates is not in
his/her everyday activity.

However, consider what you yourself wrote: while reading the book on
templates you have discovered how much you didn't know of the "core"
C++ language. It is conceivable that the "one who sticks to the
traditional OOP aspects of C++" is actually not as knowledgeable
where the "core" C++ is concerned than one thinks one is.

Can you learn to read a human language and claim proficiency in it
without, say, being able to talk? There were people who were very
versed in a foreign language without knowing how the words they read
or write are pronounced. Are they missing much? I don't know. How
do you actually measure that? What I can say is that their knowledge
is incomplete and very artificial. They are definitely missing some
jokes based on how words are pronounced... Of course, if they stick
to the traditional scientific language, they can even be productive
in an environment where they don't need to talk or understand speech
or understand jokes based on word play.

Does that answer your concerns?

V

 

[kwikius]

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

For more advanced use of templates, it is much simpler if the compiler
you are using is reasonably standard conformant, else it can be
frustrating. For instance the Template book you cite would be little
use in practise with VC++6.0 or gcc < 3.0 methinks.

Maybe that's obvious to many, but OTOH it may not be so if you are in
the position of only ever having used an older compiler.

regards
Andy Little

 

[Gianni Mariani]

Perhaps I'm just a bit frustrated, and I will soon realize the clear truth
of the matter, but right now I have some serious misgivings about the value
of investing a lot of time and effort into template programming. I just
finished reading the first 12 chapters of _C++ Templates: The Complete
Guide_. One thing that struck me as I read these chapters is how much I
didn't know about C++. I _know_ the core language specification is
contained in a finite document, but I sometimes get the sense that C++
requires an infinite amount of learning.

It's not infinite but it is a monster learning curve. Probably less of
a monster today than 6-5 years agro because there is so many more good
examples and the compilers only in the last 2-3 years have finally
started to behave well enough that the intention of the standards
writers are being met.

The primary C++ language (without templates) is substantial and quite
powerful in itself. There are many aspects of that which I have yet to
fully master. While I will grant that working with templates can help
shore up some of those skills, I have to wonder how useful templates really
are. I have discovered that code using templates can frequently not behave
as I expect or want. An example is the std::for_each algorithm. I use the
for-each idiom frequently in other languages, and also use the Cpp
implementation provided with Qt (though that has significant limitations in
its own right). The std::for_each, however, has proved virtually useless
to me.

Why is std::foreach "virtually useless" to you ?

Templates are a very important part of C++. They allow you to maintain
the strong type safety of the language yet provide a typeless interface.
Templates are less than optimal, in the sense that the language was
not originally designed with templates in mind, however having said that
the problems are only superficial (issues like needing to use the
typename and template keyword in some strange places).

As an example, I recently had a legacy file type I needed to create a
parser for, the specification is a disaster (look at the dxf specs). I
basically took the spec, wrapped a few templates around them and I was
able to capture the specification almost as written. This is alot
easier to maintain than having to create tables by hand from the spec.

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

Yes.

I'll give you an example.

We needed to create an "installer" that without a doubt required to be
tweaked ad infinitum. We discussed this and one engineer wanted to use
"expressions" using templates and another simply wanted to hard code it.
The "hard coding" guy started the development but the "expressions"
guys decided to prototype installer expressions anyway. Installer
expressions became part of the product and we ended up using it in
multiple ways that quite frankly were never part of the original thought
but worked amazingly well. Had we kept on with the hard coded methods,
we would probably have been fixing bugs in it for a while to come.

In this example it was syntactic sugar but it made two things happen:
a) it was much easier to maintain because it made making stupid errors
much harder to make.
b) forced an object model onto you that also reduced the number of errors.

Even though the templates themselves were a little complex, the
maintainer of the actual "expressions" didn't need to know the complexity.

Most of the other engineers that were aware were skeptical of using this
methodology at the time so if you do push the envelope, expect there to
be less knowledgeable and less enthusiastic developers around you being
openly skeptical.

As for templates in general, they are very very useful. Arguably, they
are the most important part of the language.

 

[Steven T. Hatton]

[.. gripe, gripe ..]
Will a programmer who knows how to use templates very well be
significantly more productive than one who sticks to the traditional
OOP aspects of C++?

In what team, doing what? IOW, yes, if using templates is what is
required from that programmer. No, if using templates is not in
his/her everyday activity.

However, consider what you yourself wrote: while reading the book on
templates you have discovered how much you didn't know of the "core"
C++ language. It is conceivable that the "one who sticks to the
traditional OOP aspects of C++" is actually not as knowledgeable
where the "core" C++ is concerned than one thinks one is.

Can you learn to read a human language and claim proficiency in it
without, say, being able to talk? There were people who were very
versed in a foreign language without knowing how the words they read
or write are pronounced. Are they missing much? I don't know. How
do you actually measure that? What I can say is that their knowledge
is incomplete and very artificial. They are definitely missing some
jokes based on how words are pronounced... Of course, if they stick
to the traditional scientific language, they can even be productive
in an environment where they don't need to talk or understand speech
or understand jokes based on word play.

Does that answer your concerns?

V

Not really. But that's probably because my concerns are such that there
really is no answer than "there's only one way to find out". I guess I'm
feeling discouraged by the number of idiosyncracies I have learned lurk
under the guise of templates. The way I see things right now, template
programming is kind of like programming the compiler to write code rather
than simply using the compiler to compile the code we write. It requires a
fairly good understanding of the compilation stages in order to do anything
beyond the basics. The knowledge and understanding will likely be useful
regardless of whether templates themselves prove useful to me.

I do have to ask myself, however, what do I get out of creating templates
which adapt to the type I instantiate them with in order to create
functions or classes? How much /reuse/ am I really likely to get out of a
template? One exercise I undertook several months ago was to create my own
vector math library using templates. You helped me work out some of the
trickier parts, you may recall. So now I have a vector math library which
is some ways is better than any others I have seen. I can instantiate the
templates with float or double. For what I'm doing, I almost always use
float because its faster, leaner, and sufficiently precise.

 

[peter koch]

Steven T. Hatton skrev:

Perhaps I'm just a bit frustrated, and I will soon realize the clear truth
of the matter, but right now I have some serious misgivings about the value
of investing a lot of time and effort into template programming.

[snip]
Do not invest more time than you believe pays then.

The primary C++ language (without templates) is substantial and quite
powerful in itself. There are many aspects of that which I have yet to
fully master. While I will grant that working with templates can help
shore up some of those skills, I have to wonder how useful templates really
are. I have discovered that code using templates can frequently not behave
as I expect or want. An example is the std::for_each algorithm. I use the
for-each idiom frequently in other languages, and also use the Cpp
implementation provided with Qt (though that has significant limitations in
its own right). The std::for_each, however, has proved virtually useless
to me.

std::for_each does not require an understanding of templates.

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

You do not need to be an expert, but a reasonable understanding would
be a definite advantage. I do use templates but do not believe I am an
expert. Still theres a lot of benefit from using templates as it
reduces lots of repetitive tasks.

/Peter

 

[Noah Roberts]

std::for_each does not require an understanding of templates.

True, however since it is a template then understanding how templates
bitch when you do something dumb is a pretty important ability to have
in using it.

In my opinion you can't really call yourself a C++ programmer if you
can't use the STL. Not understanding templates limits your ability to
use the standard library significantly.

 

[AlesD]

Steven T. Hatton napsal(a):

The std::for_each, however, has proved virtually useless to me.

Will a programmer who knows how to use templates very well be significantly
more productive than one who sticks to the traditional OOP aspects of C++?

I do not know the book, but it will certainly cover creating your own
templated classes and procedures. I would suggest start with what others
created first. It's easy and might give you beter idea of what templates
are all about.

Look at Standard Template Library. Try containers first. They are
probably as good as you would write them "from scratch", unless you have
some special cases of use. They are error free - at least compared to
what you will probably create in first few versions of your code. They
are type-safe - for both primitives and classes - with or without common
base class. And they are instant and ready to use.

Have a look at SGI implementation - the documentation contains example
snipets of code which might be more illustrative than some "deep" book.

Along the way you will certainly discover why std::for_each() and other
templated algorithms are usefull.

For me the STL alone is enough of "good-thing" that templates bring to
C++. So far I have used templates in my own designs just few times -
mainly for my own data-structures and their manipulation.

Ales

BTW: The lates big improvement of Java which is mature OOP language, was
introduction of templates (although not so powerful) as the C++ once.

 

[Steven T. Hatton]

Steven T. Hatton skrev:
std::for_each does not require an understanding of templates.

How else would it be implemented? This is what is specified in the
Standard:

template<class InputIterator, class Function>
Function for_each(InputIterator first, InputIterator last, Function f);

Now, suppose I have a collection of nodes in a scene graph, each node is a
composite of arbitrary complexity. I want to iterate over the nodes and
apply a rotation to each of them. std::for_each will not do it. I can
make std::transform work, but the amount of code needed to do so is much
more than is needed to write

for(unsigned i=0; i < coll.size();++i) coll->rotate(m);

IIRC, I can't use a local class with std::transform because I can't pass it
to a function template. There /is/ this proposal:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html

 

[peter koch]

Steven T. Hatton skrev:

How else would it be implemented? This is what is specified in the
Standard:

Well.... if you demand to know how every library function you use is
implemented, there's a lot of nontemplated code you'd have to not call.
It is correct that you need to know what to pass to the function, but
that hardly requires you to be a template expert.

/Peter

 

[Lionel B]

How else would it be implemented? This is what is specified in the
Standard:

template<class InputIterator, class Function>
Function for_each(InputIterator first, InputIterator last, Function f);

Now, suppose I have a collection of nodes in a scene graph, each node is a
composite of arbitrary complexity. I want to iterate over the nodes and
apply a rotation to each of them. std::for_each will not do it.

Why not?

I can make std::transform work, but the amount of code needed to do so is
much more than is needed to write

for(unsigned i=0; i < coll.size();++i) coll->rotate(m);

Maybe in some particular case, yes. There may be other cases where using
for_each is clearer and/or more efficient.

 

[peter koch]

Noah Roberts skrev:

True, however since it is a template then understanding how templates
bitch when you do something dumb is a pretty important ability to have
in using it.

In my opinion you can't really call yourself a C++ programmer if you
can't use the STL. Not understanding templates limits your ability to
use the standard library significantly.

There is a difference between "understanding" and "having an
understanding of". To use the standard C++ library simply requires you
to "have an understanding of".
Being able to write simple templated classes and functions should be a
requirement of every C++ programmer, but there is still a way to go if
you want to write the big, advanced template-libraries such as e.g. the
boost spirit library or some of Alexandrescus genious and insightful
typemanipulating libraries.

/Peter

 

[Steven T. Hatton]

Steven T. Hatton skrev:
Well.... if you demand to know how every library function you use is
implemented, there's a lot of nontemplated code you'd have to not call.
It is correct that you need to know what to pass to the function, but
that hardly requires you to be a template expert.

/Peter

After looking at things more closely, I now realize I /could/ use
std::for_each with a visitor pattern.

One of the problems with std::for_each in this context is that the way the
Standard read at the time Josuttis wrote TC++SL only specified means of
invoking constant member functions on collection elements using the member
function adapters.

"Note that member functions called by mem_fun_ref and mem_fun must
be /constant/ member functions. Unfortunately, the C++ standard library
does not provide function adapters form nonconstant member functions (I
discovered this while writing this book). ..."

I do not know if that has changed.

My point was not that I need to be a template expert to use the STL. It was
that the STL has some limitations which make me wonder if the approach is
really ideal. In some ways the STL approach is antithetical to object
oriented programming. I know what Stroustrup had to say about Hegel
but....

 

[peter koch]

Steven T. Hatton skrev:

peter koch wrote: [snip]
My point was not that I need to be a template expert to use the STL. It was
that the STL has some limitations which make me wonder if the approach is
really ideal. In some ways the STL approach is antithetical to object
oriented programming. I know what Stroustrup had to say about Hegel
but....

STL has nothing to do with object-oriented programming. Actually, I do
believe that e.g. Java would have problems creating a clean
"ForEach"-interface. Also the fact that there is a for_each function
does not mandate that you should use it. Use it if you find that it
makes your code more readable, and use a loop if thats more convenient
to you. Personally, I would prefer the loop if I had to e.g. create a
new class and theres nothing wrong with that approach.

/Peter

 

[Evan]

Steven T. Hatton skrev:

peter koch wrote: [snip]
My point was not that I need to be a template expert to use the STL. It was
that the STL has some limitations which make me wonder if the approach is
really ideal. In some ways the STL approach is antithetical to object
oriented programming. I know what Stroustrup had to say about Hegel
but....

STL has nothing to do with object-oriented programming. Actually, I do
believe that e.g. Java would have problems creating a clean
"ForEach"-interface.

Java has something that's arguibly better, which is a foreach loop.
http://java.sun.com/j2se/1.5.0/docs/guide/language/foreach.html

I say it's better because to use std::for_each you have to pass a
functor that does what you want in the third parameter, which means
that if you don't have one ready you either have to go off and write a
function first, or use boost::lambda (which can't always give you what
you want). No such requirement for Java's, because it's just a loop. At
the same time, if you DO have a function handy, Java's syntax is
essentially no more weildy than std::for_each.

(Java stole this from C#, which probably stole it from somewhere else.)

I'm not sure how it works behind the scenes though; it may be less
flexible in some sense than std::for_each because you can use that with
any class that gives you the proper iterators. foreach probably
requires a subclass of Collection or something.

Evan

(BTW, overall I like programming in C++ more than Java -- I feel
constrained in the latter, like "I *should* be able to do this, C++
would let me do this" -- but there are some spiffy things in Java, and
it's new for loop construct is one of them. It's syntactic sugar
(though the link makes the argument that it's syntactic sugar that
helps you avoid errors), but hey, I like sweets.)

 

[Noah Roberts]

Steven T. Hatton skrev:

peter koch wrote: [snip]
My point was not that I need to be a template expert to use the STL. It was
that the STL has some limitations which make me wonder if the approach is
really ideal. In some ways the STL approach is antithetical to object
oriented programming. I know what Stroustrup had to say about Hegel
but....

STL has nothing to do with object-oriented programming. Actually, I do
believe that e.g. Java would have problems creating a clean
"ForEach"-interface.

Java has something that's arguibly better, which is a foreach loop.
http://java.sun.com/j2se/1.5.0/docs/guide/language/foreach.html

I say it's better because to use std::for_each you have to pass a
functor that does what you want in the third parameter, which means
that if you don't have one ready you either have to go off and write a
function first, or use boost::lambda (which can't always give you what
you want). No such requirement for Java's, because it's just a loop. At
the same time, if you DO have a function handy, Java's syntax is
essentially no more weildy than std::for_each.

It's really a completely different construct. Two strengths of C++'s
version are:

1) can be called on any range of data not just a complete collection
2) can be called on a variety of constructs that are not collections,
has a more general interface.

As you said, there is boost::lambda but there is also boost::bind or
tr1::bind that will perform better in many situations.

If you want something more closely resembling a foreach loop found in
Java, Perl, etc... then have a look at BOOST_FOREACH

http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/foreach.html

 

[Steven T. Hatton]

Steven T. Hatton skrev:

peter koch wrote: [snip]
My point was not that I need to be a template expert to use the STL. It
was that the STL has some limitations which make me wonder if the
approach is
really ideal. In some ways the STL approach is antithetical to object
oriented programming. I know what Stroustrup had to say about Hegel
but....

STL has nothing to do with object-oriented programming.

I don't fully agree with that. There are class templates used to implement
collections and function objects, etc. The use of classes is certainly an
aspect of OOP. Where the STL diverges from OOP is in having functionality
separated into collections, iterators and algorithms, rather than
consolidating the data and functionality into a single class construct.
With OOP and inheritance, an interface is formally stated in the code.
With generic programming, the interface is a "pure abstraction". That's
where "concepts" come in.

Actually, I do
believe that e.g. Java would have problems creating a clean
"ForEach"-interface.

Actually, the for-each construct is part of the core Java language. It is
implemented as a syntactic alternative to the traditional for-loop.

Also the fact that there is a for_each function
does not mandate that you should use it. Use it if you find that it
makes your code more readable, and use a loop if thats more convenient
to you. Personally, I would prefer the loop if I had to e.g. create a
new class and theres nothing wrong with that approach.

Nothing wrong with creating a new class to perform an operation which can
easily be done in one line of code, and not even eliminating the original
line of code? There are times when it makes sense to use a visitor pattern
with function objects, but there are also many times when it serves no
other purpose than the complicate the code.

The situation in which I wanted to operate on a collection of nodes is
something I actually encountered, and after reviewing things, I now realize
that I /did/ implement it using a std::for_each and an inner class. It
was "the C++" way to do it. Then I realized that it was also the hard way
to do it, and reverted to using a traditional for-loop.

 

[Steven T. Hatton]

Evan wrote:

It's really a completely different construct. Two strengths of C++'s
version are:

1) can be called on any range of data not just a complete collection

That can be accomplished by providing an alternative interface to the same
underlying collection.

2) can be called on a variety of constructs that are not collections,
has a more general interface.

The Java thing to do would be "slap an interface on it" or "wrap it up in a
collection interface". The big difference as I see it is that
std::for_each takes functionality as an argument, whereas the conventional
for-each construct has a body consisting of a block of code.

As you said, there is boost::lambda

IMO, boost::lambda is a path to becoming an academic niche language.

but there is also boost::bind or
tr1::bind that will perform better in many situations.

That is something worth looking into.

If you want something more closely resembling a foreach loop found in
Java, Perl, etc... then have a look at BOOST_FOREACH

http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/foreach.html

I'm not sure what the fate of the proposed C++ for_each core language
extension will be, but from what I've seen, it's the only fully satisfying
approach.

 

[Noah Roberts]

for(unsigned i=0; i < coll.size();++i) coll->rotate(m);

std::for_each(coll.begin(), coll.end(),
boost::bind(&ContainedClass::rotate, _1, m));