Ancestors

Toot

Written by Doug Gregor on 2024-11-24 at 06:50

After a long hiatus, Part 11 is about Domain Specific (Embedded) Languages and #SwiftLang Result Builders. See how to build type-safe declarative DSLs, with a distinct flavor of expression templates. https://www.douggregor.net/posts/swift-for-cxx-practitioners-dsls/

=> More informations about this toot | More toots from dgregor79@sfba.social

Descendants

Written by Doug Gregor on 2025-01-07 at 14:07

Part 12 is about move semantics, with a side of RAII and a note on the std::optional<T&> problem. #SwiftLang tackles the problem differently from C++, with "non-copyable" types providing guaranteed unique ownership. We'll also revisit the Law of Exclusivity to incorporate non-copyable types into the safety model. https://www.douggregor.net/posts/swift-for-cxx-practitioners-move/

=> More informations about this toot | More toots from dgregor79@sfba.social

Written by mqdr7h on 2024-11-24 at 09:23

@dgregor79

As a C++ software engineer with great interest in Swift, I highly appreciate your series of articles. Thanks!!

=> More informations about this toot | More toots from mqdr7h@mastodon.social

Written by Jordan on 2025-01-07 at 16:56

@dgregor79 The merge example has convinced me that reading from a file pointer should be a mutating operation. Even if the OS provides sufficient locking, sharing a file pointer just seems like something to opt into rather than getting by default—you won’t get two copies of the file that way!

=> More informations about this toot | More toots from jrose@belkadan.com

Written by d@nny mc² on 2025-01-07 at 17:01

@jrose @dgregor79 interesting to consider how this interacts with pread/readAt-style APIs. i created a wrapper which does unsafe libc calls to enable sharing a cloneable read-only handle, which need not be exclusive and enabled e.g. parallel zip file extraction https://github.com/zip-rs/zip2/pull/236. i wished rust had this built in like go does

=> More informations about this toot | More toots from hipsterelectron@circumstances.run

Written by d@nny mc² on 2025-01-07 at 17:02

@jrose @dgregor79 requires ensuring there are no write handles to the file which i'm not sure if can be done at the compiler level

=> More informations about this toot | More toots from hipsterelectron@circumstances.run

Written by Doug Gregor on 2025-01-07 at 18:36

@jrose I feel like it depends on the API design for parts I omitted. If you have some notion of the current read pointer in a file, and read starts there to read the next N bytes, then that read is mutating. If there is no such state, and you read up to N bytes from a given offset, then I think my merge is okay. Neither of these solves the issue with the underlying file system be mutated.

=> More informations about this toot | More toots from dgregor79@sfba.social

Written by Jordan on 2025-01-07 at 18:52

@dgregor79 Yeah, absolutely it’s a digression from the main point of the article!

=> More informations about this toot | More toots from jrose@belkadan.com