Are C++ templates a precompiler thing?

[JohnQ]

Well, if they're not conforming, then it's a moot
point as to what the standard says about it

I'll have to investigate the TI stuff some more to see what additional
features they got by modifying a preprocessor to implement templates. My
impression is that they got pretty close to the Stroustrup description back
then and that's probably all the functionality I need (or even less!).

John

 

[Gavin Deane]

That's my definition of templates: a typing saver, patterned
text-replacement. Anything else is a C++-ism (extension of the original
concept). You're assuming the C++ definition is the gold cow standard of all
template definition. That's in-the-box-thinking (paradigmic).

No, I'm assuming that *in this newsgroup* the C++ definition is the
only one applicable - if someone uses the term "C++ templates" they
mean "templates as defined by the C++ standard". Not an unreasonable
assumption I think. What other definitions of "template" might exist
in the wider programming field and what their relative merits might be
against the C++ definition is entirely off-topic in this group and so
of no concern whatsoever when I am posting here.

The subject of your original post included the term "C++ templates".
Are you aware that in standard C++, "template" has a precise and well-
defined meaning? And that, with standard C++ being the topic of this
newsgroup, anyone who reads the term "C++ templates" here would be
perfectly justified in thinking that the person who wrote it meant
"templates as defined by the C++ standard"? Can you not see that, in
this forum, if you want the word "template" to mean something else,
the onus is 100% on you to provide your definition of "template" at
the outset? (Or better still, choose a different word).

And you still appear to be asking the rather pointless and self-
answering question as I paraphrased above.

Gavin Deane

 

[JohnQ]

No, I'm assuming that *in this newsgroup* the C++ definition is the
only one applicable - if someone uses the term "C++ templates" they
mean "templates as defined by the C++ standard". Not an unreasonable
assumption I think. What other definitions of "template" might exist
in the wider programming field and what their relative merits might be
against the C++ definition is entirely off-topic in this group and so
of no concern whatsoever when I am posting here.

The subject of your original post included the term "C++ templates".
Are you aware that in standard C++, "template" has a precise and well-
defined meaning? And that, with standard C++ being the topic of this
newsgroup, anyone who reads the term "C++ templates" here would be
perfectly justified in thinking that the person who wrote it meant
"templates as defined by the C++ standard"? Can you not see that, in
this forum, if you want the word "template" to mean something else,
the onus is 100% on you to provide your definition of "template" at
the outset? (Or better still, choose a different word).

And you still appear to be asking the rather pointless and self-
answering question as I paraphrased above.

I did mean "C++ templates" with the original post. I recognize them as some
kind of departure from a more generic (no pun intended) meaning. Perhaps
that more generic thing is what I would like to implement with the modified
preprocessor (though I'm not sure it would buy me much over the macro-ised
technique).

John

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

"If you don't mean C++ templates, when talking about C++, you
really have to find a different word."

Well C++ didn't invent the word 'template'.

When in Rome...

Sorry, couldn't resist.

 

[Gianni Mariani]

JohnQ wrote:
....

To me, "templates" means the kind of thing the preprocessor does (text
substitution) and using it to generate typed code.

That's only one of the things that templates are about.

C++ templates allow you to:

Change behaviour for different types.

Compute compile time constants (like find first set bit) etc.

Force compile time errors when various assumptions are invalid.

Allows extensibility by the application through overloading and
specialization.

.... just to name a few ...

Macros are almost impossible to debug because of the way they work. It
is surprising that after so many years of using the preprocessor,
debuggers can't single step through macros but alas, they can't. C++
templates however are well supported by debuggers in comparison.

While you may like to think of templates as a facncy pre-processor, in
C++ templates are a more substantial and provide a "meta programmming"
paradigm.

As I explained earlier, one example where it worked by simplification of
the code was the mapping of types to ints for reading DXF files.
Without templates, it would have been very tedious to map 1000+
operations. With C++ templates, it was cut-paste relevant table in the
docs, decorate it with a few templates, viola. Extensibility is easy as
well because as the file format expands, there is a direct correlation
to the docs and so it will be simply a matter of adding a few more types
to the header file.

If you want to talk about C++ the standard (which is what we do here),
you need to understand that templates are a more extensive meta
programming feature. While you yourself may not want to use it, it is
part of the standard and is used in a much more extensive way.

 

[Gianni Mariani]

JohnQ wrote:
....

When I say "containers" I mean the whole ball of wax:
containers/iterators/algorithms, things like smart pointers etc.

Try the smart pointer thing in macros. Specifically, you do you
implement assignment of one smart pointer type to another smart pointer
type without using templates.

... It's all
very basic stuff that preprocessor templates can handle. And those are "the
general case". No need to make everything complex IMO. Make special things
for the special cases and don't impact the general case is my motto.
Sometimes I need a truck to bring things home from Home Depot, so I rent
one. Most times I just use my car. I wouldn't want to drive a truck all the
time, or purchase one, just because I need one once a year.

OK. You think that C++ templates are too complex to learn, they're more
like the truck than the car.

That's nice, thank you for your input but you're a few years too late.
C++ templates are not going away any time soon. Go use D or Java.

You clipped the context, so here it is:

"Templates do have a learning curve. You do have to think of your code
in a more generic fashion."

To which I'll respond:

Templates shouldn't be (and are not) difficult at all. It's the C++
"almighty powerful" ones that can be "hard" (take time to learn).

This discussion then is OT here. This forum is for discussing C++ as it
is defined in the standard. If you wish to change the standard
comp.std.c++ is the proper forum. I suggest they're not going to bother
much if you proclaim C++ templates are a mess and you want to use macros
so you might want to save it, it's up to you.

 

[JohnQ]

JohnQ wrote:
...

That's only one of the things that templates are about.

C++ templates allow you to:

Change behaviour for different types.

Compute compile time constants (like find first set bit) etc.

Force compile time errors when various assumptions are invalid.

Allows extensibility by the application through overloading and
specialization.

... just to name a few ...

Macros are almost impossible to debug because of the way they work.
It is surprising that after so many years of using the preprocessor,
debuggers can't single step through macros but alas, they can't. C++
templates however are well supported by debuggers in comparison.

Just expand the preprocessor template and debug it. Problem solved.

While you may like to think of templates as a facncy pre-processor, in C++
templates are a more substantial and provide a "meta programmming"
paradigm.

Understood. It's overkill for my needs. But I'll still use them if need be
(but in a very light way).

John

 

[JohnQ]

JohnQ wrote:
...

Try the smart pointer thing in macros. Specifically, you do you implement
assignment of one smart pointer type to another smart pointer type without
using templates.



OK. You think that C++ templates are too complex to learn, they're more
like the truck than the car.

I used them for years before I knew how detrimental they were to
maintainable code. Now that I've gotten back to basics, I can use templates
without getting into trouble with them. That is, I know what NOT to do with
them.

That's nice, thank you for your input but you're a few years too late. C++
templates are not going away any time soon. Go use D or Java.


This discussion then is OT here. This forum is for discussing C++ as it
is defined in the standard.

The preprocessor is part of the standard also.

If you wish to change the standard comp.std.c++ is the proper forum.

It's probably not worth fixing. Easier to create something new and put the
old stuff in maintenance mode.

I suggest they're not going to bother much if you proclaim C++ templates
are a mess and you want to use macros so you might want to save it, it's
up to you.

That's why I'm investigating hacking a preprocessor to do a templates
implementation. I'm not convinced that I need any more power than the text
substitution of the existing preprocessors though. I'm thinking that the
only thing it would get me is not having to type all those backslashes. Oh
yeah, and a mechanism to control template generation. Neither needed, but it
would be more convenient and elegant.

John

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

[...]

" <generic.h> predates that by a lot. It proved to be
unusable. Real templates (albeit very buggy) first appeared in
CFront 3.0 (from AT&T), in 1989, I think."

Unusable to do all the advanced things that "the language
within a language" C++ templates do, yes.

Unusable for even the simplest container classes.

 

[James Kanze]

"Not templates. C++ didn't invent templates; they were present
in languages long before C++ added them. In fact, C++ added
them mainly because the earlier macro-based solution didn't
work."

You keep saying that, but of course it isn't true, for my
containers and algos work just fine.

I keep saying because it is true. Macro based generic classes
require an unacceptable amount of time and effort to use and
maintain. I've been there; I've had to maintain stuff written
using the preprocessor. And I'm not alone.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Just expand the preprocessor template and debug it. Problem solved.

Don't know about your preprocessor but the preprocessed output of a very
simple file (~20 lines) which includes <iostream> is ~50,000 lines and
760 KB large. You could probably make the preprocessor smarter (and more
complex) but then again, wasn't the complexity of templates one of your
problems?

Another point, many people use and IDE nowadays, and as long as they
don't support debugging the preprocessed code there's no easy way to
debug macro-based templates.

 

[Thomas J. Gritzan]

That's why I'm investigating hacking a preprocessor to do a templates
implementation. I'm not convinced that I need any more power than the text
substitution of the existing preprocessors though. I'm thinking that the
only thing it would get me is not having to type all those backslashes.

Then do it with files:

#define LIST_TYPE int
#define LIST_NAME int_list
#include <johnq/list.h>

#define LIST_TYPE double
#define LIST_NAME double_list
#include <johnq/list.h>

No need for backslashes in the file. No need for a class generating #define
also.

Maybe your debugger is happier with it, too, so it can step through your
functions (didn't try).

Oh
yeah, and a mechanism to control template generation. Neither needed, but it
would be more convenient and elegant.

comp.compilers - for compiler hacking
comp.lang.misc - for discussions about languages

 

[Ian Collins]

I keep saying because it is true. Macro based generic classes
require an unacceptable amount of time and effort to use and
maintain. I've been there; I've had to maintain stuff written
using the preprocessor. And I'm not alone.

Ah, so there's two of us!

 

[JohnQ]

Don't know about your preprocessor but the preprocessed output of a very
simple file (~20 lines) which includes <iostream> is ~50,000 lines and 760
KB large. You could probably make the preprocessor smarter (and more
complex) but then again, wasn't the complexity of templates one of your
problems?

Don't use the existing preprocessor to expand the "template". It's just text
replacement afterall.

Another point, many people use and IDE nowadays, and as long as they don't
support debugging the preprocessed code there's no easy way to debug
macro-based templates.

That's silly. Just expand the "macro" (search and replace if you don't have
something scriptable to work with). Template code should be pretty stable
after debugged so it's not a big deal to make a little effort during
template development.

John

 

[Ian Collins]

That's silly. Just expand the "macro" (search and replace if you don't have
something scriptable to work with). Template code should be pretty stable
after debugged so it's not a big deal to make a little effort during
template development.

More effort that isn't required when using C++ templates.

 

[JohnQ]

"James Kanze" <[email protected]> wrote in message

[...]

" <generic.h> predates that by a lot. It proved to be
unusable. Real templates (albeit very buggy) first appeared in
CFront 3.0 (from AT&T), in 1989, I think."

Unusable to do all the advanced things that "the language
within a language" C++ templates do, yes.

"Unusable for even the simplest container classes."

Like I said, it's just one technique... a starting point. I have a nice set
of containers that I find a joy to use compared to the STL ones.

John

 

[JohnQ]

"Not templates. C++ didn't invent templates; they were present
in languages long before C++ added them. In fact, C++ added
them mainly because the earlier macro-based solution didn't
work."

You keep saying that, but of course it isn't true, for my
containers and algos work just fine.

"I keep saying because it is true. Macro based generic classes
require an unacceptable amount of time and effort to use and
maintain. I've been there; I've had to maintain stuff written
using the preprocessor. And I'm not alone."

That's opinion. And you're making assumptions about the implementation that
are not necessarily correct. Again, YMMV. You say "to-maye-toe", I say
"to-mah-toe" (tomato). It's not "a thing to vote on", it's personal
preference. We'll just have to agree to disagree on this one.

John

 

[JohnQ]

More effort that isn't required when using C++ templates.

That's right. I draw the line of acceptability/concession in a different
place and for different reasons for I value different things. No big deal,
right?

John

 

[Ian Collins]

"I keep saying because it is true. Macro based generic classes
require an unacceptable amount of time and effort to use and
maintain. I've been there; I've had to maintain stuff written
using the preprocessor. And I'm not alone."

That's opinion.

Could you do us all a favor and change or fix your newsreader to quote
properly. Don't go blaming James's character set, no one else here is
troubled by it.

 

[Ian Collins]

That's right. I draw the line of acceptability/concession in a different
place and for different reasons for I value different things. No big deal,
right?

I draw the line at reinventing and using wheels with solid tyres when I
have access to pneumatic ones.