h8CplusplusGuru said:

taby said:

Oh, and if you’re using pointers (other than function pointers), you’re doing it wrong.

What's wrong with using pointers?

You should prefer to use references over pointers, for any variable where the address can neigther be nullptr nor change. Thats my main criticism of UE4 for example - everything is returned by pointer even if the object is guaranteed to exist, meaning you never know if a nullcheck is needed or not (without fully reading and understanding the source). If on the other hand, you have a codebase where pointers are exclusively returned by functions when the return-value might be a nullptr, its obvious which return-values need to be checked (and there should be way less when everything else is returned by &).

Juliean said:

You should prefer to use references over pointers, for any variable where the address can neigther be nullptr nor change.

I've heard a lot of people say that but I personally prefer pointers in most cases. I use references for operator overloading (what they were originally added to C++ for) and also to signify return parameters. I sometimes have a reference to a pointer in a function declarations. But overall I like pointers because I find them more intuitive. For instance it's obvious when I see a pointer that it's almost always referring to something on the heap. But yeah, I guess this is a matter of taste.

taby said:

I should have said that memory allocation using new and delete is generally a bad idea, because there are containers to do that job for you.

Otherwise, pointers are great.

I typically use new but not delete. (ha ha). But I really do. It's part of my smart pointer system.

taby said:

Do not use the auto keyword. You’re only obfuscating your code when you use it.

I specifically wish to highlight how wrong this is. I'm assuming here, but if you shun auto, then you haven't had to write complex code.

In addition to making code clearer and saving a ton of typing, auto is a mainstay feature that opens a door to flexibility. Not only is it an old idea, it is required in a lot of modern notation when dealing with templates. By not using auto (pretty much everywhere) you're only hamstringing yourself and keeping yourself from learning newer features.

h8CplusplusGuru said:

taby said:

Oh, and if you’re using pointers (other than function pointers), you’re doing it wrong.

What's wrong with using pointers?

There's nothing wrong with using pointers, but it boils down to expression of intent.

Null is (or at least should be) a valid state for a pointer, while a reference should never be null. If your function accepts a pointer, then it implicitly suggests that it checks the pointer's validity before using it. Conversely, if a reference is null, then it's the caller's fault for not making sure the object existed in the first place. Generally speaking I agree with taby here - you should keep your code const-correct and use references (preferably const references, unless an object is open for modification) where ever possible.

On the topic of intent and correctness - not only should you be aiming to minimize possible sources of misinterpretation, but if you're on Visual Studio, it wouldn't hurt to also pick up using SAL where ever you can. Even if you're lazy, annotating your in and out variables conveys not only meaning and clarifies intent, it allows the static analyzer to call you out if you break your own rules.

As it stands right now, SAL is proprietary (that is, patented) and therefore not supported by compilers other than VS, but since it's macro-based, it's trivial to use and keep your code portable.

I dunno… one of the more complicated codes that I wrote was an equation parser. In the end, it gives you a heap of pointer to functions, along with a list of addresses. It’s all pointers, as you can see… but not once did I use them for memory allocation — I use vector for that.

https://github.com/sjhalayka/marching_cubes/blob/master/eqparse.cpp​

Yes, the code is of the garbage in, garbage out design.

taby said:
… was an equation parser

Try extending it to support both narrow and wide strings (string and wstring) without code duplication.

I understand how unintuitive auto seems if you're not writing templated code, but even then - as an experiment, try replacing every type with auto for a week and then see if your ability to read that code goes up or down. And I mean, use it everywhere, including:

auto copyvar = oldvar;
auto newvar = float(0);

etc.

Auto is great. Trying declaring an iterator of a template of a template. It is a huge pain with classic C++, but effortless with auto.

Why would I write an equation parser using wide strings, when all of the chars necessary are not wide?

I could understand you trying to convince me to template the hell out of my quaternion library, but not the equation string.

taby said:

Why would I write an equation parser using wide strings, when all of the chars necessary are not wide?

I could understand you trying to convince me to template the hell out of my quaternion library, but not the equation string.

Because you would see why auto is useful.