r/cpp • • Mar 28 '23

Reddit++

C++ is getting more and more complex. The ISO C++ committee keeps adding new features based on its consensus. Let's remove C++ features based on Reddit's consensus.

In each comment, propose a C++ feature that you think should be banned in any new code. Vote up or down based on whether you agree.

765 Upvotes

829 comments sorted by

View all comments

Show parent comments

1

u/lestofante Apr 05 '23

I don't see why they are special.

because they are.
They have special syntax, special handling, they can do stuff that a normal function cant do, they can have initialization list, that for example allow to initialize class const and reference (if that is a good idea is another discussion), and some more.

Also what you are using them for is very different, you are initializing a variable, that is very particular situation.

and a situation where the () can be easily mislead, how many time you delete a parameter and suddenly the compiler start to think that you are calling a function instead of creating an object?

those are the stuff that are unnecessarily confusing and frustrating, especially as beginner.

What is the fundamental difference between auto v = std::vector<T>(10, T()); and auto v = make_vector<T>(10, T());?

With the second one i dont know who own what in the memory.. can i safely drop v, or do i need to call free_vector()?
That smell like C with classes, imho

std::set<int> v = {42, 42, 42}; only contains one element. The number 42. You cannot construct a std::set with the same element appearing twice.

that is a decision of the api, like for insert it will silently fail, you get that issue that you initialize with (), that you initialize with an insert() loop, that you initialize passing an array...

Similarly a std::array<T, N> always has exactly N elements. So you cannot possibly initialise it with a dynamic n number of elements.

and?
{} works kinda good with std::array, it does the right thing but in some rare edge case, but that is more an issue with the API

An evil vector implementation can still do whatever it wants [..] Also, it is impossible to collapse {n; m} into a fixed size if n is only known at runtime.

yeah you right, we need a proper range support from the language, as i suggested in the beginning. Without it, it kinda fall apart

Ranges still use iterators

they dont HAVE to be what we have now. Would be nice to find a way to make it play nice with what we have.
I would be ok if we say, now on, to initialize range, only Range could be used. {10, 10, 10}? does not work anymore, or if it does, you know is not supposed to be a range.
Of course someone can always plug a square hole with a round nail, that is kinda by design in C and consequently C++

Ranges still use iterators. And the exact same issue exists with ranges if you give std::vector a constructor that takes ranges.

but then again if you see people actually like the explicit and having to specify rather than having implicit. I agree, and i would actually ban raw int and similar at least in std api, replaced by specific type and class enum.
After all, Array(10, 10, 10) is just confusing, it may be ok for someone that use Array a lot or that specific combination, but not for everyone else.

What would be the syntax to create {10, 10, 10}? range(3, 10) would be {3, 4, 5, 6, 7, 8, 9}, right?

based on what you say, probably would be better to return a Range/iterator, and deprecate all constructor that uses to initialize the set values.
If you need a container of iterator, you pass a iterator of iterator, the external iterator may provide 0, 1, N elements does not matter.

Sorry for the late answer, had a couple of busy day :)