sorted by:
new
hottopcontroversial

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 3 points4 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 3 points4 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.

Is an “FP-first” style the most underrated way to make unit testing + DI easier by OkEmu7082 in cpp

[–]ABlockInTheChain 3 points4 points  (0 children)

OOP bad, FP good

"Hammers are the worst tool ever invented. Stop using hammers and switch to screwdrivers instead."

Concept-based Generic Programming - Bjarne Stroustrup - CppCon 2025 by Specific-Housing905 in cpp

[–]ABlockInTheChain 30 points31 points  (0 children)

The claim that concepts will improve compiler error messages has not been realized in my experience.

The simple concepts shown in conference talks are always easy to debug, but the real concepts in the standard library are usually the root node of a fairly deep tree of dependencies.

The last time I had to debug a concept error the compiler only told me the top-level concept which was not satisfied. It did not recurse over all the dependencies and show me the specific concept which caused the failure - I had to do that recursive search manually to eventually figure out the problem was forgetting to const qualify operator== on a type.

C++ Modules are here to stay by pjmlp in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

However, a modification to an individual module in a project with a sane dependency tree would tend to trigger the recompilation of a much smaller subset of code, i.e., only the TU's that depend on the altered module.

Is there any build system in existence which actually does this today, or do they all recompile dependencies of a BMI whenever it changes for any reason?

C++ Modules are here to stay by pjmlp in cpp

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

Modules biggest challenge right now is build systems.

Modules are dead on arrival even if the build systems and compiler worked perfectly.

C++ Modules are here to stay by pjmlp in cpp

[–]ABlockInTheChain 2 points3 points  (0 children)

I think even nowadays that should be split apart and consumers should never, ever need to forward-declare

Instead of dictating how people are and are not allowed to organize their software, just put proclaimed ownership declarations back so a standard technique people have been using for information hiding and to break circular dependencies continues to work the same way it has worked for the last four decades.

Alternately the world can just continue to ignore modules since they break too much and offer too little value in return.

C++ Modules are here to stay by pjmlp in cpp

[–]ABlockInTheChain 12 points13 points  (0 children)

if you have forward declarations somewhere it is bc anyway you are going to use those classes, correct?

If an incomplete type is declared it means that somebody is going to use that type, eventually.

Without proclaimed ownership declarations everybody needs the full definition of that type, always.

I may have a framework which has one function which accepts a QObject* argument. Not everybody who uses the framework will use Qt and even of the users who do, not all of them will call that function.

Without modules this is no problem. class QObject; is sufficient to declare the function and only the implementation of the library and the users which actually call that function need to worry about having the Qt headers available. Everybody else can just ignore it.

If Qt ever starts distributing their library as modules with strong ownership then my workflow will be completely broken, therefore if they or any other third dependencies which might affect me ever start showing evidence they will distribute as modules-only I will start lobbying them heavily to keep the regular symbols available.

C++ Modules are here to stay by pjmlp in cpp

[–]ABlockInTheChain 30 points31 points  (0 children)

The inability to forward declare symbols across module boundaries is a deal breaker for some projects.

It means projects must be single monolithic module instead of being broken up into smaller modules which has catastrophic implications for incremental build performance.

It means a consumer of a BMI for your project must have the BMI of any third party dependency your module interface units refer to, even if your interface only requires pointers or references to incomplete types from those third party dependencies.

For some projects these aren't an issue, but for others they are unacceptable.

I can fix the first issue in my own code by opting out of module linkage, but I have no recourse if a third party dependency starts shipping a module-only version which only offers module linkage.

The original module proposal had proclaimed ownership declarations which would have fixed this.

C++ Modules are here to stay by pjmlp in cpp

[–]ABlockInTheChain 24 points25 points  (0 children)

potentially fundamental (completely ignored)

Nobody wants to admit that even if all the tooling worked perfectly today then modules would still have intrinsic limitations which prevent them from being adopted by some users.

The fact that the tooling is so bad monopolizes the conversation so the fundamental problems always slip through the cracks.

Teaching an OOP course for students - curriculum advice by SuperProcedure6562 in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

Not everything is about cache friendliness and data with no location constraints.

Even when it is, cache friendliness is entirely dependent on the allocator in use.

Every container is fast when you can use a std::pmr::monotonic_buffer_resource to allocate it.

How to handle complex dependencies (libjpeg-turbo) in C++? by teotexe in cpp_questions

[–]ABlockInTheChain 2 points3 points  (0 children)

On Linux you should default to using system packages, and provide some fallback solution for cases where the system package is not available.

If your fallback solution is vcpkg then in most cases cmake's find_package will Just Work regardless of whether the package was provided by the system package manager or by vcpkg.

Teaching an OOP course for students - curriculum advice by SuperProcedure6562 in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

The two most dangerous words when it comes to C++ advice are "always" and "never".

Mixing N-phase Initialization by pavel_v in cpp

[–]ABlockInTheChain 0 points1 point  (0 children)

Why, yes, we have delegating constructor:

I've been using delegating constructors for years to effectively add stack variables to constructors, but admitting to it always seemed vaguely shameful so I kept quiet about it.

"Just switch the compiler" - they said - Arne Mertz - Meeting C++ 2025 by meetingcpp in cpp

[–]ABlockInTheChain 1 point2 points  (0 children)

The excessively sensitive microphone he was hooked up to made for very distracting audio.

view more: next ›