381–390 of 511 posts
Earlier quoted context omitted.
I really wish that they replace Firefox with a browser written using Servo. That'll be fun.
They're putting components from Servo inside Firefox. Servo is not yet at the point where it can full sale replace Gecko, but it's getting there.
Earlier quoted context omitted.
Not sure what to think of that. Does everything have to be async I/O now? How often do you need massive numbers of client connections?
Asynchronous nonblocking interfaces are more general-purpose than synchronous blocking interfaces. I can't speak for this library or Rust specifically, but in my experience well-designed asynchronous libraries allow you to interact with them in a synchronous style as well, if you wish. Netty is an asynchronous, event-driven network framework for Java, and it's perfectly possible to expose synchronous blocking abstrac…
Here are some papers that would normally be assigned reading in a graduate level Computer Science course in Operating Systems as background reference.
https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc7...
http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf
But like, it should be obvious: with a lightweight co-routine library you can convert anything that is synchronous into something that is asynchronous with no more if not less overhead than you would get from context switches as you are forced to incur from returning and calling a new function to implement event processing. This is no more onerous than using that same co-routine library to implement blocking on a future (to convert an asynchronous API into a synchronous one).
Earlier quoted context omitted.
> Create a vector. Push an element onto it. Take a reference to that element with operator[]. Clear the vector. Call a method on that dangling reference. > Create an object on the stack. Return a reference to that object. Call a method on that reference. References are one of the unsafe C++ elements that SaferCPlusPlus is intended to be used to replace [1]. > Create a vector. Push an element onto it. Call a method on…
> References are one of the unsafe C++ elements that SaferCPlusPlus is intended to be used to replace [1]. OK, so you can't use references. Then, as I said before, your pointer replacements have a runtime performance cost worse than GC write barriers. > Yes, that series of operations is safe. A related example from the "msetl_example.cpp" file: I don't think you understood me. I mean the this pointer. "this" is hardw…
The library provides three types of pointers - "registered", "scope" and "refcounting". I believe you are referring to the registered pointers, that indeed have significant cost on construction, destruction and assignment. But registered pointers are really mostly intended to ease the task of initially porting legacy code. New or updated code would instead use either "scope" pointers, which point to objects that have (execution) scope lifetime, or "refcounting" pointers. Scope pointers have zero extra runtime overhead, but are (at the moment) lacking the needed "static enforcer" to ensure that scope objects are indeed allocated on the stack. (Their type definition does prevent a lot of potential inadvertent misuse, but not all. And Ironclad C++ does have such a static enforcer.)
> I don't think you understood me. I mean the this pointer. "this" is hardwired into C++ to be an unsafe pointer.
You're right, that's a good point. But really it's a practical issue rather than a technical one. I mean technically, use of the "this" pointer should be replaced with a safer pointer, just like any other native pointer.
For example this is technically one of the safe ways to implement it in SaferCPlusPlus:
class CA { public:
template
void foo1(safe_this_pointer_type safe_this, safe_vector_pointer_type vec_ptr) {
vec_ptr->clear();
/* The next line will throw an exception (or whatever user specified behavior). */
safe_this->m_i += 1;
}
int m_i = 0;
}
void main() {
mse::TXScopeObj> vec1;
vec1.resize(1);
auto iter = vec1.begin();
iter->foo1(iter, &vec1);
}
So do I understand correctly that the Rust language allows for the same type of code, but the compiler won't build it unless it can statically deduce that it is safe?
> Not possible. It's totally incompatible with existing C++ designs.
Even if you prohibit the unsafe elements? Including (implicit and explicit) "this" pointers?
Earlier quoted context omitted.
It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.
Concurrently modifying aliased memory (`&` references and pointers) is undefined behavior. Not just in Rust, but in just about any language. As an aside, alias unsafety in Rust is always UB, even without concurrency.
Earlier quoted context omitted.
It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.
Any use of `unsafe` that breaks unrelated safe code is broken and buggy; if that scenario would happen like you describe it, the code is breaking Rust's aliasing rules: that's possible using `unsafe` but invalid and leads to UB.
Earlier quoted context omitted.
Why would I want to? Better to explicitly convert the number to a string.
This is something you do often in JavaScript, for example: "You have " + messages + " new messages"
print!("You have %d new messages", messages)
Earlier quoted context omitted.
In Rust, in the common case, the boiler plate you're talking about here is literally a single sigil. (Previously, it was `try!(...)`.) This is of course to say nothing about the advantages of having something that signals "this operation can return an error," (at the call site) but you seem to dismiss that out-of-hand.
I do dismiss this advantage out of hand: almost everything can fail, because most things allocate memory. It's only because Rust treats memory specially (incorrectly --- memory is just another resource) that it doesn't appear that more functions can fail. It's much more valuable to flip the sense of the annotation and mark the few functions that cannot fail in any way. Allowing most code to throw just reflects realit…
Earlier quoted context omitted.
> References are one of the unsafe C++ elements that SaferCPlusPlus is intended to be used to replace [1]. OK, so you can't use references. Then, as I said before, your pointer replacements have a runtime performance cost worse than GC write barriers. > Yes, that series of operations is safe. A related example from the "msetl_example.cpp" file: I don't think you understood me. I mean the this pointer. "this" is hardw…
> OK, so you can't use references. Then, as I said before, your pointer replacements have a runtime performance cost worse than GC write barriers. The library provides three types of pointers - "registered", "scope" and "refcounting". I believe you are referring to the registered pointers, that indeed have significant cost on construction, destruction and assignment. But registered pointers are really mostly intended…