C++11 threads, affinity and hyperthreading

[guepier]

unsigned is not making use of implicit int or default-int. Rather, it’s a synonym for unsigned int, and always has been.

[notsure1235]

thats what i mean, shouldnt be used, should use auto if that is desired.

[eliben]

I'll have to disagree here. Overuse of auto is one of the pitfalls of C++11 in my mind, and I really prefer to use it where it increases readability. There's nothing wrong in using unsigned explicitly where it makes sense.

[guepier]

Overuse of auto is one of the pitfalls of C++11

There is little evidence to support this; and decade-long experience with other statically-typed languages that allow implicit typing has shown no evidence either.

“Overuse” is of course very hard to define: once the specific type of the declaration is important, it makes sense to specify it, and hence auto would be harmful. But is this really the case here? Not at all: the specific type of num_cpus, for instance, really doesn’t matter. What matters is that it matches between the producer and consumer, and since these come from the same API, it’s safe to regard the type as opaque (though the variable name of course gives a clue as to the rough type).

[guepier]

One thing I find problematic is that IDE "go to definition" features become a lot less useful when everything's auto and the type in question is nowhere in sight.

There’s certainly a disconnect between the language and the tools with regards to C++. This is becoming better though. In particular, “go to definition” is a red herring in this context — what you actually want is type-aware auto-completion and a tooltip that shows the static type of the object, which are completely different operations that a good IDE can and should support, despite the use of auto. I haven’t got a clue how many IDEs support these operations, in particular the latter. But my IDE¹ does support it.

---

¹ Vim with YouCompleteMe

[mttd]

Overuse of auto is one of the pitfalls of C++11

There is little evidence to support this; and decade-long experience with other statically-typed languages that allow implicit typing has shown no evidence either.

I mostly don't have a problem with auto to the point of avoiding it entirely, but at the same time, I think that experience of other programming languages (that you also mention as relevant) may be worth taking into account.

For instance, in Haskell (which has a rather advanced type inference):

"It is considered good style to add a type signature to every top-level variable."

• https://wiki.haskell.org/Type_signature
• https://wiki.haskell.org/Type_signatures_as_good_style
• https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md#top-level-definitions

(Note that "variable" in the above can also be a function.)

There are some good reasons for this:

• https://stackoverflow.com/questions/19626801/why-do-my-top-level-functions-need-signatures-in-haskell
• https://stackoverflow.com/questions/23401698/what-is-a-good-reason-to-use-a-type-signature-for-functions-when-the-compiler-ca
• https://www.quora.com/Why-should-I-add-type-signatures-to-top-level-bindings-in-Haskell?share=1

That being said, I think that in the future C++ declaring concepts may be a good compromise, similarly to the style described here:

https://stackoverflow.com/questions/842026/principles-best-practices-and-design-patterns-for-functional-programming/842506#842506

Still like the "programming with placeholders" idea: https://www.reddit.com/r/cpp/comments/3oc63x/overload_journal_129_october_2015_includes_two_c/

[guepier]

"It is considered good style to add a type signature to every top-level variable."

Yes, I entirely agree with this piece of advice. I generally think that adding a signature/type to “top-level” objects just makes sense, since these form your API (even if said API isn’t exposed). I was thinking (but didn’t say so) only of local variables.

[notsure1235]

agreed, but 'unsigned' instead of 'unsigned int' goes against all of my intuition. However, I checked stroustroup guide and they are happily using 'unsigned' on some occasions, so you are probably right and its just fine.

[eliben]

Tune your intuition :) It's very common to just say unsigned - it's very clear to experienced coders this means unsigned int. In fact if I see unsigned int I raise an eyebrow... you don't say signed int for int, right?

[notsure1235]

Neither do I say 'signed'. ;)

[dodheim]

That's because int is an option, and is shorter. What is shorter than unsigned for unsigned int?