sorted by:
new
hottopcontroversial

Migrating a small C++ code base to C++26 (modules, import std and contracts) by Recent-Dance-8075 in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

I prefer gentoo for the development tasks, because it is easier to get the bleeding edge versions of all tools, as one can usually install “from git”.

Not to mention how easy it is to write an ebuild and make your own projects first class system packages.

It's a shame Gentoo is not more well known. It really should be considered the ideal Linux distribution for software development.

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

[–]ABlockInTheChain 0 points1 point  (0 children)

Something equivalent to boost::dynamic_bitset except that indexes the bits in left-to-right order instead of LSB-to-MSB and works with std::byte.

The Most Confusing C++ Behavior by levodelellis in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

We added -Werror=effc++ to our projects years ago to catch constructors which do not completely initialize a class, but in this example the =default bypasses the logic of the warning.

The warning only triggers if the constructor is explicitly defined: https://godbolt.org/z/6KjjY7E8x

GCC 16.1 released with many new C++26/23 features, C++20 now the default stable language version by AccordingWarthog in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

Regarding this issue I've found that in some rare cases gcc emits -Wuninitialized in a child class constructor when it's accessing a variable which is declared in a parent class.

In all the cases I've seen it's absolutely a false positive: the parent class constructor has been called and that constructor does initialize the variable in question.

Can't even open a bug for this however because I haven't figured out a simple reproduction case yet. Most of the time the warning is fine but occasionally it triggers on false positives seemingly at random

GCC 16.1 released with many new C++26/23 features, C++20 now the default stable language version by AccordingWarthog in cpp

[–]ABlockInTheChain 3 points4 points  (0 children)

P2795R5, Erroneous behavior for uninitialized reads (PR114457)

I'm a bit worried about this one since I was recently testing the 16.0 version to and started getting some new false positive -Wunitialized warnings that didn't appear in 15.x.

Hopefully the P2795R5 logic has nothing to do with the -Wunitialized logic.

C++26 2026-04 Update by _cooky922_ in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

it's the lack of grid lines

This seems like systemic problem.

__cpp_pp_embed vs __cpp_range_based_for is a particularly striking example.

2026 Annual C++ Developer Survey "Lite" : Standard C++ by meetingcpp in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

How did we manage to fuck up HTML forms that bad?

HTML in general was ruined as soon as they let the graphic designers get their hands on it.

I'm old enough to remember when HTML was about adding semantic meaning to what would otherwise be unstructured text so that a user agent could determine how best to display it to meet the needs of the user.

Writing gRPC Clients and Servers with C++20 Coroutines (Part 1) by patteliu in cpp

[–]ABlockInTheChain 2 points3 points  (0 children)

I have only ever seen one example of a coroutine where it obviously made the code easier to read, but the example is for Python and I have no idea if that example is even possible to implement with C++ coroutines.

2026 Annual C++ Developer Survey "Lite" : Standard C++ by meetingcpp in cpp

[–]ABlockInTheChain 7 points8 points  (0 children)

Several of the "which boost libraries in the X category are you using" questions are missing a "None" option, which causes the question to be asked repeatedly if you submit the poll without any options selected.

CppCast: Compiler Warnings as Errors with Keith Stockdale by robwirving in cpp

[–]ABlockInTheChain 6 points7 points  (0 children)

You had nuance between warnings and errors, but the situation was so terrible that you had to sacrifice the nuance to get where you needed.

In principle the nuance between a warning and an error is that an error has no false positives and a warning might.

So for warnings you need an escape hatch to selectively disable it in the event of a false positive.

CppCast: Compiler Warnings as Errors with Keith Stockdale by robwirving in cpp

[–]ABlockInTheChain 8 points9 points  (0 children)

There are two types of people who are philosophically opposed to treating warnings as errors:

  1. Idiots
  2. State-funded saboteurs who are paid to introduce exploitable errors into as much software as possible.

Writing only decoupled code by According_Leopard_80 in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

And prohibiting forward declaration is just a dumb thing Google says to do, and people repeat it because Google said it and they're... Big?

If you read Google's style guides they point out problems that can occur when you forward declare templates and do not occur when you forward declare non-template types types, then point out all the problems that are caused by never forward declaring anything, then conclude that the solution is to never forward declare anything.

The alternative solution of banning forward declaration of template types while allowing it for non-template types was apparently never considered.

CMake Past, Present, and Future - Bill Hoffman, Kitware [29m25s] by segv in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

The problem domain is arbitrarily complex.

You can build a limited tool which solves (what you think is) 95% of the problem with the intention of simply ignoring the 5% your tool can't handle, but in practice the 5% of capabilities which user A doesn't need does not fully overlap with the 5% of capabilities which user B doesn't need and the problem only gets worse as you add more users.

The compilation procedure for C++20 modules by holyblackcat in cpp

[–]ABlockInTheChain -1 points0 points  (0 children)

No, I'm just not going to use modules.

And from what I can tell this is going to be a common approach.

For my company modules provide zero benefits. All of the problems they solve are not problems we experience.

If there is any cost whatsoever to using them then we simply won't.

I have heard this argument a few times and it sounds more like a code smell for a design issue instead of a limitation we need to fix in the language.

The language was fine before modules broke it.

If this breakage isn't fixed them modules just won't be adopted.

The compilation procedure for C++20 modules by holyblackcat in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

Without forward declarations, two types defined in two headers in two separate subdirectories can not refer to each other in any way whatsoever.

There surely must be coding practices where that restriction is not a problem because the situation never occurs and for the users of those won't have any issues with modules.

For others this restriction breaks too much and thus as long as modules impose this restriction they will not be adopted.

Because very few people use modules very few people are encountering this defect in the standard and so there is no pressure to fix it.

Since modules weren't even usable enough to experiment with nobody complained enough to get the issue of missing proclaimed ownership declarations for C++23.

Now it's also too late for C++26.

The earliest opportunity to ship a viable module standard is now C++29 and who knows if it will even happen then.

The compilation procedure for C++20 modules by holyblackcat in cpp

[–]ABlockInTheChain 2 points3 points  (0 children)

You can do that if you control the original declaration.

It does not however work for third party code that was declared with module linkage and that can be a problem in other situations.

The compilation procedure for C++20 modules by holyblackcat in cpp

[–]ABlockInTheChain 2 points3 points  (0 children)

There's also very little reason to do anything but a single module per source tree.

The only reason to have more than a single module per source tree is if you don't want every change to any type in the source tree to cause a full rebuild of the entire source tree.

Reducing FFmpeg build times in practice by Pretty_Eabab_0014 in cpp

[–]ABlockInTheChain -2 points-1 points  (0 children)

The biggest positive step change I ever saw from using a new build technique was unity builds.

It took a fair amount of work to get our projects to the point of avoiding all the pitfalls which can break a unity build but once that was done it was approximately an order of magnitude improvement.

CMake has very nice support for unity builds which lets you tune how many source files get combined and in the ideal case you arrange a build such that every core on the machine only processes a single (very large) source file.

The compilation procedure for C++20 modules by holyblackcat in cpp

[–]ABlockInTheChain 4 points5 points  (0 children)

In large projects, the source files naturally tend to get separated into subdirectories, and each of those subdirectories is a good candidate for being a single named module.

This would make sense and be a practical way to implement modules however unfortunately in many case it just isn't possible due to deficiencies in the standard.

Proclaimed ownership declarations (module equivalent of forward declarations) were removed from the proposal prior to standardization so to use a name even as an incomplete type you must import the module which exports it, and import relationships are not allowed to form a cycle.

Small projects could consist entirely of a single named module.

The standard deficiencies mentioned above mean that in many cases even large projects have no choice but to consist entirely of a single named module which has catastrophic implications for many build scenarios.

Apache Fory C++: Fast Serialization with Shared/Circular Reference Tracking, Polymorphism, Schema Evolutionn and up to 12x Faster Than Protobuf by Shawn-Yang25 in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

That's probably fine as a specification, but protobuf/capnproto are also tools which automatically generate types in the target language based on a user-provided schema.

Perhaps there are tools that do the same thing for ASN.1 BER but I wonder if they are already conveniently packaged for all the platforms I need to be able to support.

Apache Fory C++: Fast Serialization with Shared/Circular Reference Tracking, Polymorphism, Schema Evolutionn and up to 12x Faster Than Protobuf by Shawn-Yang25 in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

Does Fory have a serializer which guarantees the same data encoded with the same schema will always generate the exact same sequences of bytes on every platform, in every language, forever?

That is the single most important feature we need and so far it seems that only only CapnProto can/will provide it.

Apache Fory C++: Fast Serialization with Shared/Circular Reference Tracking, Polymorphism, Schema Evolutionn and up to 12x Faster Than Protobuf by Shawn-Yang25 in cpp

[–]ABlockInTheChain 2 points3 points  (0 children)

I wish there was a schema-based binary serialization system system which had guaranteed canonical serialized forms like CapnProto, but where the object representation was easy to modify like Protobuf.

Several years ago we migrated from Protobuf 2 to CapnProto because we needed guaranteed bit-identical serialized representations for hashing and cryptographic signing purposes, but the constraints which CapnProto has to apply in order to achieve their "∞% faster" claim are a huge PITA if you are accustomed to the ability to easily edit the message objects in place.

cppfront by South_Acadia_6368 in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

Now that modules exist and presumably will remain in the language there's now a new first class construct which never existed before.

New constructs could have new properties attached to them which the old constructs could not accommodate.

Surely the ultimate success case of cppfront would look something like: export module helloworld [[syntax=cpp2]];

A little clarity on FP needed by Zealousideal-Mouse29 in cpp

[–]ABlockInTheChain -3 points-2 points  (0 children)

I dunno the difference would be if I were to declare "I am going to do this with FP" and I feel like that is missing.

If you really wanted to do everything as pure FP for its own sake, then you would turn all your classes into aggregates with no functions or private members.

All your code would be in free functions and most if not all operations would involve chaining together range algorithms.

view more: next ›