Hacker News Reader

Comment by vardump | Hacker News Reader

I'm always happier the more I see old cruft removed in a new C++ standard.

Trigraphs [1] are gone. Good riddance, they're just used for pointless pranks anyways. Otherwise they just seem to cause issues, there's always someone who didn't know about them at all.

Also "unexpected_ownership_move" err... "auto_ptr" is gone [2]. Yeah, I know, there's nothing inherently wrong with it and you knew how to use it correctly...

[1]: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n398...

[2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n419...

View on HN

Wiki[0] says that IBM opposed the removal of trigraphs. I wonder why?

[0] https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#Removal...

Because they still wanted to support some EBCDIC code pages which don't include { or }.

Thanks for a terrifying read! I shudder to think what sort of (now essentially solved) problems the engineers on those teams must have to deal with. I mean, if their code page doesn't even support [, {, }, or ], then imagine what must happen when someone tries to enter a non-english name into their system!

It's remarkable that such systems still exist (and are apparently being updated, without their foundational cracks fixed) still today!

And it's patently absurd to consider their argument that 1) they're still using trigraphs, but 2) intend to build against the C++17 spec.

FFS, if you somehow find both of these to be true, preprocess your source to convert trigraphs to the corresponding glyphs, and to a character encoding that supports them. I can't possibly believe that they're running a C++17 compiler on a system that has no support for such a character set.

Is the title in the title bar related to that article? It seems like a hold-over

Because they still sell mainframes to customers, that pay them for keeping them running as they always did.

Removing these facilities is a stunt. Real compilers will have to support them for decades (maybe at least auto_ptr) anyway, so there's no sense deleting them from the standard. It's sufficient to just recommend against their use.

I wouldn't say it's just a stunt. While they will remain supported, their removal from the standard can be cited by engineers for political support to modernize code bases. Compilers also support strict compilation modes which remove obsolete functions, to help modernize your code base. This is all facilitated by removal from the standard.

This also makes the standard smaller.

>While they will remain supported, their removal from the standard can be cited by engineers for political support to modernize code bases

Man... Who do you work for? If I used that as a reason for a refactoring my boss would laugh at me (and he's technical) . I imagine his boss would glaze over for a bit and then ask him to leave his office.

I think this casts my explanation in a very ungenerous light, I'm not really such an absurd person. Think of how a reasonable engineer would do it.

Speaking as an engineer, some of us have a tendency to want to refactor and polish code past the point where we should ship it and move on to something else. Management also has a tendency to view refactoring as unproductive and hurtful to the company's bottom line. Both are very reasonable positions. In most cases, the best strategy tends to be in the middle somewhere.

The auto_ptr class is gone from C++17 because it is error-prone to use it and there are better alternatives. However, I don't need to explain the intricacies of auto_ptr to my boss. I can just say something like, "We want to keep up with the latest industry best practices and standards. Some simple changes to our code base will reduce the chance for bugs and reduce support costs, and make it easier to develop new features."

The fact that auto_ptr has been removed from the standard entirely sends a stronger signal that you really should stop using it. Which is a good signal to send.

Trigraphs are actually incredibly annoying, because they silently change the meaning of characters (including in string literals). This is especially a problem when you use code generators.

It's why most C++ compilers these days don't even enable them by default. Kicking them out of the Standard is merely the recognition of that practice.

If you set -std=c++11 or some other version of the standard, they'll be there forever.

Reply on news.ycombinator.com