But you did: you claimed it was significant that they choose not to go
that route, despite knowing such a route was impossible due to other
language decisions. In the case of Java, these decisions were made
before the formatting functions even existed.
I only said that it was significant that languages which came after C++
chose not to use an iostream-like interface design (IOW: using "<<" and
">>" operators for stream IO).
many languages could have done something at least cosmetically similar
if they wanted (whether or not the language had things like user-defined
operator overloading, they could hard-code it, or give it special
syntax, or similar). (IOW: as syntax sugar).
not that it would necessarily be functionally equivalent (or even
necessarily user-extensible), but this is besides the point.
the point here is much more about what it looks like than what it does
or how it works.
Good for you, but it's significant to the language and it has the
final say. As such, I don't really care what significance you give
it. The language clearly impacts the design of the functions, the
formatting string language, and their capabilities. All of which
impact how users perceive and use the functions.
potentially, but they use a string and an argument list just the same.
Except no one does that in C, because doing that in C results in
either a memory-leak or code that isn't thread-safe. This isn't even
the least bit legitimate.
it depends...
one option here is to basically having a "rotating allocator" which
basically just operates as a ring buffer, with any newer allocations
overwriting whatever was there from before.
so long as no one tries to hold onto a pointer into this buffer for any
extended length of time, it all works fairly well (it assumes that code
will be done with the memory before the allocator wraps back around to
this point). (it is not strictly safe, but it tends to work).
another option is to use a garbage collector (has its own pros and cons).
I have seen stuff like this done in practice in several programs.
Yes, it does. It means that I can use the formatting function
generically, with any object, safely. I cannot do that in C. It's not
difficult in C, it is _impossible_ in C.
well, except for something:
the generic cases where this would really matter are themselves
effectively (1) impossible in C, so it is a moot point.
1: there are possible edge cases, such as a printf within a macro with
an unknown type argument, but doing anything like this is not common.
in cases where one implements a mechanism by which to effectively deal
with types which may readily change (such as a dynamic type-system),
they have likely also implemented a means by which to convert them to
strings.
for other non-C languages, they may address this matter in other ways
(since these languages need not inherit C's type-system limitations),
making arguing about it a moot point in these cases.
an example is "{0}" and similar in C#, which themselves figure out the
type. otherwise, a language could stick with a C-like "%..." notation,
but then treat the type-letters more as a formatting hint ("present it
as if it were type"), rather than having them actually specify the type.
likewise, the language could allow a general mechanism (such as a
"toString()" operation of some sort) by which to allow any type to be
used in formatted output.
It means I can pass any object to the formatting function, and I don't
have to remember the stupid formatting code (if I don't need special
behavior), nor do I have to remember to treat certain types
specially.
Why you think this is insignificant is beyond me. I also see no point
in discussing this with you further, because you have some arbitrary
and bizarre idea of the interface for a printf function that you're
unwilling or unable to properly define. Should we include FORTRAN
format strings? What about message translation formatting strings
that include special handling for plural nouns and the like? What
about the limited built-in format in Scheme?
I could go on-and-on, but hopefully my point is clear: there's little
significance in the fact that lots of formatting systems use a string
and then some arguments to interpolate into the string. It's even a
viable, reasonable solution for certain problems even with you have
something like C++ iostreams (like date/time conversion to/from
strings).
well, except FORTRAN came before C++, so would not be included in a list
of languages which came after C++.
likewise for Scheme.
although not exactly the same, both could probably otherwise be included
in this category.
but, anyways, the core definition here is that printing is done in some
form resembling:
someprintf([output,] formatstring, arguments...);
with someprintf either being a function name, or some sort of method call.
output may be seen in function-call varieties, but is normally N/A if
this is part of a method for some sort of output-stream object or
similar (which will itself define the output).
with formatstring consisting of:
characters which will go directly to output;
some means by which to specify arguments and their respective formatting
(width, formatting style, ...), which may also specify types.
and arguments being:
values which will be used in producing the output using the format
string (often, but not always, being used in-sequence).
now, what goes on inside the function, or how one can use the function,
or alternative uses with other stream types, ... are generally outside
the current scope.
granted, this is not the only style of printing interface in common use
("echo" and "BASIC-style print" variations are also floating around, but
I classify them as different styles given that values are given inline).
