111–120 of 140 posts
For example:
class State { ... }; class Connected : public State { ... };
std::unique_ptr state;
Earlier quoted context omitted.
Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself?…
> Effort in this direction would be better spent just adding new features to clang (or GCC). In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source). > You'll end up wanting to just use clang's front end to help you Probably, although there are other option…
I 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.
It's in the disk buffer and monitor examples. Here's a relevant quote: "A disk buÆer is a data structure shared by two concurrent processes. The details of how such a buÆer is constructed are irrelevant to its users. All the processes need to know is that they can send and receive data through it. If they try to operate on the buÆer in any other way it is probably either a programming mistake or an example of tricky…
None of that looks like a formalisation or even a description of a data race, at least not in the modern sense.
Hansens work formalized what I just described in terms of English, diagrams, and compiler checks. He started with sequential operations on private data in modules. He says if two or more share thd same private data they might not execute in desired order. The monitor pattern enforced user-specified order on function calls to shared data. Built-in to language & compiler.
If my description of race conditions is inaccurate or insufficient, I'd appreciate a link to one that you think is more accurate that I could use as a comparison point against the Hansen paper. Otherwise, his description of problems implementing concurrency sounds exactly like what I learned in books on multithreading, supercomputing, etc. Shared resource used in incorrect order due to concurrency.
Note: Also, his colleagues Dijkstra and Hoare were still inventing and developing formal verification at the time. Tooling sucked. Standard practice, like he did with Algol and COBOL compilers, was writing things like this in precise English with code examples or diagrams. Not sure if you were expecting a HOL model or something when you said "modern" but I figured Id mention stuff was primitive then.
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…
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/C++ in a platform and standard agnostic way is impossible.
Earlier quoted context omitted.
"I agree that people have a strong tendency to not know what past work has been done, and Concurrent Pascal is admirable, but what Rust does is not the same thing. " I'm not saying it does. The claim I replied to said preventing things like data races was done till well into the 80's. I showed systematic investigations of the problem plus a production solution had been done by mid-70's. You've nicely showed how far a…
> The claim I replied to said preventing things like data races was done till well into the 80's No, it definitely didn't: it said data races as a concept seemed to not be formalised until the late 80's.
Earlier quoted context omitted.
One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…
the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s
That really depends on which Smalltalk you're talking about, I think. Various implementations really had different concurrency models. Some implementations used native OS threads. Others ran synchronously "inside the image" but spawned threads to interact with the OS.
Earlier quoted context omitted.
the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s
Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of t…
VisualWorks got the ability to make certain objects immutable sometime in the early 2000's. The VM engineers were particularly proud of that one.
Earlier quoted context omitted.
the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s
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?
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 when you're calling out to the OS.)
Isn't this just an algebraic data structure?
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.