u/wheypoint

We need to sell c++ standard NFTs

I noticed you use a const_cast which UB

It's not; in fact const_cast itself is never UB. Mutating an object that was declared const is, but that has nothing to do with const_cast

also sometimes referred to as compile time

Totally agree and i'm looking forward to using it once we're allowed to.

I wish we could write beautiful functional code in C++, but I don't think that will ever happen :-D

I've also seen examples where I expected very nice simple code which ended up having to be a lot more complex. But I think there are already cases where functional c++ is quite beautiful, atleast considering what c++ has to work with. And there is still work going on improving them.

Great to see c++20 in action and nice write ups

I really like that modern c++ is getting these more functional features but tbh i think they aren't what i'd use here. I Think it's great when some raw loop can be replaced by some more readable desciptive algorithm, even better if it leads to shorter code. But do people really think

uint32_t count_increasing_windows(std::istream &input) {
  auto sliding_window_view = std::ranges::istream_view<uint32_t>(input) 
| std::ranges::views::transform([e1 = 0, e2 = 0, e3 = 0](uint32_t curr) mutable {
    e1 = std::exchange(e2, std::exchange(e3, curr));
    return e1 + e2 + e3;
    });
  return std::ranges::count_if(sliding_window_view, 
                           [prev = std::numeric_limits<uint32_t>::max(), drop = 2]
                           (uint32_t curr) mutable {
                              if (drop > 0) {
                                drop--;
                                return false;
                              }
                              return std::exchange(prev, curr) < curr; });}

is more readable than the equivalent super simple index or iterator based for loop?

Now maybe in haskell you could solve this using a nice functional composition of simple functions but i think it's too much for c++ ranges.

That wasn't very nice. Anyways i'll explain why your post isn't received that well. First of all it's the wrong sub. And yes reading the rules you should have figured that out. Second, do you know how often "idea people" come up with an app idea that they then want someone to work on without any own investment whatsoever?

Your post literally says "i want you to develop an app for me. i will not pay you or even participate in development, just do your own research and tell me when it's done. Oh, and make it free."

That's hardly

a marketing idea

C++ supposedly has exceptions, but they are broken (you can't throw them from constructors

wrong. youre actually supposed to do so if the object can not be constructed holding its required invariants. the entire stl is written in a way that's able to deal with this

, from destructors,

also wrong

from exception handlers

what's that? afaik not a term used in the standard but i suppose youre talking about catch clauses? also wrong either way

otherwise memory/resource leaks will happen

definetely not true. read up on raii and take a look at how the stl handles exceptions - including from special member functions

these exceptions are supposedly zero-cost at runtime, but bloat the binaries very much.

theyre optimized for the success(/non "exceptional" path), as intended

It supposedly has classes, but they are broken (due to unsafe casts and pointer arithmetic).

classes aren't broken because the language gives you a way to have lower level control if you need to

It supposedly has low-level performance, but it's broken (the compiler can insert wanton object copying anywhere

wrong. copying happens only where it's specified to happen and even then modern compilers can (and are allowed to) elide a lot of them, see for example rvo/nrvo

and forces you to pay for virtual methods even if you don't use them etc).

wrong. you never have a virtual call without a virtual member function. and even if you call a virtual member function the compiler is allowed to devirtualize if it can be proven correct

It supposedly has memory safety with smart pointers, but it's broken (can be sidestepped with raw pointers

that doesn't mean smart pointers are broken, it just gives you a lower level alternative. also raw pointers are amazing for non owning pointers and easy c interop

and can't handle reference cycles like a tracing GC can)

shared pointers dont handle reference cycles by design. neither do rusts shared pointers.

This is all beside the usual points of C++ being responsible the biggest blob of critical legacy code in the world

which is the fate of any heavily used language after decades and billions of lines of code in real world projects

which is going to take decades to rewrite,

at least thats what reddit wants. i don't see us rewriting any of our companies code. that's an immense amount of money/work just to risk it not working out, and for no actual benefit

Rust already being the world's established favorite and most popular

/r/programmingcirclejerk

template <...>
void func(...) noexcept(noexcept([] () { do_stuff(); }())) {
    do_stuff();
}

Is this even correct? Specifically is the lambda not also missing a noexcept specifier?

that is indeed not correct, but it's not what OP wrote. OP's version doesn't use noexcept(noexcept(lambda-call-expr)) but instead the correctnoexcept(lambda-call-expr) where the lambda returns the noexceptness (so a bool) of the inspected expression.

(the version you wrote would always be noexcept(false))

i know but that's not what OP asked.

also the compiler never decides when to move based on a "last use" (it doesn't decide at all, you have to tell it when something is passed by reference).

rust's system is different from c++s and OP's suggestion doesn't work in rust.

No this has absolutely nothing to do with rust. Rust doesn't decide when to move based on a "last use", it doesn't even have perfect forwarding/universal references or overloading based on rval vs lval references.

the problem with vector<bool> is the different api like returning proxies and messing with iteration.

I dont see any problem with specializing optional<_> for a bunch of std types like function or even string when all its gonna do is save some space

the entire language is designed in a way that allows leaking memory - and that's pretty easy to do (and imo a good thing. the borrow checker is annoying enough as is).

it makes total sense to allow that as it's not unsafe. i just wanted to clarify that because pretty much every second comment itt claims rust somehow prevents leaks (which it is not designed for).

cyclic reference counters (Rc, Arc)?

it's just as easy/hard to accidentally leak there as in c++: i've never had a problem with that in either of these languages. If you want guaranteed memory safety + leak freedom etc use something gced

memory leaks also compile in rust.

The first two overloads in https://en.cppreference.com/w/cpp/regex/regex_replace take the output iterator instead of constructing a new string.

you should be able to pass in text.data (since the semantics are described as like using std::copy which allows overlapping ranges). in that case the replacement would happen in-place and do no allocations.

if you then passed in your original string to the move ctor of the parameter that means you avoid copying/allocating the string buffer.

You should take text by const&

no, taking by value is correct here. const& would force making a copy even when the parameter couldve been move constructed.

Always has been

No. Writing a linked list in c++ is absolutely trivial.

yes, rusts borrow checker avoids UB. It also prohibits a lot of correct code.

Sadly many people on reddit now have adopted the opinion that it therefore enforces good code style, or even that all code rejected by it must've been bad. The truth is it only follows a very simple ruleset to determine wether something is ok (which on its on is a good thing), but leads to too many false positives on otherwise perfectly fine code. It has absolutely nothing to do with the quality, readability or correctness of the code.

There are some nice ideas in rust but both in my hobby projects as well as one real project(*) i tried it, the complexity wasnt worth it.

(*) i introduced the idea of using rust for a new work project we had started. after initial prototyping and continuosly running into problems with its type+borrow system that were trivial to solve in c++ we threw that out and did it in c++. (and i'm not saying it was impossible to do in rust. it mightve been possible if there was someone intricately familiar with all of rusts inner workings on the team). no regrets

Some of that is probably my familiarity with c++, but it's always a tradeoff and i've found c++ with its power+complexity compared to rusts to be better suited in every one of these cases.

using shared_ptr for everything is not really nice and unique_ptr isn't just a compromise.

types can be used to express different semantic models: here they express shared / unique ownership.

misusing a shared_ptr for unique ownership is not just slower. it incorrectly describes what it's doing and will confuse the reader.

also not sure sure about the "safety" remark. they may not dangle but it's easier to create memory leaks (and just messy structures in general) (which is technically "memory safe" - can not use after free if you never free..., but still may be bad design)

"It's too expensive to implement communism"

you either put ```

Don't do that. It's not displayed correctly on some verions. Always use 4 spaces

like the STL. Have you looked at the source code for that? It's horrible to read in my opinion

it's actually not that bad, the problem is it has to use _MACROS and _Uglified __names a lot to not clash with user code.

i've looked through the msvc stl a few times to see what things do and it seems really well structured

u/profanitycounter [self]

auto& x = *new X

is valid c++

Edit: of course meant reference. And this is a reply to

but I'm not 100% sure about knowing that we don't own it. Would temporary lifetime extension count as ownership or are there other examples?

because this would be an owning reference (not that anyone should write this code)

It is somewhat confusing because it is a special case.

main must have return type int

if you have a return statement inside main it must return an int, but you are allowed to not write an explicit return in which case it will return 0 (in any other function this would be UB)

you will often see void main but that is not permitted by the standard

Oh hi Arg!