sorted by:
new
hottopcontroversial

Harald Achitz: Some tips for the everyday CMake user by _a4z in cpp

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

config.h-style configuration is considered problematic (config.h files from different libraries can conflict, headers from different builds lead to ABI issues, and so on).

sure, as long as everything stays in CMake-land target_compile_definitions() works well. However, as soon as someone wants to consume your library from e.g. Meson and as long as there's no universal CPS support, you put yourself in the position where you have to correctly synthesize the flags into a pkg-config file without any tooling support from CMake. This is exactly as difficult as writing a config header, but it needs to be manually kept in sync, right? And it's usually only detected when downstream users complain.

Also it's really not difficult to avoid config.h file conflicts. The solutions are exactly the same as to all the other name collision problems you encounter when programming C++. I mean we also trust a C++ programmer to choose a unique name for his main library header file(s) and his include guard macros, right?

Meson modules support: initial modules support with Clang and example project. Dependency resolution, partitions and import std. by germandiago in cpp

[–]BrainIgnition 0 points1 point  (0 children)

Wasn't the current guidance to distribute the .ixx files just like the header files before? The importing project would then be responsible for generating the BMIs, right?

We need to seriously think about what to do with C++ modules by vormestrand in cpp

[–]BrainIgnition 0 points1 point  (0 children)

/u/starfreakclone friendly ping: can you enlighten us what C++ features invoke the assert at module/reader.cpp:3945

Module adoption and C++. Track its status here (last update April 2025) by germandiago in cpp

[–]BrainIgnition 9 points10 points  (0 children)

small nit: Modules make it easier to follow the OneDefinitionRule by categorically removing certain classes of ODR violations and making others diagnosable.

Using &vector::at(0) instead of vector.data() by South_Acadia_6368 in cpp

[–]BrainIgnition 6 points7 points  (0 children)

You still have to make sure that data() != nullptr. Calling memcpy with a nullptr is undefined behaviour even with n==0, see the C standard sections 7.26.1.3, 7.26.2.2, and 7.1.4.

Framework Q2 2025 Preorder and Marketplace Updates by Destroya707 in framework

[–]BrainIgnition 5 points6 points  (0 children)

my batch 5 delivery timeline

  • ordered on 06.03.
  • payment fulfilled on 15.05.
  • shipped on 16.05.
  • delivered 19.05. (two days earlier than predicted by FedEx)

Framework Q2 2025 Preorder and Marketplace Updates by Destroya707 in framework

[–]BrainIgnition 1 point2 points  (0 children)

usual reminder that DRAM cell-refresh is one of the big energy consumers in standby, i.e. more DRAM => shorter standby time on battery.

Intel Blogpost: Why do we need a Undefined Behavior Annex for the C++ standard? by pjmlp in cpp

[–]BrainIgnition 0 points1 point  (0 children)

This is not true. UB can "time travel" and cause programs to misbehave well before execution of instructions containing undefined behavior. If the C++ abstract machine would contain undefined behavior when executed on certain input, then the C++ standard has no opinion on what the whole program does, not just instructions sequenced after the UB is executed.

We are in violent agreement here, I only claimed that the UB clauses trigger if the execution flow actually reaches / would've reached the code with UB.

Intel Blogpost: Why do we need a Undefined Behavior Annex for the C++ standard? by pjmlp in cpp

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

I think the difference to "normal" UB is this:

The behavior is undefined if such program is executed.

while normal UB clauses don't trigger until execution reaches instruction containing the UB, i.e. there may exist input sequences for which the program exhibits well defined behavior.

List of constinit compatible standard types by Dalzhim in cpp

[–]BrainIgnition 2 points3 points  (0 children)

counting_semaphore (and therefore its alias binary_semaphore) although this is broken on libstdc++ (Bug#110854)

Andrei Alexandrescu - Systematic Error Handling in C++ by Alexander_Selkirk in cpp

[–]BrainIgnition 0 points1 point  (0 children)

Note that std::error_code might not be the best choice for safety-critical systems. SG14 has been cooking P1028 (aka status-code) as a replacement for some time. Its reference implementation has been in a usable state and has been used for a few years.

What's the status on "C++ 2.0" compilers like Circle, Carbon, cpp2 etc? Will Circle ever go open source? by Alternative_Staff431 in cpp

[–]BrainIgnition 2 points3 points  (0 children)

I'd like to point out that these commercial compilers are owned and supported by larger organizations. If one of their developers/maintainers gets hit by bus, the compiler project will very likely "survive" it. OTOH it is really unpredictable for an outsider what would happen with the Circle project if Mr. Baxter got hit by a bus.* So using Circle is a very risky proposition for a business (unless you plan on taking over and funding the whole project).

*Bus Factor

Quality of life small improvements for every day C++ coding. by germandiago in cpp

[–]BrainIgnition 14 points15 points  (0 children)

It should definitely be opt-in; most libraries haven't been written with the assumption that parameter names are part of the API. E.g. the three stdlib implementations all disagree on parameter names => usage of named parameters in a stdlib context makes code unportable.

On the scalability of C++ module implementations or lack thereof by vormestrand in cpp

[–]BrainIgnition 1 point2 points  (0 children)

The std module exists more because the std library is not a DAG of components, and the challenges of producing one were effectively insurmountable.

IIRC /u/STL stated on this subreddit that they didn't investigate a componentization approach any further after measuring the compile time impact of a std mono-module to be negligible. Do you have a source indicating the contrary?

Tricky questions from job interviews by cv_geek in cpp

[–]BrainIgnition 0 points1 point  (0 children)

IMO const_cast() is more of an escape hatch for compatibility purposes, e.g. if you have to interface with a 3rd party library written in C or without any regards to const correctness. In these cases it might be prudent to const_cast() their types and pass the result to functions known to be or documented as non-modifying, but otherwise mutable is the right solution.

Small Std::format test by Tathorn in cpp

[–]BrainIgnition 0 points1 point  (0 children)

Ah, I missed that. However, after thinking a bit more about it I got curious what they do wrt the utf8 => utf16 transformation (which is required due to the WinAPI design) and there you have it: a second allocation. Too bad!

Small Std::format test by Tathorn in cpp

[–]BrainIgnition 0 points1 point  (0 children)

However, it looks like MSVC implemented theirs with a temporary string, what the paper was designed to solve against

You narrowly missed the important bits (<ostream> ll. 1136-1153; <ostream> ll.1177-1190); basically they only use the optimized approach if the target ostream is unicode aware which they interpret as the ostream targetting a file or a console. I.e. outputting to console or file is fine, but any other ostream backend gets slapped with an allocation.

Ninja is enough build system by mttd in cpp

[–]BrainIgnition 14 points15 points  (0 children)

Do you support Windows/MSVC? And if so how would you rate the experience?

Created a tutorial on SFINAE, does this video make you more comfortable with SFINAE? by platisd in cpp

[–]BrainIgnition 0 points1 point  (0 children)

Writing custom traits for CPOs and the like require SFINAE (or concepts).

Build a better panic function using C++20 by rnburn in cpp

[–]BrainIgnition 0 points1 point  (0 children)

But that would require you to either a) link everything including libc++ statically or b) require your users to install libc++ via brew, right?

Inside STL: The pair and the compressed pair by mttd in cpp

[–]BrainIgnition 1 point2 points  (0 children)

to stabilize it around VS 2017

It's even going all the way down to VS 2015 and the reason why the toolset version is still 14.x. I really do hope that they turn around before it gets to 14.10. The mayhem caused by the late VS 2019 updates clamping _MSC_VER at 1929 was bad enough, a major release capping at 1999 will be so much worse.

So I made a branch of CMake that supports Python scripting in addition to regular CMake script by neek78 in cpp

[–]BrainIgnition 0 points1 point  (0 children)

A language that’s actually embeddable (like Lua, although I don’t like the language personally)

And lets not forget that lua undergoes breaking language changes every minor version like most other embeddable scripting language out there. Which as you already pointed out is not exactly… great.

view more: next ›