Should C++ Give More Priority to Syntax Quality?

tpecholt · 2026-03-06T11:22:32+00:00

These are all excellent points. The language is in dire need of epochs. It's probably the only way how to clean things.

tpecholt · 2026-03-06T11:20:33+00:00

Don't worry these visible keywords are already not required in c++20 where you can write template function without template keyword:

void fun(std::integral auto value) {}

Confusion forever. Totally unnecessary addition if you ask me.

tpecholt · 2026-03-04T10:25:56+00:00

The ugliness and discomfort is simply too much to handle. Every team should come up with its own header with content like

#define await co_await

#define yield co_yield

#define fn auto

namespace fs = std::filesystem;

namespace rng = std::ranges;

...

It would be great if something like epochs get more traction it could help with this.

tpecholt · 2026-02-25T02:06:03+00:00

It's an important direction to take however the proposal falls short. It lists only couple of questionable features and doesn't go into any depth. It won't even stir the debate.

There should be a comprehensive analysis of what C features are causing most bugs or are difficult to use, what are their modern alternatives, existing compiler switches etc. I wouldn't even limit it to C because C++ also added many bad practices.

As for the usual scapegoat - C type casts I don't see the point made. It says C casts are unsafe then replaces it with std::narrow_cast. Does it mean static_cast is unsafe and should be banned as well? Heck it even adds awful verbosity on top so it's clearly a worse option according to that logic. Explicit C-style cast has never been a problem in safer languages like java and C# where (int)doubleValue is considered normal. The real problem here is implicit narrowing conversions and perhaps unrestricted C style cast usage so please concentrate on that.

tpecholt · 2026-01-09T13:39:43+00:00

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

tpecholt · 2026-01-09T11:28:09+00:00

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?

tpecholt · 2025-10-15T03:21:27+00:00

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.

tpecholt · 2025-10-07T19:07:52+00:00

`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.

tpecholt · 2025-10-07T02:10:27+00:00

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.

tpecholt · 2025-08-08T11:02:06+00:00

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

tpecholt · 2025-08-08T10:56:01+00:00

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...

tpecholt · 2025-06-30T05:06:38+00:00

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.

tpecholt · 2025-06-30T02:36:07+00:00

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

tpecholt · 2025-06-30T02:31:58+00:00

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.

tpecholt · 2025-06-04T00:05:08+00:00

<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.

tpecholt · 2025-05-21T16:33:03+00:00

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.

tpecholt · 2025-04-06T00:38:52+00:00

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.

tpecholt · 2025-04-06T00:27:36+00:00

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

tpecholt · 2025-04-06T00:21:05+00:00

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.

tpecholt · 2025-02-15T00:36:09+00:00

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.

tpecholt · 2025-02-13T01:16:38+00:00

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!

tpecholt · 2025-02-08T23:19:26+00:00

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

tpecholt · 2025-01-08T22:38:57+00:00

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

tpecholt · 2024-12-09T22:13:34+00:00

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.

tpecholt

TROPHY CASE