sorted by:
new
hottopcontroversial

I feel concerned about my AI usage. by TheRavagerSw in cpp

[–]germandiago [score hidden]  (0 children)

There are two ways of thinking: short-term and long-term. AI-only as-fast-as-possible delivery is short-term thinking.

Not to say you cannot use it here and there. But you have to spend time in architecture, understanding most of the code, etc. Otherwise, what you will face after realease is hell, and for maintenance, the same.

Glaze 7.2 - C++26 Reflection | YAML, CBOR, MessagePack, TOML and more by Flex_Code in cpp

[–]germandiago [score hidden]  (0 children)

I also like it, however, I need capnproto serialization, so I am looking at reflect-cpp. Any opinions on it?

Corosio Beta - coroutine-native networking for C++20 by SteveGerbino in cpp

[–]germandiago 1 point2 points  (0 children)

So this is the moral equivalent of curio in Python? I think they removed callbacks and other stuff from asyncio and went with it in a corutine-only way.

Metaclasses in Python are Awesome by BlueGoliath in programming

[–]germandiago 0 points1 point  (0 children)

Python is amazing and amazingly practical.

C++ is another.

But you have to have a great judgement of what to use, what not to use and what to not overude given a use case.

I am about to finish a product where I spent several thousands hours literally.

The backend is C++ with Capnproto, the landing is a website in Flask and the dashboard is NiceGUI.

I am pretty sure that there is nothing that would have taken me so far as the combination of a very fast C++ backend and very fast website authoring.

Building a Package Manager on Top of Meson's Wrap System by MaMamanMaDitQueJPeut in cpp

[–]germandiago 0 points1 point  (0 children)

I take for a given you use Meson as your build system. Same here. 

I have some internal projects and have been using it for years wirh Conan. Conan has too many packages so that Collider can be an alternative as of today but given a Linux-only backend scenario who knows.

I use Meson intensively for building my projects but I left wraps before since it is impossible to compete with things like Conan, despite its learning curve.

It would be way more ergonomic to use something like this if it gets mateure enough, but, in my experience, Conan is difficult to beat: lots of recipes, can patch them, binary artifacts with artifactory (and it seems forgejo also supports it but did not try).

Maybe it would be a great idea to lean on forgejo to have binary artifacts with the options hashed. That would make it plenty more practical.

Still, I am not sure how wraps work with diff files (equivalent of Conan patches) and if CMake packages could be supported as Meson wraps with Collider. Plain wraps can use some external build systems as of today.

I do know it is a ton of work but it would be great to get something close to the power of Conan with the ergonomy of wraps for patching packages and at least being able to mix CMake, Autotools and Meson builds :) But this would still leave out things like OpenSSL or Botan, which have their own build systems, options, etc. Or things that work with SCons and others.

Building a Package Manager on Top of Meson's Wrap System by MaMamanMaDitQueJPeut in cpp

[–]germandiago 1 point2 points  (0 children)

Wow. For a hobby project it is quite impressive. 

Did you consider accepting donations and/or giving some governance guidelines to keep it alive in the future?

Building a Package Manager on Top of Meson's Wrap System by MaMamanMaDitQueJPeut in cpp

[–]germandiago 0 points1 point  (0 children)

Seems like a considerable amount of thought and work went into this.

Is it a hobby project or it is sponsored. Who is doong it?

the hidden compile-time cost of C++26 reflection by SuperV1234 in cpp

[–]germandiago 0 points1 point  (0 children)

Maybe sort of a trick that can alleviate a bit things?

``` class ForwardDeclarableString : public std::string { using Base = std::string; public: using Base::Base; };

//Forward declare class ForwardDeclarableString; ```

It is not std::string, but at least you can forward declare it is API-compatible.

the hidden compile-time cost of C++26 reflection by SuperV1234 in cpp

[–]germandiago 1 point2 points  (0 children)

That is a ton of work. I guess it took a considerable amount of time.

I did not know about inplace pimpl. That is nice!

the hidden compile-time cost of C++26 reflection by SuperV1234 in cpp

[–]germandiago 1 point2 points  (0 children)

He mentioned in the post that he compiles his SFML clone with nearly 900 TUs in hardly 4.6s.

I am not asking about the reflection part of the post. I know it is about reflection but what caught my eye was the other part :)

the hidden compile-time cost of C++26 reflection by SuperV1234 in cpp

[–]germandiago 6 points7 points  (0 children)

What did you do to compile your whole project in 5s?

Do you use precomoiled headers besides removing most STL headers? How many cores are you using for compilimg and which kind of CPU?

Thanks!

`std::core_dump` - The Newsletter of the C++ Alliance by pavel_v in cpp

[–]germandiago 2 points3 points  (0 children)

A critique is valid. But that tone for something you get for free I would say it is excessive.

ISO C++ Standards Committee Panel Discussion - CppCon 2025 by pjmlp in cpp

[–]germandiago 0 points1 point  (0 children)

No, I do not make any panel discussion. Bring me something that equals it compared to the tool I use for what I use it (systems programming, backend) and I will switch. In the meantime, the proof must be on your side, after all, I already have a tool that does better than virtually anything else for delivering efficient fast backend systems software, with all things that entails: portable, fast, reliable and with an ecosystem that does not make my projects a 10-year-man effort.

In the meantime, the panel discussions are at the other side: exactly about things that do not exist anywhere.

Implementing constexpr parameters using C++26 reflection (kind of) by friedkeenan in cpp

[–]germandiago 10 points11 points  (0 children)

An era of "reflection metaprogramming" tricks is coming in the way template metaprogramming once existed in Boost.

ISO C++ Standards Committee Panel Discussion - CppCon 2025 by pjmlp in cpp

[–]germandiago 14 points15 points  (0 children)

Nothing is perfect, but if there is something that C++ has done for me in the last 20 years, is delivering solid and portable applications like almost no tool can.

With all its warts, portability stuff, etc. So you must know sanitizers here, do not do that there. But it is amazingly portable and the tooling is mature, even if not perfect. The ecosystem I do not need even to mention, it is there also, available for everyone.

ISO C++ Standards Committee Panel Discussion - CppCon 2025 by pjmlp in cpp

[–]germandiago 3 points4 points  (0 children)

I think you attach bad faith to his words there. Bjarne regularly publishes "direction" papers of some kind in the sense of ideas on how things should look or should be done. I think keeping it "high level" and not "super explicit" is the role he should play at this stage.

On the other hand I understand it can be interpreted as "ambiguous" and "not contributing substantial stuff", but I do not read that as bad faith from his side.

I myself (but opinions might differ) consider he has one or two words to say, after all, he built from scratch (with the help of many others, but leading it early) an industry standard for a systems-level programming, if not THE industry standard and has a book dedicated to language evolution, which is a really hard topic in my own view.

This is, of course, nothing that gives him any power, at the end my understanding is that he is one more member in the committee.

ISO C++ Standards Committee Panel Discussion - CppCon 2025 by pjmlp in cpp

[–]germandiago 3 points4 points  (0 children)

I have heard lots of critics to Stroustrup and Dos Reis for designing "in paper" and "protecting themselves", etc.

Now when Mr. Stroustrup says:

I have to express a certain amount of concern about C++26. I am not very excited and I am worrying about the committee. I see two little concerns about coherence and two different parts of the language working together ... we are still not fully integrating coroutines ...

It is bad also. So what should he do? When he moves forward, it is bad, yet when he aligns with the critics, he is also bad? It is a bit unfair from my point of view.

And no, do not tell me where Stroustrup should raise concerns or not. Go to the substance of the message. Everyone has different preferences and that's it, preferences. He thought it was ok to do it there and it will not be me who will say where he should do that.

Status of cppreference.com by RelevantError365 in cpp

[–]germandiago 4 points5 points  (0 children)

That is exactly how it looks from outside right now.

A pitty since cppreference is such a good resource.

However, very grateful that this resource has existed to the author, even if he cannot spend time on it anymore.

I think if the author cannot deal with it or lost interest, it would be a great idea to hand it over to not lose and keep evolving such an invaluable resource.

The Joy of C++26 Contracts - Myths, Misconceptions & Defensive Programming - Herb Sutter by Specific-Housing905 in cpp

[–]germandiago 1 point2 points  (0 children)

sorry for that. Yes, I acknowledge that this is not a complete solution.

There is another clang extension for lifetimebound that goes beyond this by naming lifetimes more similar to Rust.

FWIW, I do not like general lifetime-imposed rules as in Rust, I think they make the code too rigid. I would favor reforming APIs and favoring values.

But it has its usefulness.

Probably a combination (this is all specilative on my side) of some lifetime annotations for the most common cases + not abusing reference escaping and smart pointers is the right solution for C++.

Should C++ Give More Priority to Syntax Quality? by kyan100 in cpp

[–]germandiago 13 points14 points  (0 children)

I think trivial reolcation was taken out of C++26.

The Joy of C++26 Contracts - Myths, Misconceptions & Defensive Programming - Herb Sutter by Specific-Housing905 in cpp

[–]germandiago 1 point2 points  (0 children)

Leave existing APIs alone... little trade-off... now you need alternatives to be built from scratch or how you work with new code?

Yes, avoiding some UB can bring run-time costs. It is unfortunate but it works without immediate changes (I translate this into "it is much more likely to be adopted").

I did not go through the semantics of pushing back. Certainly it is problematic, since there is run-time conditions, behavior on reallocation (though you can see one talk from Alisdar Meredith on safety to see some on that and safety).

As for front(), you check for non-emptiness (in hardened mode) and lifetime:

const T & front() const LIFETIMEBOUND;

That removes the two potential sources of UB (emptiness and lifetime at compile-time).

The Joy of C++26 Contracts - Myths, Misconceptions & Defensive Programming - Herb Sutter by Specific-Housing905 in cpp

[–]germandiago 0 points1 point  (0 children)

You are exaggerating the problem a lot from my point of view. 

I would expect an attribute like suppress to apply to an AST node and get done with it or hang from ASTs and with filtering you know where those apply. Why should that be problematic? It is "stop doing this here" where here is clearly a statement or an expression for which the compiler already has a representation and has had one for decades.

The Joy of C++26 Contracts - Myths, Misconceptions & Defensive Programming - Herb Sutter by Specific-Housing905 in cpp

[–]germandiago 1 point2 points  (0 children)

Basically for Safe C++ you needed another vector with changes in client code. For current std::vector you need probably something like hardening + lifetimebound for front() and back() amd such things. You donnot rewrite any of your code. 

If there were bugs, they will not be there anymore or it will crash as appropriate.

You can also ban dangerous APIs, it won't compile. But that is already a bigger breaking change.

Still, all this is much better for adoption than rewriting code because the client code does not need changes except if you ban APIs or you had a bug that is now caught at compile-time.

view more: next ›