121–130 of 140 posts
Earlier quoted context omitted.
well, yes. The nice thing is that in C++ can be implemented purely as a library. Sometimes C++ feels like the high level languages assembler.
C++ is what it is. It is "itself." I mean that in the Irish euphemism for moonshine kind of way. C++ is kind of like its own const keyword. It is what it is. const isn't immutability. It's something else. It isn't "pure" -- but it's still pretty darn useful.
Earlier quoted context omitted.
Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ comp…
>>>yes, C and C++ are more portable than LLVM C and C++ are more portable then their own compiler's backend? LLVM is clang/clang++'s assembler I get what your saying if you compile to C it can be more portable. But then you need to compile to some C standard . K&R C? ANSI C? C90? C99? C11? Why not have a compiler flag for each? What about embedded C? What companies embedded C? I can repeat this for C++ Compiling to C…
Earlier quoted context omitted.
I don't see the distinction you are suggesting. Call it a new language if you like, but if it compiles to C++, looks 99% like C++, and just smooths over the warts, then whatever you call it, that's what I'm suggesting. (I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn mor…
You're looking for some sort of code generator for C++ which only adds syntactic sugar? Interesting idea but I don't think a good one exists yet.
Earlier quoted context omitted.
It is widely speculated that pattern matching and many other syntactic enhancements are coming to C++ because of the big door that std::variant has opened.
IIRC Stroustrup mentions a desire for features such as these for versions of C++ after C++17.
Earlier quoted context omitted.
C++ is what it is. It is "itself." I mean that in the Irish euphemism for moonshine kind of way. C++ is kind of like its own const keyword. It is what it is. const isn't immutability. It's something else. It isn't "pure" -- but it's still pretty darn useful.
I have no clue what you're trying to say.
Earlier quoted context omitted.
>>>yes, C and C++ are more portable than LLVM C and C++ are more portable then their own compiler's backend? LLVM is clang/clang++'s assembler I get what your saying if you compile to C it can be more portable. But then you need to compile to some C standard . K&R C? ANSI C? C90? C99? C11? Why not have a compiler flag for each? What about embedded C? What companies embedded C? I can repeat this for C++ Compiling to C…
Lots of languages do it already. How is it impossible?
Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.
Your argument was
interoperability and portability
2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.
Also your main request
$ rustc your_program.rs --emit llvm-ir
$ llc -march=c -o your_program.c your_program.ll
$ rustc your_program.rs --emit llvm-ir
$ llc -march=cpp -o your_program.cpp your_program.llI think the example is either naive or then contrived. There's probably some behavioral changes that go with the state of the connection in which case you'd be much better served by having a State interface and then implementations for different actual states. For example: class State { ... }; class Connected : public State { ... }; std::unique_ptr state;
Earlier quoted context omitted.
Lots of languages do it already. How is it impossible?
No. Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM. Your argument was interoperability and portability 1) Rust outputs to the same object file format as C, and can be natively linked against C/C++ code. So interoperab…
Rust is not interoperable with C++ as far as I know, and even if it was, I'm not interested in Rust for this discussion for reasons I've mentioned elsewhere.
The LLVM C backend was removed. Julia devs have a version that supports the LLVM bit code that they require, but I believe it is not everything LLVM can produce.
I was under the impression that march=cpp output C++ code that rebuilt the IR, not implemented the source program.
Thanks for the advice, although none of it really applies to what I'm suggesting.
Earlier quoted context omitted.
that's interesting, AFAIK smaltalk is fully dynamic and has no compile-time type checking, so how would it statically enforce the equivalent of Send and Sync constraints?
In most implementations, Smalltalk is compiled to bytecode, and uses late binding. It's usually run on a JIT. how would it statically enforce the equivalent of Send and Sync constraints? In some Smalltalks, normal execution is synchronous. Many of them also use read and write boundaries for various purposes. The former gives you Send and Sync constraints for free. The latter can be used in difficult edge cases. (Like…
Uh, no, it gives you thread safety for free.
When my comment was talking about Send and Sync I was talking about the specific way Rust's typesystem enforces thread safety. I'm not saying that other languages don't, I'm saying that Rust's method of enforcing it might be one of the few unique things it does
Earlier quoted context omitted.
That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step. Don't compile to C.
Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ comp…
kind of paradox to say that