C++

Forum

 
Most Essential C++ Advice

seeplus (6591)
deleted account xyzzy (5768)
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 (11437)
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.
Last edited on
zapshe (1907)
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 (3932)
Explicit memory allocation has its place.

C++ casts are great though. static_cast & reinterpret_cast in particular have saved me from many problems.
Last edited on
Peter87 (11235)
My biggest problem with static_cast for simple arithmetic types is that the same type conversion can often happen implicitly in many situations.

1
2
3
 
void foo(int);

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

1
2
3
4
5
6
7
8
9
10
11
 
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.

1
2
3
 
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.
Last edited on
zapshe (1907)
Yea, makes no sense to use a whole safe cast just for something as trivial as int(5.2)
jonnin (11437)
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 (6591)
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.
Topic archived. No new replies allowed.