diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index fb94419..3c5f941 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -42,6 +42,7 @@ You can [Read an explanation of the scope and structure of this Guide](#S-abstra * [CPL: C-style programming](#S-cpl) * [PRO: Profiles](#S-profile) * [GSL: Guideline support library](#S-gsl) +* [FAQ: Answers to frequently asked questions](#S-faq) Supporting sections: @@ -308,6 +309,7 @@ Recommended information sources can be found in [the references](#S-references). * [CPL: C-style programming](#S-cpl) * [PRO: Profiles](#S-profile) * [GSL: Guideline support library](#S-gsl) +* [FAQ: Answers to frequently asked questions](#S-faq) Supporting sections: @@ -11322,6 +11324,88 @@ The use in expressions argument doesn't hold for references. **Enforcement**: Impossible in the face of history. + + +# FAQ: Answers to frequently asked questions + +This section covers answers to frequently asked questions about these guidelines. + +### FAQ.1: What do these guidelines aim to achieve? + +See the top of this page. This is an open source project to maintain modern authoritative guidelines for writing C++ code using the current C++ Standard (as of this writing, C++14). The guidelines are designed to be modern, machine-enforceable wherever possible, and open to contributions and forking so that organizations can easily incorporate them into their own corporate coding guidelines. + + +### FAQ.2: When and where was this work first announced? + +It was announced by [Bjarne Stroustrup in his CppCon 2015 opening keynote, “Writing Good C++14”](https://isocpp.org/blog/2015/09/stroustrup-cppcon15-keynote). See also the [accompanying isocpp.org blog post](https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines), and for the rationale of the type and memory safety guidelines see [Herb Sutter’s follow-up CppCon 2015 talk, “Writing Good C++14... By Default”](https://isocpp.org/blog/2015/09/sutter-cppcon15-day2plenary). + + +### FAQ.3: Who are the authors and maintainers of these guidelines? + +The initial primary authors and maintainers are Bjarne Stroustrup and Herb Sutter, and the guidelines so far were developed with contributions from experts at CERN, Microsoft, Morgan Stanley, and several other organizations. At the time of their release, the guidelines are in a "0.6" state, and contributions are welcome. As Stroustrup said in his announcement: "We need help!" + + +### FAQ.4: How can I contribute? + +See [CONTRIBUTING.md](https://github.com/isocpp/CppCoreGuidelines/blob/master/CONTRIBUTING.md). We appreciate volunteer help! + + +### FAQ.5: How can I become an editor/maintainer? + +By contributing a lot first and having the consistent quality of your contributions recognized. See [CONTRIBUTING.md](https://github.com/isocpp/CppCoreGuidelines/blob/master/CONTRIBUTING.md). We appreciate volunteer help! + + +### FAQ.6: Have these guidelines been approved by the ISO C++ standards committee? Do they represent the consensus of the committee? + +No. These guidelines are outside the standard. They are intended to serve the standard, and be maintained as current guidelines about how to use the current Standard C++ effectively. We aim to keep them in sync with the standard as that is evolved by the committee. + + +### FAQ.7: If these guidelines are not approved by the committee, why are they under `github.com/isocpp`? + +Because `isocpp` is the Standard C++ Foundation; the committee’s repositories are under [github.com/*cplusplus*](https://github.com/cplusplus). Some neutral organization has to own the copyright and license to make it clear this is not being dominated by any one person or vendor. The natural entity is the Foundation, which exists to promote the use and up-to-date understanding of modern Standard C++ and the work of the committee. This follows the same pattern that isocpp.org did for the [C++ FAQ](https://isocpp.org/faq), which was initially the work of Bjarne Stroustrup, Marshall Cline, and Herb Sutter and contributed to the open project in the same way. + + +### FAQ.8: Will there be a C++98 version of these Guidelines? a C++11 version? + +No. These guidelines are about how to best use Standard C++14 (and, if you have an implementation available, the Concepts Lite Technical Specification) and write code assuming you have a modern conforming compiler. + + +### FAQ.9: Do these guidelines propose new language features? + +No. These guidelines are about how to best use Standard C++14 + the Concepts Lite Technical Specification, and they limit themselves to recommending only those features. + + +### FAQ.50: What is the GSL (guideline support library)? + +The GSL is the small set of types and aliases specified in these guidelines. As of this writing, their specification herein is too sparse; we plan to add a WG21-style interface specification to ensure that different implementations agree, and to propose as a contribution for possible standardization, subject as usual to whatever the committee decides to accept/improve/alter/reject. + + +### FAQ.51: Is [github.com/Microsoft/GSL](https://github.com/Microsoft/GSL) the GSL? + +No. That is just a first implementation contributed by Microsoft. Other implementations by other vendors are encouraged, as are forks of and contributions to that implementation. As of this writing one week into the public project, at least one GPLv3 open source implementation already exists. We plan to produce a WG21-style interface specification to ensure that different implementations agree. + + +### FAQ.52: Why not supply an actual GSL implementation in/with these guidelines? + +We are reluctant to bless one particular implementation because we do not want to make people think there is only one, and inadvertently stifle parallel implementations. And if these guidelines included an actual implementation, then whover contributed it could be mistakenly seen as too influential. We prefer to follow the long-standing approach of the committee, namely to specify interfaces, not implementations. But at the same time we want at least one implementation available; we hope for many. + + +### FAQ.53: Why weren’t the GSL types proposed through Boost? + +Because we want to use them immediately, and because they are temporary in that we want to retire them as soon as types that fill the same needs exist in the standard library. + + +### FAQ.54: Has the GSL (guideline support library) been approved by the ISO C++ standards committee? + +No. The GSL exists only to supply a few types and aliases that are not currently in the standard library. If the committee decides on standardized versions (of these or other types that fill the same need) then they can be removed from the GSL. + + +### FAQ.55: If you’re using the standard types where available, why is the GSL `string_view` different from the `string_view` in the Library Fundamentals 1 Technical Specification? Why not just use the committee-approved `string_view`? + +Because `string_view` is still undergoing standardization, and is in a state for public review input to improve it. Types that appear in Technical Specifications (TSes) are not yet part of the International Standard (IS), and one reason they are put in TSes first is to gain experience with the feature before they are cast in a final form to become part of the standard. Some of the GSL authors are contributing what we have learned about `string_view` in the process of developing these guidelines, and a discussion of the differences, as a paper for the next ISO meeting for consideration along with all the other similar papers for the committee to consider as it decides on the final form of this feature. + + + # Appendix A: Libraries This section lists recommended libraries, and explicitly recommends a few.