Are C++ templates a precompiler thing?

[JohnQ]

Well apparently not since one can step thru template code with a debugger.
But if I was willing to make the concession on debugging, templates would be
strictly a precompiler thing? I have a feeling the answer I'm going to get
back will be "no, because templates have taken on a life of their own since
their original conception and now also affect compiler implementation"
(read: not good, IMO.

John

[JohnQ]

"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:46******** *************** @per-qv1-newsreader-01.iinet.net.au ...

JohnQ wrote:

>"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:46******* *************** *@per-qv1-newsreader-01.iinet.net.au ...

>>JohnQ wrote:
...
I'm not convinced that is true. Are you saying that macros can't be
type-safe?
Macros can't be chosen by type of parameter line a function can.

I'm not sure what you mean. Show me.

void write( int a )
{
ptintf( "%dZ", a );
}

void write( const char * str )
{
printf( "%s", str );
}
#define write( A ) printf( ???? );

Well you're trying to come up with a macro to do the work. Of course that
won't work. You have to use the text-substitution capability of the
preprocessor to do basically what the template processor in the C++ compiler
does. There's a distinct difference and that's why those
text-substitution-patterns ("templates" ) , when implemented with the
preprocessor, should not be called macros (just call them "templates" or to
distinguish between them and C++ compiler tempates, "preprocess or
templates"!).

(Using printf() was a bad example though because the format specifier
changes based upon the type. You'd have to use C++ IO with overloaded
operators even with C++ compiler templates to achieve a basic template for
the above case).

Below is the general concept of using the preprocessor for templates:

(Class functions just for illustration cuz the data members in a real
implementation would probably be public. Functions can be used to
get or set. obj does not have to be a pointer.)

#define concat2(x,y) x##y
#define slink(T) concat2(slink_, T)

// The "template" below is not a "macro" (well it is, but it isn't)
// (it's just a code generator).
//
#define DeclareSLink(T) \
class slink(T)\
{\
T* obj;\
slink(T)* next;\
\
public:\
void slink(T)(T* o, slink(T)* nxt=0)\
:obj(o), next(nxt) {}\
\
T*& Obj(){ return obj; } \
slink(T)*& Next(){ return next; }\
};

Usage example (declare a link class of type int and instantiate one, then
use it):

DeclareSLink(in t)
int x;
slink(T) my_link(&x); // type safe
int* obj = my_link.Obj(); // type safe
Do you see anything not type-safe in the above?

John

[JohnQ]

"Gianni Mariani" <gi*******@mari ani.wswrote in message
news:46******** *************** @per-qv1-newsreader-01.iinet.net.au ...

JohnQ wrote:
...

>>
If I just need to create containers and that is my only interest in using
templates, the specialized stuff you're doing is, well specialized!

It's just an example of a problem that has been solved many times and it
degenerates into alot of tedious code. This is a case where templates
simplify the code dramatically, if you know how to use them. The code in
this case is a simple transformation from the specification.

>>

>>>>I, for one, love macros. And templates. I use both all the
time. But they're not even remotely similar.
I disagree. I'm leaning toward "they should be the same". Beyond that
(macros), templates become unwieldly.
Templates do have a learning curve. You do have to think of your code
in a more generic fashion.

Just containers thank you.

Containers now, then smart pointers, special iterators etc etc. It's a
powerful tool if you learn to use it.

When I say "containers " I mean the whole ball of wax:
containers/iterators/algorithms, things like smart pointers etc. 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.

>

>>

>>>
...
Again, I whole-heartedly disagree.
That you disagree is great. Don't stop there, do tell us of your
reasoning.

I limit what templates can do by requiring of them that they can be
implemented simply.

That's a "reason" ?

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). But that's
ok, because 99% of the time, you don't need the specialized functionality.
C++ templates are a language within a language rather than just "generics".
I prefer the more general definition and basic implementation. (The K.I.S.S.
principle). When I need a truck, I'll rent one. On a daily basis though,
I'll stick to driving a car. Realize too that if you introduce C++-specific
things deeply into your code, your HIGHLY-C++-specific designs aren't going
to be portable to other languages/tools (say java or .net or Pascal or
whatever). _You_ may think that it's OK to use all the elements of C++
everywhere and all the time and as much as possible, I, OTOH, am at the
opposite end to that. Your statement "You do have to think of your code in a
more generic fashion." is not prudent advice IMO if you mean it like "see
where you can use templates and try to find ever increasing places in which
to use them". I would rather say: be judicious in the use of language
facilities, always, and prefer simple constructs and mechanisms over complex
ones.

K, nuff said (I hope).

John

[Old Wolf]

On Jun 11, 6:51 pm, "Robbie Hatley" <bogus.addr...@ no.spamwrote:

>
Templates are a part of the C++ language. They are not
preprocessor macros.

'Preprocessor macros' are also a part of C++ language.
In fact, translation phases 1-7 are what people normally
mean when the say 'the preprocessor'. Phase 8 involves
instantiating templates.

It's just a convention that compiler vendors supply
distinct executables to perform the various translation
phases.

[Ian Collins]

JohnQ wrote:

Below is the general concept of using the preprocessor for templates:

(Class functions just for illustration cuz the data members in a real
implementation would probably be public. Functions can be used to
get or set. obj does not have to be a pointer.)

#define concat2(x,y) x##y
#define slink(T) concat2(slink_, T)

// The "template" below is not a "macro" (well it is, but it isn't)
// (it's just a code generator).
//
#define DeclareSLink(T) \
class slink(T)\
{\
T* obj;\
slink(T)* next;\
\
public:\
void slink(T)(T* o, slink(T)* nxt=0)\
:obj(o), next(nxt) {}\
\
T*& Obj(){ return obj; } \
slink(T)*& Next(){ return next; }\
};

So you have a more verbose way to declare a simple "template" in global
scope. What does this gain you over the more concise standard C++
template definition?

--
Ian Collins.

[JohnQ]

"Ian Collins" <ia******@hotma il.comwrote in message
news:5d******** *****@mid.indiv idual.net...

JohnQ wrote:

>Below is the general concept of using the preprocessor for templates:

(Class functions just for illustration cuz the data members in a real
implementati on would probably be public. Functions can be used to
get or set. obj does not have to be a pointer.)

#define concat2(x,y) x##y
#define slink(T) concat2(slink_, T)

// The "template" below is not a "macro" (well it is, but it isn't)
// (it's just a code generator).
//
#define DeclareSLink(T) \
class slink(T)\
{\
T* obj;\
slink(T)* next;\
\
public:\
void slink(T)(T* o, slink(T)* nxt=0)\
:obj(o), next(nxt) {}\
\
T*& Obj(){ return obj; } \
slink(T)*& Next(){ return next; }\
};

So you have a more verbose way to declare a simple "template" in global
scope. What does this gain you over the more concise standard C++
template definition?

There's no limitation of global-only scope. The standard templates are not
much more concise.

What does the above get me, well control of the template system
implementation. A proof of concept that adequacy can be had with a
preprocessor-based implementation. (One thing that used to irk me with C++
templates is the way the compiler would generate stuff automatically. With
the above, I know that if I didn't use a DeclareX construct, it hasn't been
generated). The exercise above can be extended to actually hacking an
existing preprocessor to implement templates without all the macro-ish
backslashes (it's already been done with C++ template style syntax). Then,
you have a basic templates implementation dirt cheap, and one that you can
control.

To me, "templates" means the kind of thing the preprocessor does (text
substitution) and using it to generate typed code. Once it gets beyond that
concept, it's a different (C++-specific concept) animal, IMO. I like
templates to be implemented in the pre-compilation phases. If I ever wanna
implement that new fangled language I'm always yapping about, I'll be way
ahead by not having created dependence on things deep inside of commercial
C++ compilers that I would have a hard time reproducing (if possible at
all).

John

[JohnQ]

"Old Wolf" <ol*****@inspir e.net.nzwrote in message
news:11******** **************@ q19g2000prn.goo glegroups.com.. .

On Jun 11, 6:51 pm, "Robbie Hatley" <bogus.addr...@ no.spamwrote:

>>
Templates are a part of the C++ language. They are not
preprocessor macros.

'Preprocessor macros' are also a part of C++ language.
In fact, translation phases 1-7 are what people normally
mean when the say 'the preprocessor'. Phase 8 involves
instantiating templates.

It's just a convention that compiler vendors supply
distinct executables to perform the various translation
phases.

Are you saying that the phases only are specified and that they are not
associated with things like "preprocess or" and "compiler". (I can then make
a conforming implementation using preprocessor-based templates?).

John

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

On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:

Realize too that if you introduce C++-specific
things deeply into your code, your HIGHLY-C++-specific designs aren't going
to be portable to other languages/tools (say java or .net or Pascal or
whatever). _You_ may think that it's OK to use all the elements of C++
everywhere and all the time and as much as possible, I, OTOH, am at the
opposite end to that. Your statement "You do have to think of your code in a
more generic fashion." is not prudent advice IMO if you mean it like "see
where you can use templates and try to find ever increasing places in which
to use them". I would rather say: be judicious in the use of language
facilities, always, and prefer simple constructs and mechanisms over complex
ones.

Just a though but isn't the preprocessor quite unportable too? The
only languages I know of that have it is C and C++, and even if some
other language have one it's probably not 100% compatible with the one
in C++. Sure you can run it through the C++ preprocessor first and
then compile it with your Java (or whatever) compiler, but if you have
the C++ preprocessor you probably have the C++ compiler and could just
as well use that. And I haven't even mentioned the problem when others
want to compile your Java code that first needs to go through a
preprocessor.

--
Erik Wikström

[JohnQ]

"Erik Wikström" <er****@student .chalmers.sewro te in message
news:11******** **************@ j4g2000prf.goog legroups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:

Realize too that if you introduce C++-specific
things deeply into your code, your HIGHLY-C++-specific designs aren't
going
to be portable to other languages/tools (say java or .net or Pascal or
whatever). _You_ may think that it's OK to use all the elements of C++
everywhere and all the time and as much as possible, I, OTOH, am at the
opposite end to that. Your statement "You do have to think of your code in
a
more generic fashion." is not prudent advice IMO if you mean it like "see
where you can use templates and try to find ever increasing places in
which
to use them". I would rather say: be judicious in the use of language
facilities, always, and prefer simple constructs and mechanisms over
complex
ones.

"Just a though but isn't the preprocessor quite unportable too?"

(Oh, another one with special characters in their signature line huh).

I was thinking "portabilit y of resulting containers" for example. Now that
is easy if one hasn't relied upon anything more than simple text
substitution to generate those containers. But if the containers rely upon
highly intricate compiler-based templates mechanisms, there will be big
problems in bringing the code to a new environment because the design is
entwined with the implementation (not based upon common language constructs
but rather specialized C++ ones).

John

[Lionel B]

On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:

"Erik Wikström" <er****@student .chalmers.sewro te in message
news:11******** **************@ j4g2000prf.goog legroups.com... On 12 Juni,
05:19, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.comwrote:

"Just a though but isn't the preprocessor quite unportable too?"

(Oh, another one with an unconventional quoting style huh).

(Oh, another one with special characters in their signature line huh).

Did you mean the "ö"? Are you suggesting the poor fellow misspell his own
name???

--
Lionel B

[Gavin Deane]

On 12 Jun, 01:06, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.comwrote:

I limit what templates can do by requiring of them that they can be
implemented simply.

JohnQ: Can templates be implemented the same way as macros - straight
text substitution?

Others: No - here are some examples of things you can do with
templates that you can't do with macros.

JohnQ: Oh no - I don't mean things that complex or specialised. What I
meant to ask was, "Can a limited subset of template capabilities be
implemented as straight text substitution? The subset is limited to
only those things that can be implemented as straight text
substitution."

To which the answer is obviously "yes", by definition. But it's a
somewhat pointless question, is it not?

Gavin Deane