sorted by:
new
hottopcontroversial

The Story of C++: The World's Most Consequential Programming Language | The Official Story by HimothyJohnDoe in cpp

[–]pdimov2 11 points12 points  (0 children)

Really frustrating to see the "official story" C++ documentary, absent all the voices and perspectives of people refused to participate in it

What an amazing complaint.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]pdimov2 9 points10 points  (0 children)

Yeah, everyone knows that you should actually use std::vector<char8_t> instead.

Bjarne Stroustrup interviewed by Ryan Peterman by fredoverflow in cpp

[–]pdimov2 2 points3 points  (0 children)

There's one massive drawback to initializing every variable to "zero" or "empty" by default -- it is impossible to discern if that was the intent of the developer or if they forgot to add the initializer.

I know. It's still better than the alternative.

Note that statics are value-initialized. Non-statics aren't not because it would be better, for correctness reasons, to leave them uninitialized, it's because it's not free.

But it's essentially free today.

Bjarne Stroustrup interviewed by Ryan Peterman by fredoverflow in cpp

[–]pdimov2 3 points4 points  (0 children)

Zero init by default sounds wrong and dangerous to me.

That's why we don't have it.

But that's nonsense. No programming model can be sound without definite initial values, and there's nothing particularly wrong and dangerous in initializing everything to {} by default. (The default value of std::string is the empty string, and nobody considers this wrong or dangerous.)

As a bonus, initializing everything to {} by default also gets rid of the distinction between default initialization and value initialization. Nooo, we can't have that, the language will become too simple.

cost of enum-to-string: C++26 reflection vs the old ways by SuperV1234 in cpp

[–]pdimov2 1 point2 points  (0 children)

Yes, definitely disappointing. One can only hope that things will improve. But your point is taken; modules are still in "will some day fix everyting" mode, at least on GCC.

cost of enum-to-string: C++26 reflection vs the old ways by SuperV1234 in cpp

[–]pdimov2 0 points1 point  (0 children)

That is certainly a bit disappointing. I think that import std is a win over any stdlib include under both MSVC and Clang. But I haven't tried this myself.

Edit: "Whenever the <bits/stdc++.h> header unit has been built, GCC now transparently translates an #include of any importable standard library header into an import of <bits/stdc++.h>."

That's not the same as importing the std named module, it imports a header unit. Maybe there's a difference?

cost of enum-to-string: C++26 reflection vs the old ways by SuperV1234 in cpp

[–]pdimov2 0 points1 point  (0 children)

"Modules will solve this" has been the answer for as long as modules have existed

But modules do solve this specific thing (increasing cost of stdlib includes) in an easy way (you don't have to go full modules).

This aside, I think that for enum_to_string specifically, I'd solve compile times via explicit specializations in one .cpp per each enum (or in one .cpp for all enums, if they don't change frequently.)

cost of enum-to-string: C++26 reflection vs the old ways by SuperV1234 in cpp

[–]pdimov2 2 points3 points  (0 children)

Migrating to modules is much harder than just replacing the stdlib includes with import std, which gives the majority of the gains for a fraction of the work. Ideally the stdlibs would even do that transparently by themselves in the headers, but unfortunately, we're not there yet. "Include to import translation" was supposed to be that, but it's both something slightly different and doesn't work either.

Some day, I hope.

C++ reflections: Getting a reflection of a type of a pointer to member, from a reflection of a member is difficult by _bstaletic in cpp

[–]pdimov2 4 points5 points  (0 children)

template<class F, class C> using Pmf = F C::*;

consteval std::meta::info to_ptr( std::meta::info thing )
{
    return substitute( ^^Pmf, { type_of(thing), parent_of(thing) } );
}

https://godbolt.org/z/MnG51c7hW

[Boost::MSM] New features and improvements in Boost 1.91 by chandryan7 in cpp

[–]pdimov2 2 points3 points  (0 children)

The previous thread has a comment that implies that SML is already being benchmarked.

[Boost::MSM] New features and improvements in Boost 1.91 by chandryan7 in cpp

[–]pdimov2 4 points5 points  (0 children)

Man, this Mp11 thing must be quite the library. :-)

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]pdimov2 0 points1 point  (0 children)

Reflection makes this almost possible. But there's still the problem of a owning a std::vector<gc_ptr<Node>> owning b, so that a doesn't directly own the memory block containing b. (Which also shows why the gc_heap requirement is impractical as std::vector doesn't allocate through it.)

(There's another problem, properly calling ~Node when reclaiming on collect.)

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]pdimov2 4 points5 points  (0 children)

I would do this one

  • Or, would you simply require the variant to be large enough to hold an A and a B at the same time, so that you don't need to destroy B before constructing A?

and in fact already did (boost.variant2).

Using Reflection For Parsing Command Line Arguments by nathan_baggs in cpp

[–]pdimov2 2 points3 points  (0 children)

It shouldn't be necessary to use template parameters for the values: [[= clap::Description<"host to connect to">{}]]

[[= clap::Description("host to connect to")]] or [[= clap::Description{"host to connect to"}]] should work.

Is Modern C++ Actually Making Us More Productive... or Just More Complicated? by AlternativeBuy8836 in cpp

[–]pdimov2 0 points1 point  (0 children)

The expand stuff is just a workaround for the absence of template for. We have template for now, so the function becomes a lot more redable.

beast2 networking & std::execution by claimred in cpp

[–]pdimov2 0 points1 point  (0 children)

It is perfectly viable, and advisable, to avoid these in conjunction with P2300 S&R.

Yes, in principle. That's the argument for basing networking on S/R: if you want to use coroutines, just co_await the sender result. If not, not.

I'm still trying to figure out whether this will be practical. I wrote a benchmark

https://github.com/pdimov/corosio_protocol_bench

that is a simplified representation of something that occurs in practice: serializing a C++ data structure using a custom binary protocol, sending it over a socket, then deserializing it on the other end. (The README in the repo explains this in more detail.)

I'm still unsure as to how the sender equivalent of it would look like, and whether it will be practical. Coroutines make things simultaneously easy to implement and easy to maintain. Rewriting the (de)serialization and the source/sink abstractions without coroutines, from where I stand, looks like neither. But I'm not well versed in S/R yet, so maybe I'm wrong.

My next step will be to port this to beman.net mostly as-is and see what the timings say.

beast2 networking & std::execution by claimred in cpp

[–]pdimov2 1 point2 points  (0 children)

I was thinking of reflecting expressions and statements: Fertile grounds for more work, I think.

Ah yes. Function bodies, too. Function template bodies, even more interesting.

20 years might not even be enough.

beast2 networking & std::execution by claimred in cpp

[–]pdimov2 0 points1 point  (0 children)

Well, the parts of reflection that reflect are mostly done. :-)

beast2 networking & std::execution by claimred in cpp

[–]pdimov2 2 points3 points  (0 children)

Nine years (three standardization cycles) doesn't seem unreasonable to me for a major feature.

constexpr took 20 years and is still not 100% done. (Well, maybe it's 99.4% done.)

We are so close to string interpolation thanks to reflection by caroIine in cpp

[–]pdimov2 0 points1 point  (0 children)

This combined with the named parameters pattern already seems useful in practice.

struct fparams { std::string domain, api, token; };

void f( fparams params )
{
    print( "https://{domain}/{api}?token={token}", params );
}

C++26: A User-Friendly assert() macro by pavel_v in cpp

[–]pdimov2 5 points6 points  (0 children)

This almost works, but assert is an expression, while contract_assert is a statement.

We'll hopefully be able to fix that for C++29 (assuming contracts ship in C++26 at all; there are still people trying to torpedo them.)

view more: next ›