C++17

[Geoff Waddington]

Just about to start coding the Control Surface Integrator, anyone know of a reason(s) why I should use/not use C++17 compilers for the project ?

[Xenakios]

Reasons why you might not want to use it (or even C++11 compatible compilers) :

1) If you need to support ancient macOS-X versions. macOS-X 10.7 is the first one to have support for C++11. (More precisely, support for the C++11 standard library.) Newer C++ standards might require even later macOS versions.
2) If you need to support Windows XP. I have never got the so called "Windows XP compatibility" working with the newer Visual Studio versions. (Like VS2015 or VS2017.) The resulting binaries simply have not worked on XP for me or for people who have tried to test the binaries. It might work if the end user Windows XP installation is completely up to date with SP3 and all possible updates. I never bothered testing that scenario myself.
3) The Microsoft C++ compiler and standard library and Apple's compiler/library are not at the same level of standard compliance. If you write code that compiles for macOs, it might not work with the Microsoft compiler and vice versa. So you need to be careful which language and standard library features you use. Both platforms have good, but not complete, C++11/14 coverage now, though.

[Geoff Waddington]

As usual, good points, thanks Xen.

[Garrick]

Do any of you guys use "auto" for your types?

It feels wrong to me somehow

[Geoff Waddington]

Originally Posted by Garrick

Do any of you guys use "auto" for your types?

It feels wrong to me somehow

I grew up on a curious mix, assembly, C, and Smalltalk.

So, hell yeah, I'll be using auto wherever I can

[Garrick]

Originally Posted by Geoff Waddington

I grew up on a curious mix, assembly, C, and Smalltalk.

So, hell yeah, I'll be using auto wherever I can

Assembly infers type? Is there no end to this madness.
Well that shows how much I know. I thought assembly would be super dupa strict and make you be explicit about everything.

[Xenakios]

Originally Posted by Garrick

Do any of you guys use "auto" for your types?

It feels wrong to me somehow

It's highly debatable if "auto" is that useful for trivial stuff like integer or floating point types, but it's clearly useful when more complicated types are involved. For example, do you want to write

std::unique_ptr<MyFancyObject<String>> o = std::make_unique<MyFancyObject<String>>("foo");

or would you prefer

auto o = std::make_unique<MyFancyObject<String>>("foo");

?

And yeah, I do use "auto" regularly.

[Garrick]

Originally Posted by Xenakios

It's highly debatable if "auto" is that useful for trivial stuff like integer or floating point types, but it's clearly useful when more complicated types are involved. For example, do you want to write

std::unique_ptr<MyFancyObject<String>> o = std::make_unique<MyFancyObject<String>>("foo");

or would you prefer

auto o = std::make_unique<MyFancyObject<String>>("foo");

?

And yeah, I do use "auto" regularly.

Whoa !!
Yeah I can see now how auto could be a godsend.

Especially in your example where your fancy object's name will pretty much document itself and so easier to reason about.

This is good, it's making me re-think the whole thing.

Like you say, it has limited usefulness with primitives, but if you did, how do you cast from one type to another if you're not explicit what type it originally was?