So one "no," and one "yes, conditional." |
I didn't mean to convey a "no" on that question. I'm rather Microsoft averse, myself. The link to the Microsoft download is on the isocpp guidelines introduction, but my gravitational pull is back toward the guideline documentation as a point of focus.
...and I was wrong about my citation, it comes from Stroustrup's "Tour of C++", 2nd edition - and he references the GSL and it's namespace somewhat liberally in that text.
Microsoft's "ownership" of that GSL library is technically true, but rather "non-Microsoft" behavior relative to their past. They've "turned a new leaf", as it were, on open source software, and are participating with the C++ standards committees and on non Windows development with their tools and languages more than I would ever have expected.
I still approach Microsoft according to advise I read years ago about doing business with them. To paraphrase, if you shake hands with Microsoft, make sure you get all your fingers back.
I would argue that Microsoft is curating the GSL library you see, but I don't think they are the true origin of the work at large. It is open source. I accept it mainly because Stroustrup has his hand on it, references it, suggests it, and....it does make sense.
You may want to review the 2nd edition of "A Tour of C++" if you haven't already.
While I regard myself as a professional, having done this work since the late (late) 70's, I submit that all programmers and software engineers are autodidacts beyond college, lest they remain skilled only as frozen in the time they graduated. C++ didn't even exist in my early years, and I had incorporated my consulting firm, landed my first fortune 500 contract, fathered to girls, then approached divorce before C++ was generally regarded as even existing in the industry (late 80's).
It will happen again, repeatedly, without end in sight, that new languages and language features emerge regularly, and so we study, without end.
I submit the key differentiation of "professional" developers is commitment to the engineering practices, and, of course, the nature of being paid. I know many "professionals", or so self declared, who have no idea what professionalism is, and may well be regarded as stuck in a previous era.
However, there is an opposing problem I see in discussions everywhere you would do well to avoid. Way too many are over-focused on the latest version release of the language(s). At this point we should all have a firm grip on C++17. The compilers are compliant, and 17 was a small, incremental advance over 14, which itself wasn't a huge jump beyond 11. C++11 was the huge jump, and it took several years for all of the compilers to become fully compliant. It is, now, aged (well, too).
C++20 is a big jump. There are no compliant compilers. It makes no sense to over-focus on it until compiler compliance is possible. Of course, the people working on those compilers had better be focused as their primary objective, but that's not most of us.
All of these advancements were intended and designed for gradual, incremental incorporation into existing practice. If you're a student just now becoming competent, you probably began with C++11 and maybe C++14 in full view. Many of us come from a time decades before then. We know full well C++20 features will be incorporated in new code starting in mid to late 2020, but that's the earliest.
Even then, many will just at that point finally master C++17's minor additions, and lots of code will be in use (and relied upon) from much earlier epochs.
GSL is good stuff, and it actually follows what Stroustrup introduces in the "Principles" book - some convenience features worthy of your consumption.
Do you know boost?
A lot of what we know regard as the C++ 11 standard library components migrated from boost first.
There are way too many libraries in boost to consider all of it for your use. It is great to have around, though, so keep an updated build of it handy (a good portion of it is header only, but some must be built).