By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,616 Members | 1,198 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,616 IT Pros & Developers. It's quick & easy.

Are C++ templates a precompiler thing?

P: n/a
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
Jun 11 '07 #1
Share this Question
Share on Google+
104 Replies


P: n/a
JohnQ wrote:
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.
There isn't a precompiler.

No, if they were, they would suffer from the same drawbacks as macros,
such as file only scope and lack of type safety.

--
Ian Collins.
Jun 11 '07 #2

P: n/a
Ian Collins wrote:
JohnQ wrote:
>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.
There isn't a precompiler.
OK, there is http://www.comeaucomputing.com/, but I'm sure that's not
what you were referring to...

--
Ian Collins.
Jun 11 '07 #3

P: n/a

"JohnQ" wrote:
Are C++ templates a precompiler thing?
By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.

Templates are a part of the C++ language. They are not
preprocessor macros. If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

I, for one, love macros. And templates. I use both all the
time. But they're not even remotely similar. One is a
text-editing command; the other is a system for building
functions or classes which can use data of generic type.
The type needs to be decided-on before compile time, yes;
but templates remove the necessity of writing the same code
37 times just to handle 37 different data types.

Just try re-implimenting a container -- say, a binary tree --
for a bunch of different data types, and you'll quickly
appreciate the value of templates. (And you'll see that
macros are of no use for that purpose.)

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
triple-dubya dott tustinfreezone dott org
Jun 11 '07 #4

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5d*************@mid.individual.net...
JohnQ wrote:
>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.
There isn't a precompiler.
I meant preprocessor.
No, if they were, they would suffer from the same drawbacks as macros,
Or be as good as them. :P
such as file only scope and lack of type safety.
I'm not convinced that is true. Are you saying that macros can't be
type-safe?

John
Jun 11 '07 #5

P: n/a

"Robbie Hatley" <bo***********@no.spamwrote in message
news:Yh*******************@fe02.news.easynews.com. ..
>
"JohnQ" wrote:
>Are C++ templates a precompiler thing?

By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.

Templates are a part of the C++ language. They are not
preprocessor macros.
Can they be implemented that way though (early work did exactly that).
If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".
What's the diff?
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.
One is a
text-editing command; the other is a system for building
functions or classes which can use data of generic type.
The type needs to be decided-on before compile time, yes;
but templates remove the necessity of writing the same code
37 times just to handle 37 different data types.

Just try re-implimenting a container -- say, a binary tree --
for a bunch of different data types, and you'll quickly
appreciate the value of templates. (And you'll see that
macros are of no use for that purpose.)
Again, I whole-heartedly disagree. (Yeah, I've implemented those kinds of
things).

John
Jun 11 '07 #6

P: n/a
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote:
>such as file only scope and lack of type safety.

I'm not convinced that is true. Are you saying that macros can't be
type-safe?
How can they be? They are simple text substitutions.
--
Ian Collins.
Jun 11 '07 #7

P: n/a
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.
Jun 11 '07 #8

P: n/a
JohnQ wrote:
"Robbie Hatley" <bo***********@no.spamwrote in message
news:Yh*******************@fe02.news.easynews.com. ..
>"JohnQ" wrote:
>>Are C++ templates a precompiler thing?
By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.

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

Can they be implemented that way though (early work did exactly that).
If you refer to cfront then that's not true. The output from cfront
just used C as the "assembler".
>
>If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?
This is a cute piece of code - do this with macros.

================================================== =====================

// ======== GroupRangeDefine ==========================================
/**
* This is used in the specializations of the GroupTypeData template
* below. It contains the specification of the beginning of the
* range as specified in the dxf file.
*/

template <
int w_From,
int w_To,
typename w_ExternalType,
typename w_InternalType = w_ExternalType,
bool w_skip_white = false
>
class GroupRangeDefine
{
public:

enum {
e_From = w_From,
e_To = w_To
};
// ======== Traits ================================================
/**
* This defines the traits for this group.
*
*/

class Traits
{
public:
enum { SkipWhiteSpace = false };
typedef w_ExternalType t_ExternalType;
typedef w_InternalType t_InternalType;
};
typedef Traits t_Traits;

typedef typename GroupSemanticData<w_From>::t_SemanticTraits
t_SemanticTraits;
};

// ======== GroupTypeData =============================================
/**
* GroupTypeData scans recursively through the types looking for
* the specialization that corresponds to the w_GroupCode parameter.
* This is done so that the specifications for the group type data
* correspond in a 1:1 fashion with the dxf spec. This makes the
* compiler fill in all the blanks and hence less tedious or
* error prone.
*/

template <int w_GroupCode>
class GroupTypeData
{
public:

enum {
e_From = GroupTypeData<w_GroupCode-1>::e_From,
e_To = GroupTypeData<w_GroupCode-1>::e_To
};

typedef
typename at::TypeSelect<
(e_To < w_GroupCode),
GroupTraits_Undefined,
typename GroupTypeData<w_GroupCode-1>::t_Traits
>::w_Type
t_Traits;

typedef
typename GroupSemanticData<w_GroupCode>::t_SemanticTraits
t_SemanticTraits;
};
// specializations based on dxf documentation for "AutoCAD 2007 - March
2006"
template <class GroupTypeData< 0 : public GroupRangeDefine< 0, 9,
std::string {}; // String
template <class GroupTypeData< 10 : public GroupRangeDefine< 10, 39,
double {}; // Double precision 3D point value
template <class GroupTypeData< 40 : public GroupRangeDefine< 40, 59,
double {}; // Double-precision floating-point value
template <class GroupTypeData< 60 : public GroupRangeDefine< 60, 79,
at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 90 : public GroupRangeDefine< 90, 99,
at::Int32 {}; // 32-bit integer value
template <class GroupTypeData< 100 : public GroupRangeDefine< 100,
100, std::string {}; // String (255-character maximum; less for
Unicode strings)
template <class GroupTypeData< 102 : public GroupRangeDefine< 102,
102, std::string {}; // String (255-character maximum; less for
Unicode strings)
template <class GroupTypeData< 105 : public GroupRangeDefine< 105,
105, std::string {}; // String representing hexadecimal (hex) handle value
template <class GroupTypeData< 110 : public GroupRangeDefine< 110,
119, double {}; // Double precision floating-point value
template <class GroupTypeData< 120 : public GroupRangeDefine< 120,
129, double {}; // Double precision floating-point value
template <class GroupTypeData< 130 : public GroupRangeDefine< 130,
139, double {}; // Double precision floating-point value
template <class GroupTypeData< 140 : public GroupRangeDefine< 140,
149, double {}; // Double precision scalar floating-point value
template <class GroupTypeData< 170 : public GroupRangeDefine< 170,
179, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 210 : public GroupRangeDefine< 210,
239, double {}; // Double-precision floating-point value
template <class GroupTypeData< 270 : public GroupRangeDefine< 270,
279, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 280 : public GroupRangeDefine< 280,
289, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 290 : public GroupRangeDefine< 290,
299, at::Int8, bool {}; // Boolean flag value
template <class GroupTypeData< 300 : public GroupRangeDefine< 300,
309, std::string {}; // Arbitrary text string
template <class GroupTypeData< 310 : public GroupRangeDefine< 310,
319, BinaryXdata, std::string {}; // String representing hex value of
binary chunk
template <class GroupTypeData< 320 : public GroupRangeDefine< 320,
329, BinaryXdata, std::string {}; // String representing hex handle value
template <class GroupTypeData< 330 : public GroupRangeDefine< 330,
369, std::string {}; // String representing hex object IDs
template <class GroupTypeData< 370 : public GroupRangeDefine< 370,
379, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 380 : public GroupRangeDefine< 380,
389, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 390 : public GroupRangeDefine< 390,
399, std::string {}; // String representing hex handle value
template <class GroupTypeData< 400 : public GroupRangeDefine< 400,
409, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 410 : public GroupRangeDefine< 410,
419, std::string {}; // String
template <class GroupTypeData< 420 : public GroupRangeDefine< 420,
429, at::Int32 {}; // 32-bit integer value
template <class GroupTypeData< 430 : public GroupRangeDefine< 430,
439, std::string {}; // String
template <class GroupTypeData< 440 : public GroupRangeDefine< 440,
449, at::Int32 {}; // 32-bit integer value
template <class GroupTypeData< 450 : public GroupRangeDefine< 450,
459, at::Int32 {}; // Long
template <class GroupTypeData< 460 : public GroupRangeDefine< 460,
469, double {}; // Double-precision floating-point value
template <class GroupTypeData< 470 : public GroupRangeDefine< 470,
479, std::string {}; // String
template <class GroupTypeData< 999 : public GroupRangeDefine< 999,
999, std::string {}; // Comment (string)
template <class GroupTypeData< 1000 : public GroupRangeDefine< 1000,
1009, std::string {}; // String (same limits as indicated with 0-9
code range)
template <class GroupTypeData< 1010 : public GroupRangeDefine< 1010,
1059, double {}; // Double-precision floating-point value
template <class GroupTypeData< 1060 : public GroupRangeDefine< 1060,
1070, at::Int16 {}; // 16-bit integer value
template <class GroupTypeData< 1071 : public GroupRangeDefine< 1071,
1071, at::Int32 {}; // 32-bit integer value
template <class GroupTypeData< -5 : public GroupRangeDefine< -5, -5,
std::string {}; // APP: persistent reactor chain
template <class GroupTypeData< -4 : public GroupRangeDefine< -4, -4,
std::string {}; // APP: conditional operator (used only with ssget)
template <class GroupTypeData< -3 : public GroupRangeDefine< -3, -3,
BinaryXdata, std::string {}; // APP: extended data (XDATA) sentinel
(fixed)
template <class GroupTypeData< -2 : public GroupRangeDefine< -2, -2,
std::string {}; // APP: entity name reference (fixed)
================================================== =====================

This code allows the mapping of an int to type. This made the parsing
of dxf files a piece of cake. This can be used in a table or directly
in code and is basically a simple transformation from the dxf
documentation making the dxf parser easy to write from this point. I
don't think you can remotely do this with macros as they stand today.
After having written this DXF parser, I have yet to find a file that it
can't parse which is more than I can say for some commercial code I've
used. The neat thing is that it took me less time to write the parser
than it did trying to fix the previous version simply because I can
model the code to fit the specification closer that I could in C.

Can you create a macro to tell you if a type converts to another type or
if a type has a particular member or change behaviour of a function
template for a specific type (I call this the C++ come-from).
>
>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.

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

P: n/a
JohnQ wrote:
>
Can they be implemented that way though (early work did exactly that).
Yes, _earlier_. But also back in that time they had less semantics that ISO
C++ templates have.
>
>If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?
For one you write "#define" and for the other you write "template". Or be
more specific about your question.
>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.
Any reasons why "they should be the same"? There are a lot of semantic
differences ATM. templates are dealt with at compile time by the compiler
which is after the preprocessor has ran. Much of their semantics depend on
compiler only knowledge (such as types to deduce function template
parameters, evaluation of constant expressions at compile time, SFINAE
functionality, template names are part of the C++ compile time name system
thus working with the rules of Koening lookup and the namespace composition
and importing semantics, etc).

How would you implement something like SFINAE in the preprocessor?
Again, I whole-heartedly disagree. (Yeah, I've implemented those kinds of
things).
I seriously doubt your implementation supports SFINAE, ADL and template
parameter deduction for function templates.

--
Dizzy

Jun 11 '07 #10

P: n/a

"Gianni Mariani" <gi*******@mariani.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.

John
Jun 12 '07 #11

P: n/a

"Dizzy" <di***@roedu.netwrote in message news:f4**********@aioe.org...
JohnQ wrote:
>>
Can they be implemented that way though (early work did exactly that).

Yes, _earlier_. But also back in that time they had less semantics that
ISO
C++ templates have.
That's a good thing if you ask me though: "keeping them on a leash".
>
>>
>>If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?

For one you write "#define" and for the other you write "template". Or be
more specific about your question.
Template functionality (not the complex C++ incarnation of them) can be
implemented in various ways.
>
>>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.

Any reasons why "they should be the same"?
Reduction of complexity.
There are a lot of semantic
differences ATM. templates are dealt with at compile time by the compiler
which is after the preprocessor has ran. Much of their semantics depend on
compiler only knowledge (such as types to deduce function template
parameters, evaluation of constant expressions at compile time, SFINAE
functionality, template names are part of the C++ compile time name system
thus working with the rules of Koening lookup and the namespace
composition
and importing semantics, etc).

How would you implement something like SFINAE in the preprocessor?
Maybe I don't need that.
>
>Again, I whole-heartedly disagree. (Yeah, I've implemented those kinds of
things).

I seriously doubt your implementation supports SFINAE, ADL and template
parameter deduction for function templates.
I don't think I need that.

John
Jun 12 '07 #12

P: n/a

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:46***********************@per-qv1-newsreader-01.iinet.net.au...
JohnQ wrote:
>"Robbie Hatley" <bo***********@no.spamwrote in message
news:Yh*******************@fe02.news.easynews.com ...
>>"JohnQ" wrote:

Are C++ templates a precompiler thing?
By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.

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

Can they be implemented that way though (early work did exactly that).

If you refer to cfront then that's not true. The output from cfront just
used C as the "assembler".
HP hacked a preprocessor (PCC) to provide probably the earliest template
implementation for C++.
>
>>
>>If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?

This is a cute piece of code - do this with macros.
[example omitted}

I don't have a need to do that though. If you need to, then yeah, you may
wanna use the highly complex C++ templates.
Can you create a macro to tell you if a type converts to another type or
if a type has a particular member or change behaviour of a function
template for a specific type (I call this the C++ come-from).

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!
>
>>
>>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.
>
>>
...
>>
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.

John
Jun 12 '07 #13

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote:
>>such as file only scope and lack of type safety.

I'm not convinced that is true. Are you saying that macros can't be
type-safe?
How can they be? They are simple text substitutions.
But the text can expand to type-safe code (the same as C++ templates do).
You'll get an error at compile time if you try to pass a wrong type into a
function, for example. I don't see any difference whether templates are
implemented via the preprocessor or the compiler in regards to type safety.

John
Jun 12 '07 #14

P: n/a
JohnQ wrote:
"Gianni Mariani" <gi*******@mariani.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( ???? );

Jun 12 '07 #15

P: n/a
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
>JohnQ wrote:
>>"Ian Collins" <ia******@hotmail.comwrote:

such as file only scope and lack of type safety.
I'm not convinced that is true. Are you saying that macros can't be
type-safe?
How can they be? They are simple text substitutions.

But the text can expand to type-safe code (the same as C++ templates do).
You'll get an error at compile time if you try to pass a wrong type into a
function, for example. I don't see any difference whether templates are
implemented via the preprocessor or the compiler in regards to type safety.
OK, show us a map container implemented as macros.

--
Ian Collins.
Jun 12 '07 #16

P: n/a
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.
>
>>
...
>>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" ?
Jun 12 '07 #17

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
>>JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote:

such as file only scope and lack of type safety.
I'm not convinced that is true. Are you saying that macros can't be
type-safe?

How can they be? They are simple text substitutions.

But the text can expand to type-safe code (the same as C++ templates do).
You'll get an error at compile time if you try to pass a wrong type into
a
function, for example. I don't see any difference whether templates are
implemented via the preprocessor or the compiler in regards to type
safety.
OK, show us a map container implemented as macros.
That's not necessary. I refer you to early template implementations that
used generic.h. Once the preprocessor substitutes the type text into the
"macro" ("macro" is a somewhat inappropriate usage of the term when using
the preprocessor this way), a type-safe class exists and that is what gets
compiled. I think you are probably thinking about implementations that are
not templates (of any kind) but rather constructs based upon
pointers-to-void* ("C-style" containers/algos).

John
Jun 12 '07 #18

P: n/a
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
>JohnQ wrote:
>>"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote:
>
>such as file only scope and lack of type safety.
I'm not convinced that is true. Are you saying that macros can't be
type-safe?
>
How can they be? They are simple text substitutions.
But the text can expand to type-safe code (the same as C++ templates do).
You'll get an error at compile time if you try to pass a wrong type into
a
function, for example. I don't see any difference whether templates are
implemented via the preprocessor or the compiler in regards to type
safety.
OK, show us a map container implemented as macros.

That's not necessary. I refer you to early template implementations that
used generic.h. Once the preprocessor substitutes the type text into the
"macro" ("macro" is a somewhat inappropriate usage of the term when using
the preprocessor this way), a type-safe class exists and that is what gets
compiled. I think you are probably thinking about implementations that are
not templates (of any kind) but rather constructs based upon
pointers-to-void* ("C-style" containers/algos).
I ask again, show us a map container implemented with macros, time to
put up or shut up.

--
Ian Collins.
Jun 12 '07 #19

P: n/a

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:46***********************@per-qv1-newsreader-01.iinet.net.au...
JohnQ wrote:
>"Gianni Mariani" <gi*******@mariani.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, "preprocessor
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(int)
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

Jun 12 '07 #20

P: n/a

"Gianni Mariani" <gi*******@mariani.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

Jun 12 '07 #21

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5d*************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
>>JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:5d**************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote:
>>
>>such as file only scope and lack of type safety.
>I'm not convinced that is true. Are you saying that macros can't be
>type-safe?
>>
How can they be? They are simple text substitutions.
But the text can expand to type-safe code (the same as C++ templates
do).
You'll get an error at compile time if you try to pass a wrong type
into
a
function, for example. I don't see any difference whether templates are
implemented via the preprocessor or the compiler in regards to type
safety.

OK, show us a map container implemented as macros.

That's not necessary. I refer you to early template implementations that
used generic.h. Once the preprocessor substitutes the type text into the
"macro" ("macro" is a somewhat inappropriate usage of the term when using
the preprocessor this way), a type-safe class exists and that is what
gets
compiled. I think you are probably thinking about implementations that
are
not templates (of any kind) but rather constructs based upon
pointers-to-void* ("C-style" containers/algos).
I ask again, show us a map container implemented with macros, time to
put up or shut up.
There's another post I just made that shows the concept using an list link
(note that it is not actual code from any library that I use, but is rather
just for illustrative purposes). None of this stuff is "top secret" BTW.
Though I can't post my actual container code here, you should be able to see
the concept quite clearly. Again, it's "old hat" stuff if you've been a C++
user from the beginning. See one of my latest posts in this thread for the
"pattern".

John
Jun 12 '07 #22

P: n/a
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.

Jun 12 '07 #23

P: n/a
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.
Jun 12 '07 #24

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5d*************@mid.individual.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
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?
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
Jun 12 '07 #25

P: n/a

"Old Wolf" <ol*****@inspire.net.nzwrote in message
news:11**********************@q19g2000prn.googlegr oups.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 "preprocessor" and "compiler". (I can then make
a conforming implementation using preprocessor-based templates?).

John

Jun 12 '07 #26

P: n/a
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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

Jun 12 '07 #27

P: n/a

"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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 "portability 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
Jun 12 '07 #28

P: n/a
On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:
"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegro ups.com... On 12 Juni,
05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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
Jun 12 '07 #29

P: n/a
On 12 Jun, 01:06, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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

Jun 12 '07 #30

P: n/a
On Jun 12, 2:49 am, Ian Collins <ian-n...@hotmail.comwrote:
JohnQ wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
news:5d**************@mid.individual.net...
JohnQ wrote:
"Ian Collins" <ian-n...@hotmail.comwrote:
>>such as file only scope and lack of type safety.
I'm not convinced that is true. Are you saying that macros can't be
type-safe?
How can they be? They are simple text substitutions.
But the text can expand to type-safe code (the same as C++
templates do). You'll get an error at compile time if you
try to pass a wrong type into a function, for example. I
don't see any difference whether templates are implemented
via the preprocessor or the compiler in regards to type
safety.
OK, show us a map container implemented as macros.
Been there. Done that. It's ugly. You don't want to see it.

It's also relatively irrelevant. You can do a lot with textual
substitution, but it doesn't obey the same rules as templates.
My first AssocArray class, using generic.h, couldn't be
instantiated on a nested class, for example, since it token
pasted the class name to get the name of the "template"
instantiation. (Of course, that wasn't a problem then, since
the compiler didn't support nested classes yet anyway.)

If you really want an example of something that cannot be done
with macros, at all, try some of the template metaprogramming
stuff. Say, for example, std::distance (which selects different
algorithms according to the type of the iterator---note,
however, that my <generic.hAssocArray was a hash table, and
used a traits class to specify how to calculate the hash code
and test for equality). But IMHO, that's not really the point.
The point is that even when used for something that could be
done using macros, templates don't behave like macros. In any
way, shape, form or fashion. There's no textual substitution
involved.

--
James Kanze (GABI Software, from CAI) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 12 '07 #31

P: n/a
On Jun 11, 11:11 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Robbie Hatley" <bogus.addr...@no.spamwrote in message
news:Yh*******************@fe02.news.easynews.com. ..
"JohnQ" wrote:
Are C++ templates a precompiler thing?
By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.
Templates are a part of the C++ language. They are not
preprocessor macros.
Can they be implemented that way though (early work did exactly that).
Then they're not templates. Basically, templates were added to
the language in CFront 3.0 because macros (<generic.h>) were
found to be insufficient.
If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".
What's the diff?
They do two, fundamentally unrelated things. Templates are
integrated into the language, and operate on language level
entities, such as types and constant expressions. Macros
operate at an earlier level, on text.
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.
That solution was tried. And failed. Have you ever actually
used <generic.h>?

--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 12 '07 #32

P: n/a
On 12 Juni, 11:09, Lionel B <m...@privacy.netwrote:
On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegro ups.com... On 12 Juni,
05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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???
And now I'm a poor fellow just because I'm born with a surname not
representable in 7 bit ASCII, I don't want to think about those poor
millions of Chinese people :-)

--
Erik Wikström

Jun 12 '07 #33

P: n/a
On 12 Juni, 10:22, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message

news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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 codein
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 "portability 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).
I'm not quite sure I follow you here, do you mean that if one wanted
to port the code to another platform they should firs run it through
the preporcessor and take a look at the output to see how the
containers should be implemented. Now consider if this new platform/
language does not have a text-substituting facility like the
preprocessor and you have used your container for 15 different types,
that would mean that you would have to type 15 different
implementations of that container, no?
John
Oh, one of those few who *can* write their name in pure 7-bit ASCII.

--
Erik Wikström

Jun 12 '07 #34

P: n/a
On Jun 12, 2:06 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Gianni Mariani" <gi3nos...@mariani.wswrote in message
[...]
If you refer to cfront then that's not true. The output from cfront just
used C as the "assembler".
HP hacked a preprocessor (PCC) to provide probably the earliest template
implementation for C++.
HP never hacked the C++ preprocessor to provide templates. Get
your facts straight.

For as long as I've been using C++ (which goes back well before
templates were widespread), there was a file <generic.h>,
copyright AT&T (not HP---I was working on Sun machines at the
time), which contained a few of tricky defines which allowed
some pseudo-generic classes---my first AssocArrayOf (basically
map) was based on them. It was quite apparent, however, to
anyone that used them that they were not the solution, and that
something integrated into the language was necessary. I'm not
sure of the exact dates, and most of this I have from hearsay
(but from people who have actually worked very closely with the
people involved), but at one point, Stroustrup wrote a
preliminary definition of templates, and John Spicer implemented
an experimental version in CFront. Somehow (from what I
understand), this version got out the door, and became CFront
3.0, although it was never intended to be released by the
authors. It was rapidly replaced with version 3.0.1, which
corrected the bugs which made it totally unusable, but not much
else.

So: if you're talking about <generic.h>, it was macro based, it
came from AT&T, and it was found to be insufficient by just
about everyone who used it. And if you're talking about
templates, the first implementation was also at AT&T, it was
within CFront (which processed the pre-processor output), and
had nothing to do with the pre-processor.

[...]
Can you create a macro to tell you if a type converts to
another type or if a type has a particular member or change
behaviour of a function template for a specific type (I call
this the C++ come-from).
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!
I've actually used <generic.hin production code. For
containers and smart pointers. It doesn't work. That's why
templates were invented, because a pre-processor based solution
doesn't work.

--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 12 '07 #35

P: n/a
On Jun 12, 10:22 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
Realize too that if you introduce C++-specific
[...]
ones.
"Just a though but isn't the preprocessor quite unportable too?"
(Oh, another one with special characters in their signature line huh).
And who posts through Google, and who has a header line:
Content-Transfer-Encoding: quoted-printable
>From other posts of mine (where I've suppressed the accented
characters), I think that this line is what is causing you
problems. I don't know where it is inserted; Google doesn't
seem to insert it when I post from home. But technically, it is
legal, even if there is no real reason for it to be there, and
it shouldn't cause any problems for your newsreader.

I'm going to try to find out where it is inserted in my case,
and get rid of it if I can. But you really should get your
newsreader fixed. As far as I can tell, you're the only one who
has this problem.

--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 12 '07 #36

P: n/a
JohnQ wrote:
>
"Dizzy" <di***@roedu.netwrote in message news:f4**********@aioe.org...
>JohnQ wrote:
>>>
Can they be implemented that way though (early work did exactly that).

Yes, _earlier_. But also back in that time they had less semantics that
ISO
C++ templates have.

That's a good thing if you ask me though: "keeping them on a leash".
That's irrelevant to the original question.
>>>
If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?

For one you write "#define" and for the other you write "template". Or be
more specific about your question.

Template functionality (not the complex C++ incarnation of them) can be
implemented in various ways.
If by "templates" you mean something else that ISO C++ template keyword and
it's related functionality then probably yes, however that's irrelevant to
the original question.
>>>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.

Any reasons why "they should be the same"?

Reduction of complexity.
Nobody forces you to use them. Having them is an added bonus. You can just
use the preprocessor you are so found of.
>I seriously doubt your implementation supports SFINAE, ADL and template
parameter deduction for function templates.

I don't think I need that.
Again not relevant to the original question. The original question was,
quote: "Are C++ templates a precompiler thing?"

This was evolved into "can they be made" a precompiler thing and such. For
the first question you have an easy answer ("no because they are done by
the compiler right now"). For the second there seems to be impossible to
make it in the preprocessor without the compiler knowledge because of the
SFINAE and other template semantics. Of course you may not need those and
of course if your definition of templates resumes to just being some kind
of macros then you could do them with preprocessor macros. However
these "limited templates" are not the "C++ templates" from the original
question, which are much more rich in functionality.

You did say "C++ templates" which means the templates functionality of the
C++ language as a whole.

--
Dizzy

Jun 12 '07 #37

P: n/a

"Lionel B" <me@privacy.netwrote in message
news:f4**********@south.jnrs.ja.net...
On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:
>"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegr oups.com... On 12 Juni,
05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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???
I only speak English and recognize the English alphabet, sowwwy. I suppose
you want newgroups to be Unicode?

John
Jun 12 '07 #38

P: n/a

"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@g37g2000prf.googlegr oups.com...
On 12 Juni, 10:22, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message

news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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 "portability 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).
"I'm not quite sure I follow you here, do you mean that if one wanted
to port the code to another platform they should firs run it through
the preporcessor and take a look at the output to see how the
containers should be implemented."

Not really. Any sort of generics implementation is going to have to do code
generation. Assuming C++-style
built-into-the-compiler-in-highly-complex-ways is a deal breaker.

" Now consider if this new platform/
language does not have a text-substituting facility like the
preprocessor and you have used your container for 15 different types,
that would mean that you would have to type 15 different
implementations of that container, no?"
John
"Oh, one of those few who *can* write their name in pure 7-bit ASCII."

Making a case for Unicode? Note that my newsreader doesn't preprend the >
symbol to lines when someone uses the non-english characters in their
signature. Perhaps the Chinese should sign their posts in the gyphs of their
language too huh. And everyone should learn to read Chinese so that they
know what to call them. When in Rome...

John
Jun 12 '07 #39

P: n/a
On Tue, 12 Jun 2007 02:45:27 -0700, Erik Wikström wrote:
On 12 Juni, 11:09, Lionel B <m...@privacy.netwrote:
>On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegr oups.com... On 12
Juni,
05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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???

And now I'm a poor fellow just because I'm born with a surname not
representable in 7 bit ASCII, I don't want to think about those poor
millions of Chinese people :-)
Indeed!

--
ぐiꄍneӬl ஐ
Jun 12 '07 #40

P: n/a

"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Jun, 01:06, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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?
Yes, unless you want the C++ perversions of the concept. If so, then no.
Smells like C++ lock-in to me.
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."
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).
To which the answer is obviously "yes", by definition. But it's a
somewhat pointless question, is it not?
John
Jun 12 '07 #41

P: n/a

"James Kanze" <ja*********@gmail.comwrote in message
news:11********************@a26g2000pre.googlegrou ps.com...
On Jun 12, 2:06 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Gianni Mariani" <gi3nos...@mariani.wswrote in message
[...]
If you refer to cfront then that's not true. The output from cfront
just
used C as the "assembler".
HP hacked a preprocessor (PCC) to provide probably the earliest template
implementation for C++.
"HP never hacked the C++ preprocessor to provide templates. Get
your facts straight."

Texas Instruments. Decus C preprocessor. 1990. My bad. The fact that someone
did it though is the important thought.
Can you create a macro to tell you if a type converts to
another type or if a type has a particular member or change
behaviour of a function template for a specific type (I call
this the C++ come-from).
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!
"I've actually used <generic.hin production code. For
containers and smart pointers. It doesn't work. That's why
templates were invented, because a pre-processor based solution
doesn't work."

Once you get out of the box of thinking that C++ templates are the only
kind, things get easier. YMMV.

John
Jun 12 '07 #42

P: n/a

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.com...
On Jun 11, 11:11 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Robbie Hatley" <bogus.addr...@no.spamwrote in message
news:Yh*******************@fe02.news.easynews.com. ..
"JohnQ" wrote:
Are C++ templates a precompiler thing?
By "precompiler", I presume you mean the C/C++ preprocessor?
That's not *any* kind of "compiler", pre-, post-, or otherwise.
It's just a text editor.
Templates are a part of the C++ language. They are not
preprocessor macros.
Can they be implemented that way though (early work did exactly that).
"Then they're not templates."

Not "C++ templates" you mean.

"Basically, templates were added to
the language in CFront 3.0 because macros (<generic.h>) were
found to be insufficient."

YMMV.
If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".
What's the diff?
"They do two, fundamentally unrelated things. Templates are
integrated into the language, and operate on language level
entities, such as types and constant expressions. Macros
operate at an earlier level, on text."

I prefer the latter.
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.
"That solution was tried. And failed. Have you ever actually
used <generic.h>?"

I've built on top of that, but I've harvested the ideas there, yes. Putting
the implementation in the preprocessor is better, but I haven't tried that
yet. I agree using macroized lines to define template isn't ideal, but it's
really not that bad either unless you overuse templates. A few hacks to a
preprocessor and it improves. So I'm not that far away from having "99%" of
the functionality that I require for a fraction of the complexity, which is
nice.

John
Jun 12 '07 #43

P: n/a

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@g37g2000prf.googlegr oups.com...
On Jun 12, 10:22 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegro ups.com...
On 12 Juni, 05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
Realize too that if you introduce C++-specific
[...]
ones.
"Just a though but isn't the preprocessor quite unportable too?"
(Oh, another one with special characters in their signature line huh).
"And who posts through Google, and who has a header line:
Content-Transfer-Encoding: quoted-printable
>From other posts of mine (where I've suppressed the accented
characters), I think that this line is what is causing you
problems. I don't know where it is inserted; Google doesn't
seem to insert it when I post from home. But technically, it is
legal, even if there is no real reason for it to be there, and
it shouldn't cause any problems for your newsreader.

I'm going to try to find out where it is inserted in my case,
and get rid of it if I can. But you really should get your
newsreader fixed. As far as I can tell, you're the only one who
has this problem."

Certainly others are using OE. What's up with mine, if so then, I have no
idea. I do think news should be 7-bit ASCII though when the posts are in
English.

John
Jun 12 '07 #44

P: n/a
JohnQ wrote:
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).
Then you are offtopic to the subject of this discussion. You throw a
question like "Are _C++ templates_ a precompiler thing" then you transform
it to "my definition of templates a typing saver... anything else is a
C++-ism". You see that there is no logic there don't you?

"C++ templates" are "C++ templates" and not your definition of them (and
they are C++-isms my definition).

--
Dizzy

Jun 12 '07 #45

P: n/a

"Dizzy" <di***@roedu.netwrote in message news:f4**********@aioe.org...
JohnQ wrote:
>>
"Dizzy" <di***@roedu.netwrote in message news:f4**********@aioe.org...
>>JohnQ wrote:
Can they be implemented that way though (early work did exactly that).

Yes, _earlier_. But also back in that time they had less semantics that
ISO
C++ templates have.

That's a good thing if you ask me though: "keeping them on a leash".

That's irrelevant to the original question.
>>>>
If you want to use preprocessor macros
(and there's no reason not to), use "#define", not "template".

What's the diff?

For one you write "#define" and for the other you write "template". Or
be
more specific about your question.

Template functionality (not the complex C++ incarnation of them) can be
implemented in various ways.

If by "templates" you mean something else that ISO C++ template keyword
and
it's related functionality then probably yes, however that's irrelevant to
the original question.
>>>>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.

Any reasons why "they should be the same"?

Reduction of complexity.

Nobody forces you to use them. Having them is an added bonus. You can just
use the preprocessor you are so found of.
>>I seriously doubt your implementation supports SFINAE, ADL and template
parameter deduction for function templates.

I don't think I need that.

Again not relevant to the original question. The original question was,
quote: "Are C++ templates a precompiler thing?"

This was evolved into "can they be made" a precompiler thing and such. For
the first question you have an easy answer ("no because they are done by
the compiler right now"). For the second there seems to be impossible to
make it in the preprocessor without the compiler knowledge because of the
SFINAE and other template semantics. Of course you may not need those and
of course if your definition of templates resumes to just being some kind
of macros then you could do them with preprocessor macros. However
these "limited templates" are not the "C++ templates" from the original
question, which are much more rich in functionality.

You did say "C++ templates" which means the templates functionality of the
C++ language as a whole.
That's why it's threaded discussion: discussions evolve to give the
information, surrounding and in more detail than was originally asked for.
As the original question was mine, and I know what information I seek, the
drift of the thread away from a curt answer is indeed relevant.

John
Jun 12 '07 #46

P: n/a

"Dizzy" <di***@roedu.netwrote in message news:f4**********@aioe.org...
JohnQ wrote:
>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).

Then you are offtopic to the subject of this discussion. You throw a
question like "Are _C++ templates_ a precompiler thing" then you transform
it to "my definition of templates a typing saver... anything else is a
C++-ism". You see that there is no logic there don't you?

"C++ templates" are "C++ templates" and not your definition of them (and
they are C++-isms my definition).
I know what information I am seeking. And that is the plausibility of
implementing templates (not the C++ kind) via modification of the
preprocessor (as a modest improvement over the "macro-ised" implementation
technique). If the answer to the original question was "yes", that would
have made things appear more plausible. Since I'm not enamoured with the
feature set of C++ templates that require templates to be integrated into
the compiler, even though the answer was "no" to the original question, the
plausibility of doing templates (not the C++ kind) with a modified
precompiler remains.

John
Jun 12 '07 #47

P: n/a
On Jun 12, 6:07 pm, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
Are you saying that the phases only are specified and that they are not
associated with things like "preprocessor" and "compiler".
Yes
(I can then make a conforming implementation using preprocessor-based templates?).
Well I'm not really sure what you mean by 'preprocessor-based
templates'.
Jun 12 '07 #48

P: n/a

"Old Wolf" <ol*****@inspire.net.nzwrote in message
news:11*********************@z28g2000prd.googlegro ups.com...
On Jun 12, 6:07 pm, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>Are you saying that the phases only are specified and that they are not
associated with things like "preprocessor" and "compiler".

Yes
Cool.
>
>(I can then make a conforming implementation using preprocessor-based
templates?).

Well I'm not really sure what you mean by 'preprocessor-based
templates'.
Well I think others have answered that part of it and the answer is no, as
far as I gather. I'm not interested in producing a conforming implementation
anyway. I was just curious. By "preprocessor-based templates", in this
post's context, I mean "implementing templates (not the conforming kind) via
modification of a preprocessor. I also use "preprocessor-based templates" in
referring to the macroized templates implementation using an unmodified
preprocessor and just the text-substitution capability.

John
Jun 12 '07 #49

P: n/a
On Jun 12, 12:10 pm, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Lionel B" <m...@privacy.netwrote in message
news:f4**********@south.jnrs.ja.net...
On Tue, 12 Jun 2007 03:22:23 -0500, JohnQ wrote:
"Erik Wikström" <eri...@student.chalmers.sewrote in message
news:11**********************@j4g2000prf.googlegr oups.com... On 12 Juni,
05:19, "JohnQ" <johnqREMOVETHISprogram...@yahoo.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 hisown
name???
I only speak English and recognize the English alphabet, sowwwy.
You mean like in words like "naïve"?
I suppose you want newgroups to be Unicode?
Logically (or perhaps only hopefully), all transmission will be
in UTF-8 one of these days. There *are* places in the world
which don't speak English.

--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 12 '07 #50

104 Replies

This discussion thread is closed

Replies have been disabled for this discussion.