A parameterized class (i.e. template class / class template) is not a class?

  • Thread starter christopher diggins
  • Start date
C

christopher diggins

It appears that the following is not considered a class:

template<typename T>
class C { };

?

So officially is this considered: a class, a template, a class template, or
a template class? I always thought of it as a parameterized class. What
would the rationale be for not considering it as just a 'class'?
 
P

Pete Becker

christopher said:
It appears that the following is not considered a class:

template<typename T>
class C { };

?

So officially is this considered: a class, a template, a class template, or
a template class? I always thought of it as a parameterized class. What
would the rationale be for not considering it as just a 'class'?

It's not a class because you can't define objects of type C. It's a
class template, because it defines a pattern for creating classes.
C<int> is a class.
 
H

Howard

christopher diggins said:
It appears that the following is not considered a class:

By whom?
template<typename T>
class C { };

?

So officially is this considered: a class, a template, a class template,
or a template class? I always thought of it as a parameterized class. What
would the rationale be for not considering it as just a 'class'?

I see no such rationale.

Obviously, it's a template. What type of template?... a class template (as
opposed to, say, a function template), since it defines a class.

Also obviously (to me), it's a class, since it defines a class. I don't
know if it's correct terminology, but I often refer to it as a template
class, as in "a class that is described by a template".

But I believe that the "correct" terminology is "class template".

Is this question because one poster suggested there was no string class in
standard C++? If so, I'd ignore that statement and get on with things.
It's probably irrelevant in the long run, as long as someone you're
communicating with understands what you're trying to say.

-Howard
 
H

Howard

Pete Becker said:
It's not a class because you can't define objects of type C. It's a class
template, because it defines a pattern for creating classes. C<int> is a
class.

Good point. I agree, (and take back my remark that C itself is a class).

-Howard
 
P

Pete Becker

Howard said:
Is this question because one poster suggested there was no string class in
standard C++?

Maybe, but that statement is wrong. There's the basic_string class
template (which we've established is not a class <g>), and there's the
typedef string, which is a class.
 
A

Abecedarian

Pete said:
Maybe, but that statement is wrong. There's the basic_string class
template (which we've established is not a class <g>), and there's the
typedef string, which is a class.

Let me add something to the confusion:
From the C++ Standard, 7.1.3 The typedef specifier: "A typedef-name is
thus a synonym for another type. A typedef-name does not introduce a
new type the way a class declaration (9.1) or enum declaration does."
Also, an instantiated class template has different code generation
rules (not all functions are created) and different lookup rules (e.g.
dependent names) ...
If it were not different it would be the same ;-)

Abe
 
V

Victor Bazarov

Abecedarian said:
class in



Let me add something to the confusion:
thus a synonym for another type. A typedef-name does not introduce a
new type the way a class declaration (9.1) or enum declaration does."
Also, an instantiated class template

What is "an instantiated class template"? You mean an instantiation of
a class template?..
has different code generation
rules (not all functions are created) and different lookup rules (e.g.
dependent names) ...
If it were not different it would be the same ;-)

I am not sure how this "adds to the confusion"? 'std::string' is merely
a synonym for 'std::basic_string<char>'. The latter is a class. So is
'string'. I am not sure what it has to do with code generation rules or
the lookup rules. It's a class as far as classes are concerned in the
"class template versus class" context.

V
 
P

Pete Becker

Abecedarian said:
class in



Let me add something to the confusion:

No, please don't. <g> string is a typedef for basic_string<char>, which
is a class. Yes, the rules are somewhat different, but the point is that
it names a type. Don't get carried away with fine-tuning terms so that
they become hard to use.
 
A

Abecedarian

Pete said:
string is a typedef for basic_string<char>, which
is a class. Yes, the rules are somewhat different, but the point is that
it names a type. Don't get carried away with fine-tuning terms so that
they become hard to use.

One last wish since you are the right addressee. I'd appreciate if the
C++ Standard allowed a "real" string class alternatively to a typedef
std::basic_string<char, ...> string "class". Usability would be
improved significantly at virtually no cost and 100% backward
compatibility.

Regards,
Abe
 
P

Pete Becker

Abecedarian said:
One last wish since you are the right addressee. I'd appreciate if the
C++ Standard allowed a "real" string class alternatively to a typedef
std::basic_string<char, ...> string "class". Usability would be
improved significantly at virtually no cost and 100% backward
compatibility.

How would a "real" string class differ from basic_string<char>?
 
A

Abecedarian

Pete said:
How would a "real" string class differ from basic_string<char>?

namespace std {
class string { /* interface as basic_string template */ };
}

This class would be much more convenient for the user than a template
with 3 parameters. The verbosity of error messages could be reduced to
a fraction of basic_string, even more when string is used as template
in other templates.

Regards,
Abe
 
V

Victor Bazarov

Abecedarian said:
[..]
namespace std {
class string { /* interface as basic_string template */ };
}

This class would be much more convenient for the user than a template
with 3 parameters. The verbosity of error messages could be reduced to
a fraction of basic_string, even more when string is used as template
in other templates.

This should be solved by the compiler implementors, not by making changes
to the library. A simple feature: if a typedef is in scope, use it when
emitting an error message or a warning instead of full template spec.

V
 
P

Pete Becker

Abecedarian said:
namespace std {
class string { /* interface as basic_string template */ };
}

This class would be much more convenient for the user than a template
with 3 parameters.

That's what std::string is. It's the name of a class.
The verbosity of error messages could be reduced to
a fraction of basic_string, even more when string is used as template
in other templates.

Okay, that's a legitimate problem. But we're not going to redesign
std::string for that. The real problem is far more extensive: Compiler
writers haven't yet figured out how to give good error messages for
templates. Avoiding templates won't solve this problem. The solution has
to come from compiler writers.
 
A

Abecedarian

Pete said:
Okay, that's a legitimate problem. But we're not going to redesign
std::string for that.

No redesign necessary, just 'translate' basic_string<char, ...> to
class string. Of course, the basic_string template shall remain as it
is. Just the typedef shall be optional with a real string class
(actually 2 classes).
The real problem is far more extensive: Compiler
writers haven't yet figured out how to give good error messages for
templates.

They cannot. The problem is situated in the C++ 'template mechanism'.
Avoiding templates won't solve this problem.

Avoiding unnecessary templates for the most frequent use cases really
would mostly solve this problem

A.
 
P

Pete Becker

Abecedarian said:
No redesign necessary, just 'translate' basic_string<char, ...> to
class string. Of course, the basic_string template shall remain as it
is. Just the typedef shall be optional with a real string class
(actually 2 classes).

That's just like writing the same function twice: it leads to
maintenance problems and inconsistencies.
 
A

Abecedarian

Pete said:
That's just like writing the same function twice: it leads to
maintenance problems and inconsistencies.

Yes, for 3 Standard library implementors, and to more convenience for
thousands of programmers.
 
P

Pete Becker

Abecedarian said:
Yes, for 3 Standard library implementors, and to more convenience for
thousands of programmers.

You're forgetting the standard itself, and the thousands of programmers
who will have to deal with any inconsistencies that arise because of
this poor design.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top