C++ template tutorial/review : comments welcomed

[Guotao Luan]

Hello All:

I notice that there have been frequent questions being asked about template
here so I guess it is okay to post this message here. I just wrote a c++
tempalte tutorial/review, I would like to hear feedbacks from other users. I
do not have much experience with template myself so I am sure there are many
problems or even mistakes in this material. Comments of all types are
welcomed. and I also hope this tutorial/review is helpful for programmers
who want to learn about template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm

Thanks,
Guotao

[Victor Bazarov]

Guotao Luan wrote:

I notice that there have been frequent questions being asked about template
here so I guess it is okay to post this message here. I just wrote a c++
tempalte tutorial/review, I would like to hear feedbacks from other users. I
do not have much experience with template myself so I am sure there are many
problems or even mistakes in this material. Comments of all types are
welcomed. and I also hope this tutorial/review is helpful for programmers
who want to learn about template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm

Couple of things from the very first minute of looking it over:

(a) Introduction of bad programming techniques is not a good way to
justify using other language constructs. Nobody in their right
mind would omit inner parentheses in

#define mySquare(x) (x * x)

They would write

#define mySquare(x) ((x) * (x))

and while it doesn't solve some other problems, it would definitely
prevent mySquare(3+4) from evaluating to 22 (and not 19 as you wrote).

(b) Please replace the _tmain nonsense with the standard main and drop
the TCHAR (unless you include the definition of it in every example)
Teaching compiler-specific things in a generic language course is
A BAD IDEA(tm).

I am not going to comment more on your tutorial. These two things have
already left a bad taste in my mouth.

Programmers who want to learn about templates should read books about
templates. There are several. You mention NONE. Why is that? Have
you heard of "The C++ Templates" by Vandevoorde and Josuttis? What
about "Accelerate d C++", just for kicks? And "The C++ Standard Library"?
You don't even mention "The C++ Programming Language" by Stroustrup.
WHY NOT?

No, your tutorial definitely not the place where I'd advise anybody to
go to learn about templates. Not yet, anyway.

Good luck fixing it!

V

[JKop]

Guotao Luan posted:

Hello All:

I notice that there have been frequent questions being asked about
template here so I guess it is okay to post this message here. I just
wrote a c++ tempalte tutorial/review, I would like to hear feedbacks
from other users. I do not have much experience with template myself so
I am sure there are many problems or even mistakes in this material.
Comments of all types are welcomed. and I also hope this
tutorial/review is helpful for programmers who want to learn about
template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm

Thanks,
Guotao

Does Bjarne ever post here?

-JKop

[Unforgiven]

Guotao Luan wrote:

Hello All:

I notice that there have been frequent questions being asked about
template here so I guess it is okay to post this message here. I just
wrote a c++ tempalte tutorial/review, I would like to hear feedbacks
from other users. I do not have much experience with template myself
so I am sure there are many problems or even mistakes in this
material. Comments of all types are welcomed. and I also hope this
tutorial/review is helpful for programmers who want to learn about
template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm

I don't have the time to read such an extensive piece, but I glanced over
your first chapter and must disagree with the following: you say languages
such as C# and Java don't deal with templates because they have a unified
object model with object that derive from one base class. This isn't true,
per se. I can't speak for Java (my experience with it isn't big enough), but
in .Net at least there are still several drawbacks to using generalised
collection classes with System.Object instead of templates. The big
disadvantages are:
1. Cumbersome code: Casts to System.Object are implicit, but casts back from
System.Object to the type you desire isn't (at least not in C#, and also not
in VB.NET if Option Strict is turned on). If you're putting objects of
multiple types into a container, you need to keep track of what type they
are, using even more cumbersome code. Simple foreach iterations become
incredibly complex if you're not sure of the type of objects in the
container, due to added code for type checking and casting.
2. Performance: Casting takes a performance hit. In VB.NET, you can minimize
this by using DirectCast, but that doesn't always work. With Value Types
(objects that inherit from System.ValueTyp e such as Int32 (int), Boolean
(bool), DateTime and all structs and enums the hit is even bigger, because
these need to be boxed and unboxed to be put in a generalised container.
3. Type safety: there is no way to ensure that if you want a container of
just a certain type, that it will in fact contain just that type.

For this reason, .Net already offers some ready-made specialised collections
in the System.Collecti ons.Specialized namespace. Not only that, but generics
will be added to codename Whidbey (.Net 2.0), albeit in a wildly different
way from C++ (not so much in syntax as in implementation)

Check out these articles:
..NET: Introducing generics in the CLR
http://msdn.microsoft.com/msdnmag/issues/03/09/NET/
..NET: More on generics in the CLR
http://msdn.microsoft.com/msdnmag/is...T/default.aspx

--
Unforgiven

[Guotao Luan]

1. I agree that the statement about 'unified object model' and 'template
support' is controversial.
2. I did mention the proposed 'generic addtion' to .Net somewhere in this
tutorial. it is probablly burried deeper somwhere though.
3. Thank you for the insights of the performance and syntax issues with the
container classes in .Net.
I would really like to know the perfermance of .Net containers class v.s.
that of C++ template class, but I have not come seen any papers about it.

Guotao

"Unforgiven " <ja*******@hotm ail.com> wrote in message
news:2i******** ****@uni-berlin.de...

I don't have the time to read such an extensive piece, but I glanced over
your first chapter and must disagree with the following: you say languages
such as C# and Java don't deal with templates because they have a unified
object model with object that derive from one base class. This isn't true,
per se. I can't speak for Java (my experience with it isn't big enough), but in .Net at least there are still several drawbacks to using generalised
collection classes with System.Object instead of templates. The big
disadvantages are:
1. Cumbersome code: Casts to System.Object are implicit, but casts back from System.Object to the type you desire isn't (at least not in C#, and also not in VB.NET if Option Strict is turned on). If you're putting objects of
multiple types into a container, you need to keep track of what type they
are, using even more cumbersome code. Simple foreach iterations become
incredibly complex if you're not sure of the type of objects in the
container, due to added code for type checking and casting.
2. Performance: Casting takes a performance hit. In VB.NET, you can minimize this by using DirectCast, but that doesn't always work. With Value Types
(objects that inherit from System.ValueTyp e such as Int32 (int), Boolean
(bool), DateTime and all structs and enums the hit is even bigger, because
these need to be boxed and unboxed to be put in a generalised container.
3. Type safety: there is no way to ensure that if you want a container of
just a certain type, that it will in fact contain just that type.

For this reason, .Net already offers some ready-made specialised collections in the System.Collecti ons.Specialized namespace. Not only that, but generics will be added to codename Whidbey (.Net 2.0), albeit in a wildly different
way from C++ (not so much in syntax as in implementation)

Check out these articles:
.NET: Introducing generics in the CLR
http://msdn.microsoft.com/msdnmag/issues/03/09/NET/
.NET: More on generics in the CLR
http://msdn.microsoft.com/msdnmag/is...T/default.aspx

--
Unforgiven

[Guotao Luan]

Thank you Victor, these are tough comments but they are well said. I will
defintelly try to make some changes according to your comments.

one of the thing I need to point out though is that this is more of a
'research overview' of C++ template, not a pure 'tutorial'. so I was not
very careful when writting the section section on basic template stuffs.

Guotao


"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:NJ******** *********@dfw-read.news.verio .net...

Guotao Luan wrote:

I notice that there have been frequent questions being asked about template here so I guess it is okay to post this message here. I just wrote a c++
tempalte tutorial/review, I would like to hear feedbacks from other users. I do not have much experience with template myself so I am sure there are many problems or even mistakes in this material. Comments of all types are
welcomed. and I also hope this tutorial/review is helpful for programmers who want to learn about template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm
Couple of things from the very first minute of looking it over:

(a) Introduction of bad programming techniques is not a good way to
justify using other language constructs. Nobody in their right
mind would omit inner parentheses in

#define mySquare(x) (x * x)

They would write

#define mySquare(x) ((x) * (x))

and while it doesn't solve some other problems, it would definitely
prevent mySquare(3+4) from evaluating to 22 (and not 19 as you

wrote).
(b) Please replace the _tmain nonsense with the standard main and drop
the TCHAR (unless you include the definition of it in every example)
Teaching compiler-specific things in a generic language course is
A BAD IDEA(tm).

I am not going to comment more on your tutorial. These two things have
already left a bad taste in my mouth.

Programmers who want to learn about templates should read books about
templates. There are several. You mention NONE. Why is that? Have
you heard of "The C++ Templates" by Vandevoorde and Josuttis? What
about "Accelerate d C++", just for kicks? And "The C++ Standard Library"?
You don't even mention "The C++ Programming Language" by Stroustrup.
WHY NOT?

No, your tutorial definitely not the place where I'd advise anybody to
go to learn about templates. Not yet, anyway.

Good luck fixing it!

V

[Steven T. Hatton]

Unforgiven wrote:

Guotao Luan wrote:

Hello All:

I notice that there have been frequent questions being asked about
template here so I guess it is okay to post this message here. I just
wrote a c++ tempalte tutorial/review, I would like to hear feedbacks
from other users. I do not have much experience with template myself
so I am sure there are many problems or even mistakes in this
material. Comments of all types are welcomed. and I also hope this
tutorial/review is helpful for programmers who want to learn about
template.

Here is the link to the html version:

http://www.cs.indiana.edu/~gluan/cpp...e_tutorial.htm

I don't have the time to read such an extensive piece, but I glanced over
your first chapter and must disagree with the following: you say languages
such as C# and Java don't deal with templates because they have a unified
object model with object that derive from one base class. This isn't true,
per se. I can't speak for Java (my experience with it isn't big enough),
but in .Net at least there are still several drawbacks to using
generalised collection classes with System.Object instead of templates.
The big disadvantages are:

[smip]
What you wrote pretty much describes Java as well. I believe this
discussion from the link above is misrepresenting the history of OOP:

"Look at how template was introduced into C++, one will naturally wonder
about C++?s object model. In my opinion, the lack of a unified, monolithic
object model, where everything else is derived from object, is perhaps one
of the biggest reasons why template was introduced to write container
classes. It?s worthy to notice that once the top level object was
envisioned, languages, including both Java and C#, no longer bother to deal
with templates."
Please see the documentation for the latest version of Java:
http://java.sun.com/j2se/1.5.0/docs/....html#generics

"But given the fact that object oriented software development as a paradigm
only became dominant with the introduction of JAVA, it?s understandable
that Stroutrup did not envision a unified object model when designing C++."

It's been around since the 1970s. Someone correct me if they know better,
but I believe that has always been the design of the SmallTalk object
model. That puts it around 1972?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Guotao Luan]

Thank you for the Java generics link. I will take a look.

As for the OOP, it is true that OO has been around at least since the 70s,
but please note that I was saying that OO only became 'dominant' in the 90s.

Guotao
"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:-P************** ******@speakeas y.net...

"Look at how template was introduced into C++, one will naturally wonder
about C++?s object model. In my opinion, the lack of a unified, monolithic
object model, where everything else is derived from object, is perhaps one
of the biggest reasons why template was introduced to write container
classes. It?s worthy to notice that once the top level object was
envisioned, languages, including both Java and C#, no longer bother to deal with templates."
Please see the documentation for the latest version of Java:
http://java.sun.com/j2se/1.5.0/docs/....html#generics

"But given the fact that object oriented software development as a paradigm only became dominant with the introduction of JAVA, it?s understandable
that Stroutrup did not envision a unified object model when designing C++."
It's been around since the 1970s. Someone correct me if they know better,
but I believe that has always been the design of the SmallTalk object
model. That puts it around 1972?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Luther Baker]

Steven T. Hatton wrote:
....

[smip]
What you wrote pretty much describes Java as well. I believe this
discussion from the link above is misrepresenting the history of OOP:

"Look at how template was introduced into C++, one will naturally wonder
about C++?s object model. In my opinion, the lack of a unified, monolithic
object model, where everything else is derived from object, is perhaps one
of the biggest reasons why template was introduced to write container
classes. It?s worthy to notice that once the top level object was
envisioned, languages, including both Java and C#, no longer bother to deal
with templates."
Following your lead Steve ...

Actually, there are several reasons templates were introduced - but I
personally don't believe the monolithic object model is a very important
one.

One of the most important reasons templates came into being were to
enforce type safety. Folks were creating containers of void* and then
dangerously down-casting them as they used them. C++ is all about type
safety.

Alexandrescu does things with templates just short of teaching monkeys
to fly ... really unrelated to issues solved (or introduced) with a
monolithic object model like Java or C#.

And any developer is free to create and adhere to his own monolithic
object model in his own application. Standardizing such an ideology
would have weighted the language done with minimal advantages.
"But given the fact that object oriented software development as a paradigm
only became dominant with the introduction of JAVA, it?s understandable
that Stroutrup did not envision a unified object model when designing C++."

http://www.research.att.com/~bs/bs_faq.html#Java

<quote>
Is Java the language you would have designed if you didn't have to be
compatible with C?
No. Java isn't even close. If people insist on comparing C++ and Java -
as they seem to do - I suggest they read The Design and Evolution of C++
(D&E) to see why C++ is the way it is, and consider both languages in
the light of the design criteria I set for C++. Those criteria will
obviously differ from the criteria of Sun's Java team. Despite the
syntactic similarities, C++ and Java are very different languages. In
many ways, Java seems closer to Smalltalk than to C++.
</quote>

And keep this in mind. It is not an "object oriented paradigm" that begs
for a monolithic object model. Java in no way is more object oriented
then C++. C++ actually has much more modeling versatility in this
regard. Virtual inheritance, multiple inheritance, etc. Java OO
functionality is mostly a subset of C++ in this regard.

No, instead, Java uses a monolithic object model largely due to its
reflection api. Every Java object carries around meta information. Java
casts are always safe casts because an object knows what type it is. You
can't effectively do that unless you have a common base class.

C# has the same *feature*. Both languages compile programs that run in
virtual machines - a common base object helps ensure that information is
present.

Dynamically loading classes and instantiating methods at runtime
requires reflection which requires a common base class. Java and C# are
Virtual Machine languages and the monolithic object model provides a
larger features set for the virtual machines to depend on.

The relation of OO and monolithic object model is an afterthought at best.

It just so happens that as OO came into vogue, so also did Java and now
C# - but to imply that something that happened out of circumstance
(monolithic object model) is actually a core part of a movement (OO) is
a bit overzealous I think ... or just mistaken :)

Ah - back to templates ... now, templates are *hard* to implement in a
language - and not always necessary. That is probably "closer" to the
reason why Java and C# don't have templates _YET_.

-Luther

[Steven T. Hatton]

Guotao Luan wrote:

Thank you for the Java generics link. I will take a look.

As for the OOP, it is true that OO has been around at least since the 70s,
but please note that I was saying that OO only became 'dominant' in the
90s.

Guotao

After I posted I realized I had not really been clear. What I intended is
that the concept of a UBC (universal base class) has existed since the
beginning of SmallTalk. The idea has been considered and rejected by the
C++ designers, and their reasoning seems valid. I know this, because I'm
the person who proposed it.

There is no reason there couldn't be a 'sub-universal' base class for an
entire tool kit. AAMOF, it has been done more than once in some form or
another.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org