3 ms·

Lot of stawman arguments.

by uecker 2mo ago

embedding-shape 2mo ago
Wouldn't be a authentic pjmlp comment unless they shit on C/C++ and/or praise Java/.NET with a bunch of straw-men :)
- pjmlp 2mo ago
  How wrong you are, C++ isn't in the same league as C, Microsoft was right not wanting to keep updating their C support. It was already outdated by the time Borland released Turbo C++ 1.0 for MS-DOS, and only got new wind thanks to GNU FOSS and their manifest to prefer C as the main compiled language for GNU projects. Everywhere else outside UNIX, was going with a mix of C++ for OS frameworks, Apple, Microsoft, IBM, Be, Nokia, Epoch,.... Naturally given the option, between C, C++ and something else I might prefer that something else, however I managed a few interesting positions exactly due to my C++ skills, and interests. So don't mix my preferences for C and C++ on the same basket.
  - embedding-shape 2mo ago
    Wouldn't trade it for anything <3 Enjoy your Tuesday mate :) > So don't mix my preferences for C and C++ on the same basket. That mistake is mine indeed, I'll remember. Thanks, and I hope "no harm meant" was implicit :)
    - gchamonlive 2mo ago
      > Wouldn't be a authentic pjmlp comment unless... > and I hope "no harm meant" was implicit :) Ad hominen then an apology, mixed signals here or I'm missing something. Maybe sarcasm?
      - throwlifeaway 2mo ago
        > Ad hominen then an apology, mixed signals here or I'm missing something. Maybe sarcasm? You can express annoyance at someone's pattern of behavior without it being personal. embedding-shape isn't the only person annoyed by pjmlp's repeated disdain and snark towards people who use C (or Zig or WebAssembly or Rust or...).
        gchamonlive 2mo ago
        I didn't see snark prior to being provoked, but this seems like a discussion with history beyond this scope so I think I'd better sit this out
        pjmlp 2mo ago
        Usually I reply in the same tone as I get talked with, I have no qualms with touchy feeling culture of modern times.
        gchamonlive 2mo ago
        That explains the escalations
        throwlifeaway 2mo ago
        > Usually I reply in the same tone as I get talked with No, you're usually the initiator. Usually it's with some off-hand quip about how C programmers don't understand C, or how the people designing WebAssembly are ignorant of COM or the JVM, or how Zig is just Modula-2, etc. Most threads you participate in aren't filled with snark until you enter them.
        pjmlp 2mo ago
        You can chose no to reply, you do reply, I answer in the appropriate tone.
      - embedding-shape 2mo ago
        Yeah, original/parent comment I wrote with a twinkle in my eye (hard to communicate though), hoping that the smiley at the end conveyed it, but I might have replaced ; with : mistakenly. I think many of us throughout the years been reading pjmlp's comments which fits a certain "theme". I don't mind though, it's just text after all, but was hard to keep myself from entering the meta-conversation when the opportunity just sat there. I still don't mean no harm by it, we all have our less agreeable ways of writing our comments, I'm surely guilty of it in some way too.
        gchamonlive 2mo ago
        I understand now this is old gripe, and we are all to blame for this guilty pleasure I think :)
pjmlp 2mo ago
Really?! That is how many in C circles, including your regular comments to my comments happen to be like. Two measures two weights, in C versus other systems languages.
- uecker 2mo ago
  Maybe provide a concrete example instead of making vague accusations. Or rather, please not, it is not a useful discourse. A productive response to my comment would be an insightful explanation of how byte-level access to memory objects is done in other languages.
  - muvlon 2mo ago
    > explanation of how byte-level access to memory objects is done in other languages. I'm not pjmlp but I can explain this for the case of Rust, where this works a bit like C but with a few interesting differences. Mainly, in Rust there is not a concept of a "memory object" per se in the runtime semantics. Memory is made of allocations and allocations are made of bytes. Unlike C, bytes are guaranteed to be 8 bits in size. Every byte of memory can hold integer values (0x00 to 0xff), pieces of a pointer or be uninitialized. That means there is nothing like strict aliasing, and therefore no need to have special rules for byte-level access. You can alias any type as any other type, so long as you avoid all the other sources of UB (out-of-bounds access, uninitialized memory access etc.). The way to practically access this is much the same as in C. You can do things like cast pointers between different types and project a pointer to a struct to a pointer to one of its fields. It should be noted that, unlike with major C implementations, structs do not have a stable, well-defined layout, so if you do manual pointer math you need to put #[repr(C)] on the struct to get C layout rules (which might still yield platform-dependent field offsets, e.g. size_t is not the same size everywhere). Note also that these are the dynamic rules of Rust, you need to follow these when writing unsafe code to avoid UB. The static rules of safe Rust are much more restrictive and don't allow much at all. It is possible to write unsafe code that exposes safe abstractions for this, one example is the "bytemuck" crate. It provides macros that can parse a type definition to check certain properties (e.g. well-defined layout, no padding) and then provide you with safe functions for byte-level access. Since there is no strict aliasing, for certain types you can also get safe functions for access at other granularities. For example: #[repr(C)] struct Foo { x: u32, y: u16, z: u16 } can be safely accessed as an array of u32 values (uint32_t in C), but #[repr(C)] struct Bar { x1: u16, x2: u16, y: u16, z: u16 } can not, for alignment reasons.

Lot of stawman arguments.

by uecker 2mo ago

Lot of stawman arguments.

embedding-shape 2mo ago

Wouldn't be a authentic pjmlp comment unless they shit on C/C++ and/or praise Java/.NET with a bunch of straw-men :)

pjmlp 2mo ago
How wrong you are, C++ isn't in the same league as C, Microsoft was right not wanting to keep updating their C support. It was already outdated by the time Borland released Turbo C++ 1.0 for MS-DOS, and only got new wind thanks to GNU FOSS and their manifest to prefer C as the main compiled language for GNU projects. Everywhere else outside UNIX, was going with a mix of C++ for OS frameworks, Apple, Microsoft, IBM, Be, Nokia, Epoch,.... Naturally given the option, between C, C++ and something else I might prefer that something else, however I managed a few interesting positions exactly due to my C++ skills, and interests. So don't mix my preferences for C and C++ on the same basket.
- embedding-shape 2mo ago
  Wouldn't trade it for anything <3 Enjoy your Tuesday mate :) > So don't mix my preferences for C and C++ on the same basket. That mistake is mine indeed, I'll remember. Thanks, and I hope "no harm meant" was implicit :)
  - gchamonlive 2mo ago
    > Wouldn't be a authentic pjmlp comment unless... > and I hope "no harm meant" was implicit :) Ad hominen then an apology, mixed signals here or I'm missing something. Maybe sarcasm?
    - throwlifeaway 2mo ago
      > Ad hominen then an apology, mixed signals here or I'm missing something. Maybe sarcasm? You can express annoyance at someone's pattern of behavior without it being personal. embedding-shape isn't the only person annoyed by pjmlp's repeated disdain and snark towards people who use C (or Zig or WebAssembly or Rust or...).
      - gchamonlive 2mo ago
        I didn't see snark prior to being provoked, but this seems like a discussion with history beyond this scope so I think I'd better sit this out
      - pjmlp 2mo ago
        Usually I reply in the same tone as I get talked with, I have no qualms with touchy feeling culture of modern times.
        gchamonlive 2mo ago
        That explains the escalations
        throwlifeaway 2mo ago
        > Usually I reply in the same tone as I get talked with No, you're usually the initiator. Usually it's with some off-hand quip about how C programmers don't understand C, or how the people designing WebAssembly are ignorant of COM or the JVM, or how Zig is just Modula-2, etc. Most threads you participate in aren't filled with snark until you enter them.
        pjmlp 2mo ago
        You can chose no to reply, you do reply, I answer in the appropriate tone.
    - embedding-shape 2mo ago
      Yeah, original/parent comment I wrote with a twinkle in my eye (hard to communicate though), hoping that the smiley at the end conveyed it, but I might have replaced ; with : mistakenly. I think many of us throughout the years been reading pjmlp's comments which fits a certain "theme". I don't mind though, it's just text after all, but was hard to keep myself from entering the meta-conversation when the opportunity just sat there. I still don't mean no harm by it, we all have our less agreeable ways of writing our comments, I'm surely guilty of it in some way too.
      - gchamonlive 2mo ago
        I understand now this is old gripe, and we are all to blame for this guilty pleasure I think :)

pjmlp 2mo ago

Really?! That is how many in C circles, including your regular comments to my comments happen to be like. Two measures two weights, in C versus other systems languages.

uecker 2mo ago
Maybe provide a concrete example instead of making vague accusations. Or rather, please not, it is not a useful discourse. A productive response to my comment would be an insightful explanation of how byte-level access to memory objects is done in other languages.
- muvlon 2mo ago
  > explanation of how byte-level access to memory objects is done in other languages. I'm not pjmlp but I can explain this for the case of Rust, where this works a bit like C but with a few interesting differences. Mainly, in Rust there is not a concept of a "memory object" per se in the runtime semantics. Memory is made of allocations and allocations are made of bytes. Unlike C, bytes are guaranteed to be 8 bits in size. Every byte of memory can hold integer values (0x00 to 0xff), pieces of a pointer or be uninitialized. That means there is nothing like strict aliasing, and therefore no need to have special rules for byte-level access. You can alias any type as any other type, so long as you avoid all the other sources of UB (out-of-bounds access, uninitialized memory access etc.). The way to practically access this is much the same as in C. You can do things like cast pointers between different types and project a pointer to a struct to a pointer to one of its fields. It should be noted that, unlike with major C implementations, structs do not have a stable, well-defined layout, so if you do manual pointer math you need to put #[repr(C)] on the struct to get C layout rules (which might still yield platform-dependent field offsets, e.g. size_t is not the same size everywhere). Note also that these are the dynamic rules of Rust, you need to follow these when writing unsafe code to avoid UB. The static rules of safe Rust are much more restrictive and don't allow much at all. It is possible to write unsafe code that exposes safe abstractions for this, one example is the "bytemuck" crate. It provides macros that can parse a type definition to check certain properties (e.g. well-defined layout, no padding) and then provide you with safe functions for byte-level access. Since there is no strict aliasing, for certain types you can also get safe functions for access at other granularities. For example: #[repr(C)] struct Foo { x: u32, y: u16, z: u16 } can be safely accessed as an array of u32 values (uint32_t in C), but #[repr(C)] struct Bar { x1: u16, x2: u16, y: u16, z: u16 } can not, for alignment reasons.