5 ms·

The real language problem is that classes are closed -- you can't add your own methods to std::string (other than operators) As a C++ program grows it's more a

The real language problem is that classes are closed -- you can't add your own methods to std::string (other than operators) As a C++ program grows it's more and more tempting to make your own private string class (either by inheriting from std::string, encapsulating it, or reimplementing it) that interacts more naturally with your program's other types. I've done this myself. Of course this works great until you need to link to some other C++ library which has its own different string type. Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished.

deleted 12y ago
[deleted]
pubby 12y ago
What's wrong with free functions?
- bodyfour 12y ago
  Nothing really, but it mean your extensions aren't really first class syntactically. A developer has to remember that they write s.size() but not s.count_utf8_codepoints(). Bjarne Stroustrup actually has an interesting proposal to fix this by unifying free functions and method call syntax in C++17 although the proposal sounds pretty aggressive to me: http://isocpp.org/files/papers/N4174.pdf http://isocpp.org/files/papers/N4174.pdf Would be an interesting change.
dragonwriter 12y ago
> Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished. But then you'd have the problem with different extensions to the same base class used in different libraries used in the same project conflicting, so you'd also need to make a way to scope the extensions to prevent that.
- bodyfour 12y ago
  No different than any other symbol name in the global namespace though.
  - dragonwriter 12y ago
    Well, yes, but there's a reason that you generally avoid using the global namespace, and open classes basically make extensions to classes have the same problems that globals have. (In Ruby, where open classes are a major and frequently-leveraged feature, this became a serious issue; hence, why Ruby 2.x introduced refinements as an alternative that provides much of the utility of open classes but with less opportunity for conflicts.)

deleted 12y ago

[deleted]

pubby 12y ago

What's wrong with free functions?

bodyfour 12y ago
Nothing really, but it mean your extensions aren't really first class syntactically. A developer has to remember that they write s.size() but not s.count_utf8_codepoints(). Bjarne Stroustrup actually has an interesting proposal to fix this by unifying free functions and method call syntax in C++17 although the proposal sounds pretty aggressive to me: http://isocpp.org/files/papers/N4174.pdf http://isocpp.org/files/papers/N4174.pdf Would be an interesting change.

dragonwriter 12y ago

> Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished. But then you'd have the problem with different extensions to the same base class used in different libraries used in the same project conflicting, so you'd also need to make a way to scope the extensions to prevent that.

bodyfour 12y ago
No different than any other symbol name in the global namespace though.
- dragonwriter 12y ago
  Well, yes, but there's a reason that you generally avoid using the global namespace, and open classes basically make extensions to classes have the same problems that globals have. (In Ruby, where open classes are a major and frequently-leveraged feature, this became a serious issue; hence, why Ruby 2.x introduced refinements as an alternative that provides much of the utility of open classes but with less opportunity for conflicts.)