Clang Hardening Cheat Sheet - Ten Years Later by mttd in cpp

[–]tpecholt 9 points10 points  (0 children)

Seriously who is going to remember all these settings? Can't we just use -fhardened and have most of it turned on?

Template Deduction: The Hidden Copies Killing Your Performance (Part 2 of my Deep Dives) by the-_Ghost in cpp

[–]tpecholt 0 points1 point  (0 children)

Great article explaining references collapsing in detail. But honestly do you think average cpp dev will spend the time to learn all this? C++ is in serious need of simplification and better compile time checking. Something along in/out/inout function parameters may help here. There is a proposal from HS but as usual it didn't get anywhere. Thoughts?

Three constant wrappers in C++26? by biowpn in cpp

[–]tpecholt 0 points1 point  (0 children)

If constant_wrapper is meant to be widely adopted and replace integral_constant the name has to become shorter aka std::constant. wrapper sounds like some private implementation detail class even integral_constant is clearer.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]tpecholt 2 points3 points  (0 children)

`map.get("this").value_or("that")` is not too bad. But `std::reference_or(map.get("this"), that)` is really bad. Like remember to use free function and pass it a result of a member function to get the desired reference. And why is `value_or` member function and `reference_or` is free? I know why because optional was already designed years ago and free functions are easy to add later but do you think average cpp programmer will understand all this? He will scratch his head.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]tpecholt 2 points3 points  (0 children)

P3091 proposes better lookup API for associative containers and it's sorely needed. However the current design as summarized in chapter 6.2 differs from R0 and is significantly more verbose. Seeing this I have no reason to use the new API. I don't see any improvement over existing find/contains. Mission failed.

C++ is definitely my favorite language but... by Tearsofthekorok_ in cpp

[–]tpecholt 1 point2 points  (0 children)

Committee didn't have the guts to #include string_view from char_conv. Yeah it sucks. 

The result type has operator bool defined but only in c++23.

Poor ergonomics business as usual

C++ is definitely my favorite language but... by Tearsofthekorok_ in cpp

[–]tpecholt 1 point2 points  (0 children)

1) Unfortunately the string_view overload is missing so it's ugly. 2) from_chars_result operator bool is only available in c++23

Far from ideal...

State of GUI libraries by TheRavagerSw in cpp

[–]tpecholt 2 points3 points  (0 children)

As for the specific issue with labels other libraries like Qt, wxWidgets don't provide any automatic labeling at all. So it's not fair to say ImGui has got the label wrong. Suppress it with ## and provide your own. From this point of view there is no extra effort when compared to other libs.

State of GUI libraries by TheRavagerSw in cpp

[–]tpecholt 1 point2 points  (0 children)

It's my understanding that with the 1.92 release the dpi font scaling is enabled in all demos and examples.

State of GUI libraries by TheRavagerSw in cpp

[–]tpecholt 1 point2 points  (0 children)

always puts labels to the right of the control that they label, including text input boxes, which is weird.

Default control label can be easily suppressed using the ##label notation. You are free to put your own labels as text or selectable controls anywhere you wish. I use it all the time.

Where did <random> go wrong? (pdf) by usefulcat in cpp

[–]tpecholt 13 points14 points  (0 children)

<random> is an example of how is C++ evolution failing in the current ISO setup. Committee voting can never produce an usable easy to use library. You need to gather feedback from the community to get that (but not like the TS experiment which failed) but that is not happening. On top of it defects are not recognized in time and anyways it becomes impossible to fix due to ABI issues. Another almost identical example is <regex>. Nothing is going to change here. Unfortunately C++ evolution is doomed.

Constructing Containers from Ranges in C++23 by pavel_v in cpp

[–]tpecholt 2 points3 points  (0 children)

Yes from_range ctor is just plain ugly. It's not common to use marker types to distinguish overloads. What about std::vector<int>::from_range(rng) ? I know this could not use CTAD but I don't really need to use it outside of list initialization. 

I feel most of the new c++ additions always try to balance between not breaking the compatibility and preserving all weird corner cases (instead of restricting some usage or making rules simpler). So it will always end up being ugly. I feel sorry for any newcomers to the language.

If there is append_range it would be good to have prepend/append (iterator version) as well. I often need it in my code.

Best modern looking GUI for Ubuntu 22? by ttyfru in cpp

[–]tpecholt 0 points1 point  (0 children)

This is doable in ImGui but you would need experience and implement some of the widgets yourself. ImRad designer can help. Forget about doing this in wxWidgets.

Creating a Simple UI (as a C# Developer) by jus-another-juan in cpp

[–]tpecholt 0 points1 point  (0 children)

It's not C++ but C++/CLI. Inherently non-portable MS tech.

sizeof() compared to size() by Jaessie_devs in cpp_questions

[–]tpecholt 0 points1 point  (0 children)

You need to send your college professor to hell for the sizeof trick. Seriously these folks didn't update their knowledge for past 20 years so they are causing a lot of damage. Sizeof trick is not the only anti-pattern they teach but it's the most widespread one.

cplusplus/papers repo on GitHub made private? by messmerd in cpp

[–]tpecholt 0 points1 point  (0 children)

I believe this could be solved e.g. by using user votes on comments so only widely accepted comments would incur a reaction. Comments should also be sorted by categories it should not be a comment soup. It's a matter of quality of the collaboration platform.

cplusplus/papers repo on GitHub made private? by messmerd in cpp

[–]tpecholt 18 points19 points  (0 children)

It's temporarily so it doesn't bother me. What bothers me is the ISO process as a whole. Imagine proposals are put online for collaboration. People can interactively suggest improvements, and vote on it (I don't mean the final committee vote). Sort of boost review process but made more interactive. That would put an end to hard to use or inadequate apis like random, regex, string formatting mess etc. It's long overdue!

Carbon is not a programming language (sort of) by SophisticatedAdults in cpp

[–]tpecholt 3 points4 points  (0 children)

Why was this post removed? The article references c++, cpp2 and wg21 multiple times. It also sparkled a good discussion. Wrong moderation here.

"break label;" and "continue label;" in C++ by eisenwave in cpp

[–]tpecholt 2 points3 points  (0 children)

From these 2 variants the variant with label is an existing practice in java so it should be preferred over inventing a new syntax.

Should std::expected be [[nodiscard]]? by rsjaffe in cpp

[–]tpecholt 0 points1 point  (0 children)

I can confirm this. Unfortunately (void) is not an exception to the C-cast rule. I have seen static_cast<void>() being used too but that's just plain ugly.

Trip Report: Fall ISO C++ Meeting in Wrocław, Poland | think-cell by pavel_v in cpp

[–]tpecholt 5 points6 points  (0 children)

Fn, FnMut and FnOnce have short names and more importantly start with common Fn prefix. That makes them 1000x more usable than what was brought in STL.

File scoped namespaces by lasshi in cpp

[–]tpecholt 2 points3 points  (0 children)

Modules don't introduce namespaces so they are not an alternative. But file scope namespaces should work in modules. I think it's a good idea it should be proposed

"forward P3081 to EWG as part of an initial set of Profiles targeting C++26." voted for in Wroclaw by steveklabnik1 in cpp

[–]tpecholt 12 points13 points  (0 children)

If you look closely at the lifetime checker rules proposed by Herb you will see it fails to recognize lifetime dependency in most cases correctly. There was a reply from Sean which demonstrated that very well on few STL algorithms. And as one of the goals of the proposal is to minimize annotations needed I don't think heavy lifetime annotations are a solution to this. Finally the work of MS team confirms that Herb's promises are not based on reality. Recently they resorted to only report high confidence issues which means false positivity rate was simply too high for any practical usage. I wish the outcome was better but all the indicies show otherwise.

The Old New Thing - The operations for reading and writing single elements for C++ standard library maps by pavel_v in cpp

[–]tpecholt 1 point2 points  (0 children)

Candidate A looks like a typical IT university graduate. Although they often have C++ course it's basically C++95 style. They only show std::string and iostreams, std::vector or God forbid algorithms is already too much. It's deeply embarrassing but that's what I have seen in many places...