7 ms·

> It seems that some people are really losing the taste for good readable code. It seems that some people never had taste for good reliable code. Use `void ` a

by gignico 3mo ago

> It seems that some people are really losing the taste for good readable code. It seems that some people never had taste for good reliable code. Use `void ` and now any error whatsoever is a direct undefined behavior. Moreover `std::span` clearly says that you are not* taking ownership of the memory (even though the language does not check it of course), while `void *` does not. I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago and is such a life saver in these situations. A truly zero-cost abstraction which effectively saves you from a lot of troubles.

spacechild1 3mo ago
> but `std::span` should have been there decades ago Absolutely! I now use it consistently in all new projects where I can afford to mandate C++20. I guess nobody bothered to make a proposal before...
- pjmlp 3mo ago
  They did in C, from one of the language authors even, and it was not accepted. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.pdf https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... By the way, both Extended Pascal, Mesa/Cedar and Modula-2 have them, under the name of open arrays. Basically it took Go, C# and others for C++ to finally get its span. C probably never will.
  - spacechild1 3mo ago
    Everybody knows that C++ did not invent the concept of spans and that it was late to the party. It doesn’t change the fact that (presumably) nobody made a proposal to the C++ standard.
    - pjmlp 3mo ago
      Microsoft made the proposal for C++, after Midori project, and Office security improvements. Which by your comment, you have no clue about how it came to be. Proposal is linked in another comment of mine.
      - spacechild1 3mo ago
        Well, you could have linked an actual proposal instead of dropping some cool facts about C, Extended Pascal, Mesa/Cedar and Modula-2, as if that explained anything.
    - tialaramex 3mo ago
      > It doesn’t change the fact that (presumably) nobody made a proposal to the C++ standard. There were proposals about this for many years. C++ is just a terrible programming language, standardized by a committee (WG21) which exists in large part to boost the ego of one man, Bjarne Stroustrup. N3851 for example wants to name this idea "array_view" which like "string_view" is an impressively unwieldy name for a core language feature, because of course neither of these were actually proposed as core language features even though that's what they naturally should be -- but it is basically the slice type or as you (and modern C++) call it a "span". It's true that you can't change facts but what you've got here was a belief which was unfounded, not a fact.
      - spacechild1 3mo ago
        > There were proposals about this for many years. I wrote "presumably", but you are 100% correct. I'm always happy to be proven wrong. N3851 actually deals with multi-dimensional spans and goes way beyond a simple slice/span type. To me it seems closer to std::mdspan than std::span. The earliest proposal I could find that does propose something similar to std::span dates back to 2012: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n33... I really don't understand why this was not pursued further. At the very least, this should have made it into C++17 together with std::string_view. > because of course neither of these were actually proposed as core language features even though that's what they naturally should be Should it really? What would this even look like in C++? IMO std::span works perfectly fine as a library type. > C++ is just a terrible programming language, standardized by a committee (WG21) which exists in large part to boost the ego of one man, Bjarne Stroustrup. That's certainly not the reason why it was standardized. Pre-C++98 was wild west with every compiler offering there own (incompatible) idea of what C++ is. Yes, there are many problems with design by committee in general (and the C++ committee in particular), but there was a very good reason for standardizing the language. The committee is not a one man show and there are many occasions where Bjarne has publicly voiced his frustration and disagreement.
        tialaramex 3mo ago
        > The committee is not a one man show Of course it isn't, all the great egotists need a parade of sycophants to heap praise on them, you've doubtless seen modern US "Cabinet meetings" in which TV hosts newly elevated to run parts of the US government compete with experienced politicians as they all try to offer the most effusive praise for their snoring God King. Personally, I'd throw up, but then I'm very much of Groucho Marx's view on such things.
trumpdong 3mo ago
There's lots of UB in C-family execution models. Some of which is not actually UB because the implementation defines it - e.g. aligned DWORD-sized memory access is atomic on Windows because Microsoft said it is. By choosing to use this language you choose to navigate the UB. Otherwise you'd be writing in Go, or Python. It is possible to write reliable code despite the presence of UB in a language just like it's possible to drive to work every day for 20 years despite most of the directions you can point the car leading to an immediate crash. That's a needle with a much thinner eye than UB in C, and most people manage it. Mainly it means being very careful about lifetime and ownership. The Linux kernel manages it 99% of the time simply by being careful about lifetime and ownership, and that's a project with a huge number of contributors who don't intimately know each other's modules. I'm the Linux kernel you can't just say "new whatever" - you must have a plan for a lifetime of that whatever, and other people will review it. I agree with you about std::span.
- arcticbull 3mo ago
  Yeah but also, quick question: struct S { char c; int i; }; struct S a = {0}; struct S b = {0}; memcmp(&a, &b, sizeof(a)) == ... If you answered 0, you'd be wrong, the answer is undefined, thanks to padding, initialization and alignment rules. Padding bytes are undefined, and not guaranteed to be initialized to zero even if the variable is declared static (where the members would be zeroed). This is why the compiler is angry at the post writer, and why the reinterpret_cast is needed. Ideally if they wanted to do something with the data, they'd unbox the structure. That's why it's not a good idea to use void* to pass arbitrary data interchangeable with bytes. It's a location, it makes no representation as to what's there and how to interact with it. Let alone who owns it. std::span solves two problems here. One is the ownership problem. The other is that span<T> is a T[]. void* is god only knows. The post asserts: > The code is very clear and straightforward: you pass a pointer to the custom data structure, and its size in bytes. That’s it. Simple and clear. This is unfortunately entirely false in C thanks to the aforementioned alignment/padding UB (and of course inner pointers). This is addressed with std::span. You'd still have to reinterpret_cast your structure to get the UB. > Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine?? tl;dr: because it doesn't. It just kinda looks like it does if you squint, and it's going to lead to the gnarliest bugs in the world.
locknitpicker 3mo ago
> I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago (...) Decades is kind of a stretch. C++11 introduced smart pointers, and finally getting C++0x out of the door was already a major victory. Given the history of C++, it would be unrealistic to introduce something like std::span before C++17. Meantime, some organizations are still struggling to migrate to something like C++14.
- gignico 3mo ago
  Afaik std::span does not need anything that was not in C++98 already, or am I missing something?
  - locknitpicker 3mo ago
    > Afaik std::span does not need anything that was not in C++98 already, or am I missing something? You're missing the fact that following C++98 it took around 13 years to get the next version of the standard published delivered.
- pjmlp 3mo ago
  It could have been there since the beginning, given that open arrays (aka spans) already existed in other languages, and there was even a failed proposal from Denis Ritchie regarding C. The C++ span proposal came from Microsoft, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...
  - locknitpicker 3mo ago
    > already existed in other languages This argument is moot. The issue with spans is not that they require cutting edge technology to deliver. Before commenting, perhaps you should research why even Denis Ritchie himself could not sell his idea to C. It's funny how every single idea that's rejected is blindly lauded as brilliant but silenced due to some kind of conspiracy, and only the ideas that emerged are somehow bad, unacceptable, or late. Is the point to feel outraged?
delta_p_delta_x 3mo ago
> A truly zero-cost abstraction Sadly the MSVC ABI makes std::span and std::string_view a pessimisation: https://github.com/tringi/win64_abi_call_overhead_benchmark https://github.com/tringi/win64_abi_call_overhead_benchmark https://godbolt.org/z/7baaox7re https://godbolt.org/z/7baaox7re
- usrnm 3mo ago
  Sounds like a compiler bug to me. It is a valid reason to avoid them in some rare cases right now, but it doesn't make the feature itself bad
  - j16sdiz 3mo ago
    Those are ABI. Unless it is inlining them, the overhead is to stay.
    - usrnm 3mo ago
      ABI changes do happen. gcc had an ABI change in std::string because of C++11. It was long and painful, but everyone survived, the world did not end
      - delta_p_delta_x 3mo ago
        > ABI changes do happen Will never happen on Windows, especially not in user-mode libraries, and especially not something this pervasive.
      - pjmlp 3mo ago
        Contrary to the FOSS compile from source culture, other platforms have a different point of view on ABI breaks. Which is why Valve ended up using Proton.
        gpderetta 3mo ago
        I'm pretty sure GCC has been ABI stable far longer that MSVC which used to break ABI every release. GCC was forced to break the std::string ABI by the C++11 standard and they have been lobbing ever since against ABI breaks.
pjmlp 3mo ago
That is quite common among C developer culture, play loose and brace for impact.

by gignico 3mo ago

spacechild1 3mo ago

> but `std::span` should have been there decades ago Absolutely! I now use it consistently in all new projects where I can afford to mandate C++20. I guess nobody bothered to make a proposal before...

pjmlp 3mo ago
They did in C, from one of the language authors even, and it was not accepted. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.pdf https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... By the way, both Extended Pascal, Mesa/Cedar and Modula-2 have them, under the name of open arrays. Basically it took Go, C# and others for C++ to finally get its span. C probably never will.
- spacechild1 3mo ago
  Everybody knows that C++ did not invent the concept of spans and that it was late to the party. It doesn’t change the fact that (presumably) nobody made a proposal to the C++ standard.
  - pjmlp 3mo ago
    Microsoft made the proposal for C++, after Midori project, and Office security improvements. Which by your comment, you have no clue about how it came to be. Proposal is linked in another comment of mine.
    - spacechild1 3mo ago
      Well, you could have linked an actual proposal instead of dropping some cool facts about C, Extended Pascal, Mesa/Cedar and Modula-2, as if that explained anything.
  - tialaramex 3mo ago
    > It doesn’t change the fact that (presumably) nobody made a proposal to the C++ standard. There were proposals about this for many years. C++ is just a terrible programming language, standardized by a committee (WG21) which exists in large part to boost the ego of one man, Bjarne Stroustrup. N3851 for example wants to name this idea "array_view" which like "string_view" is an impressively unwieldy name for a core language feature, because of course neither of these were actually proposed as core language features even though that's what they naturally should be -- but it is basically the slice type or as you (and modern C++) call it a "span". It's true that you can't change facts but what you've got here was a belief which was unfounded, not a fact.
    - spacechild1 3mo ago
      > There were proposals about this for many years. I wrote "presumably", but you are 100% correct. I'm always happy to be proven wrong. N3851 actually deals with multi-dimensional spans and goes way beyond a simple slice/span type. To me it seems closer to std::mdspan than std::span. The earliest proposal I could find that does propose something similar to std::span dates back to 2012: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n33... I really don't understand why this was not pursued further. At the very least, this should have made it into C++17 together with std::string_view. > because of course neither of these were actually proposed as core language features even though that's what they naturally should be Should it really? What would this even look like in C++? IMO std::span works perfectly fine as a library type. > C++ is just a terrible programming language, standardized by a committee (WG21) which exists in large part to boost the ego of one man, Bjarne Stroustrup. That's certainly not the reason why it was standardized. Pre-C++98 was wild west with every compiler offering there own (incompatible) idea of what C++ is. Yes, there are many problems with design by committee in general (and the C++ committee in particular), but there was a very good reason for standardizing the language. The committee is not a one man show and there are many occasions where Bjarne has publicly voiced his frustration and disagreement.
      - tialaramex 3mo ago
        > The committee is not a one man show Of course it isn't, all the great egotists need a parade of sycophants to heap praise on them, you've doubtless seen modern US "Cabinet meetings" in which TV hosts newly elevated to run parts of the US government compete with experienced politicians as they all try to offer the most effusive praise for their snoring God King. Personally, I'd throw up, but then I'm very much of Groucho Marx's view on such things.

trumpdong 3mo ago

There's lots of UB in C-family execution models. Some of which is not actually UB because the implementation defines it - e.g. aligned DWORD-sized memory access is atomic on Windows because Microsoft said it is. By choosing to use this language you choose to navigate the UB. Otherwise you'd be writing in Go, or Python. It is possible to write reliable code despite the presence of UB in a language just like it's possible to drive to work every day for 20 years despite most of the directions you can point the car leading to an immediate crash. That's a needle with a much thinner eye than UB in C, and most people manage it. Mainly it means being very careful about lifetime and ownership. The Linux kernel manages it 99% of the time simply by being careful about lifetime and ownership, and that's a project with a huge number of contributors who don't intimately know each other's modules. I'm the Linux kernel you can't just say "new whatever" - you must have a plan for a lifetime of that whatever, and other people will review it. I agree with you about std::span.

arcticbull 3mo ago
Yeah but also, quick question: struct S { char c; int i; }; struct S a = {0}; struct S b = {0}; memcmp(&a, &b, sizeof(a)) == ... If you answered 0, you'd be wrong, the answer is undefined, thanks to padding, initialization and alignment rules. Padding bytes are undefined, and not guaranteed to be initialized to zero even if the variable is declared static (where the members would be zeroed). This is why the compiler is angry at the post writer, and why the reinterpret_cast is needed. Ideally if they wanted to do something with the data, they'd unbox the structure. That's why it's not a good idea to use void* to pass arbitrary data interchangeable with bytes. It's a location, it makes no representation as to what's there and how to interact with it. Let alone who owns it. std::span solves two problems here. One is the ownership problem. The other is that span<T> is a T[]. void* is god only knows. The post asserts: > The code is very clear and straightforward: you pass a pointer to the custom data structure, and its size in bytes. That’s it. Simple and clear. This is unfortunately entirely false in C thanks to the aforementioned alignment/padding UB (and of course inner pointers). This is addressed with std::span. You'd still have to reinterpret_cast your structure to get the UB. > Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine?? tl;dr: because it doesn't. It just kinda looks like it does if you squint, and it's going to lead to the gnarliest bugs in the world.

locknitpicker 3mo ago

> I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago (...) Decades is kind of a stretch. C++11 introduced smart pointers, and finally getting C++0x out of the door was already a major victory. Given the history of C++, it would be unrealistic to introduce something like std::span before C++17. Meantime, some organizations are still struggling to migrate to something like C++14.

gignico 3mo ago
Afaik std::span does not need anything that was not in C++98 already, or am I missing something?
- locknitpicker 3mo ago
  > Afaik std::span does not need anything that was not in C++98 already, or am I missing something? You're missing the fact that following C++98 it took around 13 years to get the next version of the standard published delivered.
pjmlp 3mo ago
It could have been there since the beginning, given that open arrays (aka spans) already existed in other languages, and there was even a failed proposal from Denis Ritchie regarding C. The C++ span proposal came from Microsoft, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...
- locknitpicker 3mo ago
  > already existed in other languages This argument is moot. The issue with spans is not that they require cutting edge technology to deliver. Before commenting, perhaps you should research why even Denis Ritchie himself could not sell his idea to C. It's funny how every single idea that's rejected is blindly lauded as brilliant but silenced due to some kind of conspiracy, and only the ideas that emerged are somehow bad, unacceptable, or late. Is the point to feel outraged?

delta_p_delta_x 3mo ago

> A truly zero-cost abstraction Sadly the MSVC ABI makes std::span and std::string_view a pessimisation: https://github.com/tringi/win64_abi_call_overhead_benchmark https://github.com/tringi/win64_abi_call_overhead_benchmark https://godbolt.org/z/7baaox7re https://godbolt.org/z/7baaox7re

usrnm 3mo ago
Sounds like a compiler bug to me. It is a valid reason to avoid them in some rare cases right now, but it doesn't make the feature itself bad
- j16sdiz 3mo ago
  Those are ABI. Unless it is inlining them, the overhead is to stay.
  - usrnm 3mo ago
    ABI changes do happen. gcc had an ABI change in std::string because of C++11. It was long and painful, but everyone survived, the world did not end
    - delta_p_delta_x 3mo ago
      > ABI changes do happen Will never happen on Windows, especially not in user-mode libraries, and especially not something this pervasive.
    - pjmlp 3mo ago
      Contrary to the FOSS compile from source culture, other platforms have a different point of view on ABI breaks. Which is why Valve ended up using Proton.
      - gpderetta 3mo ago
        I'm pretty sure GCC has been ABI stable far longer that MSVC which used to break ABI every release. GCC was forced to break the std::string ABI by the C++11 standard and they have been lobbing ever since against ABI breaks.

pjmlp 3mo ago

That is quite common among C developer culture, play loose and brace for impact.