-
Stay up-to-date with everything C++! Content directly fetched from the subreddit just for you. Join our group for discussions : @programminginc Powered by : @r_channels
Starting my DSA journey...
How can I crack the campus tests conducted by companies, they mostly consist of Array and String easy-moderate some times the hard questions as well. Which is the best resource to understand these topics , getting to the know the different algorithms, practicing questions and applying the concepts by which I will be comfortable in cracking these coding rounds. Please help me since I am getting behind everyone and lag a lot in coding , I am in a do or die situation since I am getting towards the end of my placement season and I am yet to secure a company on-campus. Before judging me, allow me to tell you that I am from the EXTC Department of engineering and the core companies hardly even visited the campus, and you'll must be knowing the amount of competition in the off-campus opportunities. So please provide suggestions, advices, whatever you guys have to offer
https://redd.it/1je1ckc
@r_cpp
What to know for modern C++ intern technical interview?
I’ve been studying move semantics and more advanced OOP topics, but I keep finding new patterns/ideas to know.
The position is entry level. Tell me anything you think I should look into.
https://redd.it/1jdwg4c
@r_cpp
The new release of the Memsafe project is a proof of concept for memory safety in C++ without breaking backward compatibility with old legacy code.
https://github.com/rsashka/memsafe
https://redd.it/1jdk4a7
@r_cpp
New C++ Conference Videos Released This Month - March 2025 (Updated to Include Videos Released 2025-03-10 - 2025-03-16)
**CppCon**
2025-03-10 - 2025-03-16
* Using Modern C++ to Build XOffsetDatastructure: A Zero-Encoding and Zero-Decoding High-Performance Serialization Library in the Game Industry - Fanchen Su - [https://youtu.be/agRbVcMkqTY](https://youtu.be/agRbVcMkqTY)
* Monadic Operations in Modern C++: A Practical Approach - Vitaly Fanaskov - [https://youtu.be/Ely9\_5M7sCo](https://youtu.be/Ely9_5M7sCo)
* C++ Sender Patterns to Wrangle C++ Concurrency in Embedded Devices - Michael Caisse - [https://youtu.be/a2gLF9Supic](https://youtu.be/a2gLF9Supic)
* Template-less Metaprogramming in C++ - Kris Jusiak - [https://youtu.be/yriNqhv-oM0](https://youtu.be/yriNqhv-oM0)
* Cost of C++ Abstractions in C++ Embedded Systems - Marcell Juhasz - [https://youtu.be/7gz98K\_hCEM](https://youtu.be/7gz98K_hCEM)
2025-03-03 - 2025-03-09
* Modern C++ Error Handling - Phil Nash - [https://youtu.be/n1sJtsjbkKo](https://youtu.be/n1sJtsjbkKo)
* Adventures with C++ Legacy Codebases: Tales of Incremental Improvement - Roth Michaels - [https://youtu.be/lN-dd-0PjRg](https://youtu.be/lN-dd-0PjRg)
* Deciphering C++ Coroutines Part 2 - Mastering Asynchronous Control Flow - Andreas Weis - [https://youtu.be/qfKFfQSxvA8](https://youtu.be/qfKFfQSxvA8)
* spanny 2: Rise of C++ std::mdspan - Griswald Brooks - [https://youtu.be/2VlK0vFZc7k](https://youtu.be/2VlK0vFZc7k)
* Implementing C++ Reflection Using the New C++20 Tooling Opportunity: Modules - Maiko Steeman - [https://youtu.be/AAKA5ozAIiA](https://youtu.be/AAKA5ozAIiA)
2025-02-24 - 2025-03-02
* C++/Rust Interop: A Practical Guide to Bridging the Gap Between C++ and Rust - Tyler Weaver - [https://youtu.be/RccCeMsXW0Q](https://youtu.be/RccCeMsXW0Q)
* Cross-Platform Floating-Point Determinism Out of the Box - Sherry Ignatchenko - [https://youtu.be/7MatbTHGG6Q](https://youtu.be/7MatbTHGG6Q)
* C++ Data Structures That Make Video Games Go Round - Al-Afiq Yeong - [https://youtu.be/cGB3wT0U5Ao](https://youtu.be/cGB3wT0U5Ao)
* Moved-from Objects in C++ - Jon Kalb - [https://youtu.be/FUsQPIoYoRM](https://youtu.be/FUsQPIoYoRM)
* When Nanoseconds Matter: Ultrafast Trading Systems in C++ - David Gross - [https://youtu.be/sX2nF1fW7kI](https://youtu.be/sX2nF1fW7kI)
**Audio Developer Conference**
2025-03-10 - 2025-03-16
* Our Ultra-Processed Interfaces - What Music Technology Can Learn From Doritos - Astrid Bin - [https://youtu.be/b1oNQRGIJw8](https://youtu.be/b1oNQRGIJw8)
* Automated Analog Circuit Modeling - C++, Python, MATLAB, and XML - Eric Tarr - [https://youtu.be/JBxKUXiHzJI](https://youtu.be/JBxKUXiHzJI)
* Engineering Success for Audio Software in a Crowded Market - Randy Young - [https://youtu.be/5bGMyfSIPcM](https://youtu.be/5bGMyfSIPcM)
2025-03-03 - 2025-03-09
* Workshop: Practical Machine Learning - Embed a generative AI model in your app and train your own interactions with it - Anna Wszeborowska, Harriet Drury, Sohyun Im, Julia Läger & Pauline Nemchak - [https://youtu.be/D-FRkvT5Npk](https://youtu.be/D-FRkvT5Npk)
* Keynote: Interfaces are King! - A Practical Look at AI Audio Tools and What Audio Professionals Actually Need - Andrew Scheps - [https://youtu.be/lVF6qFN0Ges](https://youtu.be/lVF6qFN0Ges)
* Challenges in Real-Time Physical Modelling for Sound Synthesis - Silvin Willemsen - [https://youtu.be/6MCS34QsyDQ](https://youtu.be/6MCS34QsyDQ)
2025-02-24 - 2025-03-02
* A Critique of Audio Plug-In Formats - VST, AU, AAX, JUCE and Beyond - Fabian Renn-Giles - [https://youtu.be/nPJpX8GR9d4](https://youtu.be/nPJpX8GR9d4)
* GPU Based Audio Processing Platform with AI Audio Effects - Are GPUs ready for real-time processing in live sound engineering? - Simon Schneider - [https://youtu.be/uTmXpyRKJp8](https://youtu.be/uTmXpyRKJp8)
* Learning While Building - MVPs, Prototypes, and the Importance of Physical Gesture - Roth Michaels - [https://youtu.be/rcKl4PVHMMQ](https://youtu.be/rcKl4PVHMMQ)
**Meeting C++**
2025-03-10 - 2025-03-16
* Clean CMake for C++ (library) developers - Kerstin Keller -
The Header-to-Module Migration Problem. A naive point of view.
The current situation for a programmer who wants to migrate from "include" to "import" is problematic, as we have seen here.
For the casual user, the main benefit of using modules is reduced compile time. This should be achieved by replacing textual inclusion with importing a precompiled binary program interface (also known as "BMI," in a ".bmi" file). To simplify this, the "header unit" module was introduced.
A Naive Programmer's Expectations and Approach
In an `#include` world, the compiler finds the header file and knows how to build my program.
When I want to migrate to modules, the most straightforward approach is with header units: change `#include "*.hpp"` to `import "*.hpp";` (cppreference).
For example, I change in `b.cpp` the `#include "a.hpp"` to `import "a.hpp";`
With this change, I'm saying: The file `a.hpp` is a module, a self-contained translation unit. You (the compiler) can reuse an earlier compilation result. This is expected to work for both "own" and "foreign library" headers.
As a naive programmer, I would further expect:
IF the compiler finds an already "precompiled" module ("bmi" binary module interface), makes the information in it available for the rest of `b.cpp`, and continues as usual,
ELSE
(pre)compiles the module (with the current compiler flags) and then makes the information in it available for the rest of `b.cpp`, and continues as usual.
This is where the simple story ends today, because a compiler considers itself only responsible for one translation unit. So, the compiler expects that `a.hpp` is already (pre)compiled before `b.cpp` is compiled. This means that the "else" case from above is missing.
So, the (from the user's perspective) simple migration case is a new problem delegated to the build system. CMake has not solved it yet.
Is This Bad Partitioning of Work?
If compilers were to work along the lines of the naive programmer's expectations (and solve any arising concurrency problems), the work of the build system would be reduced to the problem of finding and invalidating the dependency graph.
For this simple migration pattern, the differences to the "include" case would be: Remember not only the dependencies for `.cpp` files, but also for `*.hpp` files. Because in this scenario the compiler will build the missing module interfaces, the build system is only responsible for deleting outdated "*.bmi" files.
These thoughts are so obvious that they were surely considered. I think the reasons why they are not realized would be interesting. Also, in respect to "import std;", if "header units" would work as expected, this should be nothing but syntactic sugar. The fact is, this is not the case and that seems to make a lot more workarounds necessary.
The DLL/SO Symbol Visibility Problem
Beyond the `#import "header"` usability, the linker symbol visibility is practically unsolved within the usage of modules. In the current model, the imported module is agnostic to its importer. When linkage visibility must be managed, this is a pain. When the header represents the interface to functionality in a dynamic library, the declarations must be decorated differently in the implementation ("dllexport") and the usage ("dllimport") case. There may be workarounds with an additional layer of `#includes`, but that seems counterintuitive when modules aim to replace/solve the textual inclusion mess. Maybe an "extern" decoration by the import could provide the information to decide the real kind of visibility for a "dllexport" decorated symbol in the imported module.
Observation 1
When I interpret the Carbon-C++ bridge idea correctly, it seems to work like the
problem, especially with C++23, perhaps you have implemented something similar and would like to share it.
C) RTTI - is not on the table
https://redd.it/1jd8z93
@r_cpp
Simulating Rust Traits in C++
https://blog.bluempty.com/en/post/cpp-rust-trait/
https://redd.it/1jd7knq
@r_cpp
How to join or concat ranges, C++26
https://www.cppstories.com/2025/join_concat_ranges/
https://redd.it/1jd71fx
@r_cpp
first index of a uint8_t[] is always 1? I feel like I'm going insane
```c++
int minBytesForBits(int numBits) { return numBits / 8 + (numBits % 8 != 0); }
// Manage byte array for bits
class BitBuffer {
private:
size_t _size;
uint8_t *_data;
public:
// Simple initialize all bytes to 0
BitBuffer(size_t size)
: _size(size),
_data(new uint8_t[getSizeBytes()]) {
for (size_t idx = 0; idx < getSizeBytes(); idx++) {
setByte(idx, 0);
}
}
// This constructor does not validation on the given string
BitBuffer(const string &bitString)
: _size(bitString.size()),
_data(new uint8_t[getSizeBytes()]) {
for (size_t idx = 0; idx < getSizeBits(); idx++) {
bool bitVal = (bitString[idx] - '0') != 0; // should always be 1 or 0
setBit(idx, bitVal);
}
}
size_t getSizeBits() const { return _size; }
size_t getSizeBytes() const { return minBytesForBits(getSizeBits()); }
uint8_t getByte(size_t pos) const { return _data[pos]; }
void setByte(size_t pos, uint8_t value) { _data[pos] = value; }
bool getBit(size_t pos) const {
int posByte = minBytesForBits(pos);
uint8_t tgtByte = getByte(posByte);
uint8_t bitMask = 0x01 << pos % 8;
// Any value greater than 0 after masking means the bit is true
return (tgtByte & bitMask) != 0;
}
void setBit(size_t pos, bool value) {
if (getBit(pos) != value) {
int posByte = minBytesForBits(pos);
uint8_t tgtByte = getByte(posByte);
uint8_t bitMask = 0x01 << (pos % 8);
setByte(posByte, tgtByte ^ bitMask);
}
}
string toString() const {
string ret = "";
for (size_t idx = 0; idx < getSizeBits(); idx++) {
ret.append(getBit(idx) ? "1" : "0");
}
return ret;
}
};
int main() {
string strDataBits = "10001110110";
BitBuffer bb(strDataBits);
cout << bb.toString() << ": " << bb.getSizeBytes() << " [ "
<< static_cast<int>(bb.getByte(0)) << " "
<< static_cast<int>(bb.getByte(1)) << " ]" << endl;
uint8_t x = 0b10001110;
cout << int(x) << endl;
return 0;
}
```
With the above code I'd expect it to print
```txt
10001110110: 2 [ 142 113 ]
142
```
but instead I'm getting
```txt
10001110110: 2 [ 1 113 ]
142
```
It feels like I've tried everything but the first byte no matter what I put in the constructor here is always 1 and it's been driving me mad. At first I thought it was the fact that I was using unique_ptr but then switching to a normal poiter doesn't help and even aftering compiling with the `-g` flag gdb keeps giving me `<optimized out>` when trying to view the value of `bb._data`?!
https://redd.it/1jd3kwu
@r_cpp
Working on a novel job system library: mr-contractor
A couple of months ago, there was a talk on CppCon, which introduced an insanely good scheduling algorithm.
However the implementation didn't (by design) provide any execution capabilities. So when I tried to actually use it, the wrapper quickly got into it's own library. Here's a link
I think the API is really clean, it also provides compile-time type checking and code generation. Here's a quick (though very syntetic) example:
auto prototype = Sequence{
[](int x) { return std::tuple{x, x*2}; },
Parallel{
Sequence{ // Nested sequential steps
[](int a) { return a + 1; },
[](int b) { return std::to_string(b); }
},
[](int c) { return c * 0.5f; }
},
[](std::tuple<std::string, float> inputs) {
auto&& [str, flt] = inputs;
return str + " @ " + std::to_string(flt);
}
};
auto task_on_30 = apply(prototype, 30);
task_on_30->execute(); // schedule + wait
task_on_30->result();
// result = "31 @ 30.00000"
auto task_on_47 = apply(prototype, 47);
task_on_47->execute(); // schedule + wait
task_on_47->result();
// result = "48 @ 47.00000"
With the big push for memory safety, how important is it, really?
I know the common stat that gets thrown around is "70% of Windows security bugs come from memory issues"
But no one ever follows that up with how many bugs are security bugs? Are we talking half of all bugs? Is it less than 1%?
Is it really that important, outside of critical systems; which could be made 100% safe by simply isolating them from external connection? This entire fervor around 'memory safety' feels like a lot of people buying into a marketing gimmick.
To be clear: obviously being memory safe is important, fundamentally, but is it really so important as to dominate every consideration about language development. Are there really no other more important things we could be working on improving in programming languages, and cpp specifically?
Edit: For additional clarity, my thesis is that having a more transparent, usable language that made memory usage clear and well defined would more effectively reduce memory bugs than having a memory cop to police your code.
https://redd.it/1jcwkc2
@r_cpp
The language spec of C++ 20 modules should be amended to support forward declarations
This is probably going to be controversial, but the design of C++20 modules as a language feature to me seems overly restrictive with *attaching names to modules*.
According to the [language standardese](https://en.cppreference.com/w/cpp/language/modules#:~:text=not%20visible.%0A%7D-,Module%20ownership,-In%20general%2C%20if), if a class is declared in a module, it must be defined in that very same module.
The consequence of this is, that forward declaring a class in a module, which is defined in another module, is ill-formed, as per the language spec.
I think forward declaring a class A in module X and then providing a definition for A in module Y should be possible, as long as it is clear, that the program is providing **the** definition for the one and only class A in module X, not for any other A in some other module.
It should be possible to extend an interface which introduces an incomplete type, by a second interface, which provides the definition of that incomplete type.
What I would like to do is something like this:
export module X.A_Forward;
namespace X
{
export class A; // incomplete type
}
and then
export module X.A extends X.A_Forward;
namespace X
{
export class A // defines the A in module X.A_Forward
{
...
};
}
To me, it currently feels like this isn't possible. But I think we need it.
Or ist it possible and I have overlooked something? Or is this a bad idea and such a mechanism is unneeded or harmful?
The concept of having two variants of interfaces for the same thing is not without precedence.
In the standard library, there is [<iosfwd>](https://en.cppreference.com/w/cpp/header/iosfwd).
https://redd.it/1jch40x
@r_cpp
I wrote a matrix transpose by incident
#include <bits/stdc++.h>
using namespace std;
int main()
{
/ m x n matrix/
int m = 0, n = 0;
int amn;
for (int i = 0, h = 0, k = 0; i < n; i++, k++, h = 0)
{
printf("\t");
for (int j = 0; j < m; j++)
{
printf("%d ",ahk);
h++;
}
printf("\n");
}
https://redd.it/1jc7xsy
@r_cpp
cxx_modules_converter.py is a Python script to convert C++ sources and headers to C++20 modules.
My take on the C++20 modules -- a script to convert sources and headers to modules: https://github.com/zowers/cxx\_modules\_converter
It converts headers to module interface units and source files into module implementation units creating module for each .cpp/.h pair.
It does have other assumptions, e.g. .h for headers and .cppm for module interface units.
https://redd.it/1jc5q5o
@r_cpp
Cannot read properties of undefined (Readsing uri)
I started my first Hello world program with c++ and it kept giving me an error upon running
"Cannot read properties of undefined (Readsing uri)"
I have no idea what this means and i don't know how to fix it
https://redd.it/1jbr50e
@r_cpp
Dirty code: trusted keeper of errors. Broken windows theory
https://pvs-studio.com/en/blog/posts/1237/
https://redd.it/1jdyyog
@r_cpp
The most underrated feature ever: Header units!
The only thing you need is:
import "coolstuff/whatever.h";
No attaching hell for names! Everything is exported, everything is just in the global module.
As if the whole program is in one single big module. Soo wonderful!
Bonus points: Compiler does not need to scan files to search for modules.
Don't waste your time with modules!
For Windows and Microsoft Visual Studio, see: https://learn.microsoft.com/en-us/cpp/build/walkthrough-header-units?view=msvc-170
https://redd.it/1jdrh9j
@r_cpp
[https://www.youtube.com/watch?v=k76LN8dSxx4](https://www.youtube.com/watch?v=k76LN8dSxx4)
* An Introduction to Swarm Intelligence Algorithms - Frances Buontempo - [https://www.youtube.com/watch?v=ur\_Yv935rJ8](https://www.youtube.com/watch?v=ur_Yv935rJ8)
2025-03-03 - 2025-03-09
* The Aging Programmer - Kate Gregory - [https://www.youtube.com/watch?v=hs8EGgoJpdQ](https://www.youtube.com/watch?v=hs8EGgoJpdQ)
* Stories from a parallel universe - Jana Machutová - [https://www.youtube.com/watch?v=mdKdkVskrJ8](https://www.youtube.com/watch?v=mdKdkVskrJ8)
* The Beman Project: bringing standard libraries to the next level - David Sankel - [https://www.youtube.com/watch?v=GRfTzzVG6vI](https://www.youtube.com/watch?v=GRfTzzVG6vI)
2025-02-24 - 2025-03-02
* Introduction to Sender/Receiver framework - Goran Aranđelović - [https://www.youtube.com/watch?v=wcPbuYQpWPI](https://www.youtube.com/watch?v=wcPbuYQpWPI)
* The Many Variants of std::variant - Nevin Liber - [https://www.youtube.com/watch?v=GrCAb1RShxE](https://www.youtube.com/watch?v=GrCAb1RShxE)
* Testable by Design - Steve Love - [https://www.youtube.com/watch?v=HNjf6LV5d50](https://www.youtube.com/watch?v=HNjf6LV5d50)
https://redd.it/1jdhrg0
@r_cpp
"naive module translation" strategy: The Carbon Language: Road to 0.1 - Chandler Carruth - NDC TechTown 2024
Observation 2
Maybe a related post from Michael Spencer:
"... I would also like to add that this isn't related to the design of modules. Despite lots of claims, I have never seen a proposed design that would actually be any easier to implement in reality. You can make things easier by not supporting headers, but then no existing code can use it. You can also do a lot of things by restricting how they can be used, but then most projects would have to change (often in major ways) to use them. The fundamental problem is that C++ sits on 50+ years of textual inclusion and build system legacy, and modules require changing that. There's no easy fix that's going to have high performance with a build system designed almost 50 years ago. Things like a module build server are the closest, but nobody is actually working on that from what I can tell."
Conclusion
This "module build server" is probably the high-end kind of compiler/build system interaction described here in a primitive and naive approach. But compiler vendors seem to realize that with modules, the once clear distinction between compiler and build system is no longer valid when we want progress in build throughput with manageable complexity.
https://redd.it/1jddqcv
@r_cpp
utl::json - Yet another JSON lib
https://github.com/DmitriBogdanov/UTL/blob/master/docs/module_json.md
https://redd.it/1jdbqzd
@r_cpp
Extracting type info
Suppose that I want to implement the following scenario.
There is a board and each board has a set of peripherals like leds, temp sensors, gpio and so on.
Each of them implements the according C++ interface: Led, Sensor, Gpio.
At some place in the code, most likely in some high-level layer I would like to get a "reference" to the board instance and enumerate its peripherals and e.g. forward the information about all peripherals to the other service (e.g. HomeAssistant). At this point I need to know what's the interface that the device implements.
The traditional solution would be:
Make an enum DeviceType { Led, Sensor, Gpio } and add base interface Device that has method DeviceType getType() that would be overridden by derived classes. This way I can simply get the information I need.
The resulting code would be:
#include <tuple>
enum class DeviceType { Led, Sensor, Gpio };
class Device {
public:
Device() = default;
virtual ~Device() = default;
virtual DeviceType gettype() = 0;
};
class Led : public Device {
public:
DeviceType gettype() { return DeviceType::Led; };
};
class Sensor : public Device {
public:
DeviceType gettype() { return DeviceType::Sensor; };
};
class LedImpl : public Led {};
class SensorImpl : public Sensor {};
using DeviceId = int;
class MyBoard
{
public:
using DeviceInfo = std::tuple<DeviceId, std::uniqueptr<Device>>;
void init()
{
devices.pushback({1, std::makeunique<LedImpl>()});
devices.pushback({2, std::makeunique<SensorImpl>()});
}
const auto& devices()
{
return devices;
}
private:
std::vector<DeviceInfo> devices;
};#include <tuple>
enum class DeviceType { Led, Sensor, Gpio };
class Device {
public:
Device() = default;
virtual ~Device() = default;
virtual DeviceType gettype() = 0;
};
class Led : public Device {
public:
DeviceType gettype() { return DeviceType::Led; };
};
class Sensor : public Device {
public:
DeviceType gettype() { return DeviceType::Sensor; };
};
class LedImpl : public Led {};
class SensorImpl : public Sensor {};
using DeviceId = int;
class MyBoard
{
public:
using DeviceInfo = std::tuple<DeviceId, std::uniqueptr<Device>>;
void init()
{
devices.pushback({1, std::makeunique<LedImpl>()});
devices.pushback({2, std::makeunique<SensorImpl>()});
}
const auto& devices()
{
return devices;
}
private:
std::vector<DeviceInfo> devices;
};
Pros:
\- easy to implement
\- I can call switch on DeviceType
Cons:
\- "Device" is an artificial interface whose only purpose is to group all devices in single container and allow to get information about the interface the device implements
\- "Information" duplication. Basically e.g. the interface "Led" holds the same information as DeviceType::Led, both of them clearly defines what's the interface the device implements, so in my opinion this is a perhaps not code duplication, but information duplication.
\- I have to manage DeviceType num, extend it when the new interface comes up
Other solutions I have though about:
A) using std::variant, but it seems it solves the problem just partially. Indeed I no longer need to manage DeviceType but I need to manage std::variant
B) I could move the functionality of finding the type out of Device class and remove it completely.
But then I would have to manage some kind of a container that ties device instance with its type, also MyBoard::devices() would return container with some meanigless deivce ids that also seems to be kinda fishy.
I believe that there are some better solutions for such an old
Synthetisizing lightweight forward modules
I have ported the C++ sources of our [Windows application](https://www.cadifra.com/) from header files to using C++ 20 modules.
Our codebase is heavily using forward declarations for classes wherever possible.
The code is devided into ~40 packages. Every package uses a namespace and all the files of a package are part of a "Project" in Visual Studio.
Due to the strong [name attaching rules of C++20 modules](https://en.cppreference.com/w/cpp/language/modules#:~:text=In%20general%2C%20if,the%20same%20module.), I ran into problems with forward declarations.
I think I finally may have found a pattern to synthetisize a lightweight forward module per package, which can be imported instead of importing the class definition(s).
For example, in our code, we have a package `Core`.
I now have a header file `Core/Forward.h`, which just contains forward declarations of the classes in Core:
#pragma once
namespace Core
{
class CopyRegistry;
class ElementSet;
class Env;
class ExtendSelectionParam;
class IClub;
class IDiagram;
class IDirtyMarker;
class IDirtyStateObserver;
class IDocumentChangeObserver;
class IElement;
class IElementPtr;
class IFilter;
class IGrid;
class IPastePostProcessor;
class IPosOwner;
class ISelectionObserver;
class IUndoRedoCountObserver;
class IObjectRegistry;
class IUndoerCollector;
class IUndoHandler;
class IView;
class IViewElement;
class ObjectID;
class ObjectRegistry;
class PosUndoer;
class SelectionHider;
class SelectionObserverDock;
class SelectionTracker;
class SelectionVisibilityServerImp;
class Transaction;
class TransactionImp;
class Undoer;
class UndoerParam;
class UndoerRef;
class VIPointable;
class VISelectable;
class Weight;
}
I then have created a module `Core.Forward` (in file `Core/Forward.ixx`):
export module Core.Forward;
export import <Core/Forward.h>;
Which uses a [header unit](https://en.cppreference.com/w/cpp/language/modules#:~:text=A%20header%20unit%20is%20a%20separate%20translation%20unit%20synthesized%20from%20a%20header.%20Importing%20a%20header%20unit%20will%20make%20accessible%20all%20its%20definitions%20and%20declarations.).
The resulting interface module can be imported wherever just a forward declaration of a class is enough, instead of the full definition. Which means for example doing
import Core.Forward;
instead of
import Core.IElement;
when class `Core::IElement` is only used by reference in some interface.
I believe this pattern is conformant to the C++ 20 language spec.
### Previous related posts
* [The language spec of C++ 20 modules should be amended to support forward declarations](https://www.reddit.com/r/cpp/comments/1jch40x/the_language_spec_of_c_20_modules_should_be/) in r/cpp
* [C++ modules and forward declarations in partitions](https://www.reddit.com/r/cpp_questions/comments/1jb93al/c_modules_and_forward_declarations_in_partitions/) in r/cpp_questions
* [C++ modules and forward declarations](https://www.reddit.com/r/cpp/comments/1j7ue8o/c_modules_and_forward_declarations/) in r/cpp
https://redd.it/1jd7c5r
@r_cpp
Which should I use?
Sup guys, I’m new at C++ but I’m really getting into it, and as long as I’ve been learning I’ve been using VSCode to code, but I saw CLion IDE and I found it pretty cool, is it really better than VSCode text editor? Is it worth the price?
https://redd.it/1jd67lk
@r_cpp
AoS vs SoA in practice: particle simulation -- Vittorio Romeo
https://vittorioromeo.com/index/blog/particles.html
https://redd.it/1jd2v66
@r_cpp
Subverting Windows
Twenty years ago, I wrote a tool to circumvent local security policy for an account that had admin rights on the Windows operating system.
As you may or may not know, just because you are administrator does not give you full control over the box. However, what does have full control of the box (outside of kernel mode) is a Windows service running as the local system account.
So I wrote a tool which installs itself as a service, temporarily, and then uses IPC to pass commands across to the service such that they could be executed under the context of the local system account, which gives you full access to the machine.
Back then I would often use the tool to spawn an interactive command line (Cmd.exe) such that I could issue commands as the local system account.
This relied on a setting that allowed services to interact with a desktop but Windows 10 onwards (from a certain SP) has removed that 'feature' (thanks Bill).
Consequently, my tool no longer allows me to interact with the command line. It would just sit there, running as a system account, but I couldn't talk to it. Fine for scripts, a problem for an interactive command line.
This weekend I have circumvented that by adding a CommandClient/CommandServer that use TCP/IP to invoke "Cmd.exe" piping to and from stdin/stdout and returning responses back down the socket.
All is well and it works nicely but there is one problem... And this problem is the reason I am here discussing this with you because I am hoping you can help!
The problem relates to how to know when Cmd.exe has finished processing the commands that has been given to it.
Recall that I am sending input to stdin and reading stdout to get the responses.
To address how to know when all is complete what I'm actually doing is sending a rogue value to stdin which I then look for in stdout to detect when the command is being fully processed.
So I send and then read... REM MartyWasHere
Cmd.exe doesn't barf and by the time it appears in stdout, I know that the previous command was fully executed.
This all works really nicely and means that I don't have to use time sensitive code which could break functionality if the command took significant time to complete.
This is a small edge case and the tool is valuable even with this problem but I would like to solve it, if possible.
The problem is that if the command that I have issued requires further input then the rogue value interrupts that flow.
As an example, sending this...runas /user:SYSTEM c:\windows\explorer.exe
Returns this...Enter the password for SYSTEM:
And now it considers the password to be REM MartyWasHere
I.e. It does not wait for the next input from client.
I'm not sure the best way to address this. Perhaps I use 2 unidirectional sockets, with just one reading and another just sending.
But that feels over kill.
Nor do I want to write time sensitive code that can break easily.
I'm using a combination of C++/Win32 and Boost.Asio.
If you have suggestions or would like a copy of the utility...
https://github.com/batmanonabike/cmdasuser
Any help appreciated.
https://redd.it/1jcy36c
@r_cpp
Why does "%" operator not work on negative integers i.e. (-7 % 5 returns -2) but mathematically -7 modulo 5 is 3?
Title
https://redd.it/1jcqw6p
@r_cpp
about the project
Hi all,I just want to start a project and am confused with the idea to start with
Can you give me some ideas even corporate people here can give me
https://redd.it/1jcem5k
@r_cpp
I made a custom 3D rigid body Physics Engine library in C++!
Ever wanted to mess around with real-time 3D physics engine? I've been building one from scratch that currently supports linear and rotational motion for rigid bodies, collision detection, force application and integration!
I'm currently working on collision response, because it already has a collision detection system. It's completely real-time, so currently you can choose the color, mass, size of a rigid body, you can apply any amount of force, change the direction, change where you want the force to be applied (which will affect rotation) and so much more soon.
If you'd like to experiment with it yourself, or make a small game, go check out the GitHub repository. There is a demo and a guide to how to build and use the library in the README.
Feedback and contributions are welcome! :D
\> Note: The engine is in its very early stages. Please be patient as I'm working on it by myself and I have school 5 days a week, 9:30 hours per day ;)
GitHub: https://github.com/felipemdutra/pheV3
https://redd.it/1jc7q1c
@r_cpp
how to run c/c++ on VS code?
i tried many things. i watched many yt videos. i changed my os to linux nothing works .
https://redd.it/1jbvgrm
@r_cpp
Mike shah concurrency
For cracking interview in concurrency Mike shah video series on concurrency is enough in cpp or do you guys have any other suggestions
https://redd.it/1jbpdg6
@r_cpp