Friday, December 17, 2021

Digest for comp.lang.c++@googlegroups.com - 11 updates in 4 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Dec 17 04:20PM -0600

"We Make a std::shared_mutex 10 Times Faster" by AlexeyAB

https://www.codeproject.com/Articles/1183423/We-Make-a-std-shared-mutex-10-Times-Faster
 
"This article details the atomic operations and C++11 memory barriers
and the assembler instructions generated by it on x86_64 CPUs."
 
Wow, that is detailed.
 
Lynn
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 17 01:07AM

On Thu, 16 Dec 2021 07:42:52 -0800
> treat this program. And I think the answer is the same, that
> implementations are obliged to try to carry it out faithfully but
> are allowed to fail when they run out of memory.
 
Isn't overflow in signed integers still undefined behavior? If so
implementations can do whatever they want should they implement tail
call optimization and so overflow on the integer.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 17 01:28AM


> Isn't overflow in signed integers still undefined behavior? If so
> implementations can do whatever they want should they implement tail
> call optimization and so overflow on the integer.
 
Optimising that tail call won't cause integer overflow. Optimisations
are obliged to preserve semantics!
 
--
Ben.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 16 07:54PM -0800


> Isn't overflow in signed integers still undefined behavior? If so
> implementations can do whatever they want should they implement tail
> call optimization and so overflow on the integer.
 
There is one 'a' variable for each level of recursion. Each 'a'
starts at 0 and gets incremented to 1, stopping at that value
just before the recursive call. So none of the 'a' variables
ever overflows.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 16 08:10PM -0800

wij <wyniijj@gmail.com> writes:
 
[...]
 
> By the way, I though the 'stack' still must exist no matter how it
> is implemented. [...]
 
Some sort of machinery with stack-like behavior must be there, to
support recursive calls if nothing else. But there doesn't have
to be a "stack" in the sense of a fixed, contiguous region of
memory that is used exclusively for state local to each call of a
function. Other ways of providing function-local state have been
used, and depending on the operating environment they can be
practical, feasible, or even preferable.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 16 08:20PM -0800

>> concern about where memory for that object might come from.
 
> Lack of capability of operations that provide storage to fail does
> not follow from abstract machine being abstract. [...]
 
Yes, that was poor phrasing on my part. Because of the kinds of
semantic descriptions used in defining the abstract machine tend
to gloss over certain kinds of details, we may reasonably expect
that they don't take running out of memory into account. And
that is indeed the case in the C++ standard for function calls
and what happens with local variables. Section 6.9.1 paragraph 1
says this:
 
An instance of each object with automatic storage duration
(6.7.5.3) is associated with each entry into its block. Such
an object exists and retains its last-stored value during the
execution of the block and while the block is suspended [...]
 
There is no mention of any possibility of running out of memory.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 17 10:06AM

On Thu, 16 Dec 2021 19:54:17 -0800
> starts at 0 and gets incremented to 1, stopping at that value
> just before the recursive call. So none of the 'a' variables
> ever overflows.
 
Good point!
"Öö Tiib" <ootiib@hot.ee>: Dec 17 08:46AM -0800

On Friday, 17 December 2021 at 06:21:00 UTC+2, Tim Rentsch wrote:
> an object exists and retains its last-stored value during the
> execution of the block and while the block is suspended [...]
 
> There is no mention of any possibility of running out of memory.
 
I agree. There are none defined ways for some operations like

char txt[100]{};
 
to fail because of lack of storage. Meanwhile somewhat equivalent
 
std::string str(100, 0);
 
can fail because of lack of storage. There std::allocator<char>
of that str can throw std::bad_alloc.
So IMHO the first definition of txt could also be defined
to throw std::bad_alloc (or something special like
std::stack_overflow) because of failing to complete.
That would not make the abstract machine less
abstract but just ... better designed.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 16 07:46PM -0800

>> including garbage collection, running years before even the
>> predecessor to C++, "C with Classes", existed.
 
> Are you thinking of Smalltalk or LISP?
 
Smalltalk.
 
>> would have been code to free memory no code is needed, replaced
>> by a single piece of code in the memory manager.
 
> An interesting hypothesis, but I'm not convinced without data.
 
Probably it depends on what applications are being programmed, given
that Smalltalk is an interactive programming and development system.
But surely it becomes true at some point as more code is written,
since the amount of non-automatic memory management code would grow
as additional applications are written, but code (and so the amount
of code) in the garbage collector stays fixed regardless of how much
application code is added.
Juha Nieminen <nospam@thanks.invalid>: Dec 17 06:30AM

> the overall memory footprint, because all the places where there
> would have been code to free memory no code is needed, replaced
> by a single piece of code in the memory manager.
 
What systems had so little memory that they couldn't even run a C++
compiler, yet had an operating system that offered a memory manager
with GC? And, ostensibly, was a multitasking OS (given that you are
arguing the programs had an overall smaller memory footprint).
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 16 07:24PM -0800

>> very much...
 
> No, I just used friend unctions, your suggestion would have been
> interesting to try, but I no longer have those tools installed.
 
Okay, thank you. I was asking only out of curiosity.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)