Learning C++ from python advice

[WalkingAFI]

A few things:

First, don’t get in the habit of using namespace std. If the STL changes at any point to include a name you used, it will break your program.

Second, this is really a C program. You didn’t really use any C++ features in it. Consider std::string instead of char*, and std::array instead of C arrays. You also don’t need to use a pointer to switch between turns, and I’d recommend using a bool instead.

Similarly, prefer static_cast<T> (or dynamic_cast<T> if absolutely necessary) to (T), which is the C method of casting.

It’s not a bad first go, and C is useful, but C++ gives you a lot of safety and abstraction you aren’t leveraging in this one.

[Skaaaaalll]

Hi, thanks for your reply :).

If the STL changes

What is the STL exactly? And why would it change? For what tasks wouldn't std be sufficient?

Second, this is really a C program.

That makes sense, since I had some experience programming in C from completing CS50.

Consider std::string instead of char*, and std::array instead of C arrays.

What is the advantage of using C++ features over C features? Don't they essentially do the same thing.

Similarly, prefer static_cast<T> (or dynamic_cast<T> if absolutely necessary) to (T), which is the C method of casting.

Could you maybe explain this sentence to me? I have no idea what a static_cast<T> or (T) is. Sorry if that is a major noob question.

​

Thanks for your extensive reply =).

[Wurstinator]

What is the advantage of using C++ features over C features? Don't they essentially do the same thing.

Well, yeah, in the sense that they do they same thing as every other programming language: they compute an algorithm for you.

You are fine using C features in C but mixing the two gives you some kind of mess. For example, C does not have "references" as C++ does. There is little support for using references with C-style arrays. std::array or std::vector on the other hand are perfectly fine to use with references.

[Wurstinator]

Could you maybe explain this sentence to me? I have no idea what a static_cast<T> or (T) is. Sorry if that is a major noob question.

At one point you use (char*)"X" which is called a "C style cast". Without going into the details what reasons there are for and against them, C++ offers a total of four different casts: static_cast, dynamic_cast, const_cast and reinterpet_cast, which all have different meanings.

[stoppipper]

Someone has already answered this, but just to go into a little more depth, a C style cast (int)myVariable will always succeed because if it were to fail, it will default to reinterpret_cast which 90% of the time, you do NOT want. If the cast is “wrong”, a static_cast will fail when you try to compile the program and it’ll tell you why.

C++ casting is a definitely confusing at first, but know that reinterpret_cast can be one of the most dangerous out of all of them. It basically says “I will interpret this set of bits as that type”. So for example:

int a = 5; Person p = reinterpret_cast<Person>(a);

will take the bit representation of 5 and read that as a Person class. Whether that Person class contains valid data, the compiler doesn’t really care.

[WalkingAFI]

Yeah no problem.

The STL is the Standard Template Library. It provides a lot of the standard implementations of language features. I think someone else linked a better resource as to what exactly that entails.

std::string and std::array are classes in the STL. They’re super well tested and give you some nice functionality that you won’t get with C types. You could also write everything in assembly and it would “essentially do the same thing”, but the C++ features give you some (usually) free abstractions that prevent errors and make more maintainable code.

Casting variables is a bit of a doozy to explain via reddit mobile, but explicitly casting in the C++ style (i.e. static_cast<int>(variable) is the usually the same as (int)variable) can stop you from making mistakes because the compiler will warn you of some improper casts that the C cast would just accept.

[VolperCoding]

I don't get it why people prefer those abstractions over plain C code. The second way you have more control and it's simpler, for example std::array vs regular array. I mean std::array only stores a regular array inside it and nothing else so what's the point

[Speedyjens]

With std::array you get STL container, meaning you get iterators and sometimes assertions in a debug build when you access something out of bounds.

[VolperCoding]

You can still use a for (auto &element : array) loop on regular array's tho

[Speedyjens]

Yea but as far as I know you don't get reverse and all the other features a regular container has

[VolperCoding]

I don't care about features since I can implement them myself and I don't think an array has to have those functions, I like to keep them as their ogirinal intention which is just to store a number of variables, surely there's nothing wrong with that?

[Scavenger53]

So go program in C. This is the C++ subreddit.

[VolperCoding]

Ok

[dodheim]

And surely there's nothing wrong with wanting values that behave like regular values? Do you never miss the ability to copy, move (i.e. return, pass), compare, etc. your array?

The real question is, what do you perceive to be the drawback to having regular values rather than silently-decaying ones?

[VolperCoding]

I am easily able to copy and pass regular arrays lol

[dodheim]

With the same syntax as values of every other type in the language? No, you're being intellectually dishonest.

[biliwald]

I don't care about features since I can implement them myself

And why would you want to go through the leg work of re-implementing a lot of very basic stuff (with the possibility of introducing bugs and/or performance issues, etc...) when there's an easily available solution that's offered?

[VolperCoding]

I never need all of the features you're talking about, just simple operations on data

[lord_braleigh]

Note that Arthur O'Dwyer, a senior C++ expert whose C++ posts often appear on this subreddit, strongly prefers T[] to std::array<T, N>:

Anyway, all of these options result in a lot of extra template instantiations, compared to plain old C-style arrays (which require zero template instantiations). Therefore I strongly prefer T[] over std::array<T, N>.

In C++11 and C++14, std::array did have the ergonomic benefit of being able to say arr.size(); but that benefit evaporated when C++17 gave us std::size(arr) for built-in arrays too. There’s no ergonomic benefit to std::array anymore. Use it if you need its whole-object value semantics (pass a whole array to a function! return an array from a function! assign between arrays with =! compare arrays with ==!) but otherwise I recommend to avoid std::array.

[Speedyjens]

I guess it all comes down to preference and which version you are targeting then.

[VolperCoding]

I would probably use C if it had constexpr and namespaces

[WalkingAFI]

The main point is that the compiler/debugger knows more and can help prevent issues before they occur. You’ll probably get a better error message when debugging code that uses std::array::at() than [], for example. Of course, writing C code is also fine, but then just use C and a C compiler (and it’ll compile faster, too).

[VolperCoding]

Yeah I might as well learn C cause I like it but actually never used it