Due to potential new direction of D, I’m looking for some escape route just in case. I’m primarily a gamedev, so no functional programming languages like Rust or Haskell. Also one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files, so no zig, I don’t want to open two files for editing the same class/struct. Memory safety is nice to have, but not a requirement, at worst case scenario I’ll just create struct SafeArray<Type>. Also I need optional OOP features instead of reinventing OOP with all kinds of hacks many do when I would need it.

Yes I know about OpenD, and could be a candidate for such things, just looking into alternatives.

  • Ephera@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    13 days ago

    I tried something like that once. Basically, I was trying to create an API with which sysadmins could script deployments. That involves lots of strings, so I was hoping I could avoid the String vs. &str split by making everything &'static str.

    And yeah, the problem is that this only really works within one function. If you need to pass a parameter into a function, that function either accepts a &'static reference which makes it impossible to call this function with an owned type or non-static reference, or you make it accept any reference, but then everything below that function has normal borrowing semantics again.

    I guess, with the former you could Box::leak() to pass an owned type or non-static reference, with the downside of all your APIs being weird.
    Or maybe your prototyping just happens at the top and you’re fine with making individual functions accept non-static references. I guess, you’ll still have to try it.

    Since you’re already at the bargaining stage of grief programming, maybe you’re aware, but Rc and Arc are the closest you can get to a GC-like feel. These do reference counting, so unlike GC, they can’t easily deal with cyclic references, but aside from that, same thing.
    Unfortunately, they do still have the same problem with passing them as parameters…

    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      13 days ago

      The good thing about Box::leak() is that it returns a raw *mut pointer. So you need unsafe{} to dereference it. Might as well: let my_ref = &mut unsafe{*ptr}; while you are at it, so you have a perfectly normal rust reference, so the function signatures don’t need any change.

      The problem with Rc is that it would also require a RefCell most of the time. So the whole thing would be filled with Rc<RefCell<T>>. With the required .borrow_mut(). It would both do a pain to do and undo.

      And of course I want to undo it, because RC is a shitty GC.