473,704 Members | 4,096 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Are C++ templates a precompiler thing?

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
104 4572
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
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

"JohnQ" wrote:
Are C++ templates a precompiler thing?
By "precompile r", 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

"Ian Collins" <ia******@hotma il.comwrote in message
news:5d******** *****@mid.indiv idual.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

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

By "precompile r", 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
JohnQ wrote:
"Ian Collins" <ia******@hotma il.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
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
JohnQ wrote:
"Robbie Hatley" <bo***********@ no.spamwrote in message
news:Yh******** ***********@fe0 2.news.easynews .com...
>"JohnQ" wrote:
>>Are C++ templates a precompiler thing?
By "precompile r", 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.

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

// ======== GroupRangeDefin e =============== =============== ============
/**
* 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 GroupRangeDefin e
{
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 GroupSemanticDa ta<w_From>::t_S emanticTraits
t_SemanticTrait s;
};

// ======== 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_Und efined,
typename GroupTypeData<w _GroupCode-1>::t_Traits
>::w_Type
t_Traits;

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

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.