131–140 of 214 posts
Ctrl-F "networking", cry, close page... See also: https://github.com/cplusplus/networking-ts
Earlier quoted context omitted.
This is doable in c++20 https://github.com/stephenberry/glaze
That's pretty neat! What's the C++20 feature that enables this?
Earlier quoted context omitted.
Any sort of reflection brings C++ one step closer to Python. Implementing serialization for complex types often requires manual code writing or external tools. With static reflection you could automate this process template void serialize(const T& obj, std::ostream& os) { for_each(reflect(T), [&](auto member) { os Simplified property systems class Person { public: Person(const std::string& name, int age) : name(name)…
Note that you should really be using std:print rather than std::cout if using modern C++.
Serialization
#include
template
void serialize(const T& obj, std::ostream& os) {
for_each(reflect(T), [&](auto member) {
std::print("{}: {}\n", member.name(), member.get(obj));
});
}
class Person {
public:
Person(const std::string& name, int age)
: name(name), age(age) {}
std::string getName() const { return name; }
void setName(const std::string& name) { this->name = name; }
int getAge() const { return age; }
void setAge(int age) { this->age = age; }
private:
std::string name;
int age;
REFLECT_PROPERTIES(
(name, "Name of the person"),
(age, "Age of the person")
)
};
int main() {
Person person("Alice", 30);
auto properties = reflect::getProperties();
for (const auto& prop : properties) {
std::print("Property: {} ({})\n", prop.name, prop.description);
auto value = reflect::get(person, prop.name);
std::print("Value: {}\n", value);
if (prop.name == "age") {
reflect::set(person, prop.name, 31);
}
}
std::print("Updated age: {}\n", person.getAge());
return 0;
}
template
void printTypeInfo() {
constexpr auto info = reflect(T);
std::print("Type name: {}\n", info.name());
std::print("Member count: {}\n", info.members().size());
}
template
void printAllMembers(const T& obj) {
for_each(reflect(T), [&](auto member) {
std::print("{}: {}\n", member.name(), member.get(obj));
});
}Earlier quoted context omitted.
Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to…
> There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?
Earlier quoted context omitted.
C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…
While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things: 1. how immense the language has become, and how hard it got to learn and implement 2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages While I like C++ and how crazy powerful it is, I also must admit decades…
There is no alternative to modernizing C and C++ Indeed I wish they were even more aggressive about breaking changes Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages Until then, we need C/C++ to be maint…
I bring it up partially because they are not taking a "rewrite it in Zig" approach, they are specifically aiming for incremental migration in mixed C / Zig codebases.
Earlier quoted context omitted.
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…
or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)
If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.)
You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to.
Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.
I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?
I've always wondered what's the point of "replacing moc". I mean what's the problem with moc? It's required by Qt, and completely transparent by the build system. You don't even know it's used. I mean, GCC also has some helper tools used to compile C++ code and we don't talk about "replacing them". Why people want to remove moc from Qt?
Earlier quoted context omitted.
or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)
Partly true. If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.) You did say "intentionally". You could wind up using a feature unintentionally, but it's no…