I'm really enjoying learning C++ but not sure taking a udemy course can help me be employable.

I need to get proper trianing and build real projects, any recommendations?

Thank you.

I hear a lot that C++ is not a suitable language for data analysis, and we must use something like Python. Yet more than 95% of the code for AI/data analysis is written in C/C++. Let’s go through a relatively involved data analysis and see how straightforward and simple the C++ code is (assuming you have good tool which is a reasonable assumption).

Suppose you have a time series, and you want to find the seasonality in your data. Or more precisely you want to find the length of the seasons in your data. Seasons mean any repeating pattern in your data. It doesn’t have to correspond to natural seasons. To do that you must know your data well. If there are no seasons in the data, the following method may give you misleading clues. You also must know other things (mentioned below) about your data. These are the steps you should go through that is also reflected in the code snippet.

1. Find a suitable tool to organize your data and run analytics on it. For example, a DataFrame with an analytical framework would be suitable. Now load the data into your tool
2. Optionally detrend the data. You must know if your data has a trend or not. If you analyze seasonality with trend, trend appears as a strong signal in the frequency domain and skews your analysis. You can do that by a few different methods. You can fit a polynomial curve through the data (you must know the degree), or you can use a method like LOWESS which is in essence a dynamically degreed polynomial curve. In any case you subtract the trend from your data.
3. Optionally take serial correlation out by differencing. Again, you must know this about your data. Analyzing seasonality with serial correlation will show up in frequency domain as leakage and spreads the dominant frequencies.
4. Now you have prepared your data for final analysis. Now you need to convert your time-series to frequency-series. In other words, you need to convert your data from time domain to frequency domain. Mr. Joseph Fourier has a solution for that. You can run Fast Fourier Transform (FFT) which is an implementation of Discrete Fourier Transform (DFT). FFT gives you a vector of complex values that represent the frequency spectrum. In other words, they are amplitude and phase of different frequency components.
5. Take the absolute values of FFT result. These are the magnitude spectrum which shows the strength of different frequencies within the data.
6. Do some simple searching and arithmetic to find the seasonality period.

As I said above this is a rather involved analysis and the C++ code snippet is as compact as a Python code -- almost. Yes, there is a compiling and linking phase to this exercise. But I don’t think that’s significant. It will be offset by the C++ runtime which would be faster.

using DT_DataFrame = StdDataFrame<DateTime>;

DT_DataFrame   df;

df.read("IcecreamProduction.csv", io_format::csv2);

// These parameters must be carefully chosen
//
DecomposeVisitor<double>    d_v {
    180, 0.08, 0.0001, decompose_type::additive
};

df.single_act_visit<double>("IceCreamProduction", d_v);

const auto  &trend = d_v.get_trend();
auto        &data = df.get_column<double>("IceCreamProduction");

// Optional: take the trend out
//
for (std::size_t i { 0 }; auto &datum : data)
    datum -= trend[i++];

// Optional: Differencing to take serial correlation out
//
double  prev_val { data[0] };

for (auto &datum : data)  {
    const double    tmp = datum;

    datum -= prev_val;
    prev_val = tmp;
}
data[0] = data[1];

fft_v<double>   fft;

df.single_act_visit<double>("IceCreamProduction", fft);

// We assume the time series is per one unit of time
//
constexpr double    sampling_rate = 1.0;
const auto          &mags = fft.get_magnitude();
double              max_magnitude = 0.0;
std::size_t         dominant_idx = 0;

for (std::size_t i { 0 }; i < mags.size(); ++i)  {
    const double    val = std::fabs(mags[i]);

    if (val > max_magnitude) {
        max_magnitude = val;
        dominant_idx = i;
    }
}

const double    dominant_frequency =
    double(dominant_idx) * sampling_rate / double(mags.size());
const double    period = 1.0 / dominant_frequency;

std::cout << "Max Magnitude: " << max_magnitude << std::endl;
std::cout << "Dominant Index: " << dominant_idx << std::endl;
std::cout << "Dominant Frequency: " << dominant_frequency << std::endl;
std::cout << "**Period**: " << period << std::endl;

Every library needs to be included, built in 1 of 5 completely different ways, or its binaries downloaded, how do you guys keep track of all of these things? Setting things up takes up hours of frustrating error hunting and by the end I'm too exhausted to work on my actual project.

Am I missing something? Am I just not built for this?

Use this thread to share anything you've written in C++. This includes:

• a tool you've written
• a game you've been working on
• your first non-trivial C++ program

The rules of this thread are very straight forward:

• The project must involve C++ in some way.
• It must be something you (alone or with others) have done.
• Please share a link, if applicable.
• Please post images, if applicable.

If you're working on a C++ library, you can also share new releases or major updates in a dedicated post as before. The line we're drawing is between "written in C++" and "useful for C++ programmers specifically". If you're writing a C++ library or tool for C++ developers, that's something C++ programmers can use and is on-topic for a main submission. It's different if you're just using C++ to implement a generic program that isn't specifically about C++: you're free to share it here, but it wouldn't quite fit as a standalone post.

Last month's thread: https://www.reddit.com/r/cpp/comments/1hrrkvd/c_show_and_tell_january_2025/

A new release of the legendary sqlite_orm library! 🚀

This is a minor release—no uber features, but compared to other minor releases, this one is the least minor of all the minor ones!

Now, let’s go over the new features:

• New drop functions: storage.drop_table_if_exists, storage.drop_index_if_exists, and storage.drop_trigger_if_exists for those who needed alternatives to storage.drop_table, storage.drop_index, and storage.drop_trigger.

• Two new pragma fields: locking_mode and max_page_count.

• More convenient API for declaring FOREIGN KEY constraints when working with inherited mapped structures. Instead of writing:

foreign_key(&Classroom::student_id).references(column<Student>(&Base::id))

you can now write a shorter version:

foreign_key(&Classroom::student_id).references<Student>(&Student::id)

• CTE support for CRUD operations.

• Overloaded bitwise operators and unary minus.

• New example in the examples folder: any.cpp—a powerful demonstration of how to bind std::any to SQLite using sqlite_orm, allowing operations on std::any without additional serialization.

• VSCode integration: Added .vscode folder with preconfigured settings. Now, if you’re contributing to sqlite_orm, you can execute important actions directly from VSCode using Command Palette → Run Task. You can trigger formatting, run the amalgamation script, and execute unit tests right from your IDE!

• Optimized serialization: Removed unnecessary parentheses—fewer bytes mean lower memory consumption.

• More constexpr functions for better compile-time evaluation.

• Bug fixes & improvements: 4 bugs fixed + 3 important refinements applied.

Enjoy the update! 🚀✨

https://github.com/fnc12/sqlite_orm/releases/tag/v1.9.1

CppCon

2025-01-27 - 2025-02-02

• Refactoring C++ Code for Unit testing with Dependency Injection - Peter Muldoon - https://youtu.be/as5Z45G59Ws
• C++ Under the Hood: Internal Class Mechanisms - Chris Ryan - https://youtu.be/gWinNE5rd6Q
• Secrets of C++ Scripting Bindings: Bridging Compile Time and Run Time - Jason Turner - https://youtu.be/Ny9-516Gh28
• Building Safe and Reliable Surgical Robotics with C++ - Milad Khaledyan - https://youtu.be/Lnr75tbeYyA
• ISO C++ Standards Committee Panel Discussion 2024 - Hosted by Herb Sutter -https://youtu.be/GDpbM90KKbg

Audio Developer Conference

2025-01-27 - 2025-02-02

• Keynote: Foundation Models Don’t Understand Me - Lessons From AI Lutherie for Live Performances - Manaswi Mishra - https://youtu.be/SnbJpvz86SM
• Shrink Your Virtual Analog Model Neural Networks! - Christopher Clarke - https://youtu.be/lZxfv0euB98
• In Praise of Loudness - Samuel Fischmann - https://youtu.be/0Hj7PYid_tE

For those interested in exploring concurrency or micro-benchmarking, I’ve developed a c++ library that includes a collection of concurrent data structures/sync primitives. Additionally, it features a dedicated benchmarking branch with all the necessary submodules preconfigured, easy to dive into micro-benchmarking against boost right away. This Wiki is good place to start.
Any feedback/criticism is welcome.... contributions as well.

I have been doing a lot with robotics developement recently, ROS to be more percise, but my issue is I never really learned or worked with C++. I went through the learncpp.com and some other cpp learn site, but I would really love to learn through some projects, but I have no idea where to start. Does anyone have any good recommendations for where could I learn C++ throughout small projects and tasks? Preferably with solutions or code explanations alongside to give me a bit of guidance on how things should be. I intend to move onto working with openCV in the future and maybe even embedded systems on the long run. Thanks!

I developed a logger in C++23 and I need opinions so I can make it better, any feedback would be very appreciated!

https://github.com/adrianovaladar/logorithm

I like the idea of concepts. Adding compile time checks that show if your template functions is used correctly sounds great, yet it feels awful. I have to write a lot of boilerplate concept code to describe all possible operations that this function could do with the argument type when, as before, I could just write a comment and say "This function is called number_sum() so it obviously can sum only numbers or objects that implement the + operator, but if you pass anything that is not a number, the result and the bs that happens in kinda on you?". Again, I like the idea, just expressing every single constraint an object needs to have is so daunting when you take into account how many possibilities one has. Opinions?

Some of the embedded courses require you to have particular MCUs, kits etc.

What if you only have a good laptop and that's it? I'll be able to get STM32/raspberry pi after 3 months, but for the first 3 months, I'd like to just learn C++ that will be helpful to me later as an embedded programmer. My embedded goals would be knowing how to write STM32 code, write linux drivers for various cameras, audio codecs, sensors, display stuff etc.

I already have Visual studio, but also have ubuntu installed as a second OS, so pretty flexible here. Right now I'm learning about assembly (just to get a feel of what happens under the hood).

I know a little bit of python, and already know basics of C (pointers, loops, structs etc).

I know Ritchie's book is getting recommended, but I wish there was a resource that would allow me to build a project. Like to put to use my C++ skills right away, so to speak. Again, this is for junior level for now.

After working on this project for so long, I've done it! importizer v1.0.0 is out today.

Ready to switch from header-based code to the power of C++20 modules? Importizer makes the transition simple and fast, saving you time and effort!

Two Modularization Options:

• Complete Modularization: Ready to ditch header files entirely and embrace the full power of C++20 modules? This is the default option for a complete switch.
• Transitional Modularization: Want to keep both header-based and module-based interfaces for compatibility during the switch? Specify [Transitional] in your toml setting file, or use the "transitional" flag on the command line.

After running, just choose what to export, and your project is ready for use again. Transitional modularization will break very little to the header-based project, while providing a module interface for C++ module users.

Try it out on your codebase today! Let me know if it works!

Two months ago was the C++ Committee meeting, in Wrocław, Poland 🇵🇱, and the work on C++26 is ongoing!

The features voted on will be added gradually to the working draft, and will likely be officially released on the next C++ version (C++26), barring any subsequent changes. This was one before the last meeting for forwarding C++26 features.

The meeting site was lovely, with the beautiful Wroclaw market, museum, river, parks and Racławice panorama were all within walking distance.

The hotel was convenient, and the meeting organizers ran the meeting well. The hybrid (on-site/online) experience worked as expected. We appreciate that greatly!

We will continue operating hybrid meetings going forward.

Main C++26 Features approved in Wrocław: 🎉

• Improvements for structured bindings
  • P1061R10: Structured Bindings can introduce a Pack
  • P2686R5: constexpr structured bindings and references to constexpr variables
• P3068R6: Allowing exception throwing in constant-evaluation
• P1928R15: std::simd — merge data-parallel types from the Parallelism TS 2 🥳
• P3019R11: indirect and polymorphic: Vocabulary Types for Composite Class Design
• P3138R5: views::cache_latest
• P2897R7: aligned_accessor: An mdspan accessor expressing pointer over-alignment
• Improvements to std::atomic and std::atomic_ref (P2835R7, P3323R1, P3309R3)

Language Progress

Evolution Working Group (EWG) Progress

This week was dedicated to papers which might plausibly affect C++26.

Contracts:

• P2900r11: contracts for C++ — Forwarded to LEWG and CWG for inclusion in C++26 (current estimation is for them to go to plenary in February 2025 in Hagenberg, Austria).
• Added support for contracts on coroutines as proposed in P2957R2
• No added support for contracts on function pointers as explained in P3327r0
• No added support for stricter contracts (in addition to the current default relaxed contracts) as suggested in P3362R0 /P2680R0 / P3285R0, and keep relaxed the default based on the discussion in P3499R0
• const-ification remains in the contracts proposal, see discussion in P3261R1 / P3478R0
• Adopted a few fixes from CWG/SG21, see “P3520R0: Contracts for C++: Wrocław technical fixes”
• Adopted “P3510R1: Leftover properties of this in constructor preconditions”

Reflection:

• SG7 forwarded recommendation to use ^^ (unibrow) syntax for reflection, based on “P3381R0: Syntax for Reflection”
• The accessibility of members through reflection was discussed and recommended to maintain the P2996 status quo, whereby members which are regularly inaccessible are accessible through reflection:
  • P3437R1: Proposed default principles: Reflect C++, Generate C++ - Discussed
  • P3451R0: A Suggestion for Reflection Access Control — No consensus to change P2996
  • P3473R0: Splicing Should Respect Access Control — No consensus to change P2996
  • P3493R0: Syntax for Reflection — Ruminations on reflection and access
• P3394R1: Annotations for Reflection — Forwarded to CWG
• P3289R1: Consteval blocks — Forwarded to CWG
• P3273R0: Introspection of Closure Types — No consensus
• P3293R1: Splicing a base class subobject — Forwarded to CWG and LEWG

Pattern matching:

• P2688R3: Pattern Matching: match Expression — encouraged to come back
• P2392R3: Pattern matching using is and as — no consensus
• P3332R0: A simpler notation for PM — no consensus

Safety related

• P3081R0: Core safety Profiles: Specification, adoptability, and impact — strong consensus, will be designing profiles over telecons
• P3471R1: Standard library hardening — unanimously sent to LEWG, will align with contracts / profiles
• P2719R1: Type-aware allocation and deallocation functions — sent to CWG

Other Papers:

• P2830R7: Standardized Constexpr Type Ordering — we chose the implementation-defined ordering, and forwarded to LEWG
• P1061R9: Structured Bindings can introduce a Pack — what a roller coaster! On the straw polls
• P3176R0: The Oxford variadic comma — On the straw polls
• P3422R0: Allow main function in named modules — forwarded, but problems were found, pulled from the straw polls
• P2786R9: Trivial Relocatability For C++26 — Forwarded to LEWG and CWG for inclusion in C++26, but extremely tight consensus
• P3367R0: constexpr coroutines — Forwarded to CWG for inclusion in C++26, but CWG is worried about implementation burden
• P2866R4: Remove Deprecated Volatile Features From C++26 — forwarded to CWG
• P3074R4: trivial unions (was std::uninitialized) — forwarded to CWG and LEWG
• P3477R1: There are exactly 8 bits in a byte — forwarded to CWG and LEWG
• P3421R0: Consteval destructors — forwarded to CWG, but lots of neutral, consider life choices
• P3380R1: Extending support for class types as non-type template parameters — sent to LEWG to confirm usage and help the design
• P3006R1: Launder less — forward to CWG
• P2414R4: Pointer lifetime-end zap proposed solutions — combined with angelic non-determinism, use the new feature to make some concurrency easier, but point out to SG1 that they were silly and forgot some things
• P3439R0: Chained comparisons: Safe, correct, efficient — More work encouraged
• P3324R0: Attributes for namespace aliases, template parameters, and lambda captures — More work encouraged
• CWG2752: Excess-precision floating-point literals, see P3488 Floating-Point Excess Precision — no consensus based on the SG6 strong recommendations, need to see again
• P1494R4: Partial program correctness — P3352 (github) and P3403 (github) — Davis' original paper remains the status quo, volatile was not added to the list of observable effects
• P3475R0: Defang and deprecate memory_order::consume — defangged, it is gone
• P0876R18: fiber_context - fibers without scheduler — waiting for input on implementability on Windows
• P3466R0: (Re)affirm design principles for future C++ evolution — update, and adopt as a standing document

Evolution Working Group Incubator Study Group (SG17) Progress

EWGI discussed 10 papers over the entire Friday of the meeting with the intent of preparing them for presentation in EWG. Of the 10:

4 Were determined to have sufficient motivation and paper readiness to be seen by EWG, and were forwarded. All were given feedback on how to improve presentation for EWG.

4 Were given extensive feedback on how to improve the paper motivation, presentation, and contents, and had sufficient consensus to return to EWG.       Of those, 1 had very weak consensus to return.

2 were discussed extensively, and after discussion, determined to have insufficient motivation to continue or be seen again, but of course are welcome to come back with improved motivation.

Papers Forwarded to EWG

• P3407R0: Make idiomatic usage of offsetof well-defined
• P3423R0: Extending User-Generated Diagnostic Messages
• P3347R0: Invalid/Prospective Pointer Operations
• P3492R0: Sized deallocation for placement new

Papers that got feedback and will be seen again by EWGI

• P2998R0: Deducing function parameter types using alias template CTAD
• P3412R0: String interpolation
• P3469R0: Virtual deducing this
• P3405R0: Out-of-order designated initializers - Weak Consensus to Return

Papers that did not get consensus

• P3398R0: User specified type decay
• P3245R2: Allow [[nodiscard]] in type alias declarations

Core Working Group (CWG) Progress

CWG met during the full week, and reviewed 34 issues, and 17 papers, including “Reflection” and “contracts”.

Papers reviewed and sent to plenary (apply changes to the C++ Working Paper)

• P3524R0: Core Language Working Group "ready" Issues for November 2024 meeting — accept and apply all issues as Defect Reports (DR).
• P3340R0: A Consistent Grammar for Sequences (approved in St. Louis)
• P2686R5: Constexpr structured bindings and references to constexpr variables (approved in St. Louis)
• P3068R6: Allowing exception throwing in constant-evaluation
• P3247R2: Deprecate the notion of trivial types
• P2865R6: Remove deprecated array comparisons from C++26
• P1061R10: Structured Bindings can introduce a Pack
• P3176R1: The Oxford variadic comma

Papers which will need to be seen again by CWG

• P1839R6: Accessing object representations
• P2841R5: Concept and variable-template template-parameters
• P3367R1: constexpr coroutines - sent back to EWG
• P2866R4: Remove Deprecated Volatile Features From C++26
• P3422R0: Allow main function in named modules - sent back to EWG
• P3289R1: Consteval blocks
• P3074R4: trivial unions (was std::uninitialized) - sent back to EWG
• P3477R1: There are exactly 8 bits in a byte - waiting for SG22
• P2758R3: Emitting messages at compile time - Sent to LEWG
• P2434R2: Nondeterministic pointer provenance - sent back to EWG

Library Progress

Library Evolution Working Group (LEWG) Progress

LEWG met during the full week, and reviewed multiple features for C++26. The main features that captured our time were:

• P2996R4: Reflection for C++26 (already forwarded to LWG/CWG before the meeting, finalized review & looked at follow up papers)
• P1928R15: std::simd - Merge data-parallel types from the Parallelism TS2
• P2900R10: Contracts for C++

Papers forwarded to LWG

• P2996R7: Reflection for C++26
• P2900R10: Contracts for C++
• P3299R2: Range constructors for std::simd (Merged into P1928R15)
• P2846R4: reserve_hint: Eagerly reserving memory for not-quite-sized lazy ranges
• P3152R0: Add missing constructors and assignment for indirect and polymorphic
• P3074R4: trivial unions (was std::uninitialized)
• P3284R1: write_env and unstoppable Sender Adaptors
• P3367R0: constexpr coroutines
• P3449R0: constexpr std::generator
• P2830R4: Standardized Constexpr Type Ordering
• P2434R2: Nondeterministic pointer provenance
• P3138R3: views::cache_latest
• P3152R1: Add missing constructors and assignment for indirect and polymorphic (Merged into P3019R11)

Papers that got feedback and will be seen again by LEWG

• P3430R0: simd issues: explicit, unsequenced, identity-element position, and members of disabled simd
• P3096R3: Function Parameter Reflection in Reflection for C++26
• P0260R11: C++ Concurrent Queues
• P3430R0: simd issues: explicit, unsequenced, identity-element position, and members of disabled simd
• P3094R5: std::basic_fixed_string
• P2786R9: Trivial Relocatability For C++26
• P3388R0: When Do You Know connect Doesn't Throw?
• P3373R0: Of Operation States and Their Lifetimes
• P2079R5: System execution context
• P1030R7: std::filesystem::path_view
• P2645R0: path_view: a design that took a wrong turn
• P2945R1: Additional format specifiers for time_point
• P3148R0: Formatting of chrono Time Values
• P2527R3: std::variant_alternative_index and std::tuple_element_index
• P2769R0: get_element customization point object
• P3149R6: async_scope -- Creating scopes for non-sequential concurrency (design approved)
• P3425R0: Reducing operation-state sizes for subobject child operations (design approved)
• P3433R0: Allocator Support for Operation States (design approved)
• P2319R2: Prevent path presentation problems (design approved)

Papers that did not get consensus

• P3415R0: Range interface in std::optional breaks code!
• P3429R0: Reflection header should minimize standard library dependencies (first fix was accepted, rest of paper didn’t got consensus)

A list of LWG issues seen by LEWG

• LWG3454 (sent back to LWG)
• LWG2991 (sent back to LWG)
• LWG2985 (Require rebasing on P0551)
• LWG4042 (P3107 Reviewed, issue closed)
• LWG3114 & LWG3445
• LWG3114 (Networking TS, sent to SG4)
• LWG2095 & LWG3003 (will be seen as a paper (P3503R0)
• LWG532 (closed)

Policies discussion

Unfortunately, we did not have any Policies discussion during Wroclaw, we will see them again in upcoming meetings.

Information about policies can be found in: “P2267R1: Library Evolution Policies (The rationale and process of setting a policy for the Standard Library)”.

Worth noting that Evolution Work Group (EWG) have also introduced policies, and have accepted: “SD-10: Language Evolution (EWG) Principles” during Wroclaw.

Evening Sessions

In addition to the work meeting, we had two evening sessions during the week (initiated by WG21 members). Evening sessions are informative sessions, during which we do not take any binding votes.

They are meant for either reviewing topics relevant to the committee in more depth than possible during the work sessions (such is the case for "Relocatability") , or for introducing topics which are not procedurally related but are relevant to WG21 (such is the case for “Perspectives on Contracts").

• 🔎Monday: “Perspectives on Contracts" (informative, targeting full WG21)
• 🔎Tuesday: “Relocatability Intro” (informative, targeting LEWG)

Thank you to all our authors and participants, for a great collaboration in a productive and useful review process, and see you (in-person or online) in Hagenberg!◝(ᵔᵕᵔ)◜

Library Evolution Working Group Incubator Study Group (SG18) Progress

Papers that require more work / LEWGI review

• P3045R1: Quantities and units library

Papers forwarded to LEWG

• P3383R0: mdspan.at()

Papers that did not get consensus

• P2879R0: Proposal for std::dump

• PXXXXRX: paper name — description, details and updates

Library Working Group (LWG) Progress

LWG met in person throughout the week and reviewed multiple papers.

Papers forwarded to plenary

• P2835R7: Expose std::atomic_ref 's object address
• P3323R1: cv-qualified types in atomic and atomic_ref
• P3508R0: Wording for “constexpr for specialized memory algorithms
• P3369R0: constexpr for uninitialized_default_construct
• P3370R1: Add new library headers from C23
• P3309R3: constexpr atomic and atomic_ref
• P3019R11: indirect and polymorphic: Vocabulary Types for Composite Class Design
• P1928R15: std::simd—merge data-parallel types from the Parallelism TS2
• P3325R5: A Utility for Creating Execution Environments

Papers require more LWG review time

Note: List also contains papers forwarded but not add to plenary this time (either as require review from other group, finalize wording fixes, or minor changes)

• P2933R3: Extend header function with overloads for std::simd
• P3430R2: simd issues: explicit, unsequenced, identity-element position, and members of disabled simd
• P0447R27: Introduction of std::hive to the standard library
• P2996R10: Reflection for C++26
• P3137R2: views::to_input
• P3068R5: Allowing exception throwing in constant-evaluation — Forwarded, pending CWG
• P3247R2: Deprecate the notion of trivial types — Forwarded
• P3074R4: trivial unions (was std::uninitialized) — Forwarded
• P2862R1: text_encoding::name() should never return null values — Forwarded
• P3008R2: Atomic floating-point min/max — Forwarded, pending review
• P3016R5: Resolve inconsistencies in begin/end for valarray and braced initializer lists — Sent back to LEWG for design input

Issues Processing

(See: A list of LWG issues seen by LEWG)

Note: Issues finalized during a meeting are tentatively ready but voted on during the next meeting (in this case, Hagenberg).

Study Group Progress

Concurrency and Parallelism Study Group (SG1) Progress

Papers forwarded

• P3149R6: async_scope — Forwarded to LEWG
• P3296R2: let_async_scope — Forwarded to LEWG
• P3179R3: C++ parallel range algorithms — Forwarded to LEWG
• P3490R0: Justification for ranges as the output of parallel range algorithms — approved (applied on P3179R3)
• P0260R11: C++ Concurrent Queues — Forwarded to LEWG
• P3481R0: Summarizing std::execution::bulk(): issues — Forwarded to LEWG
• P2079R5: System execution context — Forwarded to LEWG
• P3475R0: Defang and deprecate memory_order::consume — Forwarded to EWG/LEWG
• P2414R4: Pointer lifetime-end zap proposed solutions — Forwarded to EWG/LEWG
• P3125R1: constexpr pointer tagging — Forwarded to LEWG
• P3111R1: Atomic Reduction Operations — Forwarded to LEWG
• P3427R0: Hazard Pointer Synchronous Reclamation — Forwarded to LEWG
• P3428R0: Hazard Pointer Batches — Forwarded to LEWG

Papers reviewed (require more work)

• P3064R2: How to Avoid OOTA Without Really Trying

Papers that did not get consensus

• P3409R0: Enabling more efficient stop-token based cancellation of senders
• P3346R0: thread_local means fiber-specific
• P3456R0: system_scheduler on Win32, Darwin and Linux — no consensus to modify P2079’s status queue

SG1 Related Issues Seen

• LWG4158: packaged_task::operator= should abandon its shared state — proposed resolution sent to LWG
• LWG3504: condition_variable::wait_for is overspecified — proposed resolution sent to LWG
• LWG4075: Thread stability requirement on constructors and destructors — resolved as not a defect (NAD)

Networking Study Group (SG4) Progress

Networking Study Group did not meet in person during Wroclaw. We hold telecons as required. Our main focus is on Networking proposals based on P2300.

Numerics Study Group (SG6) Progress

The numerics group met on Monday and Tuesday, we talked about floating-point for a total of one complete day. We had few people in the room and a few online for a minimum of our quorum of 6.

SG6 additionally met in joint session with LEWGI (SG18) for another total of a complete day. Refer to the Library Evolution Working Group Incubator Study Group (SG18) Progress above.

Papers forwarded to LEWG

• P3161R2: Unified integer overflow arithmetic — A few changes were requested but otherwise the paper was considered ready for LEWG.

• P3348R1: C++26 should refer to C23 not C17 — We requested that the <cmath> parts of C23 are processed via their own paper, so that the remaining parts of P3348 can make quicker progress.

Papers reviewed (require more work)

• P3307R0: Floating-Point Maximum/Minimum Function Objects — We encouraged further work. However, if we could pass function templates / function overload sets easily that problem wouldn't even need solving.

• P3397R0: Clarify requirements on extended floating point types — see below

• P3375R1: Reproducible floating-point results — see below

• P3488R0: Floating-Point Excess Precision (CWG2752 Excess-precision floating-point literals) — see below

• P3479R0: Enabling C pragma support in C++ — see below

We clarified our expectations of floating-point behavior for the extended floating-point types and determined that we need to implement behavior-changing attributes of the floating-point standard before we can do anything helpful. This became a recurring theme for the four papers listed above. Note, however, that we agreed on not solving this via pragmas.

Compile-time Programming Study Group (SG7) Progress

SG7 met for 1.5 days during Wroclaw, and saw the following proposals.

Papers that were forwarded to EWG

• P3381R0: Syntax for Reflection — use ^^ (unibrow) syntax for reflection
• P3419R0: Reflection Syntax Options Summary
• P3437R1: Proposed default principles: Reflect C++, Generate C++ - Discussed
• P3493R0: Ruminations on reflection and access
• P2830R4: Standardized Constexpr Type Ordering (also forwarded to LEWG)
• P3394R1: Annotations for Reflection (also forwarded to LEWG)

Papers that will be seen again by SG7

• P3385R1: Attributes reflection
• [P0707R5]](https://wg21.link/P0707R5): Metaclass functions for generative C++

Papers that did not get consensus

• P3451R0: A Suggestion for Reflection Access Control — No consensus to change P2996
• P3473R0: Splicing Should Respect Access Control — No consensus to change P2996
• P3435R0: Reflection and meta-programming — No consensus to encourages more work

Ranges Study Group (SG9) Progress

SG9 met in Wrocław on Monday and Tuesday. We also had a special session with weak quorum on Wednesday morning due to a last-minute room availability opportunity.

We forwarded five papers to LEWG—two for parallel range algorithms and three for SIMD. We requested revisions of three other papers, including one on range type-erasure, one on a generalized checked-access (at) mechanism, and one on a range adaptor for lazy scan. We also provided informal feedback to a paper on the ranges-related features of the Unicode in the Standard Library paper targeting C++29.

Papers forwarded to Library Evolution

• P3179R3: C++ parallel range algorithms — adds an execution policy for easy parallelization to the rangified algorithms
• P3490R0: Justification for ranges as the output of parallel range algorithms — modifies the rangified parallel algorithm to take a range as output, not an iterator
• P3480R0: std::simd is a range — adds begin/end to std::simd
• P3319R1: Add an iota object for simd (and more) — adds a convenient way to add a simd initialized with increasing numbers
• P3299R2: Range constructors for std::simd — changes the way std::simd is constructed from a range

Depending on LWG’s workload, they could all make it into C++26.

Papers we gave feedback on

• P3411R0: any_view — type erased view storage
• P3404R1: views::scan — a new view that computes a fold with intermediate values
• P3404R0: std::at — range-checked accesses to arbitrary containers
• P2728R7: Unicode in the library, Part 1: UTF Transcoding

We expect them all to come back for C++29.

Low Latency Study Group (SG14) Progress

SG14 did not meet during the Wroclaw meeting. We continue to hold monthly telecons to discuss low latency, gaming, and embedded related papers.

Tooling Study Group (SG15) Progress

SG15 have met for 1.5 days during Wroclaw. SG15 focused on both C++ IS targeting papers (such as Profiles and Contracts) as well as papers for the new Ecosystem IS (which was also discussed during this meeting, see below), planned to be developed parallelly to the C++ Standard.

Papers forwarded (to EWG/LEWG)

Papers targeting the C++ Standard

• P3081R0: Core safety Profiles: Specification, adoptability, and impact — Forwarded to EWG
• P2758R3: Emitting messages at compile time — Forwarded to LEWG

Papers targeting the Ecosystem IS

• P3342R0: Working Draft, Standard for C++ Ecosystem — Forwarded to EWG/LEWG
• P3335R2: Structured Core Options — Forwarded to EWG/LEWG for Ecosystem IS

Papers reviewed

• P3321R0: Contracts Interaction With Tooling — Will be seen again by SG15

Papers that did not get consensus

P3470R0: Interface-Unit-Only Module Library Support

Text and Unicode Study Group (SG16) Progress

SG16 did not meet in person during Wroclaw.

Contracts Study Group (SG21) Progress

SG21 met for 1 day (Fri) in Wroclaw. We also continue to hold weekly telecons.

Papers forwarded (to EWG/LEWG)

• P3510R2: "Leftover properties of this in constructor preconditions". The paper makes it ill-formed to refer to members of a class in the precondition assertions of its constructor and the postcondition assertions of its destructor without an explicit this-> to minimise the probability of accidentally referring to a member outside of its lifetime.
• P3520R0: "Contracts for C++: Wroclaw technical fixes". The paper fixes four minor design issues flagged by CWG during wording review of P2900.

Papers reviewed

• P3100R1: "Undefined and erroneous behaviour is a contract violation". The paper proposes a framework for safety in C++ that unifies the notion of contract violations, erroneous behaviour, and undefined behaviour. SG21 had very strong consensus to pursue this direction for post-C++26, and for the short term, to align the terminology and conforming failure modes of erroneous behaviour with that of contract-violation handling for C++26 to pave the way for that direction.
• P3205R0: "Throwing from a noexcept function should be a contract violation". SG21 gave guidance to the authors; we expect them to come back with a revision.
• P2946R1: "A Flexible Solution to the Problems of noexcept". SG21 gave guidance to the authors; we expect them to come back with a revision.

C / C++ Liaison Group (SG22) Progress

SG22 did not meet in person during Wroclaw. We continue to run telecons by demand and provide feedback through the mailing list.

Safety & Security Group (SG23) Progress

SG23 met for 2.5 days in total (Tue PM, Wed, Thu) during Wroclaw.

Papers forwarded (to EWG/LEWG)

• P2719R1: Type-aware allocation and deallocation functions — Forwarded to LEWG
• P3352R0: Taming the Demons (C++ version) - Undefined Behavior and Partial Program Correctness (as well as: N3128: Taming the Demons (for C) - Undefined Behavior and Partial Program Correctness) — Forwarded to EWG
• P1494R4: Partial program correctness — Forwarded to EWG/LEWG
• P3352R0: Taming the C++ demons — Forwarded to EWG as alternative to P1494
• P3447R0: Profiles syntax — Forwarded to EWG
• P3081R0: Core safety Profiles: Specification, adoptability, and impact — Forwarded to EWG with syntax change
• P3471R1: Standard library hardening — Forwarded to EWG/LEWG
• P3404R0: std::at : Range-checked accesses to arbitrary containers — Forwarded to LEWG
• P3465R0: Pursue P1179 as a Lifetime Safety TS — Supported

Papers reviewed

• P3402R1: A Safety Profile Verifying Class Initialization
• P3436R0: Strategy for removing safety-related undefined behavior by default
• P3446R0: Profile invalidation - eliminating dangling pointers — Support for integration with P3436
• P3442R0: [[invalidate_dereferencing]] attribute
• P3403R0: The Undefined Behavior Question

Papers that did not get consensus

• P3390R0: Safe C++

C++ Release Schedule

NOTE: This is a plan not a promise. Treat it as speculative and tentative.

See P1000, P0592, P2000 for the latest plan.

Status of Major C++ Feature Development

NOTE: This is a plan not a promise. Treat it as speculative and tentative.

• IS = International Standard. The C++ programming language. C++11, C++14, C++17, C++20, C+23, etc.

• TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.

• CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").

Updates since the last Reddit trip report are in bold.

Last Meeting's Reddit Trip Report.

If you have any questions, ask them in this thread!

Report issues by replying to the top-level stickied comment for issue reporting.

/u/InbalL, Library Evolution (LEWG) Chair, Israeli National Body Chair

/u/jfbastien, Evolution (EWG) Chair

/u/erichkeane, Evolution Working Group Incubator (SG17, EWGI) Chair, Evolution (EWG) Vice Chair

/u/hanickadot, Compile-Time programming (SG7) Chair, Evolution (EWG) Vice Chair, Czech National Body Chair

/u/ben_craig, Library Evolution (LEWG) Vice Chair

/u/c0r3ntin, Library Evolution (LEWG) Vice Chair

/u/foonathan, Ranges (SG9) Vice Chair

/u/V_i_r, Numerics (SG6) Chair

/u/bigcheesegs, Tooling (SG15) Chair

/u/tahonermann, Unicode (SG16) Chair

/u/mtaf07, Contracts (SG21) Chair

/u/timur_audio, Contracts (SG21) Vice Chair

/u/je4d, Networking (SG4) Chair

... and others ...

Is understanding Include files of say STL containers in /usr/include/ to get exposed to and be able to write good cpp a genuine way to do so as I haven't seen anyone recommend that.

Should I go after every include header file or just the most important ones and that will be a good enough start ?

I'm a web developer and I was very fed up with the overall Javascript ecosystem so last month I decided to take a small break from this entire JS world and explore something, I chose C++ solely because its one of my academic subject and I thought going slightly mid/low level would make me a better dev and make me understand the fundamentals since the JS V8 is built on C++ itself. I learnt most of the basic syntax and fundamentals about it and loved it so far.

I want to create 3-5 small/mid level projects using it for my own sake so can y'all suggest me some projects you think that'll be good and maybe impressive enough to showcase in my portfolio site.

PS: if possible something related to web, I don't like game dev so don't suggest it pls :!

Hello, i have been working on an open source dynamic system simulator for a while now emscripten build: https://dynamicsimulator-beta.static.domains/ , demo: https://youtu.be/xRRwlTSGhQI . github repo: https://github.com/ahmed-AEK/Simple_Dynamic_Simulator, mostly aimed as an educational tool for systems courses (that doesn't cost an arm and a leg). I am mostly looking for feedback and things to improve to make it more useful to people.

Also is there any better place to post it that i may get more feedback ?

Over the top of my head i think having a variable workspace and adding a scripting language (i am thinking lua) would be the next step.

I am mostly relying on sdl so that i can make a webassembly and mobile releases in the future.

What do you guys think ?

Hey everybody!

Let me introduce you to SimpleBLE, a cross-platform Bluetooth library specifically designed for use in all kinds of environments with a very simple API that just works, allowing developers to easily integrate it into their projects without much effort, instead of wasting hours and hours on development.

Among our latest new features is now full support for Android! You can now develop your SDK or applications and add Bluetooth functionality across all major mobile and desktop operating systems!

We provide comprehensive functionality support for BLE Central mode, enabling developers to scan and discover nearby BLE devices, handle pairing and connection management of peripherals, and interact with GATT characteristics and descriptors just to name a few. This functionality is fully supported across Windows, Linux, MacOS, iOS and Android, using our language bindings for C, C++ and Python, with a lot more coming soon.

We also have a preview for BLE Peripheral mode, letting you turn any compatible Linux system into a custom Bluetooth peripheral.

See for yourself how easy it is to get started by looking at our examples on GitHub.

SimpleBLE is licensed under the Business Source License 1.1 and is trusted by industry leaders across healthcare, automotive, manufacturing, and entertainment. While commercial use requires a license, SimpleBLE is free to use for non-commercial purposes and we gladly offer free licenses for small projects, so don't hesitate to reach out!

Want to know more about SimpleBLE's capabilities or see what others are building with it? Ask away!

I hate rust language, but love the tooling. I like Modern* C++ language more than Rust, but absolutely hate the tooling. Curious if the Rust Gang hype is actually legitimate or not with the robotics industry or should I stick to my guns with Python and C++?

I don't have issues learning new tech, its just part of the job. But I really don't want to waste my time if there isn't any actual momentum beyond hobby projects and C++ is being used more often beyond legacy code.

* Utilizing the newer features of C++ such as shared pointers and other features designed to make it easier to avoid memory leaks.

The other trending rant post made me curious what is the current widely used package manager and deps resolution.

Let say you use CMake, but need to add some libraries which have their own deps tree. It's possible two libraries require same dependency but with different version tha breaks ABI compatibility.

For personal project I'm a fan of vcpkg in manifest mode.

It just works™️ and setup is pretty straightforward with good integration in major IDEs. Vcpkg.io contains all libraries that I probably ever need.

At work we use Conan since it has good integration with our internal Artifactory.

I'm not fan of the python-dependant recipe in v2.0, but I but I see concrete benefit on enforcing the compliance yada-yada, since approved 3rd party package can just be mirrored, and developers can pull a maintained conan profile containing compiler settings, and cpp standard, etc.

I have been trying to "ignore" other option such as Spack, Hunter, and Buckaroo, but now I'm curious: are they any better?

What about cmake own FetchContent_MakeAvailable()'?

Non-exhaustive list:

1. Vcpkg
2. Conan
3. CMake's FetchContent_MakeAvailable()
4. CPM.CMake
5. Spack
6. Hunter
7. Buckaroo
8. Other?

Note: No flamewar/fanboyism/long rant please (short rant is OK lol) . Stick with technical fact and limit the anecdote.

If you don't use package manager that's fine, then this discusion isn't interesting for you.

Just to be clear, this discussion is not about "why you should or should not use package manager" but rather "if you use one, which, and why do you use that one?" Thanks.