1

I hear often this is for backward compatibility with C. But C does not have access specifiers, so how can they break compatibility?

And a related question, why do mixed access specifiers allow the compiler to change the order of the members of a struct in memory?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Patrick Fromberg
  • 1,313
  • 11
  • 37
  • Note that the [tag:pod] tag is marked 'DO NOT USE THIS TAG!', and the [tag:standard-layout] tag has no description (and only 30 questions, and no followers; all the questions except one have [tag:c++], which is good, especially as the one could have the tag added too if it didn't have so many other tags). I've removed the one that should not be used. – Jonathan Leffler Jan 25 '18 at 01:55
  • 2
    I suspect the reasoning goes the other way round: structs without access specifiers have to maintain a well-defined order so as to be compatible with C (and allow mixed C/C++-built binaries); but classes with access specifiers can't possibly be used in C, so compatibility is not an issue and it's OK to give the compiler the latitude to optimize. – Igor Tandetnik Jan 25 '18 at 01:55
  • Basically this: https://stackoverflow.com/questions/25479373/how-memory-is-allocated-for-private-and-public-members-of-the-class – NathanOliver Jan 25 '18 at 02:01
  • @Igor, have you ever seen a compiler change the order of the members? I have not, but the annoying restrictions disallow valuable POD usage all the time. Your argument is probably correct. But this optimization potential is not worth it to destroy the valuable POD usage in so many cases and create unexpected specifications. After all, the optimization can still be achieved reorganizing manually or maybe with some editor intelligence. – Patrick Fromberg Jan 25 '18 at 02:06
  • What kind of "POD usage" do you have in mind, that is prevented by this rule? POD struct by definition has the same access control for all non-static members, and so the order is well-defined. I'm not sure I quite grasp the nature of your concern. – Igor Tandetnik Jan 25 '18 at 02:12
  • @Igor, I do understand the "all same access specifier" rule. What I am saying is, it should not exist. I do not see why it makes sense. – Patrick Fromberg Jan 25 '18 at 02:16
  • 1
    Again, what "valuable POD usage" is being disallowed by this pernicious rule? What's the use case where a) you want a class with different access for different members, and b) you care about the ordering of these members in the memory layout? – Igor Tandetnik Jan 25 '18 at 02:22
  • @Nathan, I am not asking what the rules are, I believe I know them in this case while admitting my ignorance in most others. I am complaining about the rules. Use of aggregates and PODs is to restricted in my opinion. – Patrick Fromberg Jan 25 '18 at 02:25
  • @Igor, "valuable" means for me "no need to write code" in this case. I am super extremely lazy. And I do not care much about member ordering in memory, its the standard committee who does and as a consequence restricts POD usage. – Patrick Fromberg Jan 25 '18 at 02:29
  • 3
    What code are you forced to write now that you would rather avoid writing? What would you do with PODs absent this rule, that you are restricted from doing by this rule? Sorry, I still fail to understand the nature of the problems that this rule supposedly creates for you. – Igor Tandetnik Jan 25 '18 at 02:34

0 Answers0