4 ms·

this is basically an updated version of iso646.h [https://en.wikipedia.org/wiki/C_alternative_tokens https://en.wikipedia.org/wiki/C_alternative_tokens] ...an

this is basically an updated version of iso646.h [https://en.wikipedia.org/wiki/C_alternative_tokens https://en.wikipedia.org/wiki/C_alternative_tokens] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.

ci5er 10y ago
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases. Thoughts?
- steveklabnik 10y ago
  > specific bit manipulation Rust absolutely lets you work at the bit level, you can shift and mask just like in C. > explicit memory management It depends on what you mean by "explicit" here. Most Rust code has scope-based memory management, but you can also call malloc/free within an unsafe block.
  - ci5er 10y ago
    > but you can also call malloc/free within an unsafe block. Very cool. I was afraid I would be forced into an FFI type scenario (which Rust apparently has good support for anyway). Thanks!
    - steveklabnik 10y ago
      No problem. To elaborate on _this_ slightly, today in stable Rust you can call libc's malloc/free directly. There's also the Rust alloc::heap module, but it's not yet stable, and so is only available on nightly Rust https://doc.rust-lang.org/alloc/heap/index.html https://doc.rust-lang.org/alloc/heap/index.html
      - ci5er 10y ago
        Cool. I didn't even find either of those on the roadmap a bit over year ago when I looked at it -- outside some speculative chat on forums/lists/tickets. It seems as if I need to give it a couple more months and give it a look-see again.
- kbaker 10y ago
  Sorry, you should do more research... :) Rust has great support for very low level operations. Maybe search for 'bitwise operators' or 'inline assembly'. Memory management is even more explicit and strict than C, since you also have to deal with lifetimes and borrowing. The best thing is, though, since Rust is such a young language, you can change it! Imagine trying to add a new language feature to C, something like the ? operator currently being evaluated for addition in Rust. It would take years, if not decades, to get those things in C. Even now MSVC is just rolling out support for C99. I can definitely see Rust taking over C's current place in the market over the next decade or two. Better memory safety, higher-level constructs to improve productivity, more cross-platform compatibility, and modern libraries to deal with things like Unicode are a huge draw.
  - ci5er 10y ago
    Sounds like I should! Thanks!

ci5er 10y ago

Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases. Thoughts?

steveklabnik 10y ago
> specific bit manipulation Rust absolutely lets you work at the bit level, you can shift and mask just like in C. > explicit memory management It depends on what you mean by "explicit" here. Most Rust code has scope-based memory management, but you can also call malloc/free within an unsafe block.
- ci5er 10y ago
  > but you can also call malloc/free within an unsafe block. Very cool. I was afraid I would be forced into an FFI type scenario (which Rust apparently has good support for anyway). Thanks!
  - steveklabnik 10y ago
    No problem. To elaborate on _this_ slightly, today in stable Rust you can call libc's malloc/free directly. There's also the Rust alloc::heap module, but it's not yet stable, and so is only available on nightly Rust https://doc.rust-lang.org/alloc/heap/index.html https://doc.rust-lang.org/alloc/heap/index.html
    - ci5er 10y ago
      Cool. I didn't even find either of those on the roadmap a bit over year ago when I looked at it -- outside some speculative chat on forums/lists/tickets. It seems as if I need to give it a couple more months and give it a look-see again.
kbaker 10y ago
Sorry, you should do more research... :) Rust has great support for very low level operations. Maybe search for 'bitwise operators' or 'inline assembly'. Memory management is even more explicit and strict than C, since you also have to deal with lifetimes and borrowing. The best thing is, though, since Rust is such a young language, you can change it! Imagine trying to add a new language feature to C, something like the ? operator currently being evaluated for addition in Rust. It would take years, if not decades, to get those things in C. Even now MSVC is just rolling out support for C99. I can definitely see Rust taking over C's current place in the market over the next decade or two. Better memory safety, higher-level constructs to improve productivity, more cross-platform compatibility, and modern libraries to deal with things like Unicode are a huge draw.
- ci5er 10y ago
  Sounds like I should! Thanks!