On 28/01/2024 02:34, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Seriously, how hard would it be for you to accept the usage of
>> "function" to mean "C function" in this group? How difficult would it
>> be for you to try to speak the same language as the rest of us? Do
>> you really expect everyone else to adapt to suit your personal choice
>> of definitions? How often do you need to go round the same circles
>> again and again, instead of trying to communicate with people in a
>> sane manner?
>
> You don't really think difficulty is the issue, do you?
>

No, it was just a figure of speech.

On 27.01.2024 21:58, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 11:09:56 +0100, Janis Papanagnou wrote:
>
>> What I [think to] know is that simple word permutations don't help for
>> general cases of localization, so printf would just work for some
>> primitive application special cases.
>
> In a project I worked on some years ago, I devised a custom string-
> templating scheme for localization purposes, using keywords to represent
> the variable bits. We got as far as handling Japanese and Chinese, plus a
> few European languages. [...]

Allow me to say; this sounds very impressive to me!

Janis

On 28/01/2024 12:00, David Brown wrote:
> On 28/01/2024 02:59, Malcolm McLean wrote:
>> On 28/01/2024 01:26, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>>>>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>>>>
>>>>>> What I am saying is that standard output can take integers, floats
>>>>>> and
>>>>>> strings.
>>>>> You forgot booleans. Also enumerations can be useful.
>>>>>
>>>> Yes, and we could say fixed point, complex, etc.
>>>> It's not inherently a bad idea to extend our little stdout interface
>>>> to include booleans. But in fact there are too many output formats you
>>>> might need.
>>>> Fixed point - in C or C++ there's no standard for that, so now you are
>>>> going the OO route. As you would with enumerations as the symbol
>>>> doesn't exist at runtime.
>>>> It's not that there is no case to be made for the OO approach. What I
>>>> am saying is that in practice the locked down restricted interface
>>>> will work better.
>>>
>>> I think you mean it will work Malcolm-better.
>>>
>>> Apparently inflexibility and vulnerability to type errors are
>>> Malcolm-better than the alternative.
>>>
>> Exactly.
>> Inflexibility can be better. Because in reality most program work with
>> a restricted set of data types which it makes sense to pass to a text
>> stream, and so you only need three atomic types.
>>
>> Tpye errors are of course a nuisance with printf(). But that's because
>> of the quirks of C, not because it takes a restricted set of types,
>> and you can write a different restricted interface without this problem.
>>
>> The fact is that printf(), which works basically as I recommend, is
>> widely used as the interface to standard output, and often OO
>> alternatives are available and not used for various reasons.
>>
>> So the world is in fact "Malcolm better".
>>
>
> You mean the Malcolm-world is Malcolm-better with these restrictions,
> because in the Malcolm-world the only programming tasks that are done
> are Malcolm-tasks, and the programmers are all Malcolm-programmers.
>
> At least that's all cleared up nicely, and the rest of the world can go
> back to using more than three types, and generating outputs that are not
> just ASCII text.
>
You put non-ASCII text on stdout?
I mean, obviously in a program for international use itself. But in
routine program for general use?

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 27.01.2024 18:24, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
> As someone who as programmed daily in C++ since 1989, usually

I started C++ around the same time, actually since C++'s beginning,
so probably only few years earlier. But today I use C++ only in my
private context since, professionally, I'm not programming any more.

> in performance sensitive code, I've never found the C++ input
> and output operators useful.

I'm sure whether one finds a language (or features of a language)
useful certainly depends on various factors; education, the area
of work, the specific company (including its culture), and own
personality (own experiences, and personal background, where from
one comes).

This is why I think it makes no sense to start a dispute here.
Either you have experienced the advantages, or you haven't, or only
partly.

> The run-time cost both in space
> and time is far more than the *printf formatting functions,
> and they're less flexible when the formatting changes based,
> e.g., on locale.

Runtime costs and memory space considerations had been relevant
in my DSP assembler deep-space-satellite-communication project
(in the late 1980's).

In my C++ projects it was irrelevant whether language feature A
was 10% faster or slower compared to language feature B. There
were other factors that influenced performance; like complexity
of the algorithmic solutions. And there were other requirements
that had precedence anyway; like robust and extensible designs.
Amongst many other things.

So all I can do, if you like - but I don't know whether it helps
you, since your experiences and background certainly differs -,
is to illustrate it with a small project where specifically the
feature of discussion helped to a clear and extensible design,
simply to use and integrate; a flexibility and robust solution.

In C++ I implemented an Application Management Interface - that was
already 30 years ago, before Java provided some library like that -
that made it possible to control any object instance in a software
component by (informally written) "interface.register(item)", and
you could then interrogate or change state of such registered items
asynchronously during runtime by exchanging the de-/linearized data
through some text oriented IPC channel. There was no need to adjust
application logic and no functional dependencies. It was transparent
WRT the type of object (it could be, say, a primitive 'int' counter
or a complex 'Car' object); items of any complexity and type could
be controlled through any stream based communication interface. The
only precondition was that the object class provides operators '<<'
and '>>' for de-/serialization (and these operators were anyway
defined in our contexts, for obvious reasons), and (IIRC) that it
had the property "controllable" (an interface derivation). Thanks
to OO principles and (beside other features) C++'s '<<' operator.

(I don't want to imagine such functionality with printf and all
it's impact to the rest of the program system.)

>
>>
>> Java (as a newer language) has also some advantages, but was in many
>> respects far behind C++ (IMO).
>
> Wow, that's a strong statement. What led you to hold that opinion?

Experience with many programming languages (including Java), and
a pair of open eyes, and an open mind.

>
> Java, as a language, was rather well designed.

(It would have never occurred to me to to make such a statement.)

> The run-time costs,
> however, precluded the use of Java in most of the projects that I've
> worked on since Java was introduced.

This is just one observation. But, yes.

Janis

On 27.01.2024 22:04, Lawrence D'Oliveiro wrote:
> [...]
> In Java, as in Python, all class instances are allocated on the heap.
> Therefore the word “new” becomes superfluous. And so Python gets rid of
> it, reducing class instantiation to what looks like a function call on the
> class name.
>
> Yet Java keeps the requirement to say “new”. Why?

If the "Why?" refers to the word "keeps" then the answer seems
obvious; compatibility, to not break existing code.
If you're asking why "in the first place" they introduced it; I
suppose to differentiate it from simple types, and to indicate
that such objects are subject to the garbage collector (when
getting unused).
Maybe it's useful to know how Simula (first OO language, thus
probably a paragon for other language designs) did it. Here you
had simple types (integer, real, character, etc.), the special
type 'text' (a string class but used also like a primitive one),
and the complex class types. The latter had an own declaration
syntax 'ref(class)name' and own ref-assignments ':-' as opposed
to value-assignments ':=', own comparison operators, and they
are subject to garbage collection. This appears to some degree
to be similar to Java.

But personally I don't mind the 'new' keyword in Java anyway.
Languages shall make it possible to produce readable code; with
Java I can do that (and probably even better than in C), so that
is not what prevents me from choosing Java.

Janis

On 28.01.2024 13:00, David Brown wrote:
> On 28/01/2024 02:59, Malcolm McLean wrote:
>> [...]
>
> You mean the Malcolm-world is Malcolm-better with these restrictions,
> because in the Malcolm-world the only programming tasks that are done
> are Malcolm-tasks, and the programmers are all Malcolm-programmers.

Meanwhile I understand why Malcolm'isms have been introduced here
(as had been explained to me in another post). :-)

Janis

On 28.01.2024 17:09, Malcolm McLean wrote:
> On 28/01/2024 12:00, David Brown wrote:
[...]
> You put non-ASCII text on stdout?

Of course. - Hadn't that already been explained before?

> I mean, obviously in a program for international use itself. But in
> routine program for general use?

The meaning of "general use" is typically to be a sort of general one,
not one that is (artificially) restricted ("ASCII" vs. "non-ASCII").

Janis

On 27.01.2024 21:17, Malcolm McLean wrote:

> Standard output is any sequence of ASCII characters.

Nonsense.

> printf() is the
> main C interface to that, and supports integers, floats and strings, to
> a first approximation.

It's not an approximation; printf() is _restricted_ to these types (and
a few more variants of these few basic types, to be correct).

In an OO context you would not unnecessarily restrict yourself. (Unless
you don't know better.)

> You can of course encode any data format as any other as long as you can
> write enough. But standard output can't take images or audio, for example.

Standard output is an I/O channel; I can send to it non-text data like
the ones you mention. (Just imagine you couldn't send UTF-8 text data.)

> The OO method is to allow the stream to be extended. So, in one common
> system, we might have a "decimal" stream which takes floats and outputs in
> the format 123.456. Then we could derive a different type of stream from
> that which outputs floats as 1.23456e2. [...]

Nonsense. - You seem to have never really learned or understood OO or
what streams in C++ actually are.

Janis

> [...]

On 27.01.2024 17:25, Scott Lurndal wrote:
>
> how is
>
> cout << std::hex << std::setw((bits + 3)/4) << value << std::eol;

You forgot the first "std::" (if you wanted to make it appear complex)

std::cout << std::hex << std::setw((bits + 3)/4) << value << std::endl;

but I prefer for readability anyway the simpler form (implying 'using')

cout << hex << setw((bits + 3)/4) << value << endl;

>
> better than
>
> printf("%*x\n", (bits+3/4), value);

It's an extensible and less error prone framework in C++ as opposed
to a restricted and error prone feature in the C base. (I recently
gave an application example with some typical advantages visible in
another post here.)

But personally I had never been a fan of the stream manipulators;
I always had to look them up in the documentation (when needed).
Luckily they were rarely necessary in my contexts, so it didn't
bother me much. (OTOH, I also have look up the %x.y modifiers in
FP output format, that I also rarely use. So not much difference.)

The question of flexibility of the OO features (compared e.g. to the
restricted C printf() features) had always been of larger relevance.

Janis

On 28/01/2024 17:09, Malcolm McLean wrote:
> On 28/01/2024 12:00, David Brown wrote:
>> On 28/01/2024 02:59, Malcolm McLean wrote:
>>> On 28/01/2024 01:26, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>>>>>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>>>>>
>>>>>>> What I am saying is that standard output can take integers,
>>>>>>> floats and
>>>>>>> strings.
>>>>>> You forgot booleans. Also enumerations can be useful.
>>>>>>
>>>>> Yes, and we could say fixed point, complex, etc.
>>>>> It's not inherently a bad idea to extend our little stdout interface
>>>>> to include booleans. But in fact there are too many output formats you
>>>>> might need.
>>>>> Fixed point - in C or C++ there's no standard for that, so now you are
>>>>> going the OO route. As you would with enumerations as the symbol
>>>>> doesn't exist at runtime.
>>>>> It's not that there is no case to be made for the OO approach. What I
>>>>> am saying is that in practice the locked down restricted interface
>>>>> will work better.
>>>>
>>>> I think you mean it will work Malcolm-better.
>>>>
>>>> Apparently inflexibility and vulnerability to type errors are
>>>> Malcolm-better than the alternative.
>>>>
>>> Exactly.
>>> Inflexibility can be better. Because in reality most program work
>>> with a restricted set of data types which it makes sense to pass to a
>>> text stream, and so you only need three atomic types.
>>>
>>> Tpye errors are of course a nuisance with printf(). But that's
>>> because of the quirks of C, not because it takes a restricted set of
>>> types, and you can write a different restricted interface without
>>> this problem.
>>>
>>> The fact is that printf(), which works basically as I recommend, is
>>> widely used as the interface to standard output, and often OO
>>> alternatives are available and not used for various reasons.
>>>
>>> So the world is in fact "Malcolm better".
>>>
>>
>> You mean the Malcolm-world is Malcolm-better with these restrictions,
>> because in the Malcolm-world the only programming tasks that are done
>> are Malcolm-tasks, and the programmers are all Malcolm-programmers.
>>
>> At least that's all cleared up nicely, and the rest of the world can
>> go back to using more than three types, and generating outputs that
>> are not just ASCII text.
>>
> You put non-ASCII text on stdout?
> I mean, obviously in a program for international use itself. But in
> routine program for general use?
>

I commonly write out in UTF-8 - it does not have to be "international".
(I assume that by "international" you, as a good Brit, mean "not UK".
After all, a program written solely for use in Norwegian is not
international.)

Sometimes I will have binary data of some kind on the standard output.
It's a lot less common, but it happens. A common example would be code
for generating images or other files for a webserver.

Most of my "real" programs, rather than small utilities, are for
embedded systems where the concept of "standard output" is not really
the same as for PC's.

On 27.01.2024 16:43, David Brown wrote:
> On 26/01/2024 22:30, Janis Papanagnou wrote:
>> On 26.01.2024 19:59, David Brown wrote:
>>>
>> A computer scientist or a sophisticated programmer would know that
>> there are run-times associated in such expressions:
>>
>> cout << "S1" << f1() << "S2" << f2() << "S3" << f3();
>>
>> t1 t2 t3 t4 t5 t6 t7 t8 t9
>>
>
> The experienced or knowledgable C++ programmer (prior to C++17) would
> know that the parts here are not necessarily executed in the order you
> give.

And that was not intended in that representation. It was to show
where "time factors" are "hidden". (And if I had the intention I
could also have chosen 'dt1' instead of the inaccurate 't1' to
indicate that.) Sorry if that confuses you. I hoped that together
with the text it would be more informative (than confusing).
If one sees the time demands, and has read about our consensus
about evaluation order above (it was repeatedly stated!) there
should be no misunderstanding (or so I thought at least).

> [...]
>
>> That's why somewhat experienced programmers would not write above
>> code that way; something like "run_tests()" is (typically) or can be
>> very time consuming, so they'd do
>> t0 = get_time(); res = run_tests(); t1 = get_time();
>> cout << ... etc.
>
> Of course.

You can serialize (as I suggested previously as one example) or
embed functions like take_time(run_tests()) as another example.

>
> In practice, they could still be badly wrong even with that code -
> there's a lot of subtle points to consider when trying to time code, and
> my experience is that very few programmers get it entirely right.

Really? - I mostly had to do with folks, even newbies with a
proper CS education, who had enough experience or knowledge.
Most problems appeared in contexts where the used languages
have inherent design issues; not in any case we could avoid
use of such languages in the first place.

Janis

[...]

On 27.01.2024 17:46, David Brown wrote:
> [...]

FYI: Too long to read at the moment. (Maybe later, maybe not.)

Janis

On 28/01/2024 18:24, David Brown wrote:
> On 28/01/2024 17:09, Malcolm McLean wrote:
>> On 28/01/2024 12:00, David Brown wrote:
>>> On 28/01/2024 02:59, Malcolm McLean wrote:
>>>> On 28/01/2024 01:26, Keith Thompson wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>>>>>>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>>>>>>
>>>>>>>> What I am saying is that standard output can take integers,
>>>>>>>> floats and
>>>>>>>> strings.
>>>>>>> You forgot booleans. Also enumerations can be useful.
>>>>>>>
>>>>>> Yes, and we could say fixed point, complex, etc.
>>>>>> It's not inherently a bad idea to extend our little stdout interface
>>>>>> to include booleans. But in fact there are too many output formats
>>>>>> you
>>>>>> might need.
>>>>>> Fixed point - in C or C++ there's no standard for that, so now you
>>>>>> are
>>>>>> going the OO route. As you would with enumerations as the symbol
>>>>>> doesn't exist at runtime.
>>>>>> It's not that there is no case to be made for the OO approach. What I
>>>>>> am saying is that in practice the locked down restricted interface
>>>>>> will work better.
>>>>>
>>>>> I think you mean it will work Malcolm-better.
>>>>>
>>>>> Apparently inflexibility and vulnerability to type errors are
>>>>> Malcolm-better than the alternative.
>>>>>
>>>> Exactly.
>>>> Inflexibility can be better. Because in reality most program work
>>>> with a restricted set of data types which it makes sense to pass to
>>>> a text stream, and so you only need three atomic types.
>>>>
>>>> Tpye errors are of course a nuisance with printf(). But that's
>>>> because of the quirks of C, not because it takes a restricted set of
>>>> types, and you can write a different restricted interface without
>>>> this problem.
>>>>
>>>> The fact is that printf(), which works basically as I recommend, is
>>>> widely used as the interface to standard output, and often OO
>>>> alternatives are available and not used for various reasons.
>>>>
>>>> So the world is in fact "Malcolm better".
>>>>
>>>
>>> You mean the Malcolm-world is Malcolm-better with these restrictions,
>>> because in the Malcolm-world the only programming tasks that are done
>>> are Malcolm-tasks, and the programmers are all Malcolm-programmers.
>>>
>>> At least that's all cleared up nicely, and the rest of the world can
>>> go back to using more than three types, and generating outputs that
>>> are not just ASCII text.
>>>
>> You put non-ASCII text on stdout?
>> I mean, obviously in a program for international use itself. But in
>> routine program for general use?
>>
>
> I commonly write out in UTF-8 - it does not have to be "international".
> (I assume that by "international" you, as a good Brit, mean "not UK".
> After all, a program written solely for use in Norwegian is not
> international.)
>
I'd expect that most general purpose programs written by Norwegians use
an English interface, even if it isn't really expected that the program
will find an audience beyond some users in Norway. Except of course for
programs which in some way are about Norway.
>
> Sometimes I will have binary data of some kind on the standard output.
> It's a lot less common, but it happens.  A common example would be code
> for generating images or other files for a webserver.
>
> Most of my "real" programs, rather than small utilities, are for
> embedded systems where the concept of "standard output" is not really
> the same as for PC's.
>
I've never used standard output for binary data. It might be necessary
for webservers that serve images. But it strikes me as a poor design
decision.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote:

> On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:
>
>> The dirty little secret of pure-functional programming is that I/O
>> cannot be treated in a purely functional fashion.
>
> It can - you just have to have the IO world as an input and an output to
> your function.

You mean, carry around multiple copies of the entire Universe in
individual variables?

On Sun, 28 Jan 2024 12:53:36 +0100, David Brown wrote:

> On 27/01/2024 21:59, Lawrence D'Oliveiro wrote:
>
>> On Sat, 27 Jan 2024 17:26:24 GMT, Scott Lurndal wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>> Standard printf formatting also does not allow such re-arrangements.
>>>>
>>> Depends on what standard you use. POSIX certainly does.
>>
>> C and POSIX go together like a horse and carriage; one without the
>> other is a lot less useful.
>
> To the nearest percent, 0% of all systems running C programs support
> POSIX (or Windows, or any other "big" system). The world of small
> embedded systems totally outweigh "big" systems by many orders of
> magnitude. And perhaps 80% of such small systems are programmed in C.

And a lot of those “embedded” systems are running Android.

Android ships as many units per year as the entire installed base of
Microsoft Windows.

On Sun, 28 Jan 2024 17:42:29 +0100, Janis Papanagnou wrote:

> On 27.01.2024 22:04, Lawrence D'Oliveiro wrote:
>>
>> In Java, as in Python, all class instances are allocated on the heap.
>> Therefore the word “new” becomes superfluous. And so Python gets rid of
>> it, reducing class instantiation to what looks like a function call on
>> the class name.
>>
>> Yet Java keeps the requirement to say “new”. Why?
>
> If the "Why?" refers to the word "keeps" then the answer seems obvious;
> compatibility, to not break existing code.
> If you're asking why "in the first place" they introduced it; I suppose
> to differentiate it from simple types, and to indicate that such objects
> are subject to the garbage collector (when getting unused).

For simple types, you don’t need to use the type name at all, to create an
instance of the type. So there would be no opportunity to use or not use
the type name. Hence the question about “new” is irrelevant in this case.

On Sun, 28 Jan 2024 19:49:19 +0000, Malcolm McLean wrote:

> I've never used standard output for binary data. It might be necessary
> for webservers that serve images. But it strikes me as a poor design
> decision.

Very common in the *nix world. E.g. producing a nicely-typeset view of a
man page:

gunzip -c /usr/share/man/man7/string_copying.7.gz |
groff -kman -Tpdf |
okular - &

That second stage in the pipeline produces PDF output, which the viewer
can display directly, without having to write it to a file.

I mean, how else would you do it?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 28 Jan 2024 12:53:36 +0100, David Brown wrote:
>> On 27/01/2024 21:59, Lawrence D'Oliveiro wrote:
>>> On Sat, 27 Jan 2024 17:26:24 GMT, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> Standard printf formatting also does not allow such re-arrangements.
>>>>>
>>>> Depends on what standard you use. POSIX certainly does.
>>>
>>> C and POSIX go together like a horse and carriage; one without the
>>> other is a lot less useful.
>>
>> To the nearest percent, 0% of all systems running C programs support
>> POSIX (or Windows, or any other "big" system). The world of small
>> embedded systems totally outweigh "big" systems by many orders of
>> magnitude. And perhaps 80% of such small systems are programmed in C.
>
> And a lot of those “embedded” systems are running Android.
>
> Android ships as many units per year as the entire installed base of
> Microsoft Windows.

A lot (for some interpretations of "a lot") of embedded systems run
Android. Those aren't the one David was talking about.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> I'd expect that most general purpose programs written by Norwegians
> use an English interface, even if it isn't really expected that the
> program will find an audience beyond some users in Norway. Except of
> course for programs which in some way are about Norway.

I'm not sure why you'd expect that.

I've worked on large projects at at least three different jobs that
implement various internationalization methods to show the interface in
any of several supported languages, including Norwegian. (These were
products intended for use by non-engineers, either general consumers or
medical professional.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 28/01/2024 17:22, Janis Papanagnou wrote:
> On 27.01.2024 21:17, Malcolm McLean wrote:
>
>> Standard output is any sequence of ASCII characters.
>
> Nonsense.
>
>> printf() is the
>> main C interface to that, and supports integers, floats and strings, to
>> a first approximation.
>
> It's not an approximation; printf() is _restricted_ to these types (and
> a few more variants of these few basic types, to be correct).
>
> In an OO context you would not unnecessarily restrict yourself. (Unless
> you don't know better.)
>
>> You can of course encode any data format as any other as long as you can
>> write enough. But standard output can't take images or audio, for example.
>
> Standard output is an I/O channel; I can send to it non-text data like
> the ones you mention. (Just imagine you couldn't send UTF-8 text data.)
>
>> The OO method is to allow the stream to be extended. So, in one common
>> system, we might have a "decimal" stream which takes floats and outputs in
>> the format 123.456. Then we could derive a different type of stream from
>> that which outputs floats as 1.23456e2. [...]
>
> Nonsense. - You seem to have never really learned or understood OO or
> what streams in C++ actually are.
>
We're talking about the OO approach generally. Not C++.
That is one approach. Our base stream takes floats and produces a stream
of decimals in the format 123.456. We then decide that we don't like
that and write a derived class which uses scientific notation, 1.23456e2.
We can then toggle output between deciml and scientific mode by passing
either a base or a derived stream to an output function.

That one way of implementing OO streams and anyone with even a basic
knowledge of OO should have recognised.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 27.01.2024 21:17, Malcolm McLean wrote:
[...]
>> printf() is the
>> main C interface to that, and supports integers, floats and strings, to
>> a first approximation.
>
> It's not an approximation; printf() is _restricted_ to these types (and
> a few more variants of these few basic types, to be correct).

printf also supports pointer values with "%p". And it support single
characters, which are not strings.

strings of cousre absolutely do not have to be ASCII. Using printf to
print data with embedded null bytes is tricky -- but of course printf is
not the only interface. We can print arbitrary data with putchar,
fwrite, etc.

And in environments like POSIX that don't distinguish between text and
binary output streams, it can be perfectly sensible (though not 100%
portable) to send binary data to stdout.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sun, 28 Jan 2024 14:49:53 -0800, Keith Thompson wrote:

> A lot (for some interpretations of "a lot") of embedded systems run
> Android. Those aren't the one David was talking about.

They have a POSIX-type C runtime. Which does support “%«n»$” for
reordering args to the printf routines.

The point being the prevalence of POSIX is a little larger than you give
it credit for.

On 29/01/2024 00:03, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 14:49:53 -0800, Keith Thompson wrote:
>
>> A lot (for some interpretations of "a lot") of embedded systems run
>> Android. Those aren't the one David was talking about.
>
> They have a POSIX-type C runtime. Which does support “%«n»$” for
> reordering args to the printf routines.
>
> The point being the prevalence of POSIX is a little larger than you give
> it credit for.

As far as I can see, the way it works is to have a separate format
string for each language target. The format string will contain the bulk
of the message, together with any variably-placed argments.

If those arguments are themselves text, they may also need different
versions per target.

This provides only the crudest form of aid, every language will have its
own exceptions.

A further problem is having type info encoded within each format string,
so that now magnifies the problem of maintenance, especially if those
strings reside in external data files. If the format argument is a
variable, that also limits the ability to detect format errors.

I can't see that it's of great benefit. Internationalisation requires
some extra effort anyway beyond what a language provides, especially a
low-level one.

Can you provide one example of how it will help with just two languages
with differing word order?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 28 Jan 2024 14:49:53 -0800, Keith Thompson wrote:
>> A lot (for some interpretations of "a lot") of embedded systems run
>> Android. Those aren't the one David was talking about.
>
> They have a POSIX-type C runtime. Which does support “%«n»$” for
> reordering args to the printf routines.
>
> The point being the prevalence of POSIX is a little larger than you give
> it credit for.

Again, David wasn't talking about Android systems. He wrote:

To the nearest percent, 0% of all systems running C programs support
POSIX (or Windows, or any other "big" system). The world of small
embedded systems totally outweigh "big" systems by many orders of
magnitude. And perhaps 80% of such small systems are programmed in C.

The fact that Android systems are POSIX systems doesn't refute his
point. I don't think he considers them to be *small* embedded systems.

(A not terribly relevant piece of information: Android's C runtime
doesn't support printf's "%n" format, supposedly because it's unsafe
which renders it non-conforming.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sun, 28 Jan 2024 17:48:53 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> The point being the prevalence of POSIX is a little larger than you
>> give it credit for.
>
> Again, David wasn't talking about Android systems.

No, I was, as an example of the sort of POSIX system he thought was too
minuscule to worry about.