14

We (should) know that C++ standard library containers, including std::string, are not meant to be inherited from. But still, C++98/03 did allow us to do it even if it was leading to bugs.

Now that the final keyword is available, are those standard library container marked final to prevent bad use of inheritance with them?

If not, why is that?

Jarod42
  • 203,559
  • 14
  • 181
  • 302
Klaim
  • 67,274
  • 36
  • 133
  • 188

2 Answers2

18

The LWG discussed this issue at the recent meeting in Kona Feb. 6-10, 2012. This is LWG issue 2113.

The LWG decided to mark LWG 2113 as NAD (not a defect), with the rationale that the standard is already clear that existing classes such as containers and std::string can not be marked final by the implementation.

The discussion included the fact that while it may be frowned on to derive from such classes, it is clearly legal to do so in C++98/03. And making it illegal in C++11 would break far too much code.

Update

At this time, no library types in the current working draft are marked final.

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • Thanks for fixing the type-o Jerry. I had it in two places and just fixed the second one too. I wouldn't have noticed it without your help. – Howard Hinnant Feb 15 '12 at 18:15
  • Surely. Sorry I missed the second one. – Jerry Coffin Feb 15 '12 at 19:04
  • @HowardHinnant Thanks for the answer. Types like `std::string` and `std::vector` were available before C++11. `std::future` was introduced with C++11. Do you know why new C++11 classes were not introduced as final classes? Why I ask: It is not inherently bad to use classes like `std::future` as base class, but on the other hand, adding final would clearly show the intent. So what was/is the rational [not using final for classes in the standard library](http://eel.is/c++draft/derivation#4)? – Sonic78 Apr 23 '19 at 13:06
  • @Sonic78: I can't really speak for the entire committee. But I can easily imagine that there is insufficient motivation to make private inheritance from `future` illegal. The standard must be careful to not devolve into dictating the coding style of code outside of the standard library. – Howard Hinnant Apr 23 '19 at 14:32
2

std::string does not seem to be marked final, nor do the other containers.

My guess as to why would be that even though deriving from them isn't generally recommended, nobody was quite sure how much working code would break if it was prohibited.

Also note that, for what it's worth, final isn't technically a key word -- it's an identifier to which a special meaning is attached, but only under specific circumstances. Code that contained something like int final; final = 1; will still work. This is mostly for backward compatibility though -- at least in new code, it's almost certainly better to use final only for the special meaning, not as a normal identifier.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • 4
    I disagree with the last sentence. The whole point of not making it a keyword is to be able to have context-based keywords. It's not confusing to say `int final;` In context, we know exactly what it means, so there's no problem. Confusion would happen only with "keywords" that can appear in the same place as expressions. And that's not the case here. – Nicol Bolas Feb 15 '12 at 18:04
  • @NicolBolas If your goal is to only support syntax highlighters containing a nearly full C++ compiler, then sure. But if you avoid using context sensitive keywords in other contexts in future code, your syntax highlighting can be accurate without requiring nearly as much complexity. – Yakk - Adam Nevraumont Oct 25 '15 at 16:52