On 27.01.2024 02:43, James Kuyper wrote:
> [...]

Thanks for your posts, explanations and background information.

Yes, I know little about the persons and their posting history.
I'm trying to stay on the topical level as long as possible - it
not always works as I intend, though, when it gets pathological -
just because as soon as it gets personal the threads are usually
tainted and not fruitful. - I observe the nerves of posters here
are often stressed.

Janis

On 27.01.2024 04:05, Malcolm McLean wrote:
> [...] Personally I wanted just
> "function" and for it to be clear from context that here the term did
> not mean "subroutine".

In my book; there's the "concept function" (mathematical), and the
mapping/implementation onto/in a computer (a "calculation routine").
The latter has just different names in different languages and it
naturally has different technical details. In any form its purpose
is to be an implemented instance of a formal mathematical concept.

Janis

On 27.01.2024 04:24, Malcolm McLean wrote:
>>
> It's hard to think of anything that can be passed to standard outut
> other than integers, floating point values, and strings. So you only
> need three atomic operations.
> You can then buld complex objects consisting of integers, floats and
> strings on top of those three basic operations. But the stream itself
> should be locked down and not open to derivation.

I'm not sure where you're coming from here, what you mean by "locked
down", and why it would be a goal to reach. I used various ostreams
(output, strings, etc.) to an advantage in designing flexible usable
algorithms without duplicating code or anything. (I don't know where
your view comes from, but maybe it helps to take an existing library
based on OO design, maybe even STL (which has functional concepts as
well) and inspect what can be done with stream (or other) hierarchies
of types. - But maybe its just as I've written upthread; if you have
not experienced that yourself it's probably hard to understand where
and what the advantages are.)

Janis

On 27/01/2024 10:34, Janis Papanagnou wrote:
> On 27.01.2024 04:05, Malcolm McLean wrote:
>> [...] Personally I wanted just
>> "function" and for it to be clear from context that here the term did
>> not mean "subroutine".
>
> In my book; there's the "concept function" (mathematical), and the
> mapping/implementation onto/in a computer (a "calculation routine").
> The latter has just different names in different languages and it
> naturally has different technical details. In any form its purpose
> is to be an implemented instance of a formal mathematical concept.
>
> Janis
>

I don't really see how "Bleep" is any sort of mathematical function. But
it is clearly a "subroutine".

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

On 27/01/2024 10:43, Janis Papanagnou wrote:
> On 27.01.2024 04:24, Malcolm McLean wrote:
>>>
>> It's hard to think of anything that can be passed to standard outut
>> other than integers, floating point values, and strings. So you only
>> need three atomic operations.
>> You can then buld complex objects consisting of integers, floats and
>> strings on top of those three basic operations. But the stream itself
>> should be locked down and not open to derivation.
>
> I'm not sure where you're coming from here, what you mean by "locked
> down", and why it would be a goal to reach. I used various ostreams
> (output, strings, etc.) to an advantage in designing flexible usable
> algorithms without duplicating code or anything. (I don't know where
> your view comes from, but maybe it helps to take an existing library
> based on OO design, maybe even STL (which has functional concepts as
> well) and inspect what can be done with stream (or other) hierarchies
> of types. - But maybe its just as I've written upthread; if you have
> not experienced that yourself it's probably hard to understand where
> and what the advantages are.)
>
> Janis
>
What I am saying is that standard output can take integers, floats and
strings.
So the stream should have some facilites for writing integers (leading
zeros, signs, maybe commas separators for thousands), some for floats
(rounding, precision, scientific notation etc), some for strings (not
much you can do here other than just pass the raw characters).

Now when we've got those facilites and we are happy with them, that's
it. We don't allow further derivation of the stream to change the basic
behaviour. Now people might say "booleans, you've forgotten booleans,
surely when you pass booleans it should print "true" or "false". No.
We'll handle that at a higher level and pass "true" and "false" as strings.

The disadvantage is that you are locked into an integer/float/string
paradigm. Amd it's not OO. But the advantage is that it will be stable.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 27.01.2024 12:02, Malcolm McLean wrote:
> On 27/01/2024 10:34, Janis Papanagnou wrote:
>> On 27.01.2024 04:05, Malcolm McLean wrote:
>>> [...] Personally I wanted just
>>> "function" and for it to be clear from context that here the term did
>>> not mean "subroutine".
>>
>> In my book; there's the "concept function" (mathematical), and the
>> mapping/implementation onto/in a computer (a "calculation routine").
>> The latter has just different names in different languages and it
>> naturally has different technical details. In any form its purpose
>> is to be an implemented instance of a formal mathematical concept.
>>
>> Janis
>>
>
> I don't really see how "Bleep" is any sort of mathematical function. But
> it is clearly a "subroutine".

I don't know what that 'Bleep' is that you mention here, but I suppose
that is meant to be some function that is not returning a value but an
acoustic _side effect_. In an Algol representation something like the
function

bleep = (void) void: invoke_tone

Or in Simula or Pascal the return-typeless function (= 'procedure')

procedure bleep

Or in C the function

bleep() { invoke_tone; }

In FORTRAN and BASIC (don't remember) that function was maybe called
"subroutine"?

Nomenclature changes wording but not its underlying character. Use the
terms and models that fit best your goals. Meta-goals may be to clarify
or to muddy the issue or its details.

The term "subroutine" (for me) comprises two aspects; a hierarchical
relation, and a [computation] process character.

I'm unsure whether you wanted to express that functions with return
type void are different from functions that return non-void types and
should thus not be called functions? Other's may say that "subroutine"
is badly chosen since there's not necessarily a hierarchical semantic
when using "procedures" in context of Simula's classes with coroutines.
Or are you saying that any "non-pure" function generally relies on
side-effects and should be considered and named differently? - I'm fine
with it. As long as it's clear what goals we follow, and whether the
nomenclature is appropriate for that specific goal (and not conflicts
with other goals).

Janis

On 27.01.2024 12:13, Malcolm McLean wrote:
>>
> What I am saying is that standard output can take integers, floats and
> strings.

Oh!? That doesn't match with any output model I have in mind. (It only
matches if I'm coming from the printf() functionality as basis of all.)

Standard output can take, technically, anything. We're passing binary
and "text" across the standard channels (and may leave open whether an
UTF-8 encoded text is to be considered "binary" in some context).

On one abstraction level you can say I want to consider only non-binary
readable output, but then it's all text (int and float and bool are just
output with one of their textual standard representations).

> So the stream should have some facilites for writing integers (leading
> zeros, signs, maybe commas separators for thousands), some for floats
> (rounding, precision, scientific notation etc), some for strings (not
> much you can do here other than just pass the raw characters).

From an OO perspective we may also say the type Integer, the type Float,
etc. shall provide means to create a textual standard representation,
with options to control the form of the standard representation. Is the
form of the standard representation a property of the data type or of a
[not really] "generic" procedure that has hard-coded support for just
a hand full of predefined primitive types?

>
> Now when we've got those facilites and we are happy with them, that's
> it. We don't allow further derivation of the stream to change the basic
> behaviour. Now people might say "booleans, you've forgotten booleans,
> surely when you pass booleans it should print "true" or "false". No.
> We'll handle that at a higher level and pass "true" and "false" as strings.
>
> The disadvantage is that you are locked into an integer/float/string
> paradigm. Amd it's not OO. But the advantage is that it will be stable.

The OO methods are also stable, but they are also flexible. The concept
makes it possible to extend it to any data type. (I've done that many
times. And thinking about how that would have looked like with non-OO
and only printf() methods is a horror. But, as said; it's probably
necessary to experience that self if it's not understandable from the
explanations alone.)

Janis

On 26/01/2024 22:22, Lawrence D'Oliveiro wrote:
> On Fri, 26 Jan 2024 15:59:11 +0100, David Brown wrote:
>
>> On 25/01/2024 21:18, Lawrence D'Oliveiro wrote:
>>
>>> The compose key on *nix systems gives you a fairly mnemonic way of
>>> typing many of them.
>>>
>> It lets you type some, but it is still limited in the default setup.
>
> The default keys come from /usr/share/X11/locale/en_US.UTF-8/Compose,
> which on my system contains something like 5000 entries.

But most of these cannot be typed (by most people), because the
combinations include things like dead keys that they don't have, or
letters or keys that are from other keyboard layouts. And many of the
lines are duplicates, allowing you to use any order of the keys. For
keyboard layouts without dead keys, such as standard UK and US layouts,
there's maybe a hundred symbols they can use from that file. Those of
us with dead keys or other layouts (excluding things like Chinese with
very different input methods) get perhaps three or four hundred. Almost
all of these are letters with diacriticals. The whole point of this
file is to have one file that handles many languages - Russian typists
will see a different set of 3-400 symbols than Greek typists, but it is
all conveniently in one file. It is /not/ a set of symbols that someone
with a en_US.UTF-8 locale can access.

Out of all this, there are maybe 20-30 symbols.

Now, I agree that the compose key is a great idea, and a useful way to
get these symbols. Compose ":" "-" gives you ÷, which is ÷ great for
people who don't have an AltGr key letting them press AltGr "/" to get
it. And it lets people who have an English language layout type café,
ça, naïve, etc., making occasional use of diacriticals. But many of
these are already available (certainly on *nix, and sometimes even on
Windows) with an international keyboard layout with AltGr and a few dead
keys.

>
>> It's very useful for things like diacriticals on letters that you
>> already have, but if you want to use it for something out of the
>> ordinary, you need to make your own .XCompose file.
>
> Works fine for things like curly quotes “‘’”, em-dashes—, arithmetic
> operators ×÷, some subscripts and superscripts ₉₂U²³⁹, arrows ←↑→↓.

I can type all of these, except the subscripts, without the compose key.

I do sometimes have use of the compose key. But of the symbols or
letters that I want to type and which are not available on my normal
keys (including AltGr and dead key combinations), at most a quarter are
available in the standard compose key setup. If I expect to need the
symbol again, I'll often put it into my .XCompose file. As I say, the
compose key is good, but not /that/ useful in its default setup.

>
> I have a small number of entries in my .XCompose, because I don’t want to
> have to remember too many customizations.
>
> For less-commonly-used things, I go to an Emacs editor window and use its
> ability to enter characters by their Unicode names, then copy and paste
> from there.

I use a character map applet. But regardless, it is not convenient for
most people to use such extra symbols in normal coding.

>
>>>> And it's easy to have different symbols that appear quite similar as
>>>> glyphs, but are very different characters as far as the compiler is
>>>> concerned.
>>>
>>> You can actually take advantage of that. E.g. from some of my Python
>>> code:
>>>
>>> for cłass in (Window, Pixmap, Cursor, GContext, Region) :
>>> delattr(cłass, "__del__")
>>> #end for
>>>
>>> The human reader might not actually notice (or care) that a particular
>>> identifier looks like a reserved word, since the meaning is obvious
>>> from context. The compiler cannot deduce the meaning from that context,
>>> but then, it doesn’t need to.
>>
>> I am not at all keen on that. I am not against using non-ASCII letters
>> as though they were special symbols for particular purposes, but I'd
>> want them to stand out clearly.
>
> The whole point about this example is that they do not need to “stand out
> clearly”.

Yes, I know that was your point. And /my/ point was that I think that's
an absolutely terrible idea. But that is merely my subjective opinion.

On 26/01/2024 22:30, Janis Papanagnou wrote:
> On 26.01.2024 19:59, David Brown wrote:
>>
>> I said - repeatedly - that the order of evaluation of the operands to
>> most operators is unspecified in C and C++. [...]
>
> Yes, and this was undisputed.
>
>>
>> A typical example would be :
>>
>> cout << "Start time: " << get_time() << "\n"
>> << "Running tests... " << run_tests() << "\n"
>> << "End time: " << get_time();
>>
>> It was realistic - and indeed happened in some cases - for pre-C++17
>> compilers to generate the second "get_time()" call before "run_tests()",
>> and finally do the first "get_time()" call.
>
> Yes, we have no differences.
>
> And the sample is fine to show how we should NOT implement such time
> measurements (or similar logic)!
>

There are, of course, many reasons why this is not a good way to
implement time measurements - the order of evaluation is not the only one.

> 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. (It's not clear to me if these are the run times for different
parts, or time-stamps.) Indeed, depending on the kinds of
subexpressions you have, not only can the order of evaluation be changed
for most operators, but their evaluation can be interleaved. (I could
go through the details, but it is probably better to look them up on a
reference site such as en.cppreference.com.)

> and he would act accordingly and serialize the expression (see below).
>

If the programmer wants them to be executed in a particular order,
he/she must use constructs in the language to force that.

>> Alternatively, the compiler
>> could call "get_time()" twice, with "run_tests()" called either before
>> or after that pair. In all these cases, the user will see an output
>> that was not at all what they intended, with time appearing to go
>> backwards or the test apparently taking no time.
>>
>> This was the case regardless of whether or not "get_time()" and
>> "run_tests()" had any side-effects.
>
> We disagree here; it may not appear so to you but get_time() actually
> has a "side effect" (I put it in quotes, because it's literally no
> "effect" but for the argument of its _sequencing problem_ it's a
> relevant externality). It obtains (probably from a hardware device)
> the time when the call happened.

We don't disagree - I haven't said what "get_time()" does or how it
works, or what concept of "time" it has. I agree that getting some
real-world time from a hardware device would be a side-effect - as would
most practical ways to get a useful idea of "time". I was making a
general point - the operands to the << operator could be (pre-C++17)
evaluated in any order regardless of whether or not they had side-effects.

>
> 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.

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.

> (Note: This argument implies NOT that a language shouldn't be made as
> bulletproof as possible and sensible.)
>

A language should be convenient to use and avoid surprising the
programmer. But it should /not/ be a surprise to C or C++ programmers
that the order of evaluation of subexpressions is usually unspecified.

>>
>> You are, quite obviously, guaranteed that in "cout << a << b << c", the
>> output was in order a, b, c. But that is a totally different matter
>> from the order of evaluation (and execution, for function calls) of the
>> subexpressions a, b, and c.
>
> (It was meant as a "meta expression". I've addressed that in my
> response to Keith already; please see there.)
>
>>
>> I have said exactly what I intended to say in this thread, but I suspect
>> you have mistaken what the term "order of evaluation" means, and
>> therefore misunderstood what I wrote. I hope this is all clear to you now.
>
> The order of evaluation of the '<<' was what I spoke about. The order
> of the arguments had never been an issue. The "problem" with the order
> of the arguments becomes a problem (without quotes) when side effects
> of the arguments are inherent to the arguments.
>
> You had been focused on the evaluation of the arguments (where side
> effects might lead to unexpected behavior). I wasn't.
>

I'm afraid I can't quite follow you here. I can just hope that you
understand that evaluation order is unspecified for most operators, that
real compilers evaluate subexpressions in different orders in real code
(so the re-ordering is not hypothetical), and that C++17 added special
rules for << and >> to make things more convenient for programmers. If
I have helped you see this, or if Keith's post helped you see it, then
that's great.

On 27/01/2024 02:10, James Kuyper wrote:
> On 1/26/24 12:31, Janis Papanagnou wrote:

>> All side effects can be a problem (and should be avoided
>> unless "necessary").
>
> Virtually everything useful that a computer program does qualifies as a
> side effect. Side effects cannot be avoided, they can only be controlled.
>

Try telling that to Haskell programmers :-)

On 27/01/2024 01:38, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:
>
>> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>>
>>>> Also the stream hierarchy offers design and implementation paths that
>>>> you just don't have with printf().
>>>
>>> And that you don’t need, frankly.
>>
>> Don't be so fast with your judgment. Of course we use it to elegantly
>> and scaleably solve tasks in C++.
>
> But not localization, which is an important issue. printf-style formatting
> allows rearrangement of parts of a message to suit grammar purposes, C++-
> style output operators do not.
>

Standard printf formatting also does not allow such re-arrangements.

C++ has added "std::format" as a way of getting more flexible
formatting, including re-arrangements of parts, with type safety and
user extension support like iostreams. (I haven't used it myself, and a
deeper discussion would be better down the hall in c.l.c++.)

Generally, I think the different formatting systems have their
advantages and disadvantages. I've yet to see a system in any language
that could cover all needs.

(My own key dislike about the C++ output streams is the mess of stateful
"IO manipulators".)

On 27/01/2024 00:15, Malcolm McLean wrote:
> On 26/01/2024 19:18, David Brown wrote:

>> I think we're fine sticking to "function" meaning "C function", which
>> is well defined by the C standards, and using "mathematical function"
>> for mathematical functions, which are also quite solidly defined.  Any
>> other usage will need to be explained at the time.
>>
> Basically I wanted "function" for C functions which are also
> mathematical functions, and "procedure" for C functions which do not
> meet the definition of mathematical functions. In context, of course.

So basically, you want to use your own terms that are different from
everyone else's.

> And since this is normal, accepted usage, I though It would be accepted
> here.

No, it is not "normal, accepted usage" anywhere but when you are talking
to yourself. As I have pointed out in other posts, "function" can mean
a vast number of different things.

And it is not "normal, accepted usage" to join a discussion group with
clear and established terminology, and attempt to use your own very
different terminology. That is true even if the terminology and
definitions you want to use are well established elsewhere - which in
this case, they are not.

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?

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 27.01.2024 00:51, Lawrence D'Oliveiro wrote:
>> On Fri, 26 Jan 2024 15:41:43 -0800, Keith Thompson wrote:
>>> C++'s `cout << ...` has advantages and disadvantages.
>>
>> Interesting about Java, with all its needless complexity and futile
>> attempts at simplification, that this was one decision it made correctly,
>> and that was not to copy those operators.
>
>Chosing these operators is a separate issue.

I've always found them ugly an inefficient myself, leaving aside
the ability to override the operator for "type safety", something
that I've not found to be a compelling advantage.

how is

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

better than

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

Especially when the format string includes multiple values represented
in different bases and they may need to be reordered at runtime based
on e.g. the current locale?

On 27/01/2024 01:12, Janis Papanagnou wrote:
> On 26.01.2024 20:18, David Brown wrote:
>> On 26/01/2024 18:59, Janis Papanagnou wrote:
>>> On 26.01.2024 17:06, David Brown wrote:
>>>> On 26/01/2024 13:17, Malcolm McLean wrote:
>>>>

>
> (I don't like the habit of introducing personalized terms like
> "Malcolm functions"; this habit exposes more of the person who
> introduced it than anything else. And it anyway would only muddy
> the issue not clarify.)
>

I agree. But I'd rather he talked about "Malcolm functions" than just
wrote "functions" while meaning something completely different from what
everyone else here means by the word.

>
> (I fear this thread will lead nowhere, but okay, I'll enter...)
>

I'm trying to snip and skip stuff to reduce the size of the post here.

>> A "C function" is different from a "Pascal function", a
>> "lambda calculus function", a "Turing machine function", or any other
>> kind of function definition you want to pick.
>
> What relevance has any technical difference of "C functions"
> and "Pascal functions"? - None.

In Pascal, a "subroutine" (if we may use that as a generic term for now,
even though that too can have many different meanings) that returns a
value is a "function". If it does not return a value, it is a
"procedure". Either may or may not have side-effects. Both are called
"functions" in C.

Thus there is a difference between "C functions" and "Pascal functions".
In comp.lang.pascal, the unqualified term "function" would mean
something different from what it means in comp.lang.c.

The relevance to the discussion is that there are a vast number of
meanings of the term "function", even within the realm of computer
programming.

>
> Note: I don't want you to answer these questions. I suppose
> you might have some substantial CS background (I certainly do)
> and are not just spreading buzzwords.

My university education was in mathematics and computation, so I do have
a theoretical background. Since that time, decades ago, my work has
been practical rather than theoretical.

> Neither the technical (implementation) differences of the first
> two types are relevant for the topics that have been discussed,
> nor the algorithm theory definitions of the latter two function
> types are relevant here.

I agree that there are few practical differences between Pascal
functions/procedures and C functions. But this is not a discussion
about practical implementations of compiled imperative programming
languages - it is a discussion about terms, and why it is important to
agree on the meaning of the terms. The term "function" means different
things in Pascal and C.

>
>>
>>>
>>> From my references it seems a consensus at least in that it's
>>> reflecting a mathematical f: (x,y,...) -> (u,v,...) which is
>>> projected at (or implemented by) some routine/procedure/method/
>>> function, etc. - however it's called in any programming language.
>>
>> No, that is only one kind of function.
>
> That is an abstract representation from mathematics (and I am
> not interest in syntactic differences to other forms) that can
> be directly mapped to an algorithmic representation.

It is more general in mathematics to consider it to map one set to
another, but we sometimes use multiple parameters for convenience of
notation. (It's rare to view the codomain as multiple parts.)

>
> We write (for example [borrowed from a book]):
>
> f: R x R x R -> R for the domains; R here: real numbers
>
> f(r,R,h) -> pi/3 x h x (r^2 + r x R + R^2)
>
> and in computer languages (for example) syntactic variants of:
>
> f = (real r, real R, real h) real :
> pi/3 * h * (r^2 + r * R + R^2)
>
> The function from the language closely resembles that from the
> mathematic domain.

It resembles it in this case - though in important aspects they are very
different. However, many real-world C functions don't match closely
with a neat mathematical function (mathematical functions don't have
side-effects), and many real-world mathematical functions don't match
practical C functions. Picking one example where a reasonable match can
be made does not mean the two kinds of "function" are similar.

>
>
>> There are all sorts of questions to ask.
>
> Yes, but not many (none?) of significance in our discussion context
> here.
>

All show that the term "function" can mean a huge number of different
things. There is no single "computer science" definition or "accepted
common definition" - it's not even a close call.

And so if we are going to use that word at all, we have to agree what it
means. Since this is comp.lang.c, and since "functions" are central to
C, we use the term "function" to mean "C function" unless otherwise
/clearly/ stated.

>>>
>>> How should we get principle insights on 'sizeof', what it is,
>>> what it should be, etc., if we stay within this restricted C
>>> world terminology, and discussing even a very special type of
>>> a, umm.., function (sort of).
>>>
>>
>> Sizeof is not a C function.
>
> I know it's an operator in C. And I also wasn't saying that it's a
> C function. - You still see the "(sort of)" in my statement. And we
> already spoke about the close (but not exact) equivalences between
> functions and operators.
>

We certainly won't learn anything about "sizeof" by calling it a
"function" or a "mathematical function".

>> It is a C operator. If you don't know what
>> it is or how it works, or want the technical details, it's all in
>> 6.5.3.4 of the C standards.
>
> If that's all the OP wanted to discuss it would be easy. You don't
> even need any C standard document. Open any book, even the old K&R
> is sufficient, and look up 'sizeof'. You can read about it being an
> operator and fine. File closed. Goodbye. (What for was the original
> question of this thread? I seem to recall something about the form
> with parenthesis and type?)

I have long since forgotten what the question was - we have certainly
wandered far from the start of the thread!

>
>>
>> Trying to describe "sizeof" as a function of some sort with a different
>> kind of use of the word "function" really doesn't get us anywhere, as
>> shown in this thread. It is what it is - trying to mush it into another
>> term is not helpful.
>
> What would be the difference if the parenthesized form would be
> called a function, given that functions and operators are similar,
> and the context so restricted?

The difference is, it would not be a C function. "sizeof" operates at
compile time, and it operates on types - either an explicit type, or the
type of the expression. It has no run-time behaviour (excluding the
somewhat poorly described VLA behaviour). It does not evaluate its
operand. It has no prototype or declaration. It cannot be implemented
by the user in a free-standing implementation. You cannot take its
address. It has no linkage. You cannot use its name as an identifier.

> I don't think you can get an address
> of it (or can we?); but that again is just another implementation
> details (C specific).
>
> The need for parenthesis in sizeof(type) seems anyway to be only a
> hack, necessary for type expressions with blanks, sizeof(struct x) ?
>
> Janis
>
> BTW: There was another subthread about preprocessor use for NELEM
> determination using sizeof. When I looked up the K&R reference I
> saw its use described even as a standard pattern to determine the
> number of array elements. No wonder it became idiomatic.
>

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>
>>> Also the stream hierarchy offers
>>> design and implementation paths that you just don't have with printf().
>>
>> And that you don’t need, frankly.
>
>Don't be so fast with your judgment. Of course we use it to elegantly
>and scaleably solve tasks in C++.
>
>> Java manages just fine with printf-style formatting and “toString()” methods.
>
>I tried to explain in my other post that it's not just about a format
>(or a string-sequencing member function). But I'm sure one must be
>deeper in the topic or have experienced (besides any supposed issues)
>the sophisticated possibilities that C++ offers to support good design.

As someone who as programmed daily in C++ since 1989, usually
in performance sensitive code, I've never found the C++ input
and output operators useful. 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.

>
>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?

Java, as a language, was rather well designed. The run-time costs,
however, precluded the use of Java in most of the projects that I've
worked on since Java was introduced.

David Brown <david.brown@hesbynett.no> writes:
>On 27/01/2024 01:38, Lawrence D'Oliveiro wrote:
>> On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:
>>
>>> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>>>
>>>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>>>
>>>>> Also the stream hierarchy offers design and implementation paths that
>>>>> you just don't have with printf().
>>>>
>>>> And that you don’t need, frankly.
>>>
>>> Don't be so fast with your judgment. Of course we use it to elegantly
>>> and scaleably solve tasks in C++.
>>
>> But not localization, which is an important issue. printf-style formatting
>> allows rearrangement of parts of a message to suit grammar purposes, C++-
>> style output operators do not.
>>
>
>Standard printf formatting also does not allow such re-arrangements.
>

Depends on what standard you use. POSIX certainly does.

>
>(My own key dislike about the C++ output streams is the mess of stateful
>"IO manipulators".)
>

Hear! Hear!

The run-time cost of all those stateful manipulators isn't free, either.

On 27/01/2024 18:26, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 27/01/2024 01:38, Lawrence D'Oliveiro wrote:
>>> On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:
>>>
>>>> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>>>>
>>>>>> Also the stream hierarchy offers design and implementation paths that
>>>>>> you just don't have with printf().
>>>>>
>>>>> And that you don’t need, frankly.
>>>>
>>>> Don't be so fast with your judgment. Of course we use it to elegantly
>>>> and scaleably solve tasks in C++.
>>>
>>> But not localization, which is an important issue. printf-style formatting
>>> allows rearrangement of parts of a message to suit grammar purposes, C++-
>>> style output operators do not.
>>>
>>
>> Standard printf formatting also does not allow such re-arrangements.
>>
>
> Depends on what standard you use. POSIX certainly does.

Sure. But not all of the world is POSIX. (Okay, a lot of it is, and
it's fine to rely on POSIX features if you know that's appropriate.)

>
>
>>
>> (My own key dislike about the C++ output streams is the mess of stateful
>> "IO manipulators".)
>>
>
> Hear! Hear!
>
> The run-time cost of all those stateful manipulators isn't free, either.

For my own use, I've sometimes used classes letting you do :

debug_log << "X = " << x << " = 0x" << hex(x, 8) << "\n";

"hex(x, 8)" returns a value of a class holding "x" and the number of
digits 8, and then there is an overload for the << operator on this
class. No extra state needs to be stored in the logging class, I can
make as many of these formatters as I like, and the intermediary classes
all disappear in the optimisation.

It just seems so much cleaner and more efficient than the way C++
streams are done.

(It doesn't allow re-arranging the parts in the format, nor does it
solve the "1 thingy / 2 thingies" issue, but it's good enough for my needs.)

David Brown <david.brown@hesbynett.no> writes:
>On 27/01/2024 18:26, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>>>
>>> (My own key dislike about the C++ output streams is the mess of stateful
>>> "IO manipulators".)
>>>
>>
>> Hear! Hear!
>>
>> The run-time cost of all those stateful manipulators isn't free, either.
>
>For my own use, I've sometimes used classes letting you do :
>
> debug_log << "X = " << x << " = 0x" << hex(x, 8) << "\n";
>

example:
void
c_processor::dump_rle(c_logger *lp, ulong task)
{ mem_addr_t rle = c_system::self()->get_rlist_base()
+ (task * RLIST_ENTRY_SIZE);

lp->log("Reinstate List Entry at %9.9llu\n", rle);
lp->log("Task #%4.4llu ET %9.9llu #ET: %5.5llu"
" Prio: %2.2llu Op Claim: %4.4llu\n",
getdigits(rle+RLIST_TASKNUM, RLIST_TASKNUM_LEN),
getdigits(rle+RLIST_ENV_TBL_ADDR, RLIST_ENV_TBL_ADDR_LEN),
getdigits(rle+RLIST_NUM_MAT, RLIST_NUM_MAT_LEN),
getdigits(rle+RLIST_TASKPRIO, RLIST_TASKPRIO_LEN),
getdigits(rle+RLIST_OPCLAIM, RLIST_OPCLAIM_LEN));
lp->log("MCP Lock# %4.4llu USER Lock# %4.4llu "
"Task Owning %4.4llu Next Task %4.4llu\n",
getdigits(rle+RLIST_MCPLOCKNUM, RLIST_MCPLOCKNUM_LEN),
getdigits(rle+RLIST_USERLOCKNUM, RLIST_USERLOCKNUM_LEN),
getdigits(rle+RLIST_TASKNUMOWN, RLIST_TASKNUMOWN_LEN),
getdigits(rle+RLIST_NEXTTASK, RLIST_NEXTTASK_LEN));
lp->log("Time Slice Remaining: %8.8llu New Time Slice: %8.8llu\n",
getdigits(rle+RLIST_TSR, RLIST_TSR_LEN),
getdigits(rle+RLIST_NTS, RLIST_NTS_LEN));
lp->log("Wait field: %6.6llx\n",
gethex(rle+RLIST_WAIT_FIELD, RLIST_WAIT_FIELD_LEN));
lp->log(" IX4 %8.8llx IX5 %8.8llx IX6 %8.8llx IX7 %8.8llx\n",
gethex(rle+RLIST_MOBIX, 8),
gethex(rle+RLIST_MOBIX+8, 8),
gethex(rle+RLIST_MOBIX+16, 8),
gethex(rle+RLIST_MOBIX+24, 8));

c_environment env(this, rle+RLIST_ACTIVE_ENV);
char buf[10];
lp->log(" %s:%6.6llu IntMask=%2.2llx\n",
env.print(buf, sizeof(buf)),
getdigits(rle+RLIST_IP, RLIST_IP_LEN),
getdigits(rle+RLIST_IMASK, RLIST_IMASK_LEN));
}

I'd really hate to have to write and support a C++ outputstream
version of that using the << operator overloads.

On 27/01/2024 11:53, Janis Papanagnou wrote:
> On 27.01.2024 12:13, Malcolm McLean wrote:
>>>
>> What I am saying is that standard output can take integers, floats and
>> strings.
>
> Oh!? That doesn't match with any output model I have in mind. (It only
> matches if I'm coming from the printf() functionality as basis of all.)
>
Yes, exactly.
Standard output is any sequence of ASCII characters. printf() is the
main C interface to that, and supports integers, floats and strings, to
a first approximation.
>
> Standard output can take, technically, anything. We're passing binary
> and "text" across the standard channels (and may leave open whether an
> UTF-8 encoded text is to be considered "binary" in some context).
>
> On one abstraction level you can say I want to consider only non-binary
> readable output, but then it's all text (int and float and bool are just
> output with one of their textual standard representations).
>
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.
>> So the stream should have some facilites for writing integers (leading
>> zeros, signs, maybe commas separators for thousands), some for floats
>> (rounding, precision, scientific notation etc), some for strings (not
>> much you can do here other than just pass the raw characters).
>
> From an OO perspective we may also say the type Integer, the type Float,
> etc. shall provide means to create a textual standard representation,
> with options to control the form of the standard representation. Is the
> form of the standard representation a property of the data type or of a
> [not really] "generic" procedure that has hard-coded support for just
> a hand full of predefined primitive types?
>
>>
>> Now when we've got those facilites and we are happy with them, that's
>> it. We don't allow further derivation of the stream to change the basic
>> behaviour. Now people might say "booleans, you've forgotten booleans,
>> surely when you pass booleans it should print "true" or "false". No.
>> We'll handle that at a higher level and pass "true" and "false" as strings.
>>
>> The disadvantage is that you are locked into an integer/float/string
>> paradigm. Amd it's not OO. But the advantage is that it will be stable.
>
> The OO methods are also stable, but they are also flexible. The concept
> makes it possible to extend it to any data type. (I've done that many
> times. And thinking about how that would have looked like with non-OO
> and only printf() methods is a horror. But, as said; it's probably
> necessary to experience that self if it's not understandable from the
> explanations alone.)
>
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.
So
x = 123.456
stream.write(x)

would have different results depending on what stream we are passed.
It's flexible but not very stable, and the 123.456 output has no special
status.

Nw it's not inherently, necessarily the case that the data you can pass
to standard output is integers, floats and strings. You could devise a
program which operates on different data entirely, like Huffman codes.
But in practise the data will be build of those atoms, and so it makes
sense for the interface to standard output to handle them, then be
lokced down, so it can't be overidden and everything always works in the
same way.

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

On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote:

> On 27/01/2024 02:10, James Kuyper wrote:
>
>> On 1/26/24 12:31, Janis Papanagnou wrote:
>
>>> All side effects can be a problem (and should be avoided unless
>>> "necessary").
>>
>> Virtually everything useful that a computer program does qualifies as a
>> side effect. Side effects cannot be avoided, they can only be
>> controlled.
>>
> Try telling that to Haskell programmers :-)

The dirty little secret of pure-functional programming is that I/O cannot
be treated in a purely functional fashion.

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.

I did have to make some small code changes. For example in Japanese the
equivalent of “either «a», «b» or «c»” becomes something like “either «a»
or1 «b» or2 «c»”, with different words for “or1” and “or2”. In other
languages, the “or1” could just be a comma, as in the template with more
than 3 cases. So you can see why I needed to add a template for exactly 3
cases.

As I recall, it took some explaining to the translators to get them to
understand the scheme. They were not accustomed to working in terms of
abstract sentence/phrase structure with placeholders. I had to keep
supplying plenty of examples.

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.

On Sat, 27 Jan 2024 17:24:27 GMT, Scott Lurndal wrote:

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

It tried to be simpler than C++. If you compare the respective sizes of
the core language manuals, you would have to agree it failed miserably.

And the cost of that “simplicity” was the leaving out of useful features
like operator overloads for user types, unsigned integers, typedefs and
generics (later added back in a hacky way).

Here’s a Java feature that might surprise some people: in C++, you use the
word “new” to denote that a class instance is being allocated on the heap.
A declaration without that word indicates that the instance is being
allocated on the stack.

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?

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.

On Sat, 27 Jan 2024 16:17:47 +0100, David Brown wrote:

> On 26/01/2024 22:22, Lawrence D'Oliveiro wrote:
>
>> The default keys come from /usr/share/X11/locale/en_US.UTF-8/Compose,
>> which on my system contains something like 5000 entries.
>
> But most of these cannot be typed (by most people), because the
> combinations include things like dead keys that they don't have, or
> letters or keys that are from other keyboard layouts.

OK, after some examination, here’s the expression I came up with:

grep '^<Multi' /usr/share/X11/locale/en_US.UTF-8/Compose |
grep -cvE '<dead|<U|<Cyril|<Greek|<.horn|<kana'

That comes up with a figure of 1540. Given there were a few more obscure
names I didn’t bother to filter out, I’d say that figure is only a few
dozen too high. Then divide by 2 (crudely) to allow for alternative
orders, that still leaves several hundred, I would say, that can be typed
on a regular US keyboard (which we also use in NZ).

Looking at the list in more detail, I see things like currency signs,
musical notes, the hammer and sickle, the peace symbol, a heart, single
and double arrows, a bunch of maths symbols, circled letters and numbers,
a few APL symbols ... and all typable, if you have a font that can display
them.