5 ms·

> I only post to HN to plug my project called SaferCPlusPlus From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is havin

> I only post to HN to plug my project called SaferCPlusPlus From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is having a separate, project-specific account in itself not cool? > not ever to talk about the submitted article. I try to post/plug only when I think it's relevant. I think. For example, in the "gmm.pdf" linked in the comment I responded to, the author says that specific types of references can only target objects owned/allocated by the associated allocator. There is no available reference type that can target objects from different allocators. References in Rust, for example, can target any object regardless of how they were allocated, but imposes strict restrictions that the author implies he's trying to avoid. So I tried to point out that SaferCPlusPlus has pointer types that can safely target objects allocated by different allocators and do not have the strict restrictions of Rust's references. As far as I know, these types of pointers are (still) unique to SaferCPlusPlus, and I assume I am one of a few people who is familiar with these pointers. But there's nothing proprietary about them. If the author is constructing a language with a goal of flexibility wrt to memory safety, I thought he might consider whether such pointer/reference types might be compatible with his language design. I think they unquestionably increase flexibility (while maintaining memory safety).

jondgoodwin 8y ago
> There is no available reference type that can target objects from different allocators. Cone actually does support Rust-like, lifetime-constrained borrowed references which can do exactly that safely. Cone also supports raw pointers (however de-reference safety is the responsibility of the programmer). I appreciate the chance to learn about your language's unique form of reference type. I am less likely to call them safe than you, no doubt because I use a different criteria for safety. A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value with no chance of exception. I don't think your references would comply with this. A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints but, unlike with your references, they could not expect such pointers to turn into nullptr if the object they refer to has been freed. Given the nature of Cone's design, there is no way to accomplish this mechanic with decent performance, especially given that borrowed references and raw pointers are both able to point inside an allocated object. I do appreciate your bringing it to my attention and wish you all the best with getting others to learn about and adopt your language.
- duneroadrunner 8y ago
  > Cone actually does support Rust-like, lifetime-constrained borrowed references Ah, so kind of a super-set of Rust functionality. Presumably these would require a "borrow checker" or equivalent? Is that already implemented? So how do you address the safety of, say, taking a reference to an element in a (resizable) vector? Rust's "exclusivity of mutable references" restriction intrinsically makes the vector immutable while the borrowed reference exists, but do I understand that Cone doesn't have that restriction? The "C++ lifetime profile checker", on the other hand, makes the vector non-resizable (but leaves the data mutable). > A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value SaferCPlusPlus provides both a pointer that throws an exception if you attempt an invalid memory access (though it could just as easily return an optional<>, and you can always query if the target is valid), and one that terminates the program if its target is ever deallocated prematurely (and thus (technically) satisfies your criteria). (The latter has less/minimal overhead.) > A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints Or reference counting pointers or GC, right? The features needed to implement the pointers I mentioned is either support for calling a destructor on move operations or the ability to make an object non-movable, and, support for copy constructors or the ability to make an object uncopyable. Does/could your language support some combination of those features? I explain the reason the pointers are important in an article called "Implications of the Core Guidelines lifetime checker restrictions" [1]. Specifically, I give an example of reasonable C++ code [2] that historically had no corresponding efficient implementation in Safe Rust. (I think it's still the case, but I haven't fully investigated the implications of Rust's new "pinning" feature.) It can, however, be implemented in a memory safe way using the SaferCPlusPlus pointers in question [3]. Basically the example just temporarily inserts a reference to a (stack allocated) local variable into a list (or whatever dynamic container), given that the local variable does not outlive the container. > especially given that borrowed references and raw pointers are both able to point inside an allocated object SaferCPlusPlus has the equivalent of "borrowed references"[4] (though even more restricted until C++'s "borrow checker" (the aforementioned "lifetime profile checker") is completed), and they can safely point "inside" (allocated) objects. Note that the second safe pointer type (the one that potentially terminates the program), is a "strong" pointer, and there is a simple mechanism for obtaining a "borrowed reference" from a strong pointer [5]. And from there, a simple mechanism for obtaining a reference to an (interior?) member [6]. The other pointer (the one that potentially throws an exception) would be considered a "weak" pointer, and you cannot obtain a "borrowed reference" directly from a weak pointer. But often, the weak pointer is used to target an object that can yield a borrowed reference (like a strong pointer, for example), or a borrowed reference directly. > all the best with getting others to learn about and adopt your language. You too :) I can see the appeal of this sort of clean, flexible language. But in the case of SaferCPlusPlus the goal is not necessarily (just) for programmers to adopt it. In part it's maybe a demonstration (to language designers such as yourself :) of a set of language elements that use run-time safety enforcement mechanisms but are a little more flexible than (and might be a good / (unintuitively) needed complement to) their counterparts that rely on strictly compile-time safety enforcement. Oh and if you do get around to checking out SaferCPlusPlus in more depth, apologies for the inadequate documentation in advance. Feel free to post any questions you might have. :) [1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul/implications%20of%20the%20lifetime%20checker%20restrictions.md https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul/implications%20of%20the%20lifetime%20checker%20restrictions.md#snippet-4 https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [3] https://github.com/duneroadrunner/misc/blob/54204445bc099987cef6246db5b8b1ce3b4e8e06/201/8/Jul/implications1.cpp#L93 https://github.com/duneroadrunner/misc/blob/54204445bc099987... [4] https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitemfixedpointer https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitem... [5] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope_strong_pointer_store https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope... [6] https://github.com/duneroadrunner/SaferCPlusPlus#make_pointer_to_member_v2 https://github.com/duneroadrunner/SaferCPlusPlus#make_pointe...

jondgoodwin 8y ago

> There is no available reference type that can target objects from different allocators. Cone actually does support Rust-like, lifetime-constrained borrowed references which can do exactly that safely. Cone also supports raw pointers (however de-reference safety is the responsibility of the programmer). I appreciate the chance to learn about your language's unique form of reference type. I am less likely to call them safe than you, no doubt because I use a different criteria for safety. A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value with no chance of exception. I don't think your references would comply with this. A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints but, unlike with your references, they could not expect such pointers to turn into nullptr if the object they refer to has been freed. Given the nature of Cone's design, there is no way to accomplish this mechanic with decent performance, especially given that borrowed references and raw pointers are both able to point inside an allocated object. I do appreciate your bringing it to my attention and wish you all the best with getting others to learn about and adopt your language.

duneroadrunner 8y ago
> Cone actually does support Rust-like, lifetime-constrained borrowed references Ah, so kind of a super-set of Rust functionality. Presumably these would require a "borrow checker" or equivalent? Is that already implemented? So how do you address the safety of, say, taking a reference to an element in a (resizable) vector? Rust's "exclusivity of mutable references" restriction intrinsically makes the vector immutable while the borrowed reference exists, but do I understand that Cone doesn't have that restriction? The "C++ lifetime profile checker", on the other hand, makes the vector non-resizable (but leaves the data mutable). > A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value SaferCPlusPlus provides both a pointer that throws an exception if you attempt an invalid memory access (though it could just as easily return an optional<>, and you can always query if the target is valid), and one that terminates the program if its target is ever deallocated prematurely (and thus (technically) satisfies your criteria). (The latter has less/minimal overhead.) > A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints Or reference counting pointers or GC, right? The features needed to implement the pointers I mentioned is either support for calling a destructor on move operations or the ability to make an object non-movable, and, support for copy constructors or the ability to make an object uncopyable. Does/could your language support some combination of those features? I explain the reason the pointers are important in an article called "Implications of the Core Guidelines lifetime checker restrictions" [1]. Specifically, I give an example of reasonable C++ code [2] that historically had no corresponding efficient implementation in Safe Rust. (I think it's still the case, but I haven't fully investigated the implications of Rust's new "pinning" feature.) It can, however, be implemented in a memory safe way using the SaferCPlusPlus pointers in question [3]. Basically the example just temporarily inserts a reference to a (stack allocated) local variable into a list (or whatever dynamic container), given that the local variable does not outlive the container. > especially given that borrowed references and raw pointers are both able to point inside an allocated object SaferCPlusPlus has the equivalent of "borrowed references"[4] (though even more restricted until C++'s "borrow checker" (the aforementioned "lifetime profile checker") is completed), and they can safely point "inside" (allocated) objects. Note that the second safe pointer type (the one that potentially terminates the program), is a "strong" pointer, and there is a simple mechanism for obtaining a "borrowed reference" from a strong pointer [5]. And from there, a simple mechanism for obtaining a reference to an (interior?) member [6]. The other pointer (the one that potentially throws an exception) would be considered a "weak" pointer, and you cannot obtain a "borrowed reference" directly from a weak pointer. But often, the weak pointer is used to target an object that can yield a borrowed reference (like a strong pointer, for example), or a borrowed reference directly. > all the best with getting others to learn about and adopt your language. You too :) I can see the appeal of this sort of clean, flexible language. But in the case of SaferCPlusPlus the goal is not necessarily (just) for programmers to adopt it. In part it's maybe a demonstration (to language designers such as yourself :) of a set of language elements that use run-time safety enforcement mechanisms but are a little more flexible than (and might be a good / (unintuitively) needed complement to) their counterparts that rely on strictly compile-time safety enforcement. Oh and if you do get around to checking out SaferCPlusPlus in more depth, apologies for the inadequate documentation in advance. Feel free to post any questions you might have. :) [1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul/implications%20of%20the%20lifetime%20checker%20restrictions.md https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul/implications%20of%20the%20lifetime%20checker%20restrictions.md#snippet-4 https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [3] https://github.com/duneroadrunner/misc/blob/54204445bc099987cef6246db5b8b1ce3b4e8e06/201/8/Jul/implications1.cpp#L93 https://github.com/duneroadrunner/misc/blob/54204445bc099987... [4] https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitemfixedpointer https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitem... [5] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope_strong_pointer_store https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope... [6] https://github.com/duneroadrunner/SaferCPlusPlus#make_pointer_to_member_v2 https://github.com/duneroadrunner/SaferCPlusPlus#make_pointe...