Talk:cpp/language/type

It might be worth noting that at least back in 2002 it was UB to specialize standard containers with incomplete types. I discussed this problem here: http://en.cppreference.com/w/Talk:cpp/container#We_should_probably_mention_that_it_is_illegal_to_create_containers_with_incomplete_types

rename 'pointer to data member' to 'pointer to member object'

I propose to rename all occurrences of 'pointer-to-data-member' to 'pointer-to-member-object'
Reasons:

1) I noticed chaotic usages of BOTH of them in the wiki, while the first one should be considered as a mistake. A data of member reference type is also of data member, but a pointer to such a member is an error.

2) Terms 'pointer to object' 'reference to object' are used, which is inconsistent with 'pointer to data member'. More importantly, 'member of object type' (aka member object) is exactly the target of a so-called 'pointer-to-data-member'

3) In C++ standard, it says 'A non-static data member of non-reference type is a member subobject of a class object', indirectly approves the term 'member object' (or at least 'member subobject')

Note 1: I propose it here instead of editing it directly due to its widespread occurrences including:

• cpp/language/pointer#Pointers_to_data_members, Most occurrences are links to here.
• cpp/language/type
• cpp/language/operator_member_access
• cpp/utility/functional/bind
• cpp/utility/functional/invoke

And so on.

Note 2: I found C++ standard is more likely to use 'data member of non-reference type' (4 occurrences in C++20), but isn't it too long for us to use that in wiki? And more strangely, there ARE 6 'pointer-to-data-member' found in C++20 standard with a 'pointer to data member of non-reference type' and 5 others without any suffix (ironically, 3 of 5 is found in definition of INVOKE). Does it mean 'data member' actually implies 'member object'? further discussion is necessary.

Problem with "member (sub)object" is that it can refer to base class subobjects. I reckon "pointer to data member object" perhaps? --Ybab321 (talk) 10:41, 24 October 2021 (PDT)

I would rather go the other way and purge mentions of "object" from the discussions of pointers to data members, because those beasts do not hold memory addresses and do not point to objects (or anything). Consider struct S { int a; } s;: the expression &s.a is a pointer that points to a member subobject, while the expression &S::a is a pointer-to-data-member, which is just a strongly-typed number zero. --Cubbi (talk) 08:33, 25 October 2021 (PDT)

Diagram et al

Lets talk. I suppose I should lead by saying that "explain what you're trying to achieve in discussion first" is a reasonable ask and "reminder: I can make whatever edits I want" is an utterly childish response, and one that applies to either direction of a revert. I personally don't have strong feelings about the language side of the site, it's lost its focus on comprehension IMO, but I'll give my stance.

I think the links to the type traits are fine, but I think the page is presented better without them and that's my preference. The diagram is cool, though I'm not much of a diagram guy myself. In response to "Without, the diagram makes no sense", I would suggest changing the diagram labels from "is_xyz" to "xyz", I don't think the "is_" prefix adds any value anyway, and then your diagram makes sense again. --Ybab321 (talk) 03:53, 8 January 2025 (PST)

If links are fine, then let's leave them. If "I just don't like them" is the only reason, it's a pretty weak position when removing someone else's effort.

Changing is_xyz to xyz makes no sense. There is no such entity as an 'object' in the library, however, there is a std::is_object trait.

I honestly really don't understand the opposite position. What is the problem when the section "fundamental" has a link to "std::is_fundamental" trait? Does it violate any rule? Any common sense? Ruslo (talk) 04:27, 8 January 2025 (PST)

Your stance of xyz being non-sense whilst is_xyz being sensible due to the presence of a type trait with that name is absurd, the "is" brings no clarity. Your stance on "I don't like not having the links" is no stronger than "I don't like the links", your other points are also general statements that could equally be made about the revert.

It seems to me that you consider the fact that you made an edit to be sufficient justification for these - honestly rather inconsequential - changes. Again, I have no horse in this race, but if there's no argument for the merit of keeping those type trait links, it would seem that you currently hold a minority opinion. --Ybab321 (talk) 06:36, 8 January 2025 (PST)

wow, please no, this diagram is worse than no diagram at all: showing relationship between traits instead of types (where's int?), lots of empty visual elements, oversized. Didn't we have Hinnant's C++0x type tree from https://howardhinnant.github.io/TypeHiearchy.pdf represented at some point, or did I dream it? (It would be 18 years out of date now and could probably be laid out better, but it'd help grasp the relationship between the types visually) --Cubbi (talk) 10:59, 8 January 2025 (PST)

(@Ruslo @Ybab321) My bad. I copied that reminder from the edit page above the save button as a response to “You are ruining someone else contribution”. What I would like to mean is that everyone making an edit sees the reminder before submitting, and that means an acknowledgement of “I understand that my edits are not permanent”. I did not intend to insult anyone by claiming “I can overwrite any edit you made if I want to”. I am sorry about that.

(also @Cubbi) The main purpose of the initial edit I made is to copy (and rearrange) the definitions of miscellaneous type categories to this page, so that descriptions in cpp/language pages do not need to link to cpp/named req pages for those definitions. I am not strongly against the type trait links, and the latest version is totally OK for me. --Xmcgcg (talk) 17:59, 8 January 2025 (PST)

[this diagram is worse than no diagram at all: showing relationship between traits instead of types (where's int?), lots of empty visual elements, oversized] It's a skeleton showing all parent types and their relationship to the std::is_scalar/std::is_object (one, or both, or none). The current version shows 15 elements, std::is_integer is a parent for 18 types: bool, char, signed char, unsigned char, char8_t, char16_t, char32_t, wchar_t, signed char, short, int, long, long long, unsigned char, unsigned short, unsigned, unsigned long, unsigned long long. Adding them will make it unnecessarily bigger without showing any new information about hierarchy. Details are always available in the text. The diagram is complete in the terms that it shows that std::is_fundamental contains std::is_void, std::is_arithmetic, std::is_null_pointer, and nothing else. As for the empty visual elements, I can experiment a bit. I can even attach a source graphml file if you want to give it a try yourself. Ruslo (talk) 06:06, 9 January 2025 (PST)

[Didn't we have Hinnant's C++0x type tree ...]

I haven't seen this one, I figured out myself that some tree might be helpful while reading the "Type classification" section. The fact that Howard tried to make one just proves the point that having a diagram is a useful thing.

If you check the Hinnant's type tree, you can notice the next inconsistencies and sources of confusion:

- nullptr_t is a type, there is no std::is_nullptr_t, but there is std::is_null_pointer

- void, float, int, etc. are types. However, pointer, scalar, and object are not types but free-form terms from C++ standards, but they all look the same

- There is "floating_point" (with an underscore). So it's not a free-form term? At the same time, there are "member object pointer", "member function pointer", etc., without underscore

The goal of my edits:

- Add a bridge between abstract notions and some code. Every type mentioned in a list has a corresponding trait you can check, like "fundamental types -> std::is_fundamental" or "union types -> std::is_union". It's a homogeneous approach that covers everything. I guess we all agree that officialese filled with abstract terms are much less exciting than having something to try yourself

- "is_fundamental" is similar to "std::is_fundamental"; just imagine you put "using std;" somewhere. However, if you use "class", "enum", or "void", but "null_pointer," it's overly confusing

The diagram is saved as an SVG file, you can actually click on each element, so if you click on "is_fundamental", it will open the "cpp/types/is_fundamental" page, again, consistency (note: you have to "open image in new tab" in a browser, otherwise it will not work) Ruslo (talk) 06:06, 9 January 2025 (PST)

A smaller version of the diagram has been added. If you don't like anything, please kindly explain what can be improved instead of removing it from the page. Ruslo (talk) 06:30, 9 January 2025 (PST)

(@Ruslo) Btw, the template {{cot}} has an optional title parameter. It makes sense to add the string explaining what is under the cut, e.g. ~ {{cot|Type traits hierarchy diagram}} (or whatever else is appropriate). In addition, the "clicability" of the SVG can also be mentioned in a comment before the SVG. --Space Mission (talk) 06:52, 9 January 2025 (PST)

(@Space Mission) Updated, thanks for the hints. --Ruslo (talk) 07:46, 9 January 2025 (PST)