4 ms·

I realize that almost every language could be described as a subset of C++, but I read articles like this and think... Deterministic language that has type inf

I realize that almost every language could be described as a subset of C++, but I read articles like this and think... Deterministic language that has type inference, C interop, and uses ownership to govern object lifetimes? We have that. It's C++11. auto with std::unique_ptr and std::move(). Only slightly serious. ;-)

sitkack 9y ago
So Carp could compile to that subset of C++. But C++11 isn't _just_ that. It is all of C++11. C++ would even more successful if it was easy to make a proper subset of it.
- geokon 9y ago
  That's what the GSL was supposed to be https://github.com/Microsoft/GSL https://github.com/Microsoft/GSL It seemed really cool. All compile time checks. I have no idea why it didn't take off
  - pjmlp 9y ago
    Sure it did. Some of the new C++17 library updates come from there, and both clang and VC++ implement those static checks.
    - geokon 9y ago
      I've only have a pretty basic understanding of how it works, but I thought the checks didn't rely on the compiler. They're special templates that fail when their conditions aren't met And when I say it didn't take off - I mean that I haven't come across a single large project that has take up using the GSL. Hope I'm wrong - maybe I just haven't looked in the right place?
      - pjmlp 9y ago
        No, GSL is a kind of stop-gap solution, until standard catches on. For example std::string_view and ongoing design on std::array_view are based on gsl::span. The gsl::byte is also no longer needed on C++17 thanks to std::byte as yet another example. The GSL asserts are there until code contracts[0] get into the standard. The magical types like gsl::owner allow clang-tidy and VC++ checkers to apply a Rust-like memory tracking usage. Kate Gregory did a presentation at CppCon 2017. "10 Core Guidelines You Need to Start Using Now" https://www.youtube.com/watch?v=XkDEzfpdcSg https://www.youtube.com/watch?v=XkDEzfpdcSg As for not taking off, being initially a Microsoft proposal, it is surely used by Office and Windows teams, specially given they already use SDL (Security Definition Language) macros as well. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054...
  - duneroadrunner 9y ago
    The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end when it comes to memory safety. In fact it formalizes the depenedency on intrinsically unsafe elements like native pointers, std::shared_ptr, etc. I mean, with "regular" C++ you're not actually obligated to use those intrinsically unsafe elements. With the Core Guidelines you are. SaferCPlusPlus[1] is an alternative subset of C++ that doesn't have that same problem. It achieves memory safety by simply excluding the intrinsically unsafe elements and providing memory-safe alternatives. > All compile time checks. Not quite in reality. One small issue with the GSL, for example, is that its not_null pointer class does a run-time check on every pointer dereference[2]. SaferCPlusPlus can enforce "not null"ness at compile-time. A bigger example, for instance, is the situation where you want to allow multiple threads to simultaneously modify different parts of an array. With SaferCPlusPlus, this is straightforward and safe [3]. With the GSL/Core Guidelines, less so. I don't know how much these technical considerations factor into (or will factor into) popularity of adoption. I don't know how big the intersection is of the sets of developers who take code safety seriously and those who remain interested in C++. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b9315911ef6aa210df7d1e31/include/gsl/pointers#L93 https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b93159... [3] https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40f7b3cf13cbfe6c8ec690e6d172fc1632c1/msetl_example2.cpp#L402 https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40...

sitkack 9y ago

So Carp could compile to that subset of C++. But C++11 isn't _just_ that. It is all of C++11. C++ would even more successful if it was easy to make a proper subset of it.

geokon 9y ago
That's what the GSL was supposed to be https://github.com/Microsoft/GSL https://github.com/Microsoft/GSL It seemed really cool. All compile time checks. I have no idea why it didn't take off
- pjmlp 9y ago
  Sure it did. Some of the new C++17 library updates come from there, and both clang and VC++ implement those static checks.
  - geokon 9y ago
    I've only have a pretty basic understanding of how it works, but I thought the checks didn't rely on the compiler. They're special templates that fail when their conditions aren't met And when I say it didn't take off - I mean that I haven't come across a single large project that has take up using the GSL. Hope I'm wrong - maybe I just haven't looked in the right place?
    - pjmlp 9y ago
      No, GSL is a kind of stop-gap solution, until standard catches on. For example std::string_view and ongoing design on std::array_view are based on gsl::span. The gsl::byte is also no longer needed on C++17 thanks to std::byte as yet another example. The GSL asserts are there until code contracts[0] get into the standard. The magical types like gsl::owner allow clang-tidy and VC++ checkers to apply a Rust-like memory tracking usage. Kate Gregory did a presentation at CppCon 2017. "10 Core Guidelines You Need to Start Using Now" https://www.youtube.com/watch?v=XkDEzfpdcSg https://www.youtube.com/watch?v=XkDEzfpdcSg As for not taking off, being initially a Microsoft proposal, it is surely used by Office and Windows teams, specially given they already use SDL (Security Definition Language) macros as well. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054...
- duneroadrunner 9y ago
  The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end when it comes to memory safety. In fact it formalizes the depenedency on intrinsically unsafe elements like native pointers, std::shared_ptr, etc. I mean, with "regular" C++ you're not actually obligated to use those intrinsically unsafe elements. With the Core Guidelines you are. SaferCPlusPlus[1] is an alternative subset of C++ that doesn't have that same problem. It achieves memory safety by simply excluding the intrinsically unsafe elements and providing memory-safe alternatives. > All compile time checks. Not quite in reality. One small issue with the GSL, for example, is that its not_null pointer class does a run-time check on every pointer dereference[2]. SaferCPlusPlus can enforce "not null"ness at compile-time. A bigger example, for instance, is the situation where you want to allow multiple threads to simultaneously modify different parts of an array. With SaferCPlusPlus, this is straightforward and safe [3]. With the GSL/Core Guidelines, less so. I don't know how much these technical considerations factor into (or will factor into) popularity of adoption. I don't know how big the intersection is of the sets of developers who take code safety seriously and those who remain interested in C++. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b9315911ef6aa210df7d1e31/include/gsl/pointers#L93 https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b93159... [3] https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40f7b3cf13cbfe6c8ec690e6d172fc1632c1/msetl_example2.cpp#L402 https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40...