int's mixing with __int64's in argument list not working?

[Evert]

That doesn't apply to the variable-arguments part of the arguments list. IIRC, bool, char and similar things smaller than an int get converted to an int, and floats get converted to double. Other than that its kind of up to the compiler. If your int type is 32-bits and you pass a 64-bit type like long long, its likely to be stored differently than if you pass an int. Both the function passing the argument and the function interpreting it through va_arg or whatever (i.e. sprintf), have to use the same type or at least use types with the same representation on this platform+compiler combo.

It's worth noting here that GCC at least can issue warning for mis-matches between the format string and the actual arguments. It's generally a good idea to treat those as errors.
One potential gotcha: the printf format options refer to the traditional C integer types (int, long int, long long int), which don't necessarilly map onto int32_t, int64_t in a way that is predictable and portable across different architectures, compilers and platforms.

It's a matter of taste. Personally I avoid the C++ stream IO stuff like the plague, finding printf/sprintf a lot easier to work with.

++

[sje]

The old C variable argument list is one of the oldest and biggest kludges in that language and probably everyone who has used it has had at least one related bug. In those cases where a variable number of arguments are needed, the solution is to use one of the standard list templates and so pass a list of values instead of risking bugs and dependency issues due to a lack of strong typing.

Nearly three decades ago, I used to teach C to assembly language programmers. Many had problems with printf() and all of them had problems with scanf().

As far as personal taste is concerned, I have no taste for antiquated language constructs that lead to bugs.