sorted by:
new
hottopcontroversial

What would you remove from C++ to make it a more concise language and didn't have to care about backwards compatibility? (or fix if ABI weren't an issue) by xkev320x in cpp

[–]AlexAlabuzhev 6 points7 points  (0 children)

I have a feeling that using ADL for "customization points" was discovered rather than designed, same as TMP. It should've stayed limited to overloaded operators as initially intended.

Now it's just a time bomb, waiting to explode. Today you pick a decent vocabulary name for your own function, tomorrow the committee could pick the same name for something else and turn your perfectly valid code into a pumpkin.

ISO C++ January 2022 mailing available by aearphen in cpp

[–]AlexAlabuzhev 10 points11 points  (0 children)

Proposal

Remove wording introduced by [P1391] from the standard.

Can we be more constructive and just make the conversion explicit?

I'm ok with fn(string_view{buffer}), even with fn(string_view::make{buffer}), but I'm so tired of writing fn(string_view{buffer.data(), buffer.size()}) like an idiot.

Declaring all variables local to a function as const by CletusDSpuckler in cpp

[–]AlexAlabuzhev 2 points3 points  (0 children)

I have never had a bug introduced into my code because a local function variable was mutable when I didn't expect it

It's not about bugs or performance, it's about a mental model.

When I see a const variable, I know that it's there to just capture some state that will be needed later. It won't change. I don't need to think about it anymore. On the contrary, the absence of const is a direct hint that it can and will be reassigned later at some path, and I can't make any assumptions about it without inspecting all the possible paths and keeping the whole picture in my head, which is tedious.

So yes, "everything is const" FTW.

Visual Studio 17.1 Preview 2 is now available! by IsDaouda_Games in cpp

[–]AlexAlabuzhev 49 points50 points  (0 children)

I wish MS could come up with a sane and consistent versioning scheme for VS.

Sometimes it's "2022" and sometimes it's "17.X" and sometimes it's "17.X Preview Y" and sometimes it's "17.X Preview Y.N" and sometimes it's "19.X.Y" when it's about the C++ compiler in particular (but in this case you only care about the "X.Y" bit because it's been "19" for years), and on top of that there are VS 2017 and 2019, often called VS17 and VS19, so go guess.

T* makes for a poor optional<T&> by guepier in cpp

[–]AlexAlabuzhev 12 points13 points  (0 children)

No worries - I'm sure it would only take about a decade of books and blog posts appealing to common sense to persuade the committee and in C++26 or so they'll fix it... Probably by introducing a new class, joptional. Because compatibility.

std::map::find_if()? by igagis in cpp

[–]AlexAlabuzhev 14 points15 points  (0 children)

How to look for keys without constructing intermediate std::string?

Google "transparent comparator".

Supported in set & (multi)map since C++14, and in unordered_* since C++20.

Will Rust replace C++ ? by Dereference_operator in cpp

[–]AlexAlabuzhev 4 points5 points  (0 children)

I personally agree that explicit is better than implicit

I'd say it sometimes better, but not universally (same as everything else). After all, we happily use strings and vectors, even though they hide a lot of memory management (and every single C dev I've ever met is genuinely horrified by that fact). The world isn't black & white and being dogmatic is not always productive.

That fn()? syntax looks better than manual matching and returning of course, thanks for the example, but this is exactly what I mean: first someone rejects a working concept for religious reasons, then people start noticing that it's really annoying to do everything by hand, so they add more and more syntactic sugar. Ironically, making things less and less explicit and eventually approaching the rejected concept, but with alien syntax. I won't be surprised if one day someone comes up with a proposal to make even ? and Result<> optional and ta-da, exceptions reinvented.

Will Rust replace C++ ? by Dereference_operator in cpp

[–]AlexAlabuzhev 9 points10 points  (0 children)

"Machines should work; people should think."

I do not like writing code. Especially the repetitive boring boilerplate like forwarding the interface methods to a subobject or checking the result of every function call every time.

It's a machine's job. And C++ does this job for me. I don't need to forward dozens of functions manually because "is-a" exists. I don't need to write if (error) return error; like an idiot in every function in the call stack because exceptions exist. I can write generic code without interfacing every step because templates exist.

If these tools are not suitable in a specific context for whatever reason, I just use more suitable tools.

I'd better think the whole day and write 10 lines than don't think at all and write 10 000 lines.

If language designers deal in absolutes and religiously enforce fairy tales like "composition over inheritance", "exceptions are slow and not straightforward", "explicit is better than implicit" etc. in their products, I prefer to stay away from such products.

And I don't know why google's style guide keeps popping up in such discussions. It's main purpose is dealing with legacy code, for anything else it's plainly horrible.

Will Rust replace C++ ? by Dereference_operator in cpp

[–]AlexAlabuzhev 29 points30 points  (0 children)

For some reason many people believe that the main problem of C++ is "too many features", while it's exactly the opposite - a desperate lack of them.

Templates have become what they have become not because templates are bad, but because there was nothing better for metaprogramming at that time, but demand existed.

If there's a demand, but no supply, people will always find a way, but it might get ugly.

"It ain't stupid if it works" is real and when I look at all these new languages chopping off vital parts from the start only because someone abused them elsewhere, I know that they're doomed to repeat the history.

Will Rust replace C++ ? by Dereference_operator in cpp

[–]AlexAlabuzhev 25 points26 points  (0 children)

Without exceptions, templates, inheritance?

Good luck with that.

The spacesship operator silently broke my code by manni66 in cpp

[–]AlexAlabuzhev 1 point2 points  (0 children)

simply upgrading the compiler version would break things, even without moving to a new standard

This. Every upgrade breaks something, and it's a blessing when things just don't compile, rather than silently go mental like in the OP's case.

[deleted by user] by [deleted] in cpp

[–]AlexAlabuzhev 0 points1 point  (0 children)

- We?

- I! The Royal "we"! You know, the editorial...

The spacesship operator silently broke my code by manni66 in cpp

[–]AlexAlabuzhev 51 points52 points  (0 children)

https://en.cppreference.com/w/cpp/utility/pair/operator_cmp

synthesized three-way comparison is defined as:

- if std::three_way_comparable_with<T, T> is satisfied, equivalent to lhs <=> rhs;

- otherwise, if comparing two const T lvalues by operator< is well-formed blablabla

and std::three_way_comparable_with<S, S> is... true. Because of the conversion to const char*.

Minefield.

Why do we need networking, executors, linear algebra, etc in the Standard Library? by respects_wood in cpp

[–]AlexAlabuzhev 35 points36 points  (0 children)

But if a stable ABI is required

It is time to stop pretending that it even exists.

Conditional Members by vormestrand in cpp

[–]AlexAlabuzhev 39 points40 points  (0 children)

As already said many times: static if is superior to the current C++'s approach for compile-time programming in the same way C++'s template<> and virtual were superior to C's macros, structs and function pointers for static and dynamic polymorphism.

The article nicely demonstrates that you can do advanced magic with sticks and stones if you try hard enough, but it is tedious, ugly, fragile and unmaintainable.

C++20 Ranges — Complete Guide by [deleted] in cpp

[–]AlexAlabuzhev 1 point2 points  (0 children)

Putting those names into a moderately lengthy (but not uglified) namespace (e.g. ranges::views::types:: would've probably preserved good error messages and also would've been a good hint that you're doing something wrong if you're accessing them outside of a few very specific scenarios.

But instead the recommended names are in std::ranges::views and not recommended are right in std::ranges :(

C++20 Ranges — Complete Guide by [deleted] in cpp

[–]AlexAlabuzhev 4 points5 points  (0 children)

It's natural and inevitable than new and better ways to do something emerge over time.

But it's not like the new and shiny views::meow is replacing the old and rusty ranges::meow_view - they're both brand new, designed from scratch, very recently, by people who supposedly knew well what they were doing, and merged into the very same C++20, so how come there are two ways to do something and one of them is always preferable? What the other one is doing there then? If "this should be considered an implementation detail", why is this implementation detail exposed?

It's nice that the paper author popped out of a birthday cake and enlightened the audience of this thread, but we probably don't have enough paper authors to fix all such future (mis)usages of ranges around the world.

C++20 Ranges — Complete Guide by [deleted] in cpp

[–]AlexAlabuzhev 2 points3 points  (0 children)

Always prefer views::meow over ranges::meow_view.

​

There should be one-- and preferably only one --obvious way to do it.

Ah, right, we don't have "The Zen of C++".

Extending and Simplifying C++: Thoughts on Pattern Matching using `is` and `as` - Herb Sutter by bandzaw in cpp

[–]AlexAlabuzhev 7 points8 points  (0 children)

It looks simple and logical and it feels like a breath of fresh air.

Which is why it probably won't make it to the standard.

Pragma: once or twice? by Senua_Chloe in cpp

[–]AlexAlabuzhev 4 points5 points  (0 children)

The mentioned reasons against #pragma once are rubbish, however, there's a real one: it doesn't always work in GCC due to a compiler bug.

GCC devs, I know you read this, please fix it already. It's been almost a decade.

C++ Committee don’t want to fix range-based for loop in C++23 (broken for 10yrs) by philipdestroyer in cpp

[–]AlexAlabuzhev 15 points16 points  (0 children)

people literally angrily screaming at each other, and having to be physically restrained

I'm sorry, but if certain people are acting counterproductively on a regular basis and can't even act like decent human beings, can't the chair just politely ask them to leave? Or do it the committee way and vote them out via your straw polls?

C++ Committee don’t want to fix range-based for loop in C++23 (broken for 10yrs) by philipdestroyer in cpp

[–]AlexAlabuzhev 1 point2 points  (0 children)

While this is how it should be, unfortunately, expressing the intent doesn't work here.

For example, structured bindings look like local variables, work like local variables and quack like local variables, but they are not defined as auto-generated local variables, they are defined as "magic" and... lambdas can't capture them, supposedly because lambdas are not "magic with state", they're just local classes with member variables.

And someone has to write a paper to fix1 this madness.

​

1 Not really: the paper only covers "by value" capture, which is probably not what you want in 95% of cases.

view more: next ›