I've seen that in order to check if a type T is a class I can use:
bool isClass = std::is_class<T>::value;
It returns true for both classes and structs. I know that in C++ they are almost the same thing, but I'd like to know why there's not a distinction between them in the type trait. Is it always useless to check this difference, or is there some more reason that I don't understand?
It returns true for both classes and structs. I know that in C++ they are almost the same thing, but I'd like to know why there's not a distinction between them in the type trait.
Unfortunately this is a common misconception in C++. Sometimes it comes from fundamental misunderstanding, but at other times it comes from an ambiguity in English. It can come from inaccurate compiler diagnostics, badly-written books, incorrect SO answers…
You've probably read something like this:
"There is no difference in C++ between a struct and a class except the default visibility of members and bases."
This passage can be interpreted in a sense that is misleading, because the notions of identity and equality are hard to distinguish when using phrases like "no difference".
In fact, C++ has not had structs since 1985. It only has classes.
The kind of types that you declare with the keyword class and the keyword struct are classes. Period. The keyword struct, and the visibility rules that are the default when defining a class using that keyword, were kept only for backward compatibility with C … but that's a syntax thing. It doesn't make the resulting types actually be of a different kind.
The type trait makes no distinction because there literally isn't one to make.
struct creates classes, not structs. Your assertion "therefore struct is a C++ feature" is a non sequitur, I'm afraid. –
Cosmopolis std::is_class trait makes this abundantly clear. –
Cosmopolis struct and actually defining it as class, or vice versa, yields a compiler warning (if not an error)? –
Granddaddy struct or int which bear the same name in both languages are still different. –
Coherence struct declares a class. That is one, single concept. C++ does not have structs, or structures. At all. Feel free to write your own competing answer, but I have to go now and will be unable to further entertain this discussion. –
Cosmopolis struct is misleading (because it doesn't define one), the standard is full of errors and the language people use is incorrect and badly written. I see. –
Coherence struct in C++ can have virtual member functions. –
Schismatic struct (which indeed exists only for compatibility) introduces a class. Period. I can well believe that many people get this wrong but that's not my fault, nor is it my problem! –
Cosmopolis struct introduces a class. This is the point. –
Cosmopolis class, you are in fact declaring a struct. That the standard mentions classes at all is editorial sloppiness. C++ has not had classes since 1979 (the new synonym for struct was introduced by Bjarne to get funding -- it sounds fashionable). That's not my fault, and not my problem. :-) –
Coherence struct in C++ gets you more than you might expect. –
Schismatic std::is_class type trait? ;) –
Cosmopolis is_struct, I think it matters indeed. Because that's literally what the question is about. –
Cosmopolis is_class function name could arbitrarily also be is_struct. I don't see how C++ is different in this regard from, say, Go or Rust. Both Go and Rust have structs (and definitely no classes), but these are different from C structs (and also one another). Or do you mean to tell me Go and Rust don't have structs too? What is it that they have then??? –
Sumrall is_class could have been is_struct". But it isn't! Just as it isn't is_unicorn. Then you go on about some other, unrelated languages...? –
Cosmopolis struct keyword and it also defines POD structs as a subset of classes. You on the other hand haven't really explained anything, you haven't even explained what "to have structs" means to you - what does that even mean? Also, how is C++ different from the two languages I mentioned that "have structs"? –
Sumrall struct X; // declare X as a struct type I think that's pretty clear. –
Sumrall struct or the class-key class” (the distinction here is between struct and union class types). –
Riojas struct and class. Contrary to that assertion, a union is also a class. Summing up, this answer is nonsense through and through.] –
Riojas struct keyword have a different name mangling than types declared with the class keyword. Here for instance the function that takes a struct void f(const foo&) is mangled into ?f@@YAXABUfoo@@@Z and the function that takes a class void g(const bar&) is mangled into ?g@@YAXABVbar@@@Z. (Notice the U / V before the name of the function). This has implications if you ship a header with just a forward-declaration and the implementation is another type (missing symbols, etc.) –
Jokjakarta struct keyword at all in your C++ code? Might be the same, standard-wise, but how about programmer-wise? Do you write your traits with class, not struct templates? Do you represent your POD with classes? –
Twelvemonth It is impossible to distinguish a difference in semantics for empty definitions like
class C {
public:
};
from
struct S {
};
or similarly
class C {
};
and
struct S {
private:
};
Apart from the struct vs class keyword, there is no behavioral difference detectable. See also this Q&A.
Note: As remarked by @KyleStrand, derivation also requires explicit access specifiers, so S : private Base {}; and C : Base {}; are equivalent, the same as S : Base {}; and C : public Base {};, where S is a struct, C is a class, and Base can be either.
struct Derived : Base { is equivalent to class Derived : public Base { public:, and class Derived : Base { is equivalent to struct Derived : private Base { private:. –
Calash class C privately inherits from its bases by default, and a struct S publicly inherits from its bases by default. You've written that subclasses of a class C privately inherit from it by default, and that subclasses of a struct S publically inherit from it by default, which isn't the case. –
Schnitzler They're the same thing. The only difference (default member visibility) exists only at compile time. There is otherwise no difference at all between struct and class.
ETA: What you probably want is std::is_pod, which will tell you if your class is a "plain old data type". Much of the discussion and commentary on this question seems to indicate that this is what those who think there should be a distinction actually want.
bool isClass = std::is_class<T>::value; is also evaluated at compile time. It should be a problem to evaluate std::is_struct. –
Ripieno struct is more often used for simple POD classes, and in natural language the word "struct[ure]" is more often used for PODs or standard layout classes. So some people do distinguish, intuitively perhaps. You also asked "What would the point of distinguishing between them be?". Answer: One may want to tell C compatible aggregates from others (see my answer to the OP). The language could have chosen to use the keywords struct and class for that distinction, but it didn't. –
Coherence Others have pointed out correctly that in C++ the keywords struct and class have the same meaning except for the difference in member visibility.
Whether you call aggregate types thus defined "structs" or "classes" or "weiruewzewiruz" is up to you. In the interest of communication it is generally advisable to follow established conventions, so I would advise against "weiruewzewiruz".
It is also recommended to use semantic differences as a guideline for word choices. The use of struct is more common for simple aggregated data which does not have a lot of internal logic and invariants; a typical use would be struct point { float x; float y; };. Such types are often called "structs" or "structures" in the literature. It would not be surprising if somebody using fprintf in C++ referred to the first argument as a "pointer to a FILE struct". FILE is an example of what Scott Meyers' means in "More Effective C++", Item 34:
It is safe to assume that a structure definition that compiles in both languages [C and C++ -p.a.s] is laid out the same way by both compilers.
Concerning the natural language, the word choice "structure" is not coincidental: Meyers is talking about a plain old data aggregate which has identical semantics in both languages, right down to the bit level.
Concerning programming language, it wouldn't matter if the C++ definition of the data aggregate in question used the keyword struct or class (with a public access specifier). struct is perhaps the more natural choice, because the C++ semantics of the aggregate are the semantics of a C struct. Also, using struct enables both C and C++ sources to easier share one type definition.
The C++ standard uses "struct" and "structure" both in natural and programming language, not only in cases of interoperability: 1.7/5: "A structure declared as", or 3.2/4 struct X; // declare X as a struct type. Most interesting is 9/8, laying ground for interop-criteria:
8 A standard-layout struct is a standard-layout class defined with the class-key struct or the class-key class. [...]
How anybody reading this can claim that there are no structs in C++ is beyond me. This clearly is not an editing error because the terms "struct" and "class" are explicitly set in relation to each other.
More interesting than word choices and matters of taste, however, are manifest, testable differences. Under what circumstances is a C++ aggregate comparable to and compatible with a C struct? Perhaps this question was underlying your question? The standard layout mentioned in the quote is the criteria. It is detailed in 9/7 and essentially prescribes that
The standard then says
9 [ Note: Standard-layout classes are useful for communicating with code written in other programming languages. Their layout is specified in 9.2.—end note ]
Of course a struct definition which compiles in C fulfills these criteria, hence Scott Meyers' assertion. FILE from stdio.h is a prominent, not-quite-trivial example. Note that the standard doesn't make guarantees because object layout is implementation dependent and may change just with a compiler option.
Whether a class has standard layout can be tested with the type trait std::is_standard_layout<T>. The following program, which is inspired by an example on cppreference, checks the main cases laid out in the standard.
#include <cstdio>
#include <typeinfo>
#include <type_traits>
using namespace std;
struct funcOnlyT // fine
{
int f();
};
class podT { // "class" is ok
int m1;
int m2;
};
struct badAccessCtrlT { // bad: public/private
int m1;
private:
int m2;
};
struct polymorphicT { // bad: polymorphic
int m1;
int m2;
virtual void foo();
};
struct inheritOkT: podT // ok: inheritance, data only on one level
{
int f();
};
struct inheritPlusDataT: podT // bad: inheritance, data on 2 levels
{
int m3;
};
template<typename T1, typename T2>
struct templT // ok with std layout types T1, T2
{
T1 m1;
T2 m2;
};
// print type "name" and whether it's std layout
template<typename T>
void printIsStdLayout()
{
printf("%-20s: %s\n",
typeid(T).name(),
std::is_standard_layout<T>::value
? "is std layout"
: "is NOT std layout");
}
int main()
{
printIsStdLayout<funcOnlyT>();
printIsStdLayout<podT>();
printIsStdLayout<badAccessCtrlT>();
printIsStdLayout<polymorphicT>();
printIsStdLayout<inheritOkT>();
printIsStdLayout<inheritPlusDataT>();
printIsStdLayout<templT<int, float> >();
printIsStdLayout<FILE>();
}
Sample session:
$ g++ -std=c++11 -Wall -o isstdlayout isstdlayout.cpp && ./isstdlayout
9funcOnlyT : is std layout
4podT : is std layout
14badAccessCtrlT : is NOT std layout
12polymorphicT : is NOT std layout
10inheritOkT : is std layout
16inheritPlusDataT : is NOT std layout
6templTIifE : is std layout
9__sFILE64 : is std layout
struct". I would go further and say that these supposed standardese meaning of "struct" is neither widely-recognised nor unambiguous enough for a trait type to be named after it. –
Cosmopolis C++11 §9/10 ([class]/10):” A standard-layout struct is a standard-layout class defined with the class-key
structor the class-keyclass. A standard-layout union is a standard-layout class defined with the class-keyunion.
” A POD struct is a non-union class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). […]
Since a POD struct is a standard-layout class it is a subset of standard-layout struct. As far as I know this is the most general meaning of struct in the C++ standard. And so presumably what you're looking for is a type trait or set of type traits that lets you identify a standard-layout struct as such.
And voilà, looking at the list of type traits there's is_class and is_standard_layout. When a type satisifies ¹both it's a “struct”. Or more precisely, it's a standard-layout struct, as defined by C++11 §9/8.
Regarding
” I'd like to know why there's not a distinction between [class and struct] in the type trait
Well, there is. That's the is_standard_layout trait.
Regarding
” Is it always useless to check this difference, or is there some more reason that I don't understand?
No, it's not useless to check this difference. The standard defines standard-layout for the reason that it's very practically useful. As the standard itself notes,
C++11 §9/9 ([class]/9):” [Note: Standard-layout classes are useful for communicating with code written in other programming languages. Their layout is specified in 9.2.—end note ]
Notes:
¹ The is_class trait is true for a class or struct, but not for a union, even though the standard defines that “a union is a class”. I.e. the trait is more specific than the general terminology.
class vs struct. As such, I propose adding a note to your answer that this definition of "struct" is not the one the OP was referring to (maybe). –
Cosmopolis © 2022 - 2024 — McMap. All rights reserved.
(struct|class) MyClass : public BaseClass { private: ...., there is no difference betweenstructandclass. – Calashstructdoes not implyPOD struct. – Calash