[HN Gopher] C++20 Ranges Algorithms - 7 Non-Modifying Operations
___________________________________________________________________
C++20 Ranges Algorithms - 7 Non-Modifying Operations
Author : ibobev
Score : 43 points
Date : 2022-04-25 16:58 UTC (6 hours ago)
(HTM) web link (www.cppstories.com)
(TXT) w3m dump (www.cppstories.com)
| pavon wrote:
| This is nice short-hand that I've wanted for a while. I do wish
| they would have made them overloads of the existing functions in
| the same namespace, rather than in a new ranges namespace. Oh
| well, you can always use that namespace, and even if you don't
| "::ranges" is still less typing than "begin(), end()".
| beojan wrote:
| You can always do something like
|
| namespace rng = std::ranges;
| curiousgal wrote:
| I'd be curiously to see how many people actually use modern C++
| professionally. I've always been under the impression that
| adoption of the standard lags behind by like 7 years or so.
| pavlov wrote:
| I wrote C++ at Facebook last year and got to use C++20 features
| like ranges.
|
| It wasn't my call, though. Meta has a relatively big C++ infra
| team that participates in the standards committee, maintains
| the Folly utility library, and decides how complex new features
| like coroutines are adopted. On top of that, my code plugged
| into another team's system, and they had written their own
| guidelines on how/if they want to use specific C++ and Folly
| features.
|
| These guardrails were really useful for a C fossil like me with
| an on-off relationship to C++... It's not a terrible language
| anymore, but it's even harder than before to find the right
| subset. At least boost can be finally buried.
| duped wrote:
| The last time I used C++20 features (modules) I caused a
| segfault in GCC. This was in December, iirc it was GCC 11.
| pjmlp wrote:
| Right now VC++ is the only viable option for C++20 modules,
| and even it isn't without warts.
| tialaramex wrote:
| It is kind of crazy that JTC1 is OK with producing entirely
| imaginary documents. Do you think the two standards bodies
| _know_ that the product of WG21 is just pieces of paper
| with no idea whether they can be or will be implemented? Or
| is this all far above what anybody senior at ISO or the IEC
| understands because they aren 't programmers?
|
| Even at W3C you were expected (when I had anything to do
| with it) to actually build the prototype before you publish
| the standard, and obviously the IETF's "Rough Consensus and
| Running Code" speaks to that way of thinking too.
|
| I feel like if ISO 216 claimed you can fold a _square_ 1x1
| metre piece of paper in half and preserve the proportions,
| that wouldn 't have survived into a published document.
| Sure you can _write_ that claim, but you cannot actually
| make that fold, it 's surely amazing that the C++ Committee
| are not subject to the same consideration and yet here we
| are.
| mhh__ wrote:
| They do reject things based on implementation difficulty
| too. "Static if considered" rejects it on the basis that
| the implementations would struggle.
| Kranar wrote:
| Not really, it had nothing to do with implementation
| difficulty and the paper actually states that
| implementing static if would be fairly easy:
|
| http://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2013/n361...
|
| What the paper says is that static if would make it much
| harder to perform static analysis of source code, not
| really because it's hard to implement but because the
| kind of combinatorial explosion introduced by having non-
| local bifurcating source code branches to analyze makes
| analysis incredibly slow.
|
| C++ did eventually adopt if constexpr, which does not
| have this problem since the branches are always local.
| mhh__ wrote:
| if constexpr is the static if we have at home. It's
| rubbish.
| pjmlp wrote:
| On the contrary, what is happening is the hard reality of
| MIT based compilers when downstream doesn't care about
| improving upstream language compliance.
|
| clang is trailing C++20, since Apple and Google stop
| caring to be first line contributors.
|
| GCC is actually not that far behind VC++.
|
| And regarding building prototypes, VC++ modules
| implementation was the prototype.
| gotaquestion wrote:
| I see a lot of it in the academic AI world, mostly because as
| students move from Python (study) to real-world deployments,
| they need to convert to C++ for performance. Hence, over the
| past decade I've seen C++ start to look more like a
| transliteration of Python, and be used that way.
|
| The fact that TensorFlow on Python can use GPUs/TPUs is a no-
| brainer, but that only works in the server center and not in
| the field.
| jcelerier wrote:
| I generally start using -std=c++XX switches in compilers before
| the standards are actually released ; I don't remember the last
| time I've seen a project that wasn't at least c++17
| wyldfire wrote:
| LLVM itself has only just now green-lit using c++17 [1] so I
| find myself using c++14 most of the time.
|
| [1] https://discourse.llvm.org/t/important-new-toolchain-
| require...
| jcelerier wrote:
| You are seriously missing out. C++17 has worked fine for
| years with clang - and I wouldn't ever go back to writing
| sfinae code since c++20 concepts are there, it's a massive
| simplification; likewise for structured bindings (for(auto&
| [k,v] : map)), if constexpr, ...
| GuB-42 wrote:
| That's about right in my case. 2019 was more or less the years
| we switched to C++11. Some projects started using C++11 way
| earlier, and we still have some code we keep C++98, so, 8
| years.
|
| Anyways, I don't know what you are calling "modern" C++, but
| for me it is C++11 and up. C++11 to C++20 introduced a few
| major changes but none as pervasive as C++98 to C++11.
| veilrap wrote:
| My company does a decent job at keeping up with the standard.
| Getting from C++11 to C++14 was challenging, and C++14 to C++17
| took quite a bit of time, but we're on track to be on C++20
| later this year.
| rubyist5eva wrote:
| Do you have a strategy for doing this? Since C++ stays
| relatively backwards compatible I would imagine there is lots
| of legacy code that gets untouched but newer features would
| go into the new stuff - with legacy code getting replaced
| only for big refactorings?
| veilrap wrote:
| Our code tends to be shipped running on top of a relatively
| up-to-date version of linux. So we tend to go through the
| pain of testing/refactoring needed to get to the next
| version of C++ when we upgrade to the next stable version
| of linux that we're going to support.
| psyclobe wrote:
| I've shipped two projects wholly in c++20 in the past 4 years
| with modern practices spanning three platforms (win/Lin/OSX).
|
| No plans to go back to an older standard.
| Kranar wrote:
| What does "wholly in C++20" mean? How does "wholly in C++20"
| differ from "partially in C++20" or just "using C++20"?
| advael wrote:
| I have a habit of modernizing (and functionalizing) C++
| codebases in recent jobs I've taken, which tends to fix a lot
| of memory-related bugs as well as improving performance and
| readability. When an organization is hidebound in some way,
| someone has to push to make the change, but it definitely can
| happen if you can demonstrate the benefits
| latenightcoding wrote:
| that sounds about right, 5 years ago I was pleasantly surprised
| when large existing C++ code bases were C++11, now it's very
| common.
| 29athrowaway wrote:
| Low level languages give you fine control over memory
| management.
|
| But many companies do not like how the standard library does
| memory management and they roll their own allocators and
| libraries that use them.
| Espressosaurus wrote:
| I've been using C++17 since 2019; C++11 since 2013, and we're
| starting to scope out upgrading our toolchain to C++20.
|
| Depending on where you work at, my experience suggests 2-5
| years for adoption.
| fassssst wrote:
| Windows uses it extensively for both user land system code and
| the app platform.
| jahnu wrote:
| All c++20 here and just waiting for Clang and ultimately Xcode
| to catch up with MSVC so we can use ranges and pmr
| thraneh wrote:
| range-v3 is a great library allowing you to bridge the gap:
| https://github.com/ericniebler/range-v3
| [deleted]
| cosmiccatnap wrote:
| I like c++ but it feels maddening to learn. There was a time when
| I would tell people to learn C++ but now I tell them to start
| with C and work their way up because if the choice is between C
| and C++, C has become the more readable language somehow if you
| don't know what abstract classes, templates, and functional
| constructs are....even a bubble sort in C++ takes some explaining
| in terms of just the syntax sugar.
|
| GO and rust are great languages and I hope they go the distance
| and learn some of the lessons from C and especially C++
| codr7 wrote:
| These days it makes more sense to start from the other end if
| you ask me, and that has been true for quite a while.
|
| I find that my C++ style has drifted further and further into
| value land with time, which is a major difference to C where
| the same style is pretty much impossible to pull off.
|
| From one perspective, the language gets less and less complex;
| but the flip side is that all the old stuff is still in there
| and has the potential to cause a lot of trouble if you're not
| familiar with the details.
|
| Taken as a whole, it's pretty much an impossible language to
| master and has been for some time.
| swatcoder wrote:
| Even as a polyglot that picks up new languages quickly and
| often, I think this is true of most actively maintained major
| languages now.
|
| We're in an age where major languages are expected to cross-
| pollinate: if there's a cool paradigm or technique in some
| other major language, how do we evolve our language to support
| it?
|
| That's not a terrible thing in itself, but it means that most
| major languages are multi-paradigm now and become more so every
| release.
|
| As a consequence, learning becomes less straightforward.
|
| C may feel like a nice starter to you specifically because it's
| been comparatively resistant to this trend. It's got a ton of
| tricks to learn, but there are only a few paths through
| learning it.
| gotaquestion wrote:
| C takes on many dialects based on specialization. Compare
| code from the following, and you will see a range from
| trivial to understand to WTF. These are all real-world
| applications:
|
| - Linux kernel (events) - https://github.com/torvalds/linux/b
| lob/master/kernel/events/...
|
| - Arm CMSIS - (16-bit math) - https://github.com/ARM-
| software/CMSIS_5/blob/develop/CMSIS/D...
|
| - Numerical Methods in C - (Jacobian FP) -
| https://github.com/saulwiggin/Numerical-Recipies-
| in-C/blob/m...
|
| - GNU 'ls' Command -
| https://github.com/coreutils/coreutils/blob/master/src/ls.c
|
| - Gstreamer - (De-facto media streaming) - https://github.com
| /GStreamer/gstreamer/blob/master/gst/gstel...
|
| GStreamer is my favorite because it basically creates VTables
| like C++ but calls them Klasses (based on Gnome), and it is
| just a brilliant framework in general, but an utter
| perversion of C IMHO.
| [deleted]
| mrlonglong wrote:
| The Linux kernel does the same thing as Gstreamer with file
| operations etc, I r thought it pretty neat, not really a
| perversion at all.
| pjmlp wrote:
| Even with C it only looks like it, if one sticks mainly with
| a specific compiler and OS.
| inetknght wrote:
| > _There was a time when I would tell people to learn C++ but
| now I tell them to start with C and work their way up_
|
| I tell people to learn Python. When they get a hang of it then
| I introduce them to C and pointers. When they can demonstrate
| effective use of pointers without blowing up then advance to
| C++. If not then just keep using Python. I'd rather them learn
| computer science fundamentals on the easy language. Then they
| can learn the better language out of necessity ("i need more
| performance" or "i need more control over the data structure in
| memory" or similar) instead of shoehorning them into a language
| they're not ready for.
|
| I love C++. But it's not for everyone.
| tialaramex wrote:
| If what you need is C++ (which IMNSHO it is not) then starting
| with C is a bad idea. Here's Kate Gregory's talk, you should
| definitely listen to her even if you think I'm an idiot because
| she actually teaches people C++ and I (thankfully) do not.
|
| https://www.youtube.com/watch?v=YnWhqhNdYyk
|
| Now here's my rant, which is unrelated to Kate's very smart
| talk:
|
| C has an excuse, because it was written in the 1970s for the
| PDP-11. In the 1970s _struct_ qualifies as a fancy new feature.
| In the 1970s a _wide pointer_ is very expensive. In the 1970s a
| _linked list_ is often a good choice of data structure. C++
| comes along quite a lot later. These things are already untrue
| or fast becoming untrue, but rather than risk being _unpopular_
| Bjarne 's language just cargo cults C. It is almost all of C,
| plus more... stuff.
|
| C++ does not fix any of the worst problems with C, because
| doing so would risk losing compatibility and hurt Bjarne's
| adoption story. As a result, with only a handful of exceptions
| _all of that broken garbage is still there_. C++ still has the
| almost useless built-in array type from C, it keeps weird
| syntax from C that was too hard to ban in the 1970s compiler
| but you should never use, its built-in types have the same
| stupid, confusing names like "long" and "double", it has this
| awful "macro pre-processor" which makes even trivial tooling
| problems very difficult and set back software quality by at
| least a decade.
|
| Kate's approach _avoids_ teaching beginners about most of this.
| It 's still there, which is bad, but at least you aren't making
| them learn about it, only to them immediately tell them it's
| forbidden knowledge and is prohibited in your nice modern C++
| codebase. Instead of starting with raw pointers, and then
| trying to impress upon them later that these are a bad idea,
| Kate gets to begin with references and then a smart owning
| pointer.
| pjmlp wrote:
| Struct was already a feature in Jovial in 1958, but I
| digress.
|
| Plenty of very hard 1970's features at Bell Labs, weren't a
| problem at IBM, DEC, Xerox, Olivetti,....
|
| As for the way C compatibility taints C++, I agree, however
| Bjarne made juice with the lemons he had, and if it is to do
| a Python 3 in the C++ world, then most would rather migrate
| to Rust than use such C incompatible C++.
| annowiki wrote:
| Why wouldn't they just use the older version of C++? If you
| don't want non-c compatible c++ you could just stick to
| C++20 instead of upgrading to "C++breaking_changes".
|
| I ask because its not like support will ever be phased out
| like Python 2.
| pjmlp wrote:
| A language isn't used alone, it depends on an ecosystem,
| and people that care to keep old compilers going.
___________________________________________________________________
(page generated 2022-04-25 23:01 UTC)