The undisciplined use of GOTOs is bad, agreed.
The key to writing any software is lots of commenting.
On Tue, 20 Oct 2026 19:04:55 GMT, Charlie Gibbs wrote:
The undisciplined use of GOTOs is bad, agreed.
Is there such a thing as a *disciplined* use of gotos?
I find the C code I write tends to do a lot of dynamic resource
allocations. These can sometimes fail with errors. So error recovery
will invariably involve cleaning up those parts of the allocations
which already succeeded. Gotos are no good for this; you need to exit
levels of structure nesting one by one, disposing of allocations as
you go.
On Tue, 20 Oct 2026 19:04:55 GMT, Charlie Gibbs wrote:
The undisciplined use of GOTOs is bad, agreed.
Is there such a thing as a *disciplined* use of gotos?
On Tue, 20 Oct 2026 19:04:55 GMT, Charlie Gibbs wrote:
The undisciplined use of GOTOs is bad, agreed.
Is there such a thing as a *disciplined* use of gotos?
I find the C code I write tends to do a lot of dynamic resource
allocations. These can sometimes fail with errors. So error recovery
will invariably involve cleaning up those parts of the allocations
which already succeeded. Gotos are no good for this; you need to exit
levels of structure nesting one by one, disposing of allocations as
you go.
I put together an example here <https://gitlab.com/ldo/a_structured_discipline_of_programming>. This
is an extension module that offers services to Python code, because
that is just about the worst example I could think of, for those who
think gotos can cut it.
On 2026-10-20, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
I find the C code I write tends to do a lot of dynamic resource
allocations. These can sometimes fail with errors. So error
recovery will invariably involve cleaning up those parts of the
allocations which already succeeded. Gotos are no good for this;
you need to exit levels of structure nesting one by one, disposing
of allocations as you go.
I know that a lot of CS types are going to stick pins into little
dolls that look like me for saying this, but IMHO resource pointers,
handles, etc. should be global.
On Tue, 20 Oct 2026 23:18:44 GMT, Charlie Gibbs wrote:
I know that a lot of CS types are going to stick pins into little
dolls that look like me for saying this, but IMHO resource pointers,
handles, etc. should be global.
Surely any variable which is only used locally to a particular block
should be declared local to that block. Why should resource pointers
be any different?
On 2026-10-21, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Tue, 20 Oct 2026 23:18:44 GMT, Charlie Gibbs wrote:
I know that a lot of CS types are going to stick pins into little
dolls that look like me for saying this, but IMHO resource
pointers, handles, etc. should be global.
Surely any variable which is only used locally to a particular
block should be declared local to that block. Why should resource
pointers be any different?
Many resource pointers aren't local, though. Consider a program
which loads a table from a file, then uses it for lookups while
processing data in another file. You might decompose the program
into a function that loads the table, and another that performs
lookups. The main routine calls the table load routine, and opens
the file to be processed. It then loops reading records, calling the
lookup function each time. The table, dynamically allocated by the
table load function, must remain allocated when the allocator exits,
and must be available to the lookup function on each call; it cannot
be local to either of those functions.
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow -
whereas a goto out of a deeply nested loops is blindingly obvious -
and its less efficient.
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow -
whereas a goto out of a deeply nested loops is blindingly obvious -
and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
What about the cleanup?
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow -
whereas a goto out of a deeply nested loops is blindingly obvious -
and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
What about the cleanup?
On Wed, 21 Oct 2026 07:55:39 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow -
whereas a goto out of a deeply nested loops is blindingly obvious -
and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
Fine, well you stick with your gotos-are-bad religious doctrine based on something one guy said 50 years ago and the rest of us will carry on writing usable and easy to follow code.
What about the cleanup?
What about it? you think a flag test in a loop automagically fixes that?
On Wed, 21 Oct 2026 07:55:39 -0000 (UTC), Lawrence D?Oliveiro wrote:
What about the cleanup?
What about it? you think a flag test in a loop automagically fixes that?
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow
- whereas a goto out of a deeply nested loops is blindingly
obvious - and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
What about the cleanup?
What cleanup, exactly? We are talking Fortran, remember.
A co-worker actually tracked down such an issue. It turned out that
in certain cases of misuse of indirection, you could assign new
values to constants, such that '2' might have the value 1.
I occasionally use GOTOs, but usually only after considering other alternatives. The flag test is the big red flag. If I have to keep
testing a flag for several layers to get out of a loop, there has to
be a better way.
On Wed, 21 Oct 2026 13:27:48 -0000 (UTC), Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow
- whereas a goto out of a deeply nested loops is blindingly
obvious - and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
What about the cleanup?
What cleanup, exactly? We are talking Fortran, remember.
The principle applies to Fortran as it does to any language where you
have to explicitly manage storage allocations.
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where you
have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again,
how *exactly* does using GOTO to break out of a Fortran 77 do
loop require cleanup?
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where you
have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again,
how *exactly* does using GOTO to break out of a Fortran 77 do
loop require cleanup?
Read that again: ?explicitly manage storage allocations?.
On 21 Oct 2026 16:02:16 GMT, Ted Nolan <tednolan> wrote:
A co-worker actually tracked down such an issue. It turned out that
in certain cases of misuse of indirection, you could assign new
values to constants, such that '2' might have the value 1.
Certain early Fortran implementations. Couldn?t happen in any other
language ...
On 21 Oct 2026 16:02:16 GMT, Ted Nolan <tednolan> wrote:
A co-worker actually tracked down such an issue. It turned out that
in certain cases of misuse of indirection, you could assign new
values to constants, such that '2' might have the value 1.
Certain early Fortran implementations. Couldn?t happen in any other
language ...
On Thu, 22 Oct 2026 02:00:29 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again, how
*exactly* does using GOTO to break out of a Fortran 77 do loop
require cleanup?
Read that again: ?explicitly manage storage allocations?.
Sure, what is the EXACT clean up that you envision?
On Wed, 21 Oct 2026 13:27:48 -0000 (UTC), Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to follow
- whereas a goto out of a deeply nested loops is blindingly
obvious - and its less efficient.
The goto from the deep inner block to the outer one is ?blindingly
obvious? ... ly wrong.
What about the cleanup?
What cleanup, exactly? We are talking Fortran, remember.
The principle applies to Fortran as it does to any language where you
have to explicitly manage storage allocations.
On Thu, 22 Oct 2026 02:17:59 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 02:00:29 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again, how
*exactly* does using GOTO to break out of a Fortran 77 do loop
require cleanup?
Read that again: ?explicitly manage storage allocations?.
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
On Thu, 22 Oct 2026 03:35:07 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 02:17:59 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 02:00:29 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote: >>>>>
The principle applies to Fortran as it does to any language
where you have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again,
how *exactly* does using GOTO to break out of a Fortran 77 do
loop require cleanup?
Read that again: ?explicitly manage storage allocations?.
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 13:27:48 -0000 (UTC), Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote: >>>>>>
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to
follow - whereas a goto out of a deeply nested loops is
blindingly obvious - and its less efficient.
The goto from the deep inner block to the outer one is
?blindingly obvious? ... ly wrong.
What about the cleanup?
What cleanup, exactly? We are talking Fortran, remember.
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
DO loops do not introduce scope in Fortran.
On Thu, 22 Oct 2026 04:33:04 -0000 (UTC), Steven G. Kargl wrote:
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Not in your example. Which is why it was irrelevant.
On 10/21/26 17:37, Lawrence D?Oliveiro wrote:
On 21 Oct 2026 16:02:16 GMT, Ted Nolan <tednolan> wrote:
A co-worker actually tracked down such an issue. It turned out that
in certain cases of misuse of indirection, you could assign new
values to constants, such that '2' might have the value 1.
Certain early Fortran implementations. Couldn?t happen in any other
language ...
Probably called a subroutine with constant 2 as an argument, which the subroutine modified. I don't think FORTRAN used dummy arguments or call- by-value.
On Thu, 22 Oct 2026 04:50:10 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 04:33:04 -0000 (UTC), Steven G. Kargl wrote:
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Not in your example. Which is why it was irrelevant.
Then give a Fortran 77 example that requires cleanup.
You can't, can you?
Using GOTO to jump out of do-loop in Fortran 77 does
not lead to some mysterious "storage allocation" to
cleanup.
PS: a smart compiler would actually not generate code
to execute the do-loop for the code in my example.
On Thu, 22 Oct 2026 03:46:30 -0000 (UTC), Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 13:27:48 -0000 (UTC), Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Wed, 21 Oct 2026 07:42:30 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 01:29:18 -0000 (UTC), Lawrence D?Oliveiro wrote: >>>>>>>
On Tue, 20 Oct 2026 17:24:27 -0000 (UTC), boltar wrote:
** The setting a flag method which has to be checked in every
nested loop test is just an [asinine] way to code.
If you have to do cleanup at each level before exiting, then it
works perfectly well.
It may well work but it doesn't make it good. Its harder to
follow - whereas a goto out of a deeply nested loops is
blindingly obvious - and its less efficient.
The goto from the deep inner block to the outer one is
?blindingly obvious? ... ly wrong.
What about the cleanup?
What cleanup, exactly? We are talking Fortran, remember.
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
DO loops do not introduce scope in Fortran.
Nobody said anything about ?scope?.
On 10/22/2026 12:56 PM, Steven G. Kargl wrote:
On Thu, 22 Oct 2026 04:50:10 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 04:33:04 -0000 (UTC), Steven G. Kargl wrote:
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Not in your example. Which is why it was irrelevant.
Then give a Fortran 77 example that requires cleanup.
You can't, can you?
Using GOTO to jump out of do-loop in Fortran 77 does
not lead to some mysterious "storage allocation" to
cleanup.
PS: a smart compiler would actually not generate code
to execute the do-loop for the code in my example.
Open Watcom Fortran 77 has /allocate/ and /deallocate/ according to a
quick glance at the manual, but I have never used them.
I guess the point is we don't want to allocate in a loop?
On Thu, 22 Oct 2026 14:34:20 +0800, Johann 'Myrkraverk' Oskarsson wrote:
On 10/22/2026 12:56 PM, Steven G. Kargl wrote:
On Thu, 22 Oct 2026 04:50:10 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 04:33:04 -0000 (UTC), Steven G. Kargl wrote:
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Not in your example. Which is why it was irrelevant.
Then give a Fortran 77 example that requires cleanup.
You can't, can you?
Using GOTO to jump out of do-loop in Fortran 77 does
not lead to some mysterious "storage allocation" to
cleanup.
PS: a smart compiler would actually not generate code
to execute the do-loop for the code in my example.
Open Watcom Fortran 77 has /allocate/ and /deallocate/ according to a
quick glance at the manual, but I have never used them.
Dynamic memory management via allocate/deallocate was introduce
in Fortran 90. Open Watcom Fortran 77 may have added those as
an extension. The Fortran 77 standard does have a dynamic memory
feature. But, this seems irrelevant to Lawrence, who has coined
the term "storage allocation", which is not Fortran terminology.
We are now waiting for a definition for this term.
I guess the point is we don't want to allocate in a loop?
I allocate memory in do-loops all time. It would be a significant pessimization to write something like
integer, allocatable :: i(:)
i = [0] ! A 1-element array.
do j = 1, 9
i = [i,j] ! Re-allocate i on assignment
end do
10 print *, i
end
Note, there is no clean up of 'storage allocation' when the
loop terminates. The Fortran standard does not mandate when
memory that may have been freed during the re-allocation is
actually garbaged collected. The program could return memory
to the system during the re-allocation or when the program
terminates.
On Thu, 22 Oct 2026 02:17:59 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 02:00:29 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again, how
*exactly* does using GOTO to break out of a Fortran 77 do loop
require cleanup?
Read that again: ?explicitly manage storage allocations?.
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
On Wed, 21 Oct 2026 08:05:02 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 07:55:39 -0000 (UTC), Lawrence D?Oliveiro wrote:
What about the cleanup?
What about it? you think a flag test in a loop automagically fixes that?
It needs to be done at each level before exiting to the outer level.
I can show you some example code, if you like.
On Thu, 22 Oct 2026 04:33:04 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 03:35:07 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 02:17:59 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 02:00:29 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 01:16:25 -0000 (UTC), Steven G. Kargl wrote:
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote: >>>>>>
The principle applies to Fortran as it does to any language
where you have to explicitly manage storage allocations.
Fortran 77 does not have dynamic memory allocation. So, again,
how *exactly* does using GOTO to break out of a Fortran 77 do
loop require cleanup?
Read that again: ?explicitly manage storage allocations?.
Sure, what is the EXACT clean up that you envision?
?Storage allocations?.
There isn't any "storage allocation" to cleanup.
Not in your example. Which is why it was irrelevant.
On Wed, 21 Oct 2026 08:05:02 -0000 (UTC), boltar wrote:
On Wed, 21 Oct 2026 07:55:39 -0000 (UTC), Lawrence D?Oliveiro wrote:
What about the cleanup?
What about it? you think a flag test in a loop automagically fixes that?
It needs to be done at each level before exiting to the outer level.
I can show you some example code, if you like.
boltar@battlestar.co.uk writes:
On Wed, 21 Oct 2026 19:01:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <11bb1da$qfn9$1@dont-email.me>, <boltar@battlestar.co.uk> wrote: >>>>Not sure why you think its conspiracy anything. I use the language on a >>>>daily basis and everytime a new version comes out I hope they've added >>>>something useful but since 2014 its been a law of diminishing returns. >>>>Plus there's unexplained omissions - eg threads have been part of the core >>>>language since 2011. Great, but what about processes? When do we get them? >>>>Sure, I could just use fork() but then I could also just use pthread_create()
too.
One can implement a pretty reasonable threads library given the
virtual machine model of standard C or C++. Processes? With
Virtual machine? Wrong language , comp.lang.java is that way --->
The C/C++ "Virtual Machine Model" as described in the language
specifications is an apple.
A virtual machine (vmware, kvm, xen, et alia) is an orange.
assert(apples != oranges);
Somebody who knows the first thing about Fortran, which you
clearly don't, might have realized that scope is the only
way to mandate storage allocation/deallocation in Fortran.
[ Keeping the C++ group because that's at least in context, but I'm not
subscribing to it at the moment. I suppose this could eventually go to
folklore or alt.unix.geeks? ]
On 2026-10-22, Scott Lurndal wrote:
boltar@battlestar.co.uk writes:
On Wed, 21 Oct 2026 19:01:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <11bb1da$qfn9$1@dont-email.me>, <boltar@battlestar.co.uk> wrote:
Not sure why you think its conspiracy anything. I use the language on a >>>>>daily basis and everytime a new version comes out I hope they've added >>>>>something useful but since 2014 its been a law of diminishing returns. >>>>>Plus there's unexplained omissions - eg threads have been part of the core >>>>>language since 2011. Great, but what about processes? When do we get them? >>>>>Sure, I could just use fork() but then I could also just use pthread_create()
too.
One can implement a pretty reasonable threads library given the
virtual machine model of standard C or C++. Processes? With
Virtual machine? Wrong language , comp.lang.java is that way --->
The C/C++ "Virtual Machine Model" as described in the language
specifications is an apple.
A virtual machine (vmware, kvm, xen, et alia) is an orange.
assert(apples != oranges);
And here I think "virtual machine" was mistaken to be the Java Virtual >Machine, not the orange type above?
(A grapefruit? Pineapple? Banana?)
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach if
you allocate random stuff here and there.
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
On Thu, 22 Oct 2026 00:24:48 -0000 (UTC), Lawrence D?Oliveiro wrote:
The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.
So, why can't you provide an example of storage allocation, where
cleanup is relevant, so that using a GOTO would be problematic. That
way we could have some idea what you're talking about.
On Fri, 23 Oct 2026 03:33:44 -0000 (UTC), Lawrence D?Oliveiro wrote:
So you can see there is no way out of the inner block without passing
through the dispose call.
'break' is just another name for 'goto label'.
Using gotos would contribute nothing except make it harder to
assure yourself of the simplicity of the control flow.
PS: We're still waiting on a definition of "storage allocation"
... allocate object pointer ...
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach if
you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I gather there?s been a proposal that?s been kicking around for some
years, to adopt something based on Cairo
<https://www.cairographics.org/>.
On Fri, 23 Oct 2026 04:10:39 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 03:33:44 -0000 (UTC), Lawrence D?Oliveiro wrote:
So you can see there is no way out of the inner block without passing
through the dispose call.
'break' is just another name for 'goto label'.
Using gotos would contribute nothing except make it harder to
assure yourself of the simplicity of the control flow.
PS: We're still waiting on a definition of "storage allocation"
... allocate object pointer ...
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
On 10/22/2026 8:21 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a
user interface programming model for quite a long time.
First they need a standardized graphics API.
I gather there?s been a proposal that?s been kicking around for
some years, to adopt something based on Cairo
<https://www.cairographics.org/>.
That's a fairly decent one.
Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb:
But "break" is useful because it can't branch to any arbitrary
point in the enclosing function. It can only break out of a
specific enclosing construct. That makes the code easier to read
and write.
The goto usually isn't the problem, you see it and you see where its
target is.
[ Keeping the C++ group because that's at least in context, but I'm
not subscribing to it at the moment. I suppose this could eventually
go to folklore or alt.unix.geeks? ]
On 2026-10-22, Scott Lurndal wrote:
boltar@battlestar.co.uk writes:
On Wed, 21 Oct 2026 19:01:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <11bb1da$qfn9$1@dont-email.me>,
<boltar@battlestar.co.uk> wrote:
Not sure why you think its conspiracy anything. I use the
language on a daily basis and everytime a new version comes out I >>>>hope they've added something useful but since 2014 its been a law
of diminishing returns. Plus there's unexplained omissions - eg >>>>threads have been part of the core language since 2011. Great,
but what about processes? When do we get them? Sure, I could just
use fork() but then I could also just use pthread_create() too.
One can implement a pretty reasonable threads library given the
virtual machine model of standard C or C++. Processes? With
Virtual machine? Wrong language , comp.lang.java is that way --->
The C/C++ "Virtual Machine Model" as described in the language specifications is an apple.
A virtual machine (vmware, kvm, xen, et alia) is an orange.
assert(apples != oranges);
And here I think "virtual machine" was mistaken to be the Java Virtual Machine, not the orange type above?
(A grapefruit? Pineapple? Banana?)
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I gather there?s been a proposal that?s been kicking around for some
years, to adopt something based on Cairo
<https://www.cairographics.org/>.
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens. There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance >between features, efficiency, portability, size, hardware support, and
what they are used for.
People who think C++ should have a standardised graphics API usually
mean they want to standardise the API they use on the one application
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach if
you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to initialize it?
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens.˙ There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance between features, efficiency, portability, size, hardware support, and
what they are used for.
People who think C++ should have a standardised graphics API usually
mean they want to standardise the API they use on the one application
type that they write.
I gather there?s been a proposal that?s been kicking around for some
years, to adopt something based on Cairo
<https://www.cairographics.org/>.
On 23/10/2026 08:25, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
Chris' wording is perhaps poor, but the principle is right.
I don't know PL/I or Fortran, but in C if you have :
˙˙˙˙typedef struct data_struct { int a; int xs[20]; } S ;
˙˙˙˙S build_some_data(void) {
˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙ s.a = 123;
˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) s.xs[i] = i;
˙˙˙˙˙˙˙ return s;
˙˙˙˙}
˙˙˙˙void foo() {
˙˙˙˙˙˙˙ S s = build_some_data();
˙˙˙˙}
then it is typically handled as though you had written :
˙˙˙˙void build_some_data(S * p) {
˙˙˙˙˙˙˙ p->a = 123;
˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) p->xs[i] = i;
˙˙˙˙˙˙˙ return;
˙˙˙˙}
˙˙˙˙void foo() {
˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙ build_some_data(&s);
˙˙˙˙}
That is - the caller creates the /space/ for the returned object, but
does not do any kind of initialisation.˙ It passes a pointer to that
space as a hidden parameter to the function that wants to return the
object.
That principle should work fine in any language, as long as the size of
the returned object is known by the caller code.
On 10/22/26 22:29, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
That obviously wouldn't work, since then the caller would have to
know something about the object beforehand.
On Fri, 23 Oct 2026 04:22:13 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 04:10:39 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 03:33:44 -0000 (UTC), Lawrence D?Oliveiro wrote:
So you can see there is no way out of the inner block without passing
through the dispose call.
'break' is just another name for 'goto label'.
Using gotos would contribute nothing except make it harder to
assure yourself of the simplicity of the control flow.
PS: We're still waiting on a definition of "storage allocation"
... allocate object pointer ...
Nice use of quoting without adding context.
On Fri, 23 Oct 2026 05:54:44 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 04:22:13 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 04:10:39 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 03:33:44 -0000 (UTC), Lawrence D?Oliveiro wrote:
So you can see there is no way out of the inner block without passing >>>>> through the dispose call.
'break' is just another name for 'goto label'.
Using gotos would contribute nothing except make it harder to
assure yourself of the simplicity of the control flow.
PS: We're still waiting on a definition of "storage allocation"
... allocate object pointer ...
Nice use of quoting without adding context.
Just pointing out (in case you didn?t notice) that the points you were raising were already addressed in the posting you were (supposedly)
replying to ...
On Thu, 22 Oct 2026 22:31:07 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:21 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a
user interface programming model for quite a long time.
First they need a standardized graphics API.
I gather there?s been a proposal that?s been kicking around for
some years, to adopt something based on Cairo
<https://www.cairographics.org/>.
That's a fairly decent one.
It is (based on PostScript but goes beyond it), but the draft proposal
I?ve seen is somewhat butchered. No text/font API, for a start.
The JavaScript browser-based 2D Canvas API is also based on Cairo, and
that was also butchered, albeit in a different way.
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens.˙ There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance between features, efficiency, portability, size, hardware support, and
what they are used for.
People who think C++ should have a standardised graphics API usually
mean they want to standardise the API they use on the one application
type that they write.
I gather there?s been a proposal that?s been kicking around for some
years, to adopt something based on Cairo
<https://www.cairographics.org/>.
Fwiw, Cairo is up on vcpkg, so its really easy to build and
integrate with any MSVC project.
https://vcpkg.io/en/package/cairo
On Thu, 22 Oct 2026 22:31:07 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:21 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a
user interface programming model for quite a long time.
First they need a standardized graphics API.
I gather there?s been a proposal that?s been kicking around for
some years, to adopt something based on Cairo
<https://www.cairographics.org/>.
That's a fairly decent one.
It is (based on PostScript but goes beyond it), but the draft proposal
I?ve seen is somewhat butchered. No text/font API, for a start.
The JavaScript browser-based 2D Canvas API is also based on Cairo, and
that was also butchered, albeit in a different way.
On Fri, 23 Oct 2026 12:48:58 -0700, Chris M. Thomasson wrote:
Fwiw, Cairo is up on vcpkg, so its really easy to build and
integrate with any MSVC project.
https://vcpkg.io/en/package/cairo
Do you get Fontconfig and FreeType as well?
I thought Windows had native equivalents to all this functionality
anyway, yet here you are, reimplementing the entire Free Software
stack in parallel to it.
On 10/23/26 02:45, David Brown wrote:
On 23/10/2026 08:25, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
Chris' wording is perhaps poor, but the principle is right.
I don't know PL/I or Fortran, but in C if you have :
˙˙˙˙˙typedef struct data_struct { int a; int xs[20]; } S ;
˙˙˙˙˙S build_some_data(void) {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ s.a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) s.xs[i] = i;
˙˙˙˙˙˙˙˙ return s;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s = build_some_data();
˙˙˙˙˙}
then it is typically handled as though you had written :
˙˙˙˙˙void build_some_data(S * p) {
˙˙˙˙˙˙˙˙ p->a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) p->xs[i] = i;
˙˙˙˙˙˙˙˙ return;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ build_some_data(&s);
˙˙˙˙˙}
That is - the caller creates the /space/ for the returned object, but
does not do any kind of initialisation.˙ It passes a pointer to that
space as a hidden parameter to the function that wants to return the
object.
That principle should work fine in any language, as long as the size
of the returned object is known by the caller code.
That last sentence is why it would not work fine,
On 10/23/26 02:45, David Brown wrote:
On 23/10/2026 08:25, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
Chris' wording is perhaps poor, but the principle is right.
I don't know PL/I or Fortran, but in C if you have :
˙˙˙˙˙typedef struct data_struct { int a; int xs[20]; } S ;
˙˙˙˙˙S build_some_data(void) {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ s.a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) s.xs[i] = i;
˙˙˙˙˙˙˙˙ return s;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s = build_some_data();
˙˙˙˙˙}
then it is typically handled as though you had written :
˙˙˙˙˙void build_some_data(S * p) {
˙˙˙˙˙˙˙˙ p->a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) p->xs[i] = i;
˙˙˙˙˙˙˙˙ return;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ build_some_data(&s);
˙˙˙˙˙}
That is - the caller creates the /space/ for the returned object, but
does not do any kind of initialisation.˙ It passes a pointer to that
space as a hidden parameter to the function that wants to return the
object.
That principle should work fine in any language, as long as the size
of the returned object is known by the caller code.
That last sentence is why it would not work fine,
On Fri, 23 Oct 2026 09:02:50 -0700, Peter Flass wrote:
On 10/22/26 22:29, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
That obviously wouldn't work, since then the caller would have to
know something about the object beforehand.
And what if the object didn?t consist of just *one*
dynamically-allocated block, but needed links to other blocks as well?
What if it needed objects dynamically allocated by other APIs, the
details of which are internal to those APIs? Is the caller required to
know about all these implementation details?
In short, the concept doesn?t scale, because it completely breaks the
concept of data abstraction.
And it just pushes the dynamic-allocation problem elsewhere, without
making it easier.
On 10/22/26 22:29, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach if
you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
That obviously wouldn't work, since then the caller would have to know something about the object beforehand. I think you'd have to depend on
the compiler to destroy the object when it goes out of scope, unless the caller destroys it itself.
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens.
There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance between features, efficiency, portability, size, hardware support, and
what they are used for.
David Brown <david.brown@hesbynett.no> schrieb:
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens.
I have one Fortran program which has an excellent graphics API,
it writes Postscript. Works fine. Can't do any mouse clicks on
it and expect anything to happen, though :-)
Works for all programming languages as long as they do text I/O.
There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance
between features, efficiency, portability, size, hardware support, and
what they are used for.
I guess mine is an example rather restricted graphics API, then :-)
On Fri, 23 Oct 2026 19:20:50 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 05:54:44 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 04:22:13 -0000 (UTC), Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 04:10:39 -0000 (UTC), Steven G. Kargl wrote:
On Fri, 23 Oct 2026 03:33:44 -0000 (UTC), Lawrence D?Oliveiro wrote: >>>>>> So you can see there is no way out of the inner block without passing >>>>>> through the dispose call.
'break' is just another name for 'goto label'.
Using gotos would contribute nothing except make it harder to
assure yourself of the simplicity of the control flow.
PS: We're still waiting on a definition of "storage allocation"
... allocate object pointer ...
Nice use of quoting without adding context.
Just pointing out (in case you didn?t notice) that the points you were
raising were already addressed in the posting you were (supposedly)
replying to ...
And, we are still waiting for your definition of "storage allocation"
and its needed cleanup in the context of Fortran 77. It as been pointed
out to you multiple times that Fortran 77 does not have dynamic memory allocation. Fortran 77 does not have pointers and it does not have
objects. So, what is this mythical cleanup of storage allocation in
Fortran 77?
It's okay to admit that you were making a some generalization that
does not apply to Fortran 77.
That obviously wouldn't work, since then the caller would have to
know something about the object beforehand.
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
In short, the concept doesn?t scale, because it completely breaks
the concept of data abstraction.
And it just pushes the dynamic-allocation problem elsewhere,
without making it easier.
It can be made to work ...
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
That obviously wouldn't work, since then the caller would have to
know something about the object beforehand.
non sequitur?
Fwiw, vcpkg has a lot of them, ready to automatically build and
integrate. vcpkg is actually... Well, its pretty nice and so far...
Seems to work for me.
Well, for me. I had LOGO, PILOT and BASIC on my first Atari when I
was a little kiddo in the early to mid 80's. Born in 1977. I had
some books to go with them. So, I read the damn books. Started
programming!
On Fri, 23 Oct 2026 13:02:44 -0700, Chris M. Thomasson wrote:
Well, for me. I had LOGO, PILOT and BASIC on my first Atari when I
was a little kiddo in the early to mid 80's. Born in 1977. I had
some books to go with them. So, I read the damn books. Started
programming!
My first exposure to a real computer system was a DEC PDP-11. I
remember the first time I saw an Apple II running LOGO. Somebody tried telling it to do a file I/O command without a floppy in the drive. It
ground away for a few seconds, and then produced an error message --
of course.
What was that error message? I was expecting something like ?DISK
ERROR? or ?I/O ERROR?. Instead, it said
I?m having trouble with the disk.
To me, that was like a splash in the face with a pail of cold water.
The idea of an error message phrased in plain, approachable language
(using a first-person pronoun, even) instead of technical terms?? That
was a revelation.
On Fri, 23 Oct 2026 12:55:02 -0700, Chris M. Thomasson wrote:
Fwiw, vcpkg has a lot of them, ready to automatically build and
integrate. vcpkg is actually... Well, its pretty nice and so far...
Seems to work for me.
How does it work for end-users? Are your dependencies automatically
brought in when they install your package? How are they kept
up-to-date?
On 10/23/2026 3:46 PM, Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 12:55:02 -0700, Chris M. Thomasson wrote:
Fwiw, vcpkg has a lot of them, ready to automatically build and
integrate. vcpkg is actually... Well, its pretty nice and so far...
Seems to work for me.
How does it work for end-users? Are your dependencies automatically
brought in when they install your package? How are they kept
up-to-date?
Oh yeah. In your build directory, say Debug or Release, it has all of
the built shared libs and everything you need to run it.
Keeping them up to date is, afaict, manual.
On Fri, 23 Oct 2026 13:56:49 -0700, Chris M. Thomasson wrote:
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
In short, the concept doesn?t scale, because it completely breaks
the concept of data abstraction.
And it just pushes the dynamic-allocation problem elsewhere,
without making it easier.
It can be made to work ...
I?m sure it?s *possible*, but what is the *point*?
The whole aim of levels of abstraction is to tame the multi-headed
beast of complexity that is computer programming. What you are doing
here is breaking down those levels, all in the aid of, I don?t know,
just to keep using gotos in your code, or something.
On Fri, 23 Oct 2026 14:29:22 -0700, Chris M. Thomasson wrote:
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
That obviously wouldn't work, since then the caller would have to
know something about the object beforehand.
non sequitur?
I don?t care, because ... I didn?t say that.
On 2026-10-23, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Fri, 23 Oct 2026 13:02:44 -0700, Chris M. Thomasson wrote:
Well, for me. I had LOGO, PILOT and BASIC on my first Atari when I
was a little kiddo in the early to mid 80's. Born in 1977. I had
some books to go with them. So, I read the damn books. Started
programming!
My first exposure to a real computer system was a DEC PDP-11. I
remember the first time I saw an Apple II running LOGO. Somebody tried
telling it to do a file I/O command without a floppy in the drive. It
ground away for a few seconds, and then produced an error message --
of course.
What was that error message? I was expecting something like ?DISK
ERROR? or ?I/O ERROR?. Instead, it said
I?m having trouble with the disk.
To me, that was like a splash in the face with a pail of cold water.
The idea of an error message phrased in plain, approachable language
(using a first-person pronoun, even) instead of technical terms?? That
was a revelation.
Unfortunately it's not the kind of revelation I welcome. Back
in my mainframe days, I learned to hate catch-all error messages;
they're the sign of a programmer who's too lazy to try to help
the user. If something goes wrong, I want to be given some clues
as to where to look. But more and more these days, your typical
error message is "Something went wrong." Nothing more. This kind
of conduct should be condemned.
Think of it from a support person's point of view. A user calls
and says, "I have an error message." "OK," you reply, "what is
the message?" "It doesn't work." That's what the user would have
said anyway - we've just wasted some time, and we still have to
start the same old game of Twenty Questions.
I'm not saying that we should go back to the days of cryptic error
codes. But an error message can be both friendly and helpful.
For your case, how about something like "There is no disk in the
drive" or "The disk is write-protected"? And then follow it with
an error code for those of us who know how to interpret them.
Users shouldn't be made to guess what the computer already knows.
Virtual machine? Wrong language , comp.lang.java is that way --->
On 10/23/2026 3:42 PM, Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 13:56:49 -0700, Chris M. Thomasson wrote:
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
In short, the concept doesn?t scale, because it completely breaks
the concept of data abstraction.
And it just pushes the dynamic-allocation problem elsewhere,
without making it easier.
It can be made to work ...
I?m sure it?s *possible*, but what is the *point*?
The whole aim of levels of abstraction is to tame the multi-headed
beast of complexity that is computer programming. What you are
doing here is breaking down those levels, all in the aid of, I
don?t know, just to keep using gotos in your code, or something.
Well, not about goto's and such. Just so a lib can inform the caller
as to what it needs to work with. The caller sets it up, then calls
into the init etc. Its being used in a lot of places. Take Vulkan.
On 10/23/26 02:34, David Brown wrote:
On 23/10/2026 05:21, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 15:41:15 -0500, Lynn McGuire wrote:
I have been advocating for quite a while that C++ should add a user
interface programming model for quite a long time.
First they need a standardized graphics API.
I hope that never happens.˙ There are large numbers of graphics APIs,
with huge ranges of what they support, how they work and their balance
between features, efficiency, portability, size, hardware support, and
what they are used for.
People who think C++ should have a standardised graphics API usually
mean they want to standardise the API they use on the one application
type that they write.
I gather there?s been a proposal that?s been kicking around for some
years, to adopt something based on Cairo
<https://www.cairographics.org/>.
You need something with subsets. At least a "basic" subset, a "full"
subset, and something in between that satisfies most uses. Or maybe
subsets for different purposes, but they should all be compatible.
On 10/23/26 02:45, David Brown wrote:
On 23/10/2026 08:25, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach
if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
Chris' wording is perhaps poor, but the principle is right.
I don't know PL/I or Fortran, but in C if you have :
˙˙˙˙˙typedef struct data_struct { int a; int xs[20]; } S ;
˙˙˙˙˙S build_some_data(void) {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ s.a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) s.xs[i] = i;
˙˙˙˙˙˙˙˙ return s;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s = build_some_data();
˙˙˙˙˙}
then it is typically handled as though you had written :
˙˙˙˙˙void build_some_data(S * p) {
˙˙˙˙˙˙˙˙ p->a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) p->xs[i] = i;
˙˙˙˙˙˙˙˙ return;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ build_some_data(&s);
˙˙˙˙˙}
That is - the caller creates the /space/ for the returned object, but
does not do any kind of initialisation.˙ It passes a pointer to that
space as a hidden parameter to the function that wants to return the
object.
That principle should work fine in any language, as long as the size
of the returned object is known by the caller code.
That last sentence is why it would not work fine,
On Fri, 23 Oct 2026 17:01:28 -0700, Chris M. Thomasson wrote:
On 10/23/2026 3:42 PM, Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 13:56:49 -0700, Chris M. Thomasson wrote:
On 10/23/2026 12:19 PM, Lawrence D?Oliveiro wrote:
In short, the concept doesn?t scale, because it completely breaks
the concept of data abstraction.
And it just pushes the dynamic-allocation problem elsewhere,
without making it easier.
It can be made to work ...
I?m sure it?s *possible*, but what is the *point*?
The whole aim of levels of abstraction is to tame the multi-headed
beast of complexity that is computer programming. What you are
doing here is breaking down those levels, all in the aid of, I
don?t know, just to keep using gotos in your code, or something.
Well, not about goto's and such. Just so a lib can inform the caller
as to what it needs to work with. The caller sets it up, then calls
into the init etc. Its being used in a lot of places. Take Vulkan.
Where in Vulkan? Exposing implementation details to the caller not
only increases complexity, it also limits the implementor?s ability to
change those details later.
Iiic, vkGetBufferMemoryRequirements and vkGetImageMemoryRequirements,
which return a VkMemoryRequirements struct containing size, alignment,
and memoryTypeBits. The caller allocates the memory with
vkAllocateMemory and binds it with vkBindBufferMemory.
Also, iirc io_uring: IORING_SETUP_NO_MMAP (Linux 6.5+) lets the caller supply the memory for the rings and SQE array. It must be suitably
aligned (page or huge page), and the caller has to compute how big it
needs to be from the entry count and flags.
So it can be made to work.
On 10/23/2026 8:33 PM, Lawrence D?Oliveiro wrote:
On Fri, 23 Oct 2026 17:01:28 -0700, Chris M. Thomasson wrote:
On 10/23/2026 3:42 PM, Lawrence D?Oliveiro wrote:
The whole aim of levels of abstraction is to tame the
multi-headed beast of complexity that is computer programming.
What you are doing here is breaking down those levels, all in the
aid of, I don?t know, just to keep using gotos in your code, or
something.
Well, not about goto's and such. Just so a lib can inform the
caller as to what it needs to work with. The caller sets it up,
then calls into the init etc. Its being used in a lot of places.
Take Vulkan.
Where in Vulkan? Exposing implementation details to the caller not
only increases complexity, it also limits the implementor?s ability
to change those details later.
Iiic, vkGetBufferMemoryRequirements and
vkGetImageMemoryRequirements, which return a VkMemoryRequirements
struct containing size, alignment, and memoryTypeBits. The caller
allocates the memory with vkAllocateMemory and binds it with vkBindBufferMemory.
Or what about miniaudio?s ma_engine_get_heap_size plus ma_engine_init_preallocated
On 24/10/2026 03:06, Peter Flass wrote:
On 10/23/26 01:01, boltar@caprica.universe wrote:
On Thu, 22 Oct 2026 12:19:49 -0400 (EDT)
kludge@panix.com (Scott Dorsey) gabbled:
In article <11bd7tj$rh4f$1@dont-email.me>,˙
<boltar@battlestar.co.uk> wrote:
Most of us have a CS degree. But then we go out into the real
world, get a
job and find out what real programming on real products entails,
not a load
of virtual academic naval gazing.
That's because it's not a trade school degree.˙ It's not there to teach >>>> you to program, it's there to teach you the fundamentals that you
need to
properly understand programming.
No, it teaches you fundamentals of certain aspects of computer
paradigms such
as databases, graphics, AI. Most people into computers learn actual
programming
long before they hit university.
Engineering schools are even more that way.˙ They don't teach you much >>>> engineering, but they give you all the background that you need to learn >>>> engineering.
Programming isn't pure engineering - its a combination of
engineering, logic,
art and a trade.
If you just want a job, getting one of these degrees is not for
you. It's
not there for that.
Bill Gates never earned a degree. He seemed to do ok.
From what I understand, he wasn't a very good programmer, though.
A story I heard thirty-odd years ago about Bill Gates' purported
programming ability:
When MS started making money from their MSBASIC compiler, they started
hiring real staff.
One of them was tasked with working through the various functions that
BASIC does, such as opening files, sorting arrays, and the like.
When he looked at the sort routine, he exclaimed, loudly, "What idiot
wrote this, it doesn't do anything!"
Bill was in the room at the time, wandered over and had a look at what
they were working on, and said, "Oh, the sort routine. I could never
get that to work."
Apparently it was not a career-limiting action by the programmer.
Cheers,
Gary B-)
On 2026-10-24, Gary R. Schmidt wrote:
On 24/10/2026 03:06, Peter Flass wrote:
On 10/23/26 01:01, boltar@caprica.universe wrote:
On Thu, 22 Oct 2026 12:19:49 -0400 (EDT)
kludge@panix.com (Scott Dorsey) gabbled:
In article <11bd7tj$rh4f$1@dont-email.me>,
<boltar@battlestar.co.uk> wrote:
Most of us have a CS degree. But then we go out into the real
world, get a
job and find out what real programming on real products entails,
not a load
of virtual academic naval gazing.
That's because it's not a trade school degree.˙ It's not there to teach >>>>> you to program, it's there to teach you the fundamentals that you
need to
properly understand programming.
No, it teaches you fundamentals of certain aspects of computer
paradigms such
as databases, graphics, AI. Most people into computers learn actual
programming
long before they hit university.
Engineering schools are even more that way.˙ They don't teach you much >>>>> engineering, but they give you all the background that you need to learn >>>>> engineering.
Programming isn't pure engineering - its a combination of
engineering, logic,
art and a trade.
If you just want a job, getting one of these degrees is not for
you. It's
not there for that.
Bill Gates never earned a degree. He seemed to do ok.
From what I understand, he wasn't a very good programmer, though.
A story I heard thirty-odd years ago about Bill Gates' purported
programming ability:
When MS started making money from their MSBASIC compiler, they started
hiring real staff.
One of them was tasked with working through the various functions that
BASIC does, such as opening files, sorting arrays, and the like.
When he looked at the sort routine, he exclaimed, loudly, "What idiot
wrote this, it doesn't do anything!"
Bill was in the room at the time, wandered over and had a look at what
they were working on, and said, "Oh, the sort routine. I could never
get that to work."
Apparently it was not a career-limiting action by the programmer.
Cheers,
Gary B-)
And this is probably an example of where it is important to have at
least somehow learned (be it from a "CS" degree or not) that there are well-known sorting strategies and algorithms and that they perform differently, and that it's probably better to implement something sufficiently tested and reviewed? And to know how to pick one that
doesn't work too terribly for the kind of data being sorted.
Still, sorting is, I think, part of the fundamental basics covered in programming education, and at least at higher education level you can probably expect that to include a glance at the different algorithms.
So, by the standards of at least 10-20 years ago, this would probably
mean Gates wasn't much of a serious programmer? He wouldn't need to *memorize* all of them, but just to know that he could look it up and
pick one. But maybe things were vastly different back then?
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach if
you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the
caller?
Have the caller have the object before hand and call a function to initialize it?
Even analogous, to say, an API that says read n bytes and store into
buffer. Well, the caller has lifetime of said buffer. The caller makes
the buffer, calls into the function.
On Sun, 25 Oct 2026 16:16:26 -0700, Chris M. Thomasson wrote:
Even analogous, to say, an API that says read n bytes and store into
buffer. Well, the caller has lifetime of said buffer. The caller makes
the buffer, calls into the function.
So how is the caller supposed to manage that memory?
On Sun, 25 Oct 2026 16:16:26 -0700, Chris M. Thomasson wrote:
Even analogous, to say, an API that says read n bytes and store into
buffer. Well, the caller has lifetime of said buffer. The caller makes
the buffer, calls into the function.
So how is the caller supposed to manage that memory?
I had a quick look at that. It seems to have to do with the reality of graphics hardware implementing different kinds of memory with
different kinds of characteristics, and the impossibility of
completely such ignoring such issues in real-time 3D rendering.
I expect higher-level APIs (e.g. game engines) will wrap all this
behind their own higher-level abstractions, so regular
programmers/game creators don?t have to worry about it.
In short, it?s an abstraction that leaks that you accept only because
you have to, not because it?s a good idea for abstractions in general.
If you can successfully hide issues of memory and other resource
allocation behind your abstraction, you would still rather do it than
not.
So, to get back to my point, the technique I use is based on a form of structured programming called a ?Nassi-Shneiderman diagram?. The
overall structure looks like
... initialize object pointer to NULL ...
do /*once*/
{
... possible other stuff ...
... allocate object pointer ...
if (error occurred)
break;
... possible other stuff using object pointer ...
}
while (false);
... call free(3) (or equivalent) on object pointer ...
So you can see there is no way out of the inner block without passing
through the dispose call. Using gotos would contribute nothing except
make it harder to assure yourself of the simplicity of the control
flow.
Looks deceptively simple. But the same technique can scale up to quite complex cases.
A caller provided buffer is normal with a lot of API's out there.
Managing the memory is the caller?s job in C anyway.
A lib that never allocates behind your back is what you
want in embedded, kernel, and arena code ...
I distinctly recall working with Sweet-16 on my ][+ back in the day,
but can't recall the details.
The interpreter is assembled from source on a PDP-10 with at least
128K (and preferably more) of 36 bit words,because it's implemented
as local system call macros in PDP-10 assembler.
Bill wrote the basic framework, Monte Davidoff wrote the
transcendental math functions, and Paul Allen wrote the PDP-10 code
to do the assembly.
NB: I worked for Paul building Living Computers: Museum+Labs and
working there as an engineer from 2003-2018, then till 2020 when we
closed due to the pandemic. I've seen the original code, with named attributions.
On Sun, 25 Oct 2026 19:28:00 -0700, Chris M. Thomasson wrote:
A lib that never allocates behind your back is what you
want in embedded, kernel, and arena code ...
Even kernels want a common memory-management architecture, so addon
modules don?t have to reinvent memory management on their own.
Think of something like allocating low-priority cache memory, for
stuff that can be dumped if necessary: that needs to be managed in the
core of the kernel, so that if apps need regular memory for things
they want to keep in memory, the kernel can free up cache as necessary
to make more memory available.
Stop trying to rationalize away the whole point of dynamic memory
allocation.
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway: instead of
solving the resource-allocation problem once and for all in the
library API, you are pushing the burden onto all the client code, each
one of which has to solve it for itself.
That?s a dumb way to design things.
On Sun, 25 Oct 2026 19:21:00 -0700, Chris M. Thomasson wrote:
Managing the memory is the caller?s job in C anyway.
Does that apply to the caller of library APIs like malloc(3) and
free(3)?
On 10/25/2026 8:40 PM, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:21:00 -0700, Chris M. Thomasson wrote:
Managing the memory is the caller?s job in C anyway.
Does that apply to the caller of library APIs like malloc(3) and
free(3)?
Yes. The caller calls malloc, if it succeeded, the caller needs to free
what it got... Right?
On 10/25/2026 8:40 PM, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:21:00 -0700, Chris M. Thomasson wrote:
Managing the memory is the caller?s job in C anyway.
Does that apply to the caller of library APIs like malloc(3) and
free(3)?
Yes. The caller calls malloc, if it succeeded, the caller needs to free
what it got... Right?
Say a lib that has foo_create... Well, the damn called must remember
to call foo_destroy, right?
HUH? How do you call say, fread without a user provided buffer?
If you need dynamic memory fine.
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
On Mon, 26 Oct 2026 13:23:59 -0700, Chris M. Thomasson wrote:
If you need dynamic memory fine.
What the hell do you think we have been talking about this whole
time??
On Mon, 26 Oct 2026 13:33:37 -0700, Chris M. Thomasson wrote:
Say a lib that has foo_create... Well, the damn called must remember
to call foo_destroy, right?
Are you backpedalling from your previous idea that the caller must
allocate the memory for the library to use?
On 26/10/2026 21:29, Chris M. Thomasson wrote:
On 10/25/2026 8:40 PM, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:21:00 -0700, Chris M. Thomasson wrote:
Managing the memory is the caller?s job in C anyway.
Does that apply to the caller of library APIs like malloc(3) and
free(3)?
Yes. The caller calls malloc, if it succeeded, the caller needs to
free what it got... Right?
Exactly.˙ The caller is responsible for /managing/ the memory (or it can pass on that responsibility to something else).˙ malloc and free are
provide and dispose of memory, they do not manage it.
On 10/26/2026 2:45 PM, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:33:37 -0700, Chris M. Thomasson wrote:
Say a lib that has foo_create... Well, the damn called must
remember to call foo_destroy, right?
Are you backpedalling from your previous idea that the caller must
allocate the memory for the library to use?
Where did I say must?
On Mon, 26 Oct 2026 14:53:48 -0700, Chris M. Thomasson wrote:
On 10/26/2026 2:45 PM, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:33:37 -0700, Chris M. Thomasson wrote:
Say a lib that has foo_create... Well, the damn called must
remember to call foo_destroy, right?
Are you backpedalling from your previous idea that the caller must
allocate the memory for the library to use?
Where did I say must?
You said ?Managing the memory is the caller?s job in C anyway.? You
didn?t say ?could be the caller?s job? as in ?the caller could have a choice?, you said ?*is* the caller?s job?. No choice. I.e. the caller
*must* manage memory.
On Sun, 25 Oct 2026 19:21:00 -0700, Chris M. Thomasson wrote:
Managing the memory is the caller?s job in C anyway.
Does that apply to the caller of library APIs like malloc(3) and
free(3)?
On Mon, 26 Oct 2026 14:53:48 -0700, Chris M. Thomasson wrote:
On 10/26/2026 2:45 PM, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:33:37 -0700, Chris M. Thomasson wrote:
Say a lib that has foo_create... Well, the damn called must
remember to call foo_destroy, right?
Are you backpedalling from your previous idea that the caller must
allocate the memory for the library to use?
Where did I say must?
You said ?Managing the memory is the caller?s job in C anyway.? You
didn?t say ?could be the caller?s job? as in ?the caller could have a choice?, you said ?*is* the caller?s job?. No choice. I.e. the caller
*must* manage memory.
On 23/10/2026 18:57, Peter Flass wrote:
On 10/23/26 02:45, David Brown wrote:
On 23/10/2026 08:25, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 22:29:45 -0700, Chris M. Thomasson wrote:
On 10/22/2026 8:19 PM, Lawrence D?Oliveiro wrote:
On Thu, 22 Oct 2026 07:26:21 -0700, Peter Flass wrote:
That's why I try to use PL/I AUTOMATIC (stack) storage and not
allocate a lot of stuff. You need to have a disciplined approach >>>>>>> if you allocate random stuff here and there.
What if you?re building an object that needs to be returned to the >>>>>> caller?
Have the caller have the object before hand and call a function to
initialize it?
I?m assuming that all that BASIC programming hasn?t got to your head,
and you?re not serious. ;)
Chris' wording is perhaps poor, but the principle is right.
I don't know PL/I or Fortran, but in C if you have :
˙˙˙˙˙typedef struct data_struct { int a; int xs[20]; } S ;
˙˙˙˙˙S build_some_data(void) {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ s.a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) s.xs[i] = i;
˙˙˙˙˙˙˙˙ return s;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s = build_some_data();
˙˙˙˙˙}
then it is typically handled as though you had written :
˙˙˙˙˙void build_some_data(S * p) {
˙˙˙˙˙˙˙˙ p->a = 123;
˙˙˙˙˙˙˙˙ for (int i = 0; i < 20; i++) p->xs[i] = i;
˙˙˙˙˙˙˙˙ return;
˙˙˙˙˙}
˙˙˙˙˙void foo() {
˙˙˙˙˙˙˙˙ S s;
˙˙˙˙˙˙˙˙ build_some_data(&s);
˙˙˙˙˙}
That is - the caller creates the /space/ for the returned object, but
does not do any kind of initialisation.˙ It passes a pointer to that
space as a hidden parameter to the function that wants to return the
object.
That principle should work fine in any language, as long as the size
of the returned object is known by the caller code.
That last sentence is why it would not work fine,
OK.˙ Knowing the size of the returned object is an absolute requirement
for pre-allocation by the caller, and it is a requirement that is fine
for a lot of situations and a lot of languages.˙ But if it is not the
case for PL/I, Fortran, or any other particular language (or particular function in any language), then I fully agree - the object's space can't
be handled by the caller.
On Sat, 24 Oct 2026 13:27:30 -0700, Chris M. Thomasson wrote:
Or what about miniaudio?s ma_engine_get_heap_size plus
ma_engine_init_preallocated
No idea about that, but the same principle would apply.
On Sat, 24 Oct 2026 13:27:30 -0700, Chris M. Thomasson wrote:
Or what about miniaudio?s ma_engine_get_heap_size plus
ma_engine_init_preallocated
No idea about that, but the same principle would apply.
On Tue, 27 Oct 2026 09:06:26 +0100
David Brown <david.brown@hesbynett.no> wrote:
[snip]
And there are languages like Erlang that divide everything into
micro-processes, and use the same mechanisms for controlling and
passing data around regardless of whether this little processes are
in the same thread, or different threads, different OS processes, or
different computers. That works because there are very narrow and
tightly controlled mechanisms for sharing data.
Note that these are both languages that run on a VM, not compiled
languages.
What you wrote about Erlang resembles MPI, which of course is readily >available for many compiled or jitted languages, including Fortran, C
and C++.
I tried to utilize MPI 20 years ago, but the thinking behind it is to >different from mine, so I ran away in horror.
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:[restore snippage]>> On 2026-10-25 23:39, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway: instead of
solving the resource-allocation problem once and for all in the
library API, you are pushing the burden onto all the client code, each
one of which has to solve it for itself.
That?s a dumb way to design things.
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
In article <20261027102255.00006052@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
On Tue, 27 Oct 2026 09:06:26 +0100
David Brown <david.brown@hesbynett.no> wrote:
[snip]
And there are languages like Erlang that divide everything into
micro-processes, and use the same mechanisms for controlling and
passing data around regardless of whether this little processes are
in the same thread, or different threads, different OS processes, or
different computers. That works because there are very narrow and
tightly controlled mechanisms for sharing data.
Note that these are both languages that run on a VM, not compiled
languages.
What you wrote about Erlang resembles MPI, which of course is readily >>available for many compiled or jitted languages, including Fortran, C
and C++.
I tried to utilize MPI 20 years ago, but the thinking behind it is to >>different from mine, so I ran away in horror.
Erlang uses the "actor" model to represent concurrency; state is
held by each actor, and actors communicate via message passing,
potentially changing state in response to messages. This is a
model for _concurrency_, in which multiple independent threads
of execution are coordinated to some in a single system.
On 2026-10-26 17:45, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:[restore snippage]>> On 2026-10-25 23:39, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway: instead of
solving the resource-allocation problem once and for all in the
library API, you are pushing the burden onto all the client code, each >>>> one of which has to solve it for itself.
That?s a dumb way to design things.
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
fread() uses a caller-provided buffer, which, according to your previous comment, "push[es] the burden onto all the client code, each one of
which has to solve it for itself", so according to you, "That's a dumb
way to design things"..If that isn't your actual opinion of fread(),
your comments need to be at least a little more nuanced to avoid
applying to fread().
On 10/27/26 08:00, James Kuyper wrote:
On 2026-10-26 17:45, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:[restore snippage]>> On 2026-10-25 23:39, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway: instead of >>>>> solving the resource-allocation problem once and for all in the
library API, you are pushing the burden onto all the client code, each >>>>> one of which has to solve it for itself.
That?s a dumb way to design things.
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
fread() uses a caller-provided buffer, which, according to your previous
comment, "push[es] the burden onto all the client code, each one of
which has to solve it for itself", so according to you, "That's a dumb
way to design things"..If that isn't your actual opinion of fread(),
your comments need to be at least a little more nuanced to avoid
applying to fread().
The difference is that the size of the buffer for fread() is the maximum
you want/expect to read. The size of an object is the size it is, not >necessarily what you expect. If you don't provide enough space you will >truncate.
On 2026-10-26 17:45, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:
On 2026-10-25 23:39, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway:
instead of solving the resource-allocation problem once and for
all in the library API, you are pushing the burden onto all the
client code, each one of which has to solve it for itself.
That?s a dumb way to design things.
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
fread() uses a caller-provided buffer, which, according to your previous comment, "push[es] the burden onto all the client code, each one of
which has to solve it for itself", so according to you, "That's a dumb
way to design things"..
On 2026-10-25 20:42, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 16:16:26 -0700, Chris M. Thomasson wrote:
Even analogous, to say, an API that says read n bytes and store into
buffer. Well, the caller has lifetime of said buffer. The caller makes
the buffer, calls into the function.
So how is the caller supposed to manage that memory?
On Tue, 27 Oct 2026 11:00:08 -0400, James Kuyper wrote:
On 2026-10-26 17:45, Lawrence D?Oliveiro wrote:
On Mon, 26 Oct 2026 13:26:38 -0700, Chris M. Thomasson wrote:
On 2026-10-25 23:39, Lawrence D?Oliveiro wrote:
On Sun, 25 Oct 2026 19:11:48 -0700, Chris M. Thomasson wrote:
A caller provided buffer is normal with a lot of API's out there.
No it isn?t. It?s not a good way to manage things, anyway:
instead of solving the resource-allocation problem once and for
all in the library API, you are pushing the burden onto all the
client code, each one of which has to solve it for itself.
That?s a dumb way to design things.
HUH? How do you call say, fread without a user provided buffer?
Relevance being?
fread() uses a caller-provided buffer, which, according to your previous
comment, "push[es] the burden onto all the client code, each one of
which has to solve it for itself", so according to you, "That's a dumb
way to design things"..
Not even paying attention to what?s being said in the parts you
quoted, never mind the parts you didn?t. Note my remark above about
?solving the resource allocation problem?; elsewhere I asked: ?What if
you?re building an object that needs to be returned to the caller??
Not clear yet what we?re talking about here? We?re not talking about
random API calls, we?re talking about libraries that need to create
and manage abstract objects that encapsulate the function they are
providing!
... without the context that applies elsewhere, your comment about
resource allocation comes off as a non-sequitur.
On Tue, 27 Oct 2026 21:35:09 -0400, James Kuyper wrote:No, none of those comments appear anywhere in this sub-thread as
... without the context that applies elsewhere, your comment about
resource allocation comes off as a non-sequitur.
That?s just an excuse. Other comments of mine, from further back in
this particular line of this thread:
* ?What if you?re building an object that needs to be returned to the
caller??
* ?The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.?
* ?If you have to do cleanup at each level before exiting, then it works
perfectly well.?
Did you notice any of that?
On Tue, 27 Oct 2026 21:35:09 -0400, James Kuyper wrote:
... without the context that applies elsewhere, your comment about
resource allocation comes off as a non-sequitur.
That?s just an excuse. Other comments of mine, from further back in
this particular line of this thread:
* ?What if you?re building an object that needs to be returned to the
caller??
* ?The principle applies to Fortran as it does to any language where
you have to explicitly manage storage allocations.?
* ?If you have to do cleanup at each level before exiting, then it works
perfectly well.?
Did you notice any of that?
From elsewhere in the discussion:
I find the C code I write tends to do a lot of dynamic resource
allocations. These can sometimes fail with errors. So error
recovery will invariably involve cleaning up those parts of the
allocations which already succeeded. Gotos are no good for this;
you need to exit levels of structure nesting one by one, disposing
of allocations as you go.
I put together an example here
<https://gitlab.com/ldo/a_structured_discipline_of_programming>.
This is an extension module that offers services to Python code,
because that is just about the worst example I could think of, for
those who think gotos can cut it.
Did you pay attention to any of that?
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 5 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 232:41:51 |
| Calls: | 221 |
| Files: | 21,513 |
| Messages: | 84,424 |