>the full bower checker in C++ approach is incompatible with all current C++ Circle is an implementation of C++ that includes a borrow checker and is 100% backwards compatible with C++: https://www.circle-lang.org/site/index.html
That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code. a nice attempt but I have millions of lines of c++ that isn't going away-
"C++ isn't really backward compatible with C because to take advantage of its classes and templates you need to change so much code..."
>the full bower checker in C++ approach is incompatible with all current C++ Circle is an implementation of C++ that includes a borrow checker and is 100% backwards compatible with C++: https://www.circle-lang.org/site/index.html
That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code. a nice attempt but I have millions of lines of c++ that isn't going away-
Circle is 100% backward compatible with C++. That is a technical property of the language.
You are welcome to take your millions of lines of C++ code and it will compile without change using Circle as any valid C++ code is valid Circle code, which is the technical definition of being backward compatible.
You don't need to change existing code to use Circle or the new features Circle introduces, you can just write new classes and functions with those features and your existing code will continue to compile as-is.
While I sort of agree on the complaint, personally I think the best spot of C++ in this ecosystem is still on great backward-compatibility and marginal safety improvements. I would never expect our 10M+ LOC performance-sensive C++ code base to be formally memory safe, but so far only C++ allowed us to maintain it for 15 years with partial refactor and minimal upgrade pain.
I think at least Go and Java have as good backwards compatibility as C++. Most languages take backwards compatibility very seriously. It was quite a surprise to me when Python broke so much code with the 3.12 release. I think it's the exception.
I don't know about go, but java is pathetic. I have 30 years old c++ programs that work just fine.
However, an application that I had written to be backward compatible with java 1.4, 15 years ago, cannot be compiled today. And I had to make major changes to have it run on anything past java 8, ~10 years ago, I believe.
The C++ Core Guidelines have existed for nearly 10 years now. Despite this, not a single implementation in any of the three major compilers exists that can enforce them. Profiles, which Bjarne et al have had years to work on, will not provide memory safety[0]. The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. However, it's already too late.…
I hoped Sean would open source Circle. It seemed promising, but it's been years and don't see any tangible progress. Maybe I am not looking hard enough?
He's looking to sell Circle. That must be the reason he's not open sourcing it.
That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code. a nice attempt but I have millions of lines of c++ that isn't going away-
Circle is 100% backward compatible with C++. That is a technical property of the language. You are welcome to take your millions of lines of C++ code and it will compile without change using Circle as any valid C++ code is valid Circle code, which is the technical definition of being backward compatible. You don't need to change existing code to use Circle or the new features Circle introduces, you can just write new…
You don't get the advantages of circle if you are constantly dealing with code that is returning raw pointers you have to deallocate. Or APIs where you need to pass in an index which the called function then uses vectors operator []. Safe C++ (from the same guy from what I can tell) only is safe if you used std2 containers, and otherwise rewrite your C++ entirely. Sure the world would be better if we did, but that would cost billions of dollars so it isn't happening. What we need is a way to introduce some safety into code that already exists without spending billions and a lot of time to rewrite it.
That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code. a nice attempt but I have millions of lines of c++ that isn't going away-
"C++ isn't really backward compatible with C because to take advantage of its classes and templates you need to change so much code..."
That is not backward compatibility. In the real world people mix C and C++ all the time without a lot of complex rewriting. Most of the time they don't even write a wrapper around the C, or if they do it is a easy/thin wrapper (generally you take a function returning a pointer you have to delete and make it a smart pointer), not a deep rewrite of the C code.
All my efforts to do the above so I can mix C++ and Rust have quickly failed when I realized that my wrappers would not be thing, and thus they would cost large performance penalties.
"C++ isn't really backward compatible with C because to take advantage of its classes and templates you need to change so much code..."
That is not backward compatibility. In the real world people mix C and C++ all the time without a lot of complex rewriting. Most of the time they don't even write a wrapper around the C, or if they do it is a easy/thin wrapper (generally you take a function returning a pointer you have to delete and make it a smart pointer), not a deep rewrite of the C code. All my efforts to do the above so I can mix C++ and Rust ha…
The cxx crate offers partial interop between C++ and Rust - for example, it wraps the C++ unique_ptr (the "take a pointer you have to delete and make it a smart pointer" abstraction) so Rust can make use of it appropriately. It's nowhere near complete, but they do welcome patches and issue reports. Anyway, this isn't even all that relevant to Circle and Safe C++, that can potentially share more with C++ than Rust does, such as avoiding a separate heap abstraction so that Safe C++ might be able to free objects that were allocated in legacy C++ code, etc.
Circle is 100% backward compatible with C++. That is a technical property of the language. You are welcome to take your millions of lines of C++ code and it will compile without change using Circle as any valid C++ code is valid Circle code, which is the technical definition of being backward compatible. You don't need to change existing code to use Circle or the new features Circle introduces, you can just write new…
You don't get the advantages of circle if you are constantly dealing with code that is returning raw pointers you have to deallocate. Or APIs where you need to pass in an index which the called function then uses vectors operator []. Safe C++ (from the same guy from what I can tell) only is safe if you used std2 containers, and otherwise rewrite your C++ entirely. Sure the world would be better if we did, but that wo…
By your standard C++11 isn't backward compatible with C++98.