Avoid 'auto' in tutorials

Yeah, haha.
I agree: Visual Studio is much better at this.
Maybe XCode is optimised for Swift and not for C++?

1 Like

Probably, even tho didn’t Xcode exist before Apple made Swift?
Anyway I did setup VSCode to build using xcodebuilds as one user forum stated in another post but had my Mac formated so lost it. It was a bit tricky but it ended up working, so will make a guide one of this days if I do it again.

1 Like

Yeah, that works. But I have to write it first. If I just scan over a file, to read the source code, I can’t get the type.

This pitfall applies to comments as well.
It is fortunately easy to change an identifier throughout its scope, and I do that immediately when I discover any of its implications are obsolete. Comments are harder to update, I find.

1 Like

This is great when it all propagates correctly, but in audio signal processing, the type can affect the actual algorithm you need. For example, changing a typical white-noise generator from 32 to 64 bits will break it. When I write int, I’m really thinking int32, and I am writing things like that more and more just to nail it down. I could also use an assertion, I suppose.

1 Like

I see that as another reason to use auto. It avoids typing the wrong type and seeing it silently fail with an implicit conversion. It also makes easier to modify an algorithm for a different type without having to check every declaration.

1 Like

Which is actually a plus for auto. auto will never change the type, it keeps the type it was assigned to. If you want to force something to a certain type, you can certainly do with an explicit cast, and that is then right in front of your eyes, just what was requested.

4 Likes

i had no c++ knowledge when i started using juce in december. juce makes c++ pretty easy (in many cases)

also i feel like there is a musunderstanding in this post. this post was, if i understand it right, not meant to say auto is bad. so no one needs to use arguments why auto is a good keyword. it’s only about its readability. and when people read code they wanna get an overview about all things happening by just looking at it without hovering over each variable. especially when a code’s topic is hard to grasp it can be additionally confusing if not even the types are clear on first sight. it’s not that it makes the tutorials completely useless ofc. just a minor inconvenience

@reFX @hdlAudio
Same here, no C++ knowledge at all before Juce, only many failed attempts to get into C++. Juce is what made it possible for me to properly learn it. Now, only about 2 years later, my first programs are on sale

@topic: +1 for auto in tutorials, even though readability suffers a little. You don’t have to be type specific in other languages too and the benefits of using auto outweigh the readability issues imo

2 Likes

I’ll consider C++ ready for the ‘auto’ keyword (at least for signal-processing applications, which is normally what I am doing) when std::abs() is equivalent to the proper choice among abs(), labs(), llabs(), fabs(), fabsf(), fabsl(), etc., and 1.3 % 1.0 == fmod(1.3,1.0), etc. If some function starts returning a different type, such as a float instead of int, auto is going to make it harder to figure out what went wrong. I don’t intend to use ‘auto’ except when it saves typing without loss of specification. For signal processing, I want to specify the type I am writing for. If a function tries to return something else, I want the compilation to fail.

That is exactly the thinking of the C++ / STL designers: std::abs et al. will always return the same type as you feed into. Because any choice would be ambigous, or could lead out of the numeric limits.
It is also guaranteed, since the template specialisation is chosen after the argument’s type, but never after the return type.

You can force a different specialisation like that:

auto foo = std::sin<double>(3.14f); // will implicitly cast the float argument to double
                                    // and will return that type

The return type of the function is declared, and the compiler will check, if that type is assignable to the variable. That means auto will choose the return type of the function.
If using a specific type here, one should at least have all conversion warnings enabled (and listen to them/fix them).
It will only fail, if there is no implicit cast available.

1 Like

I think for numbers (float/int/double/etc) the use of concrete types is still more clear, even though many people do those as templates where it’s all back to T anyway. But 99% of types in your product code are usually not primitives…

Thanks for the modern C++ (STL) lesson - I didn’t know about templated basic math such as std::sin<double>(). Yes, I need type-conversion warnings and time to pay attention to them :-). I would also like better template support in Xcode! (And/or time to master AppCode)

LOL at this comment. Good luck writing something equivalent to JUCE in Rust. See you in a few years at least…

5 Likes