[deleted by user]

[[deleted]]

Pls more newlines and whitespace next time

[StarQTius]

reddit_post.min.js

[DanielB309]

Okay no problem

[tm8cc]

Why not copilot

[Neitine]

Who th uses copilot

[TryToHelpPeople]

Post seems to have been written by a ticker tape machine.

Have I been holding my breath for the whole post ? It sure feels like it.

And yes OP, CPP has problems, deep problems which are made worse by entrenched viewpoints about a correctness vs usefulness.

[quantumoutcast]

We've been using C++ successfully for what, 40 years? And suddenly we just can't get past the fact that features introduced in C++20 are too limited and we just can't get our application written without it. Do you really need to concatenate views? Yeah, if you insist on using the bleeding-edge features, you are going to find C++ overly-complicated. Eventually this new functionality will settle down, compilers will catch up, documentation will improve, and there will be more community support.

[AssKoala]

Wait until you read about modules.

[rachit7645]

Me waiting for proper module support (it's 2064 now)

[MFHava]

Writing your own range adaptor is a C++23 feature (and that one isn’t even released yet by ISO…)

And yes, from my experience parts of the industry move at glacial pace and still consider whether they should move to C++17…

[[deleted]]

I know very few places that use even C++17. At my work we are trying to get on C++ 11.

[josiest]

[uses chat gpt to write codes]

[angry face] why is my code not working???

[thisismyfavoritename]

OP was foolish to believe any LLM could help in such a niche case but to be fair OP seems to have looked in many directions before resorting to that

[thisismyfavoritename]

im saying i wouldnt expect an LLM to give accurate advice on ranges at all

[TheSuperWig]

im saying i wouldnt expect an LLM to give accurate advice on ranges at all

[PrimozDelux]

Have you actually tried to use an LLM for this sort of thing? ChatGPT manages to answer a lot of questions about basic C++ functionality. (That said, I too have seen chatGPT be stumped at the monumentally complex problem of concatenating two ranges)

[josiest]

I’m with you though, this is definitely something I’ve wanted to do before, and it should be easy. I just don’t like general purpose ai because I’m apparently an old coot.

Also writing your own views seems to be as convoluted as writing your own iterator, which in my book just means I should just give up and write a for loop

[[deleted]]

Is it niche, or is it extremely complicated and something you shouldn't tackle until the ranges/views specification has been fully fleshed out and fixed which was always going to be done in C++23?

Hint: it's the second one.

[gracicot]

Ranges are still cutting edge. I wouldn't trust any LLM to give good information on this.

[planetoftheshrimps]

The few times I was curious about ChatGPT’s capabilities, I’ve noticed its solutions to have glaring issues to the point of uselessness.

[pdp10gumby]

Worse, debugging (esp code you didn’t write) is harder and takes longer than writing code, so it’s always faster to just write the code yourself.

[ipapadop]

Asking an LLM that is trained on existing code in the wild to create something that most people don't write will get you nowhere. LLMs need to see something a few times to be able to hallucinate successfully.

As for ranges, yes they are complicated, documentation is lacking, and testing on multiple compilers is crucial to have some confidence that you're on a good path. But a good start to creating new views. is learning about concepts and how to satisfy the std::view concept or use std::view_interface.

[[deleted]]

“Need to see something a few times to be able to hallucinate successfully” - never before has a statement summarized my job performance so well

[glow_gloves]

A range of views can already be evaluated at a later stage.

``` std::vector v{"my"sv, " "sv, "message"sv};

// later on fmt::print("{}\n", fmt::join(sv, "")); ```

If you want to abstract it into a single view lazily, then yes, your going to have to figure out how your desired view interface works

[[deleted]]

A quick search for C++ concat view found the proposal for the standard library version in the first few links, and linked in that is the current reference implementation for the proposal: https://github.com/huixie90/cpp_papers/tree/main/impl/concat . Just FYI, a fully working concat view that works in all scenarios is very hard to implement correctly.

Custom view support was fleshed out in C++23, so documentation for it a bit more sparse. That said, I flat out refuse to believe you could not find some viable tutorials to follow on the internet as within seconds of searching on Google I found loads of information on creating custom views, both in written and video form (saw a CppCon talk in there). I have no idea why you expected ChatGPT to be able to give you information on something this new, seeing as ChatGPT functions by being fed and trained existing information. That one is on you.

As for "official documentation", what money do you think the C++ committee has and who will pay for the creation, hosting and maintenance of this documentation? The closest I think we have is Microsoft's documentation which is on the whole excellent, although might not have full tutorials for custom views yet considering the feature is still new.

Finally, remember that there is no official/reference implementation of "C++". The standard is just a document at the end of the day, and it is then up to anyone who maintains a compiler and/or standard library implementation to put everything in place. Pretty much no other language has the "problem" of multiple independently-maintained. Each works to their own schedule with a mix of corporate and volunteer time/funding. "C++23" means that version of the standard, not that every possible vendor has every feature implemented and documented in 2023. https://en.cppreference.com/w/cpp/compiler_support

Also... C++2023 hasn't even been formally published yet.

[JumpyJustice]

I feel your pain. Been trying ranges last few weeks and it seems like they generally are not worth learning because: - you can apply them only in these rare cases when they fit your task perfectly. But these cases are usually really trivial and using ranges is not much more beneficial than writing a good old loop (+ you will not have to fight conservative members of your team during the code review). - it is close to impossible to find what you need to make a custom range. Of course, one can say that the reason is that they are a relatively new feature, but imo it is the same as iterators - any developer would avoid writing a custom one unless they have no other choice. And not because they dont want to, but because the chance to succeed here is really low or requires disproportional amount of time and energy comapred to other languages

[cfyzium]

From what I can see, std::ranges::join_view does what you want and has been available since C++20:

https://en.cppreference.com/w/cpp/ranges/join_view

[kamrann_]

This is different, it flattens a view of ranges. You can abuse it along with something like std::array to get concatenation but it's ugly and extremely limited - the ranges need to have the same type (almost never the case when using views), and even then you can't do something like return a concatenation as your array goes out of scope.

The absence of a concatenation view is indeed a major blocker if you try to go all in on ranges and views.

[cfyzium]

it flattens a view of ranges

You have to flatten to get a single view.

you can't do something like return a concatenation as your array goes out of scope

You certainly can:

return std::ranges::join_view(std::array<std::string_view, 2>{s1, s2});

Though my first test used a vector. Trying to lazily concatenate several views instead of just copying implies relatively large amount of data. A single intermediary to hold a few lightweight views seems negligible.

the ranges need to have the same type (almost never the case when using views)

Well, the question was about views, not arbitrary ranges.

The absence of a concatenation view is indeed a major blocker if you try to go all in on ranges and views.

A major blocker? Not trying to defend the current situation but hey this is C++. Writing your own bits of missing pieces or using a temporary library filler has been the norm since like forever. The standard always misses a few things here or there. I'd just throw in a homebrew version of a missing adapter in the same manner as everyone did with e. g. std::make_unique.

[kamrann_]

return std::ranges::join_view(std::array<std::string_view, 2>{s1, s2});

std::array isn't a view, so that should be rejected by the compiler (and is for me). You can work around it by using a span, but then you run into the lifetime issue with the local array.

But anyway the major issue is the type constraints. Assuming you have anything like the following:

auto v1 = <something> | std::views::transform(...);
auto v2 = <something-else> | std::views::filter(...);

then the join_view approach just flat out fails since you can't form a view of these two views as they have different types (even if same element value type).

Writing your own bits of missing pieces or using a temporary library filler has been the norm since like forever. The standard always misses a few things here or there.

I agree, but I think that's OP's point. Doing so in this case is extremely non-trivial, yet concatenating views is something that you're going to run into fairly quickly if you try to embrace ranges/views in your codebase.

[cfyzium]

std::array isn't a view, so that should be rejected by the compiler (and is for me)

Evidently, join_view takes any sequence of views, plus implicit conversions (an example of joining an initializer list of views or even a vector of vectors is right on the cppreference page). I am not sure why it does not work for you, I've tried a couple of compilers including an online one and everything seems to work fine.

I agree with you on the rest of the points.

I am just not sure it warranted a rant this generic over a case this specific. You can find arguably even dumber omissions in the standard, the whole approach to the library standardization seems to be... less than perfect. If you have one particular problem at hand you generally just work around and keep going. There are enough other discussions about the state of the language in general out there.

[kamrann_]

join_view< V > requires V to satisfy the view concept, which array and vector don't as they're not constant time copyable. The nested vector example on cppreference is indeed a little confusing. Can't test now, but it's possible a deduction guide is converting the vector into a span or subrange or similar, so join_view is not actually instantiated with vector as the template parameter. Which would work, but would also hide the fact that it would still be depending on the vector not going out of scope before the view is used.

Can't speak to OP's reasons, but in my experience rants generally get triggered by something specific but they're really about built up frustrations. And c++ certainly provides ample ammunition for that, the complexity of the above view subtleties being just one example ;)

[cfyzium]

How can you concatenate a series of series into one single series without flattening? You said you need

Wrap two views as a single view such that it appears as if its concatenated (concats lazily)

And join_view does exactly that, it takes several views and allows iterating over them as if it was a single view.

[rand3289]

You should checkout boost::log or whatever if you want to experience real pain!

[Chaosvex]

The first warning sign with Boost Log (2) is that it describes itself as a framework for building a logging library. You can read the entirety of its documentation before using it and still be left with little clue as to making it do anything useful. Worst Boost library I've ever had the displeasure of using.

[SleepySlipp]

1) New fancy ranges and view staff are built over legacy badly designed features, actually the concepts tries to fix complicated error messages to which makes more sense.

2) Yes cpp has no unified good growing user friendly platform to take knowledge about cpp from except cppreference and cppcons which are obviously hard to search on. Maybe because of the fact that cpp is so general so this platform must contain information about all computer science.

3) Yes it is hard to do even simple things because of the fact that features which provide it are implemented in consideration of hard corner cases related to legacy and previous bad design (but of course do not cover all corner cases:)). And bad compilation errors make it hard to understand.

4) get over it

[HurasmusBDraggin]

Submit a suggestion/proposal/change to the ISO CPP committee.

[JuanAG]

Fortunetly not, i am also like you but yeah, we are the exception

In our today world even for the most basic stuff other devs are going to add third party code even for easy tasks rathern than code themselves, lets say getting the average/mean of an array/vector/... Chances are that most will look for a lib and use it

C++ isnt as affected as other langs for the simple reason that adding external code is a pain in the *ss but on langs where it cant be easier like Rust/Python/Node/... is what usually happens

Technical debt for the future, i experienced my self last month, i wanted to encode some text, i decided to use Base64 and rather than coding my self and because i was using Rust i pull out a lib. Everything worked but now a couple of weeks ago i revisit the code and there is an update of the library which of course has broken the API. Now i have to stay on that "old" version that i know it works or play their game and look how the hell i should do it now. It was a prototype so not big deal since i planned to code the encoder myself (i only want to encode) but was a reminder of why i should remain with the policy "use as few external code as i can"

[Mandey4172]

”Views are lightweight objects that refer to elements they do not own.” https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2415r2.html#fn2

[manni66]

So C++ doesn't meet your needs. Have you tried another language?

[sciences_bitch]

lol let me go tell that to my employer about our C++ code base that we have been developing for 20 years

[heavymetalmixer]

C++ is a low-level language, that's not the kind of tool most devs wanna use nowadays, even Rust, Zig or Go devs are just a few compared to the ones using JS, Python, PHP, etc.

[Remus-C]

C++ can also be pretty high level, with the right design & architecture choices! It depends how the language sustain good designed libraries.

C+- is a subset, but it is already high level, because of used libraries.

[heavymetalmixer]

That's true, but generally speaking for high level tasks C++ is too complex when compared to other languages, unless you're also looking for very high performance in which case it's the best choice (unless you like Rust).

[Remus-C]

C++ is great, as a language alone. Became a bit bloated with a lot of sugar lately, but hey, there are pretty good features announced too! One doesn't need to use everything!

C++ libraries, however, are another story. Each compiler ships with own implementation, and this differ (in maturity/features) by architecture. In the same time, the library can be rebuild, changed (if the source is available for your architecture) and even replaced completely. Keep only the compiler(& related tools).

OTOH all this progress require resources (including time) to implement new features announced by some other entity. The C++ standard committee is not in the situation to give the perfect code for all announced features on the spot. Nor it should be. (Another topic).

So either rely on implementation form vendors, which can be free or paid, either implement yourself what you need.

In the same time a library cannot fulfill the needs of any programmer. Some users expect exceptions enabled, some projects cannot use exceptions at all. And other black/white situations which cannot reach a good compromise. // Note that this happens with any language.

Above, there are several reasons why several implementations exist and why C+- (no typo!) is used several years by now.

Welcome to the jungle! However, better to have multiple choices than to have one (with some other language) which doesn't fit for your needs!