Most Essential C++ Advice

[seeplus]

This article may be of interest
https://www.codeproject.com/Tips/5249485/The-Most-Essential-Cplusplus-Advice

[George P]

The advice is pretty much boiler-plate stuff, for the most part not at all controversial.

A major problem with this advice lies with the way far too many people are being taught C++ in schools and universities, rooted in pre-C++11 as THE only way to instruct first time students.

Not the fault of the article's author. C++ Core Guidelines say much the say as this article, in greater depth.

The advice will more than likely be ignored by a lot of people. I ain't one of "them."

[jonnin]

I try to follow most of those as best as I can.
But my C casts will probably follow me into the grave, because the new ones are clunky -- and they freaking admitted this when they added them, because the creator of it has a hateful grudge against casting things and thought it would be rare so clunky was somehow 'good'. Bah humbug. Ill use the new ones when OOP is involved, but the C ones are just fine to turn a double to an int or the like.

[zapshe]

Don’t use new/delete... Don’t Use Old-Style or C-Style Casts

Those two are debatable. It's like saying don't use plastic because metal is better. Sure, but plastic can be more than good enough for a situation.

[mbozzi]

Explicit memory allocation has its place.

C++ casts are great though. static_cast & reinterpret_cast in particular have saved me from many problems.

[Peter87]

My biggest problem with static_cast for simple arithmetic types is that the same type conversion can often happen implicitly in many situations.

void foo(int);

foo(myVec.size()); // ok 

void foo(int);
void foo(double);

foo(myVec.size()); // error: ambiguous

foo(static_cast<int>(myVec.size())); // This is ok ...

foo(int(myVec.size())); // ... but why not simply do this ...

int myVecSize = myVec.size(); // ... when the same conversion is allowed implicitly here? 
foo(myVecSize);

It just feels wrong and inconsistent that the same conversion that I sometimes let happen implicitly I should sometimes be overly verbose about. For the same reason I'm also not fond of C++11 banning narrowing conversions inside {} initialization.

I guess it might make sense if you use compiler flags that warn about loss of precision/narrowing, but warning about all such conversions adds a lot of noise, and would force you to add a lot of explicit casts to silence them.

std::int8_t a = 50; // implicit conversion from int
std::int8_t b = 2; // implicit conversion from int
std::int8_t c = a + b; // implicit conversion from int 

GCC has -Wconversion. In the past I think it warned in too many cases (e.g. on line 3 above) but it seems to have gotten some improvements (i.e. it warns in fewer cases) so maybe it's worth a try, at least on new project? I'm a bit hesitant to rely too much on these flags because they seem to differ quite a lot between different compilers and compiler versions so there would be no strict standard for when to use an explicit cast.

[zapshe]

Yea, makes no sense to use a whole safe cast just for something as trivial as int(5.2)

[jonnin]

its just the space to me. Sometimes when doing math you can have 3+ casts in 1 line to shut up the warnings, and that is unreadable with the gigantic safe ones.
I understand why we need them at times, but the intentional ugly was a bad choice.

[seeplus]

I think one of the reasons was to make it easy to find them with a search. Just search for _cast. You can't find the c/functional casts easily like that.