- Forum
- General C++ Programming
- N4190
N4190
| Adopted N4190, and actually removed (not just deprecated) several archaic things from the C++ standard library, including auto_ptr, bind1st/bind2nd, ptr_fun/mem_fun/mem_fun_ref, random_shuffle, and a few more. Those are now all removed from the draft C++ 17 standard library and will not be part of future portable C++. - https://isocpp.org/blog/2014/11/updates-to-my-trip-report |
N4190: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190.htm
Made me remember the somewhat heated debate in this thread (almost three years ago); I was quite new to cplusplus.com at that time.
http://www.cplusplus.com/forum/general/62326/
If they remove everything old why not just create a new language? It's just confusing having different versions of a language that are incompatible with each other. Isn't backward compability important anymore?
AFAIK, this is the first instance of deprecated features being actually removed.
I tend to broadly agree with STL on this:
I tend to broadly agree with STL on this:
| Q2. Will removing this stuff from the Standard immediately break the world? A2. No. Remember that the Standard is not an implementation. An implementation is free to provide a strictly conforming C++14 mode with all of this deprecated stuff, and a strictly conforming C++17 mode without any of this stuff. Also, an implementation can provide a C++17 mode with the very slightly nonconformant behavior of also implementing this stuff according to C++14's specification. ... Practically speaking, implementations will be able to migrate away from deprecated-then-removed stuff as quickly or as slowly as they like. Q3. Then why bother removing anything? A3. ... More significantly, it sends a very clear message to authors, teachers, and the C++ community that this stuff shouldn't be used anymore. |
This is probably just going to lead to a lot of compilers leaning on the "As-if" rule to swap out deprecated stuff for their modern equivalent at compile-time. Likely this will mean that a lot more new programmers are going to have one more error\warning message that they will constantly ignore because "... it always says that. But I don't get it, my other programs worked before.". That is assuming instructors don't just make ancient compilers mandatory for their class like we see with so many people who are stuck using Blood-shed Dev.
I know I'm a pessimist, but I don't see how this is supposed to effect a positive change for the way C++ is taught. The problem isn't with the language and what it does or does not allow, it's the people who teach it wrong or who don't update their lessons to reflect new standards that do the damage to new programmers. Now this is a solved problem, a lot of industries have adopted a third party licensing\certification or evaluation that has to be periodically renewed for it's members to maintain their credibility. The question they need to look at now is whether or not this problem warrants such a measure.
| More significantly, it sends a very clear message to authors, teachers, and the C++ community that this stuff shouldn't be used anymore. |
I know I'm a pessimist, but I don't see how this is supposed to effect a positive change for the way C++ is taught. The problem isn't with the language and what it does or does not allow, it's the people who teach it wrong or who don't update their lessons to reflect new standards that do the damage to new programmers. Now this is a solved problem, a lot of industries have adopted a third party licensing\certification or evaluation that has to be periodically renewed for it's members to maintain their credibility. The question they need to look at now is whether or not this problem warrants such a measure.
Last edited on
> This is probably just going to lead to a lot of compilers leaning on the "As-if" rule to
> swap out deprecated stuff for their modern equivalent at compile-time.
You need to read up on the as-if rule; it is not a difficult concept to understand.
> a lot of industries have adopted a third party licensing\certification or evaluation
> that has to be periodically renewed for it's members to maintain their credibility.
I don't know of even one competent C++ software house relying on third-party certification to assess the proficiency of their programmers.
> swap out deprecated stuff for their modern equivalent at compile-time.
You need to read up on the as-if rule; it is not a difficult concept to understand.
> a lot of industries have adopted a third party licensing\certification or evaluation
> that has to be periodically renewed for it's members to maintain their credibility.
I don't know of even one competent C++ software house relying on third-party certification to assess the proficiency of their programmers.
I don't see where you think I went wrong with my statement about the as-if rule. I'm saying that if the newer, conforming compiler sees some deleted feature then they will likely just throw up a warning message to the programmer and swap in a modern equivalent rather then rejecting the code outright. This is literally changing the code but not the behavior of the program. You'll have to point out where I went wrong here.
That's probably more to do with the lack of market dominance of any one certification over the other. Or do you really think that an HR monkey is going to be able to differentiate between a capable programmer and a poser that can regurgitate exam questions when asked? Anyway, my thought was that the certification requirement would be put on the instructors since they are the ones that are doing the most damage toward the understanding of the language.
I don't think it would be necessary, or even a productive idea for that matter, to require that the programmers themselves certify but if they did then they would hardly be the first. Yes, I know "Sun was a private company and Java was their product ... that product now belongs to Oracle ... not the same thing as C++... cash grab ... monetizing revenue streams ..." and you would be right about all of it, but I'm saying that that the idea would not be unprecedented and would hardly be a barrier to entry for anyone who you might consider "competent".
| I don't know of even one competent C++ software house relying on third-party certification to assess the proficiency of their programmers. |
That's probably more to do with the lack of market dominance of any one certification over the other. Or do you really think that an HR monkey is going to be able to differentiate between a capable programmer and a poser that can regurgitate exam questions when asked? Anyway, my thought was that the certification requirement would be put on the instructors since they are the ones that are doing the most damage toward the understanding of the language.
I don't think it would be necessary, or even a productive idea for that matter, to require that the programmers themselves certify but if they did then they would hardly be the first. Yes, I know "Sun was a private company and Java was their product ... that product now belongs to Oracle ... not the same thing as C++... cash grab ... monetizing revenue streams ..." and you would be right about all of it, but I'm saying that that the idea would not be unprecedented and would hardly be a barrier to entry for anyone who you might consider "competent".
Last edited on
> I don't see where you think I went wrong with my statement about the as-if rule.
First, try to understand what the as-if rule is; what it permits, and what it does not permit. The as-if rule does not permit an implementation to subvert the qualified or unqualified name lookup rules of the language.
> Or do you really think that an HR monkey is going to be able to differentiate between
> a capable programmer and a poser that can regurgitate exam questions when asked?
You do not have the faintest idea of how, in practice, C++ programmers are hired or evaluated by even semi-competent C++ software houses, do you?
First, try to understand what the as-if rule is; what it permits, and what it does not permit. The as-if rule does not permit an implementation to subvert the qualified or unqualified name lookup rules of the language.
> Or do you really think that an HR monkey is going to be able to differentiate between
> a capable programmer and a poser that can regurgitate exam questions when asked?
You do not have the faintest idea of how, in practice, C++ programmers are hired or evaluated by even semi-competent C++ software houses, do you?
I see, because the user may want to use their own definition for that label or whatever so nothing should be done to prevent that which is why as-if doesn't apply. I can except that. You seem to be saying that the standards comity doesn't want these features accounted for in anyway at all which seems to contradict their comment about allowing a product to deviate slightly from strict adherence. Their comment about deviation is what made me think that they intended these removals to fall into the conditionally supported category. The meaning of 'removed' is still sinking in for me since, as you have already said, this hasn't been done before.
There is that qualifier again, I find it kind of amusing that you would classify a firm as 'incompetent' because a project manager might ask a member of HR to actually do their job and pre-filter a pool of candidates. Or that you actuallythink that act like most people obtain their position through personal recommendation and that their portfolio isn't actually a factor.
There is that qualifier again, I find it kind of amusing that you would classify a firm as 'incompetent' because a project manager might ask a member of HR to actually do their job and pre-filter a pool of candidates. Or that you actually
Last edited on
| They also removed trigraphs which constantly were an eyesore for me. |
IBM is still upset about it.
| AFAIK, this is the first instance of deprecated features being actually removed. |
std::gets was deprecated in C++11 and removed in C++14, although that just followed the developments in C
Topic archived. No new replies allowed.