Date: Sun, 27 Nov 2022 03:29:11 +0400
The question that Mehmet wants to ask, maybe, is for how long we should carry-forward legacy C++?Bjarne stipulated that, there is a simpler C++ waiting to emerge, but if we keep carrying the old bagage we will keep thinking in the old ways, and create constraints to our imagination process for no reasons.After a while ahead, compiler implementers will not be able to juggle between the new C++ (17, 20, ..up) and the old one.Just taking a look at the gcc stl implementation you will find a lot of.#ifdef....#endifWhich is purely C style, just to accommodate for the different C++ standards. I think we need to sit all together, and ask ourselves, what do we want C++ to be in the near future?It is good to have strong roots, but let the leaf prosper.That's my opinion.RegardsNadirSent from my Galaxy
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 11/27/22 2:51 AM (GMT+04:00) To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] Pragmas using multiple C++ standards within the same project On Sat, Nov 26, 2022 at 4:31 PM Mehmet Kayaalp via Std-Proposals<std-proposals_at_[hidden]> wrote:>> Thiago, Sebastian, Bo, and Arthur: Thank you for your feedback and drilling questions. Based on your input, I revised the following sentence to disambiguate my intention (see the italicized parts):> I fail to understand why we don’t come up with new preprocessor/compiler directives for each translation unit, indicating which compiler version should compile it to produce the intended assembler code (instead of compiling the entire set of codes with a single compiler).>> You all noted that this has already been done by others. But all mentioned solutions were outside of C++ standards; thus, they do not affect the decision-making of the C++ standardization committee. Without an intrinsic C++ solution that enables us to use the existing libraries and legacy codes, the C++ standardization committee would not attempt to eliminate the old baggage, simplify the language significantly and make the new C++ a more coherent language.>> > Why do we have to "eliminate" the old features? Just stop using them!> The backward compatibility requirement (along with the long legacy of C and C++) makes the modern C++ language very complex, making it too difficult for newcomers to embrace and learn the language and master the language in its entirety. A simpler and more coherent new standard can be embraced by newcomers easily and would provide developers with explicit guidelines about the preferred features of the language. By ignoring this, we would be making C++ less and less popular in the coming decades.Here's a question: what good are "newcomers" if their "mastering thelanguage" does not mean they've actually mastered *the language*?I'm not talking about how a newcomer might be unable to work well inC++17 through SFINAE if they're used to C++20 concepts. I'm talkingabout how having basic elements of the grammar behave differently (andtherefore incompatibly) between versions is helpful to their"mastery".A good C++20 programmer should be able to at least read C++98/03 code.They may not understand why the code does things a certain way, butthey should be able to understand what is happening. Archaic C++ isstill recognizable C++, even if it is primitive. What you want is toeffectively raise a generation of "C++" programmers who cannot evenread older versions of what is ostensibly the same language.Furthermore, if you start gatekeeping language features behindgrammatical changes, what happens to people who want to use some ofthose language features but *without* the grammatical changes? Likethey have a large codebase of C++23, and they want to use somereflection from C++26. But your hypothetically incompatible C++26means that they have to change a bunch of C++23 stuff that they haveno need to change.With your suggestion, everything is either/or.> We all can agree that such a new standard would not have all the bells and whistles of the current language, but with the proposed approach, one can always fall back on using the deprecated features supported by older standards for more flexibility and control.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 11/27/22 2:51 AM (GMT+04:00) To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] Pragmas using multiple C++ standards within the same project On Sat, Nov 26, 2022 at 4:31 PM Mehmet Kayaalp via Std-Proposals<std-proposals_at_[hidden]> wrote:>> Thiago, Sebastian, Bo, and Arthur: Thank you for your feedback and drilling questions. Based on your input, I revised the following sentence to disambiguate my intention (see the italicized parts):> I fail to understand why we don’t come up with new preprocessor/compiler directives for each translation unit, indicating which compiler version should compile it to produce the intended assembler code (instead of compiling the entire set of codes with a single compiler).>> You all noted that this has already been done by others. But all mentioned solutions were outside of C++ standards; thus, they do not affect the decision-making of the C++ standardization committee. Without an intrinsic C++ solution that enables us to use the existing libraries and legacy codes, the C++ standardization committee would not attempt to eliminate the old baggage, simplify the language significantly and make the new C++ a more coherent language.>> > Why do we have to "eliminate" the old features? Just stop using them!> The backward compatibility requirement (along with the long legacy of C and C++) makes the modern C++ language very complex, making it too difficult for newcomers to embrace and learn the language and master the language in its entirety. A simpler and more coherent new standard can be embraced by newcomers easily and would provide developers with explicit guidelines about the preferred features of the language. By ignoring this, we would be making C++ less and less popular in the coming decades.Here's a question: what good are "newcomers" if their "mastering thelanguage" does not mean they've actually mastered *the language*?I'm not talking about how a newcomer might be unable to work well inC++17 through SFINAE if they're used to C++20 concepts. I'm talkingabout how having basic elements of the grammar behave differently (andtherefore incompatibly) between versions is helpful to their"mastery".A good C++20 programmer should be able to at least read C++98/03 code.They may not understand why the code does things a certain way, butthey should be able to understand what is happening. Archaic C++ isstill recognizable C++, even if it is primitive. What you want is toeffectively raise a generation of "C++" programmers who cannot evenread older versions of what is ostensibly the same language.Furthermore, if you start gatekeeping language features behindgrammatical changes, what happens to people who want to use some ofthose language features but *without* the grammatical changes? Likethey have a large codebase of C++23, and they want to use somereflection from C++26. But your hypothetically incompatible C++26means that they have to change a bunch of C++23 stuff that they haveno need to change.With your suggestion, everything is either/or.> We all can agree that such a new standard would not have all the bells and whistles of the current language, but with the proposed approach, one can always fall back on using the deprecated features supported by older standards for more flexibility and control.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2022-11-26 23:29:21