6 ms·

I know I'm not going to make a lot of friends with this opinion, but this is a perfect example of everything that's wrong with modern C++. Seriously who, excep

by rsp1984 8y ago

I know I'm not going to make a lot of friends with this opinion, but this is a perfect example of everything that's wrong with modern C++. Seriously who, except for a small circle of academics, actually believes that this is good, readable, concise, maintainable code? Who asked for this? When I read inline constexpr auto for_each = []< Range R, Iterator I = iterator_t<R>, IndirectUnaryInvocable<I> Fun>(R&& r, Fun fun) requires Range<indirect_result_t<Fun, I>> { return std::forward<R>(r) | view::transform(std::move(fun)) | view::join; }; I can't help but being reminded of Java [1][2]. Meanwhile it's 2019 and C++ coders are still - Waiting for Cross-Platform standardized SIMD vector datatypes - Using nonstandard extensions, libraries or home-baked solutions to run computations in parallel on many cores or on different processors than the CPU - Debugging cross-platform code using couts, cerrs and printfs - Forced to use boost for even quite elementary operations on std::strings. Yes, some of these things are hard to fix and require collaboration among real people and real companies. And yes, it's a lot easier to bury your head in the soft academic sand and come up with some new interesting toy feature. It's like the committee has given up. Started coding C++ when I was 14 -- 20 years ago. [1] https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr... [2] http://projects.haykranen.nl/java/ http://projects.haykranen.nl/java/

deleted 8y ago
[deleted]
stefan_ 8y ago
This has been the story with C++ forever. I think currently half the standardization and compiler implementation bandwidth is taken up by turning C++ into the slowest virtual machine ever devised (constexpr). The constexpr story is presumably very similar to what happened with templates. There was a genuine niche use case, and that was perfectly covered in the initial implementation. But the feature just lends itself perfectly to extremely clever, single A4 page example code. No one ever went "ooh" and "aah" at a basic_string::split paper.
dman 8y ago
This looks like something a library author would write while implementing a range and not something that end users would write while using ranges. Could you point to an implementation in a different language that offers a similar abstraction in a more succinct manner (While offering the same type safety and low runtime overhead).
- danbolt 8y ago
  I feel like what you’re touching at is kind of the core of why C++ can be so difficult to parse through sometimes. It really is trying to make a general purpose abstraction while also having a low overhead. This results in a need for detail and complexity that you can simply not need to worry about in languages like Python or Clojure. When my university peers and I were learning C++, a lot of us strongly preferred using C99 since it didn’t seem as awful in terms of complexity and verbosity.
- rudolph9 8y ago
  Does this this suffice https://doc.rust-lang.org/std/ops/struct.Range.html https://doc.rust-lang.org/std/ops/struct.Range.html ?
  - dfbrown 8y ago
    No, ranges in C++ are analogous to the iterator trait in rust
- 12298765 8y ago
  Check out Go
slavik81 8y ago
Most of that code is for optimization or error messages. I think you could strip it down to: auto for_each = [](R&& r, Fun fun) { return r | view::transform(fun) | view::join; }; I also removed inline and constexpr because he didn't need them in his example. I don't disagree that it's ugly, but it's not as bad as it looks when you go through the standard library. Those are functions that have been written, optimized and generalized to handle all sorts of cases. Your needs are almost certainly more specific, and you will undoubtedly write functions that are much simpler. That being said, I kind of agree. I would have preferred your list of features to getting Concepts. I find SIMD to be a particular sore spot.
- spiritcat 8y ago
  Do c++ regulars eventually just get numb to how hideous the :: syntax is to look at?
  - blattimwind 8y ago
    Not the worst piece of C++ syntax by various orders of magnitude.
    - justAnotherNET 8y ago
      and what does that say?
  - fermienrico 8y ago
    It is as if we don't learn! Same thing in Rust. :: is adds so much visual noise. Julia is the only modern language with beautiful syntax. I think we should pay more attention to the aesthetics of a language just like we do with spoken languages. Certain languages just sound beautiful - Japanese and French. C++ is old but Rust could have paid more attention to subjective aspects of a language.
    - deleted 8y ago
      [deleted]
lallysingh 8y ago
This is exciting stuff unless you look at other languages and see what a mess this is.
acadien 8y ago
Not to mention the nightmare that is organizing the compiler on large projects. I've seen multiple large companies employ teams of 10+ engineers just trying to keep the compiler in order. Optimizations that take weeks or months to develop result in 10x improvements while I'm not aware of developers in other languages having this problem.
tomnj 8y ago
This is library code which most users of the range library will not themselves need to write. Using ranges absolutely leads to shorter and more elegant code. The implementation of the library is complicated. Much of what’s likely unfamiliar with this example is the use of C++ “concepts” (a technical term), and is not actually necessary, but is placed there to actually give better error messages to users of the library (without them, template code is basically duck-typed, and can give terrible error messages). I’d argue that the core of that code: the transform followed by the join is actually quite readable. I also wouldn’t at all say C++ is overly academic. It’s an extremely pragmatic community. Yes, the standardization process is slow, but I don’t view, as a C++ user, the issues you mention as serious. To me, there’s nothing wrong with using high quality third party libraries like boost (and Eric’s range v3 library). My biggest frustrations with C++ are the build and packaging stories.
- Something1234 8y ago
  Boost is not high quality. It massively balloons the compile time, and there's random incompatibilities between minor versions. It's also a hunt to figure out which header I need to include for certain libraries. There's no consistent feeling to the library. My biggest gripe is that it makes vims completion stupid slow by bringing in a large number of headers.
  - gumby 8y ago
    Finally! It's not just me. But...I will say some good ideas made it into the standard thanks to a first implementation in boost, though what ended up being standardized is typically much cleaner and more orthogonal. Then again this is how we got the standard containers and so much more standard library goodness -- via Stepanov stepping up and writing the STL. The best way to think of boost as the npm.
  - tomnj 8y ago
    > boost is not high quality This is just false.
    - 8y ago
realityczeque 8y ago
I really, really don't want cross-platform SIMD in C++. The reason I write asm is I know how the machine works and exactly what I want the machine to do. It's already hard enough to get what you want from the compiler and trying to make it cross-platform is guaranteed to make it even harder. If you don't believe me try opening an audio device or a serial port from Java, which purports to contain cross-platform libraries for these devices but in fact makes it totally impossible to use them. As for std::string I never find myself using boost for any reason so I'm curious what the indispensable boost feature is for strings. The only thing I want from std::string is the ability to resize it without initializing allocated space, the ability to construct a string from an existing data pointer, and the ability to release the data pointer from an existing string (basically the union of a string a unique_ptr).
- slavik81 8y ago
  Do you use std::vector when working with SIMD? I find the SIMD alignment requirements make it difficult to integrate intrinsics with the rest of my code. Maybe I'm just missing something, but I'm having a hard time with it.
  - realityczeque 8y ago
    That's a good point. If you use a custom allocator with your vector then you can be sure of the alignment, although the compiler will pretend to be unaware of it. All that stuff I want for string goes for vector, too.
nummy 8y ago
agreed! C++ looks like a completely different language now.
liopleurodon 8y ago
I totally agree. It's stuff like this that will usher in the rust revolution Edit: also wanted to add - what a disaster
icedchai 8y ago
Java is generally much more syntactically straightforward.
the_clarence 8y ago
That's why people are moving to Rust.
wraithdroplets 8y ago
I have an adjectival reply which is less based in fact but more in practical maxim. One problem with the late stage of a general purpose language may be described by one instructor's phrase as "programming zoo." Thus people tend to keep to the usual described animals but then formerly binary dynamic linked libraries need to be opened up to be cured and then the zoos sort of super-zoo thus become ooze. So it is true. (p) There is no real way to gate a general purpose programming language of industrial application for the rules of commerce are too adaptive. Thus version restriction by compiler is one method to reduce intellectual orthogonal complexity, in sense of bizarre constructs going fourth wall against each other and paralyzing the human analyst.
int0x80 8y ago
That code sample is outright ridiculous, it is totaly out of control. Can't agree more.
shaklee3 8y ago
At some point, I agree. But then I see people on here talk up Haskell and lisp, an those are far worse.

deleted 8y ago

[deleted]

stefan_ 8y ago

This has been the story with C++ forever. I think currently half the standardization and compiler implementation bandwidth is taken up by turning C++ into the slowest virtual machine ever devised (constexpr). The constexpr story is presumably very similar to what happened with templates. There was a genuine niche use case, and that was perfectly covered in the initial implementation. But the feature just lends itself perfectly to extremely clever, single A4 page example code. No one ever went "ooh" and "aah" at a basic_string::split paper.

dman 8y ago

This looks like something a library author would write while implementing a range and not something that end users would write while using ranges. Could you point to an implementation in a different language that offers a similar abstraction in a more succinct manner (While offering the same type safety and low runtime overhead).

danbolt 8y ago
I feel like what you’re touching at is kind of the core of why C++ can be so difficult to parse through sometimes. It really is trying to make a general purpose abstraction while also having a low overhead. This results in a need for detail and complexity that you can simply not need to worry about in languages like Python or Clojure. When my university peers and I were learning C++, a lot of us strongly preferred using C99 since it didn’t seem as awful in terms of complexity and verbosity.
rudolph9 8y ago
Does this this suffice https://doc.rust-lang.org/std/ops/struct.Range.html https://doc.rust-lang.org/std/ops/struct.Range.html ?
- dfbrown 8y ago
  No, ranges in C++ are analogous to the iterator trait in rust
12298765 8y ago
Check out Go

slavik81 8y ago

Most of that code is for optimization or error messages. I think you could strip it down to: auto for_each = [](R&& r, Fun fun) { return r | view::transform(fun) | view::join; }; I also removed inline and constexpr because he didn't need them in his example. I don't disagree that it's ugly, but it's not as bad as it looks when you go through the standard library. Those are functions that have been written, optimized and generalized to handle all sorts of cases. Your needs are almost certainly more specific, and you will undoubtedly write functions that are much simpler. That being said, I kind of agree. I would have preferred your list of features to getting Concepts. I find SIMD to be a particular sore spot.

spiritcat 8y ago
Do c++ regulars eventually just get numb to how hideous the :: syntax is to look at?
- blattimwind 8y ago
  Not the worst piece of C++ syntax by various orders of magnitude.
  - justAnotherNET 8y ago
    and what does that say?
- fermienrico 8y ago
  It is as if we don't learn! Same thing in Rust. :: is adds so much visual noise. Julia is the only modern language with beautiful syntax. I think we should pay more attention to the aesthetics of a language just like we do with spoken languages. Certain languages just sound beautiful - Japanese and French. C++ is old but Rust could have paid more attention to subjective aspects of a language.
  - deleted 8y ago
    [deleted]

lallysingh 8y ago

This is exciting stuff unless you look at other languages and see what a mess this is.

acadien 8y ago

Not to mention the nightmare that is organizing the compiler on large projects. I've seen multiple large companies employ teams of 10+ engineers just trying to keep the compiler in order. Optimizations that take weeks or months to develop result in 10x improvements while I'm not aware of developers in other languages having this problem.

tomnj 8y ago

This is library code which most users of the range library will not themselves need to write. Using ranges absolutely leads to shorter and more elegant code. The implementation of the library is complicated. Much of what’s likely unfamiliar with this example is the use of C++ “concepts” (a technical term), and is not actually necessary, but is placed there to actually give better error messages to users of the library (without them, template code is basically duck-typed, and can give terrible error messages). I’d argue that the core of that code: the transform followed by the join is actually quite readable. I also wouldn’t at all say C++ is overly academic. It’s an extremely pragmatic community. Yes, the standardization process is slow, but I don’t view, as a C++ user, the issues you mention as serious. To me, there’s nothing wrong with using high quality third party libraries like boost (and Eric’s range v3 library). My biggest frustrations with C++ are the build and packaging stories.

Something1234 8y ago
Boost is not high quality. It massively balloons the compile time, and there's random incompatibilities between minor versions. It's also a hunt to figure out which header I need to include for certain libraries. There's no consistent feeling to the library. My biggest gripe is that it makes vims completion stupid slow by bringing in a large number of headers.
- gumby 8y ago
  Finally! It's not just me. But...I will say some good ideas made it into the standard thanks to a first implementation in boost, though what ended up being standardized is typically much cleaner and more orthogonal. Then again this is how we got the standard containers and so much more standard library goodness -- via Stepanov stepping up and writing the STL. The best way to think of boost as the npm.
- tomnj 8y ago
  > boost is not high quality This is just false.
  - 8y ago

realityczeque 8y ago

I really, really don't want cross-platform SIMD in C++. The reason I write asm is I know how the machine works and exactly what I want the machine to do. It's already hard enough to get what you want from the compiler and trying to make it cross-platform is guaranteed to make it even harder. If you don't believe me try opening an audio device or a serial port from Java, which purports to contain cross-platform libraries for these devices but in fact makes it totally impossible to use them. As for std::string I never find myself using boost for any reason so I'm curious what the indispensable boost feature is for strings. The only thing I want from std::string is the ability to resize it without initializing allocated space, the ability to construct a string from an existing data pointer, and the ability to release the data pointer from an existing string (basically the union of a string a unique_ptr).

slavik81 8y ago
Do you use std::vector when working with SIMD? I find the SIMD alignment requirements make it difficult to integrate intrinsics with the rest of my code. Maybe I'm just missing something, but I'm having a hard time with it.
- realityczeque 8y ago
  That's a good point. If you use a custom allocator with your vector then you can be sure of the alignment, although the compiler will pretend to be unaware of it. All that stuff I want for string goes for vector, too.

nummy 8y ago

agreed! C++ looks like a completely different language now.

liopleurodon 8y ago

I totally agree. It's stuff like this that will usher in the rust revolution Edit: also wanted to add - what a disaster

icedchai 8y ago

Java is generally much more syntactically straightforward.

the_clarence 8y ago

That's why people are moving to Rust.

wraithdroplets 8y ago

I have an adjectival reply which is less based in fact but more in practical maxim. One problem with the late stage of a general purpose language may be described by one instructor's phrase as "programming zoo." Thus people tend to keep to the usual described animals but then formerly binary dynamic linked libraries need to be opened up to be cured and then the zoos sort of super-zoo thus become ooze. So it is true. (p) There is no real way to gate a general purpose programming language of industrial application for the rules of commerce are too adaptive. Thus version restriction by compiler is one method to reduce intellectual orthogonal complexity, in sense of bizarre constructs going fourth wall against each other and paralyzing the human analyst.

int0x80 8y ago

That code sample is outright ridiculous, it is totaly out of control. Can't agree more.

shaklee3 8y ago

At some point, I agree. But then I see people on here talk up Haskell and lisp, an those are far worse.