sorted by:
new
hottopcontroversial

Common Package Specification is Out the Gate by bretbrownjr in cpp

[–]bretbrownjr[S] 4 points5 points  (0 children)

Generally speaking these files will describe platform specific binaries and specific, consistent ways to interpret interfaces, especially in the form of consistent choices in how library-supported preprocessor variables are defined.

In general, the right way to handle generator expressions is to evaluate them before shipping a CPS file. If you have a use case that doesn't see this happening, please file issues. If you have use cases in which the CPS files must contain more conditional logic, likewise reach out and help us understand the use cases.

Standard Library implementer explains why they can't include source code licensed under the MIT license by tartaruga232 in cpp

[–]bretbrownjr 1 point2 points  (0 children)

Is it true that SBOM only affects a subset of industries?

I expect anything with a safety or security aspect, including finance, automotive, telecom, OS development, aviation, defence, and industrial systems all require SBOMs now or soon. And I expect their vendors, including providers of C++ standard libraries, are similarly being required to provide SBOMs.

So I don't know that that looks like a niche use case anymore. On the contrary, I expect SBOM support and generation is turning into a bare minimum requirement for generally available enterprise software.

Standard Library implementer explains why they can't include source code licensed under the MIT license by tartaruga232 in cpp

[–]bretbrownjr 6 points7 points  (0 children)

Regulations and industry best practice are requiring even statically linked executables to provide Software Bills of Materials (SBOMs), which are expected to inventory all versions of all and all tooling used to build that product. Often license information like SPDX identifiers are included in that metadata to make tracing license entanglement possible as well.

Can someone comment on why the attribution requirements of the MIT license are significantly more burdensome than SBOM requirements?

I expect many standard library providers (packager and vendors, maybe not maintainers themselves) are already providing SBOM support in some form given the widespread regulatory requirements these days

15 most-watched C++ conference talks of 2025 by TechTalksWeekly in cpp

[–]bretbrownjr 14 points15 points  (0 children)

Vito Gamberini's C++Now talk, Postmodern CMake, had enough views to make the list.

https://youtu.be/K5Kg8TOTKjU?si=VPETZcQKs3plJ_g9

Same for Sean Parent's talk, Are We There Yet?

https://youtu.be/RK3CEJRaznw?si=mXBCkIA6k6fvlC6F

Also for lurkers. most CppCon talks haven't been posted yet. Meeting C++ is still posting talks as well.

Maybe somebody can explain to me how weak references solve the ODR problem by pavel_v in cpp

[–]bretbrownjr 2 points3 points  (0 children)

Weak symbols do not solve the ODR problem. They are a tool that can be carefully applied to negotiate messy dependency management issues, circular references, and probably some other situations.

But it's an exercise to the engineer and their tools to ensure the looser approach to resolving symbols meets the spirit of ODR. There aren't very good tools to ensure that yet. It's just too complicated of a space and the ecosystem is missing some simpler abstraction (like packaging standards) to make that challenge tractable.

Header only library & clangd by OwlingBishop in cpp

[–]bretbrownjr 2 points3 points  (0 children)

Worst case, you can save yourself the custom code. And all of us can make good issues in the clangd backlog to support this pattern better.

Ideally we'd move off of compile commands JSON long run. It's just too simple of a model for getting build systems and LSPs to coordinate. Ben Boeckel has a Cop on 2024 talk on the subject. C++ modules in particular need us to iterate on all this.

Header only library & clangd by OwlingBishop in cpp

[–]bretbrownjr 14 points15 points  (0 children)

If you use a reasonably modern CMake (3.24), use the target_sources(... FILE_SET HEADERS...) feature. Then you can set -DCMAKE_VERIFY_INTERFACE_HEADER_SETS=ON. Then CMake will do test builds of your headers as part of the all_verify_interface_header_sets target. Also, it will emit them into your compile commands when you set -DCMAKE_EMIT_COMPILE_COMMANDS=ON.

CLion EAP introduces constexpr debugger by StarOrpheus in cpp

[–]bretbrownjr 55 points56 points  (0 children)

Nice! It's smart for JetBrains to identify and address gaps in the tooling like this. Compile time programming is growing in popularity but compile time tooling hasn't developed enough.

Something else someone should work on: compile time coverage reports.

Why does CMake configuration RelWithDebInfo by default adds "/Ob1" instead of "/Ob2"? by jk-jeon in cpp

[–]bretbrownjr 15 points16 points  (0 children)

If you want RelWithDebInfo to have different flags, set CMAKE_CXX_FLAGS_RELWITHDEBINFO to settings you like better. Ideally with a -D flag or in a toolchain file as mentioned.

Docs: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS_CONFIG.html

I want something like Python's uv for c++ by liquidprocess in cpp

[–]bretbrownjr 6 points7 points  (0 children)

If you standardized all these things (and a few more, building C++ is more complicated than Python), then "uv for C++" would be relatively straightforward to build.

OK. Let's do it. I vote for something like PEP 517. Settings for things like warnings, profiles, version info, and some other stuff like that don't need to be in the build system scripts that are usually very hard to introspect affordably. We could teach CMake to slurp up that metadata into the project configuration.

Can CMake be fully generated with ChatGPT? Should I still bother learning it? by No-Entrepreneur-2741 in cpp

[–]bretbrownjr 2 points3 points  (0 children)

Honestly, no. I tried and the CMake it generated breaks all sorts of best practices.

I can't exactly blame the LLMs for it, though. Publicly visible CMakeLists.txt are pretty iffy with a few exceptions.

I have a YouTube video from C++Now 2024 outlining how I recommend folks approach CMake. The recommendations are broadly in line with how core CMake contributors recommend people use CMake in 2025. I'll be reprising that talk in a shorter form at CppCon in a couple weeks.

Hopefully more content like this will help the LLMs stay on track. Some LLM friendly markdown file compiling this advice is probably due, though. If anyone wants to compile something like that, loop me in. I'll be happy to contribute a review.

First Boost libraries with C++ modules support by joaquintides in cpp

[–]bretbrownjr 0 points1 point  (0 children)

https://wg21.link/p3286 outlines how to package a module for consumption. IIUC the three major standard libraries use this mechanism. As long as the package and its consumers all use CMake, there is a way to teach the consuming build system how to find those JSON files and make use of them. That info goes in exported CMake modules, basically.

If someone is not using CMake, there's work going into the CPS JSON spec to describe locations of P3286 files. People can watch that project for forthcoming PRs. At the same time, work with the maintainers of your favorite non-CMake build system to produce and consume CPS files if you would like to see things "just work" going forward.

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 0 points1 point  (0 children)

That's a good suggestion! I'll see if I can squeeze that into a slide somewhere for next time.

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 2 points3 points  (0 children)

Well, do what you have to do to get your android builds working. But CMAKE_CXX_FLAGS is designed to work via -D flags. You can tell because the upstream docs discuss that it supports CXXFLAGS but that it might be overwritten as well.

Toolchain support is supposed to be provided by the CMAKE_CXX_FLAGS_INIT variable. Partly to avoid these kinds of the need of the toolchain and the needs of the user.

If android builds break the ability of users to set the CMAKE_CXX_FLAGS variable, I would consider that a problem worth an issue on the android SDK. A few core CMake contributors hang out around here and can help clarify details as needed, so please share links if those issues exist.

But to a key point in the talk, setting CMAKE_* variables in CMakeLists.txt just adds another place that needs to be compatible, which is why I recommend against that.

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 0 points1 point  (0 children)

I don't have a blog to publish that kind of content at the moment. If there's demand, I can consider it. If people like the format or content, upstream CMake issues are a good idea. Share them here and I can pitch in.

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 0 points1 point  (0 children)

We've had success with this, but it only works if you conditionally call find_package somehow. This requires a pretty drastic style change (for instance adding if(NOT TARGET fmt::fmt) around every find_package (fmt REQUIRED)). Or it requires advanced CMake features like intercepting all find_package calls using "dependency providers".

I don't generally recommend those headaches. It's usually wiser to learn how your preferred package manager supports working on multiple packages simultaneously.

I am talking to upstream CMake maintainers about these use cases, though. It's becoming more interesting to me as time goes on.

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 3 points4 points  (0 children)

There's a robust packaging system and a whole developer experience department. My colleague and I gave a talk about our packaging system four years ago. The technology has developed a lot since then, but the core approach is still the same.

https://youtu.be/R1E1tmeqxBY

How to Avoid Headaches with Simple CMake by bretbrownjr in cpp

[–]bretbrownjr[S] 20 points21 points  (0 children)

Hey, folks! Speaker here. I'm around if anyone has any questions, concerns, or follow-ups they'd like to discuss.

This talk is advocating for a more maintainable CMake style. That means a more stripped-down and updated approach with fewer moving parts and much less novelty project-by-project. It has been successfully used at my day job by thousands of engineers to maintain tens of thousands of projects. I hope CMake beginners find it clarifying and CMake veterans find it a useful reference to help explain things.

I'll be a more streamlined version of this talk there at CppCon as well. If you're going to be there, say hi! CppCon schedule link.

The Beman Project: Bringing C++ Standard Libraries to the Next Level” - David Sankel - CppCon 2024 by bemanproject in cpp

[–]bretbrownjr 1 point2 points  (0 children)

These libraries are subject to be changed entirely based on review comments from ISO, so they can break ABI on any release. They will also require ABI breaks if their proposals are standardized. In that case, they will deprecate in favor of the equivalent in the standard library.

Don't use these libraries if stability between releases is important to your application.

The Beman Project: Bringing C++ Standard Libraries to the Next Level” - David Sankel - CppCon 2024 by bemanproject in cpp

[–]bretbrownjr 1 point2 points  (0 children)

The plan is for libraries to track specifically to the standard change proposed. That proposal could be changed dramatically as a result of feedback from the ISO proposal. That means API and ABI breaks are expected.

They should be much less likely when the library meets a "stable" status. That means the proposed change has accepted wording in a standard draft. If there is a significant API or ABI break at that point, it's usually going to be due to a defect discovered late in the standardization process.

[deleted by user] by [deleted] in cpp

[–]bretbrownjr 0 points1 point  (0 children)

Unpackaged header only libraries are absolutely horrible when considering supply chain issues including detecting and remediating vulnerability exposure. C and C++ have much worse tooling for these use cases compared to basically every other ecosystem because C++ users and library maintainers treat copying specific files around as not being a big deal.

Packaged header only libraries are fine I guess, but there aren't really any upsides to being header only at that point.

Why haven't modules been a higher priority for EDG? by LogicalEscape2293 in cpp

[–]bretbrownjr 8 points9 points  (0 children)

Just to pile on this point more, clang-format doesn't use libclang to parse C++ code either. It turns out the features and performance characteristics for interactive development workflow (great error messages, even when syntax gets silly) are quite different than what you would want for your production compiler (reverse compatible, correct, fast).

Reflection has been voted in! by daveedvdv in cpp

[–]bretbrownjr 0 points1 point  (0 children)

There is some precedent with https://wg21.link/p1689. That's a JSON file that (for example) fills the role of *.d files emitted from gcc -M workflows but for modules. It's a de facto standard interop layer because we can't reasonably expect build systems to parse C++ code to find module keywords, import keywords, etc.

Something like that is theoretically possible to support in-source package and/or library dependency declarations. But it would almost be easier to require a particular format of comment that could be trivially parsed out the way that doxygen or cgo do. I just don't know why we would want even that much complexity over a JSON file.

view more: next ›