[safercplusplus]

Yeah. The provided build script produces a DEBUG executable (only). The NDEBUG version isn't tested regularly yet. But performance isn't really an issue, so the NDEBUG version has sort of been de-prioritized in favor of feature completion. The fact that it crashes at all in any mode is generally concerning (and a little ironic for this tool), but the crashes are generally due to the use of the (libtooling) clang library. Its (not-super-well-documented) interface seems to be designed for maximum speed, not safety. And I've found that some of the perhaps lesser used elements (including some used for static analysis) are just buggy, and the bugs sometimes change from version to version. But yeah, the tool is not yet in a well-tested or polished state. But I figure, even in a not-well-tested state it can only improve the safety of the code it analyzes/enforces. I mean, even if any bugs or shortcomings in the tool prevent it being able to fully achieve the design goal of ensuring that the analyzed code is completely safe, in any case it shouldn't result in the analyzed code being any less safe than without it, right?

p.s.: Despite complaining about and trying to deflect blame on the clang library, of course it is an amazing library without which none of this would be practically doable.

p.p.s.: Please don't hesitate to post any problems you encounter as an issue in the repository.

p.p.p.s.: At this point, volume is low enough that any feedback at all is welcomed as an issue in the repository.

p.p.p.p.s.: I didn't post this item. I was rather surprised to stumble upon it this morning.

[coffeeaddict1]

> I didn't post this item. I was rather surprised to stumble upon it this morning.

Hey, I posted this because I've been following your repo for quite a while. Together with Circle's borrow checker and Cpp2, I think this is a promising approach to make C++ safer although I wish the committee would be more involved in these sort of experiments (something that probably won't happen anytime soon).

[safercplusplus]

Hey thanks for your support! Committee interest might be nice, but I think what would be most helpful at this point is just additional resources in general, whether as a result of committee interest or otherwise. :)

Here's a feature comparison table that would go on the scpptool retail packaging. (HN supports mono-space font right?):

                               | scpptool |  circle  |   cpp2   |
    -------------------------------------------------------------
    |addresses lifetime safety |     Y    |     Y    |     N    |
    -------------------------------------------------------------
    |addresses iterator safety |     Y    |     Y    |     N    |
    -------------------------------------------------------------
    |supports auto-conversion  |     Y    |     N    | probably |
    |of legacy C++ code        |          |          |  doable  |
    -------------------------------------------------------------
    |reasonable support for    |     Y    |     N    |   not    |
    |cyclic references         |          |          |  safely  |
    -------------------------------------------------------------
    |works with any C++        |     Y    |     N    |     Y    |
    |compiler                  |          |          |          |
    -------------------------------------------------------------

[tialaramex]

Sure, that's certainly what such a feature comparison table would look like, a list of what you claim is great about your product, with check marks by it, and then everybody else's product doesn't have as many check marks.

But of course the reason you see these "comparison tables" on such products is that that's all they functionally are, a list of what you, the product's creator, think is great about your product, not actually a meaningful comparison.

[repelsteeltje]

> I think this is a promising approach to make C++ safer although I wish the committee would be more involved in these sort of experiments..

I'm as exited as the next guy about cpp2, circle and rust, but I'm not sure that's what the committee should focus on any time soon.

If you haven't already, take an hour or so to watch the cppnow24 keynote C++ Should Be C++ by David Sankel.