C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Pragmas using multiple C++ standards within the same project

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Fri, 25 Nov 2022 07:34:29 +0100
To keep your suggestion simpler, you should really focus on syntax vs. C++ standard version. New C++ standard versions sometimes introduce behavioral changes; a variety or even mix of behaviors you would get even within one translation unit.   You can - as far as there is no ABI change - compile different translation units with different compiler switches already now, and link them together.   #pragmas directives are mostly meant for implentation specific code, but I understood that you are suggesting an addition to the standard, so it can use the larger and cleaner design space.   So new standards could proposedly support an alternative syntax mode.   How does it interact with #include? #include s can be inserted within expressions.   Do the proposed syntax pragmas work on a source file level, i.e. they are reset during an include (and restored after it) to maintain compatibility with current include files? Or would the including file be responsible and explicitly include some library headers in compatibility mode.   What about C macro compatibility?   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Mehmet Kayaalp via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 25.11.2022 06:00 Betreff:[std-proposals] Pragmas using multiple C++ standards within the same project An:std-proposals_at_[hidden]; CC:Mehmet Kayaalp <mehmet.kayaalp_at_[hidden]>; Preserving the old syntax without sacrificing the new  (or Letting evolution runs its course freely) It is claimed that “100% syntax backward compatibility” [https://youtu.be/ELeZAKCN4tY] is one of the major reasons against the progress of drastically simplifying syntax. The worth of C++ would not be the same if we ignore the entire evolution of C++ and the richness of existing libraries, which no one could rewrite in a brand-new syntax. In a natural evolution, the process involves not only the addition of new, worthy features to the gene pool but also the elimination of the old and nasty features from it. No one claims that if we write a new (C++) language from scratch with all that we know now but without the baggage of not-so-worthy features that are everywhere in great libraries, the syntax would be so complex. Current IDEs such as Microsoft’s Visual Studio comprise multiple C++ compilers, each associated with a different ISO standard. I fail to understand why we don’t come up with a version “pragma” for each piece of code, 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). What would be the unsolvable problem for linkers to link those assembler codes produced by different versions of compilers? This approach would limit neither “[1] the market for vendors/suppliers/builders, [2] the set of libraries and tools for users, nor [3] the set of collaborators (suitable employees, students, consultants, experts, etc.) for projects” [https://www.stroustrup.com/compat_short.pdf]. On the contrary, I would surmise that this approach would enhance those possibilities by leaps and bounds. I am sure I am missing certain side effects here and there, but how important and how difficult would they be, compared to the benefits of producing and maintaining a cleaner code set by letting evolution take its will freely? Best, --mehmet kayaalp -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2022-11-25 06:34:31