Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123511 > unrolled thread

“Is C++ Dead?”

Back to article view | Back to comp.lang.c++

Contents

  “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-05 15:19 -0600
    Re: “Is C++ Dead?” wij <wyniijj5@gmail.com> - 2026-03-06 08:14 +0800
      Re: “Is C++ Dead?” "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-03-06 12:53 +0800
    Re: “Is C++ Dead?” "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-03-06 12:48 +0800
      Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-06 13:25 -0800
        Re: “Is C++ Dead?” "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-03-07 13:15 +0800
        Re: “Is C++ Dead?” Michael S <already5chosen@yahoo.com> - 2026-03-07 20:03 +0200
          Re: “Is C++ Dead?” "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-03-08 16:26 +0800
            Re: “Is C++ Dead?” David Brown <david.brown@hesbynett.no> - 2026-03-08 11:49 +0100
              Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-08 16:46 +0100
                Re: “Is C++ Dead?” David Brown <david.brown@hesbynett.no> - 2026-03-08 19:22 +0100
                  Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-08 14:38 -0700
                    Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-10 14:17 +0100
                      Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-10 22:47 +0000
                      Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-10 17:07 -0700
              Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-08 14:11 -0700
            Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-08 22:54 +0000
      Re: “Is C++ Dead?” Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-03-09 08:27 +0100
        Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-09 17:36 -0500
          Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-10 13:27 +0000
          Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-15 19:13 +0000
            Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-15 19:40 +0000
            Re: “Is C++ Dead?” Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-15 21:15 +0000
              Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-15 18:15 -0500
            Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-15 17:33 -0500
              Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-16 00:28 +0000
              Re: “Is C++ Dead?” wij <wyniijj5@gmail.com> - 2026-03-17 00:53 +0800
            Re: “Is C++ Dead?” George Neuner <gneuner2@comcast.net> - 2026-03-16 10:31 -0400
              Re: “Is C++ Dead?” Michael S <already5chosen@yahoo.com> - 2026-03-16 17:56 +0200
              Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-16 17:06 +0000
                Re: “Is C++ Dead?” George Neuner <gneuner2@comcast.net> - 2026-03-16 23:00 -0400
                  Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-18 00:20 +0000
          Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-18 19:09 +0100
            Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-18 14:21 -0500
              Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-18 20:53 +0100
                Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-18 13:28 -0700
                Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-18 16:45 -0500
              Re: Re: “Is C++ Dead?” scott@slp53.sl.home (Scott Lurndal) - 2026-03-18 21:24 +0000
                Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-18 16:41 -0500
                  Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-18 19:58 -0700
                    Re: “Is C++ Dead?” Lynn McGuire <lynnmcguire5@gmail.com> - 2026-03-19 00:33 -0500
                      Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-18 22:50 -0700
                    Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-19 10:40 +0100
                      Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-19 12:26 -0700
                  Re: “Is C++ Dead?” Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-19 10:28 +0100
                Re: “Is C++ Dead?” David Brown <david.brown@hesbynett.no> - 2026-03-19 10:20 +0100
                  Re: “Is C++ Dead?” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-19 12:31 -0700
        Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-10 13:21 +0000
    Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-12 19:46 +0000
      Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-14 23:35 +0000
        Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-15 13:35 +0000
          Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-15 15:37 +0000
            Re: “Is C++ Dead?” Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-15 17:58 +0000
            Re: “Is C++ Dead?” Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-15 22:23 +0000
              Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-16 15:34 +0000
                Re: Re: “Is C++ Dead?” scott@slp53.sl.home (Scott Lurndal) - 2026-03-16 15:58 +0000
                  Re: “Is C++ Dead?” Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-17 00:02 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#123622

On 3/18/2026 9:58 PM, Chris M. Thomasson wrote:
> On 3/18/2026 2:41 PM, Lynn McGuire wrote:
>> On 3/18/2026 4:24 PM, Scott Lurndal wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> On 3/18/2026 1:09 PM, Bonita Montero wrote:
>>>>> Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
>>>>>
>>>>>> If C++ is too complex for a programmer then the programmer is not
>>>>>> a good programmer.
>>>>>
>>>>> I'm a good C++ programmer but I admit that C++ is much less readable
>>>>> as for example Rust. And both languages server the same purpose. But
>>>>> I still like C++.
>>>>>
>>>>>> The only exception to that is multiple thread software. That stuff
>>>>>> is dadgum complicated. But the multiple thread software is not used
>>>>>> very often in my circles.
>>>>>
>>>>> Most MT-algoritms are easy (embarassingly parallel).
>>>>
>>>> Spinning off threads is easy.  Deciding which variables to mutex is 
>>>> not.
>>>
>>> As someone with four decades of multitheaded programming experience
>>> at both the lowest levels (OS) and highest levels (applications),
>>> I strongly disagree.
>>>
>>> It's very easy to determine whether a particular datum is
>>> subject to concurrent access based on understanding the
>>> underlying algorithms used.
>>>
>>>>   Especially in software hundreds of thousands of lines of of C++ long.
>>>>
>>>> My Windows user interface is well over 500,000 lines of C++ code.
>>>
>>> Ah, windows.  Sigh.
>>>
>>> My current project at work is over 3 million lines of C++ code, and
>>> leverages 64 physical cores using over 120 threads (pthreads)
>>> with pretty much 100% utilization across all the cores.
>>
>> Nice !  Good job.
>>
>>> The nice thing about C++ is that if you do it right, all the
>>> locking is almost always encapsulated within a class (e.g.
>>> a class member and associated member functions), which naturally
>>> restricts the scope of the lock to within the class.
>>
>> It is always, "if you do it right".
> 
> If you decide to use threads. Make sure to learn about mutex and condvar 
> first! Then learn about embarrassingly parallel, where no mutex and 
> condvar are "necessarily" needed. Then ponder on lock-free.
> 
> Make sure to never have to use lock-free unless you absolutely have to!
> 
> Fwiw, I used to converse with David Butenhof back on 
> comp.programming.threads. Nice guy, and wrote a nice book to read before 
> you even go into C++ threads, perhaps. Well... ? I remember he was 
> pondering on writing another book, cooking with posix threads.
> 
> https://www.amazon.com/Programming-POSIX-Threads-David-Butenhof/ 
> dp/0201633922
> 
> :^) Real all of it, then ponder on how C++ is there ready willing and able.

I have four threads in my Windows user interface to make the startup 
faster.  But the variables do not cross the thread boundaries.

I have a copy of "C++ Concurrency in Action: Practical Multithreading" 
First Edition by Anthony Williams.  I have yet to read it though.
  
https://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/dp/1933988770/

Lynn

[toc] | [prev] | [next] | [standalone]

#123623

On 3/18/2026 10:33 PM, Lynn McGuire wrote:
[...]
> I have a copy of "C++ Concurrency in Action: Practical Multithreading" 
> First Edition by Anthony Williams.  I have yet to read it though.
> 
> https://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/ 
> dp/1933988770/

That is another good one. I used to converse with him quite a bit as well.

[toc] | [prev] | [next] | [standalone]

#123626

Am 19.03.2026 um 03:58 schrieb Chris M. Thomasson:

> If you decide to use threads. Make sure to learn about mutex and condvar 
> first! Then learn about embarrassingly parallel, where no mutex and 
> condvar are "necessarily" needed. Then ponder on lock-free.

Embarassingly parallel doesn't mean that no mutexes or
condvars are necessary, just that parallelizing was easy.

> Make sure to never have to use lock-free unless you absolutely have to!

There are only two definitive lock-free algorithms: lock-free stacks
and lock free queues. Lock-free stacks have a very rare usage. Lock
-free queues have the disadvantage that they have to be polled - which
is an absolute noo-go - and that can't be resized at runtime.
But when you have a queue guarded with a mutex and a condvar that's
mostly sufficient because there's rarely an overlap of the access
between producers and consumers since enqueuing and dequeuing usually
takes a minimum of computation time.
On Windows you could use deques. Although the Window's deques are not
very smart since they work with chunks of one element, they don't with-
draw every node which is being poped; instead they go to a standby list
so that they can be recycled very fast. This is allowed by the deque
-interface since it has a shrink_to_fit() call.
Libstdc++ (clang++ and g++ on all OSs except macOS) allocates the items
at chunks up zo 512 bytes. This makes mostly linear memory accesses and
allocations and deallocations to happen not often.
I wasn't satisfied with that solution so that I wrote a simple deque
-replacement. Acces is supported not by iterators (to much work) but
with a functional interface.

Here's the code:

#pragma once
#include <array>
#include <vector>
#include <memory>
#include <iterator>
#include <algorithm>
#include <concepts>
#include <cassert>
#include <optional>
#include "defer.hpp"
#include "ndi.hpp"
#include "cacheline.hpp"
#undef min

#if defined(__clang__)
	#pragma clang diagnostic push
	#pragma clang diagnostic ignored "-Wunqualified-std-cast-call"
	#pragma clang diagnostic ignored "-Wdangling-else"
	#pragma clang diagnostic ignored "-Wlogical-op-parentheses"
#endif

template<typename T>
struct xdeque
{
	xdeque();
	xdeque( xdeque<T> &&other ) noexcept;
	//xdeque( const xdeque<T> &other );
	~xdeque();
	xdeque<T> &operator =( xdeque<T> &&other ) noexcept;
	//xdeque<T> &operator =( const xdeque<T> &other ) noexcept;
	template<typename ... Params>
	T &emplace_back( Params &&... params );
	//void emplace_back_row( T &&value, size_t n );
	void pop_front() noexcept;
	std::optional<T> pop_back() noexcept;
	T &front() noexcept;
	const T &front() const noexcept;
	size_t size() const noexcept;
	bool empty() const noexcept;
	void clear() noexcept;
	void shrink_to_fit() noexcept;
	template<typename Consumer>
	void consume( Consumer consumer );
	template<typename Consumer>
	void consume( Consumer consumer ) const;
private:
	template<size_t N>
	struct n_chunk;
	template<size_t N>
	using n_chunk_ptr = std::unique_ptr<n_chunk<N>>;
	template<size_t N>
	struct n_chunk : std::array<tndi<T>, N>
	{
		n_chunk_ptr<N> next;
	};
	static constexpr ptrdiff_t
		XN_CHUNK = (ptrdiff_t)(512 - sizeof(n_chunk<1>)) / 
(ptrdiff_t)sizeof(T) + 1,
		N_CHUNK = XN_CHUNK >= 1 ? XN_CHUNK : 1;
	using chunk = n_chunk<N_CHUNK>;
	using chunk_ptr = n_chunk_ptr<N_CHUNK>;
	using chunk_ptrs = std::vector<chunk_ptr>;
	chunk_ptrs m_chunks;
	chunk_ptr m_firstStandby;
	using chunks_it = typename chunk_ptrs::iterator;
	using chunk_it = typename chunk::iterator;
	struct pointer
	{
		chunks_it itChunks;
		chunk_it itChunk;
	} m_begin, m_end;
	void shrinkChunks() noexcept;
#if !defined(NDEBUG)
	bool checkQueue() noexcept;
#endif
};

template<typename T>
void xdeque<T>::shrinkChunks() noexcept
{
	using namespace std;
	defer exitCheck( [&] { assert(checkQueue()); } );
	if( (size_t)(m_begin.itChunks - m_chunks.begin()) * 2 <= m_chunks.size() )
		return;
	std::move_iterator
		itBegin( m_begin.itChunks ),
		itEnd( m_chunks.end() );
	size_t toEnd = m_end.itChunks == m_chunks.end();
	m_chunks.resize( copy( itBegin, itEnd, m_chunks.begin() ) - 
m_chunks.begin() );
	m_begin.itChunks = m_chunks.begin();
	m_end.itChunks = m_chunks.end() - (!toEnd && m_chunks.size());
}

#if !defined(NDEBUG)
template<typename T>
bool xdeque<T>::checkQueue() noexcept
{
	if( m_begin.itChunks > m_end.itChunks )
		return false;
	if( m_begin.itChunks == m_chunks.end() )
		return m_end.itChunks == m_chunks.end();
	if( m_begin.itChunks == m_end.itChunks )
		return m_begin.itChunk < m_end.itChunk;
	if( m_end.itChunks != m_chunks.end() && (m_end.itChunk == 
(*m_end.itChunks)->begin() || m_end.itChunk == (*m_end.itChunks)->end()) )
		return false;
	if( m_begin.itChunk < (*m_begin.itChunks)->begin() || m_begin.itChunk 
 >= (*m_begin.itChunks)->end() )
		return false;
	return true;
}
#endif

template<typename T>
xdeque<T>::xdeque() :
	m_begin( m_chunks.begin(), chunk_it() ),
	m_end( m_chunks.end(), chunk_it() )
{
}

template<typename T>
xdeque<T>::xdeque( xdeque<T> &&other ) noexcept :
	m_chunks( std::move( other.m_chunks ) ),
	m_firstStandby( std::move( other.m_firstStandby ) ),
	m_begin( other.m_begin ),
	m_end( other.m_end )
{
	other.m_chunks.resize( 0 );
	other.m_begin.itChunks = other.m_chunks.begin();
	other.m_end.itChunks = other.m_chunks.end();
}

template<typename T>
xdeque<T> &xdeque<T>::operator =( xdeque<T> &&other ) noexcept
{
	using namespace std;
	m_chunks = move( other.m_chunks );
	m_firstStandby = move( other.m_firstStandby );
	m_begin = other.m_begin;
	m_end = other.m_end;
	other.m_chunks.resize( 0 );
	other.m_begin.itChunks = other.m_chunks.begin();
	other.m_end.itChunks = other.m_chunks.end();
	return *this;
}

template<typename T>
inline xdeque<T>::~xdeque()
{
	clear();
}

template<typename T>
template<typename ... Params>
T &xdeque<T>::emplace_back( Params &&... params )
{
	using namespace std;
	defer exitCheck( [&] { assert(checkQueue()); } );
	defer unchunk( [&]
		{
			if( m_end.itChunks == m_chunks.end() || m_end.itChunk > 
(*m_end.itChunks)->begin() )
				return;
			chunk_ptr lastEmpty = move( *m_end.itChunks );
			lastEmpty->next = move( m_firstStandby );
			m_firstStandby = move( lastEmpty );
			m_chunks.pop_back();
			assert(checkQueue());
		} );
	if( m_end.itChunks == m_chunks.end() )
	{
		bool wasEmpty = m_begin.itChunks == m_chunks.end();
		chunk_ptr append = move( m_firstStandby );
		if( append )
			m_firstStandby = move( append->next );
		else
			append = make_cl_unique<chunk>();
		defer unappend( [&]
			{
				append->next = move( m_firstStandby );
				m_firstStandby = move( append );
			} );
		size_t iBegin = m_begin.itChunks - m_chunks.begin();
		m_chunks.emplace_back( move( append ) );
		unappend.disable();
		m_begin.itChunks = m_chunks.begin() + iBegin;
		m_end.itChunks = m_chunks.end() - 1;
		m_end.itChunk = (*m_end.itChunks)->begin();
		if( wasEmpty )
			m_begin.itChunk = (*m_begin.itChunks)->begin();
	}
	T &value = m_end.itChunk->emplace( forward<Params>( params ) ... );
	unchunk.disable();
	if( ++m_end.itChunk == (*m_end.itChunks)->end() )
		m_end.itChunks = m_chunks.end();
	return value;
}

template<typename T>
void xdeque<T>::pop_front() noexcept
{
	if( empty() )
		return;
	defer shrink( [&] { shrinkChunks(); } );
	m_begin.itChunk++->destruct();
	auto remove = [this]
	{
		chunk_ptr firstEmpty = move( *m_begin.itChunks );
		firstEmpty->next = move( m_firstStandby );
		m_firstStandby = move( firstEmpty );
	};
	if( m_begin.itChunks != m_end.itChunks )
	{
		if( m_begin.itChunk != (*m_begin.itChunks)->end() )
			return;
		remove();
		if( ++m_begin.itChunks != m_chunks.end() )
			m_begin.itChunk = (*m_begin.itChunks)->begin();
		return;
	}
	if( m_begin.itChunk != m_end.itChunk )
		return;
	remove();
	m_begin.itChunks = m_chunks.end();
	m_end.itChunks = m_chunks.end();
}

template<typename T>
std::optional<T> xdeque<T>::pop_back() noexcept
{
	using namespace std;
	if( empty() )
		return nullopt;
	defer shrink( [&] { shrinkChunks(); } );
	pointer end = m_end;
	if( end.itChunks == m_chunks.end() )
	{
		end.itChunks = m_chunks.end() - 1;
		end.itChunk = (*end.itChunks)->end();
	}
	T value( move( *--end.itChunk ) );
	end.itChunk->destruct();
	m_end = end;
	bool singleChunk = m_end.itChunks == m_begin.itChunks;
	if( singleChunk && m_end.itChunk != m_begin.itChunk ||
		!singleChunk && m_end.itChunk != (*m_end.itChunks)->begin() )
		return value;
	chunk_ptr lastEmpty = move( *m_end.itChunks );
	lastEmpty->next = move( m_firstStandby );
	m_firstStandby = move( lastEmpty );
	m_chunks.pop_back();
	m_end.itChunks = m_chunks.end();
	if( singleChunk )
		m_begin.itChunks = m_chunks.end();
	return value;
}

template<typename T>
inline T &xdeque<T>::front() noexcept
{
	assert(m_begin.itChunks != m_chunks.end());
	return *m_begin.itChunk;
}

template<typename T>
inline const T &xdeque<T>::front() const noexcept
{
	assert(m_begin.itChunks != m_chunks.end());
	return *m_begin.itChunk;
}

template<typename T>
size_t xdeque<T>::size() const noexcept
{
	if( m_begin.itChunks == m_chunks.end() )
		return 0;
	size_t n = (m_end.itChunks - m_begin.itChunks) * N_CHUNK;
	if( m_end.itChunks != m_chunks.end() )
		n += m_end.itChunk - (*m_end.itChunks)->begin();
	n -= m_begin.itChunk - (*m_begin.itChunks)->begin();
	return n;
}

template<typename T>
inline bool xdeque<T>::empty() const noexcept
{
	return m_begin.itChunks == m_chunks.end();
}

template<typename T>
void xdeque<T>::clear() noexcept
{
	if( empty() )
		return;
	defer shrink( [&] { shrinkChunks(); } );
	for( ; ; )
	{
		chunk_it itChunkEnd;
		if( m_begin.itChunks != m_chunks.end() - 1 || m_end.itChunks == 
m_chunks.end() )
			itChunkEnd = (*m_begin.itChunks)->end();
		else
			itChunkEnd = m_end.itChunk;
		do
			m_begin.itChunk->destruct();
		while( ++m_begin.itChunk != itChunkEnd );
		chunk_ptr firstEmpty = move( *m_begin.itChunks );
		firstEmpty->next = move( m_firstStandby );
		m_firstStandby = move( firstEmpty );
		if( ++m_begin.itChunks == m_chunks.end() )
		{
			m_end.itChunks = m_chunks.end();
			return;
		}
		m_begin.itChunk = (*m_begin.itChunks)->begin();
	}
}

template<typename T>
inline void xdeque<T>::shrink_to_fit() noexcept
{
	m_firstStandby.reset();
}

template<typename T>
template<typename Consumer>
void xdeque<T>::consume( Consumer consumer )
{
	using namespace std;
	if( m_begin.itChunks == m_chunks.end() )
		return;
	defer shrink( [&] { shrinkChunks(); } );
	int ret = 1;
	do
	{
		size_t nChunk;
		if( m_begin.itChunks != m_end.itChunks )
			nChunk = (*m_begin.itChunks)->end() - m_begin.itChunk;
		else
			nChunk = m_end.itChunk - m_begin.itChunk;
		do
		{
			if constexpr( requires() { (int)consumer( move( **m_begin.itChunk ) 
); } )
				ret = (int)consumer( move( **m_begin.itChunk ) );
			else
				consumer( move( **m_begin.itChunk ) );
			if( ret < 0 )
				return;
			m_begin.itChunk++->destruct();
		} while( --nChunk && ret );
		if( nChunk )
			return;
		chunk_ptr emptied = move( *m_begin.itChunks );
		emptied->next = move( m_firstStandby );
		m_firstStandby = move( emptied );
		if( m_begin.itChunks != m_chunks.end() - 1 )
			m_begin.itChunk = (*++m_begin.itChunks)->begin();
		else
		{
			m_begin.itChunks = m_chunks.end();
			m_end.itChunks = m_chunks.end();
			return;
		}
	} while( ret );
}

template<typename T>
template<typename Consumer>
void xdeque<T>::consume( Consumer consumer ) const
{
	const_cast<xdeque<T> &>( *this ).consume( [&]( const T &value ) { 
return observer( value ); } );
}

#if !defined(NDEBUG)
template
struct xdeque<int>;
#endif

#if defined(__clang__)
	#pragma clang diagnostic pop
#endif

[toc] | [prev] | [next] | [standalone]

#123627

On 3/19/2026 2:40 AM, Bonita Montero wrote:
> Am 19.03.2026 um 03:58 schrieb Chris M. Thomasson:
> 
>> If you decide to use threads. Make sure to learn about mutex and 
>> condvar first! Then learn about embarrassingly parallel, where no 
>> mutex and condvar are "necessarily" needed. Then ponder on lock-free.
> 
> Embarassingly parallel doesn't mean that no mutexes or
> condvars are necessary, just that parallelizing was easy.

Notice the quotes around "necessarily" ? :^)



> 
>> Make sure to never have to use lock-free unless you absolutely have to!
> 
> There are only two definitive lock-free algorithms: lock-free stacks
> and lock free queues. 

Oh really? Sigh.

[...]

[toc] | [prev] | [next] | [standalone]

#123625

Am 18.03.2026 um 22:41 schrieb Lynn McGuire:

> It is always, "if you do it right".

Handling locks is mostly very easy. But sometimes it is necessary
to handle the locks efficiently. And sometimes that's very tricky.

[toc] | [prev] | [next] | [standalone]

#123624

On 18/03/2026 22:24, Scott Lurndal wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 3/18/2026 1:09 PM, Bonita Montero wrote:
>>> Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
>>>
>>>> If C++ is too complex for a programmer then the programmer is not
>>>> a good programmer.
>>>
>>> I'm a good C++ programmer but I admit that C++ is much less readable
>>> as for example Rust. And both languages server the same purpose. But
>>> I still like C++.
>>>
>>>> The only exception to that is multiple thread software. That stuff
>>>> is dadgum complicated. But the multiple thread software is not used
>>>> very often in my circles.
>>>
>>> Most MT-algoritms are easy (embarassingly parallel).
>>
>> Spinning off threads is easy.  Deciding which variables to mutex is not.
> 
> As someone with four decades of multitheaded programming experience
> at both the lowest levels (OS) and highest levels (applications),
> I strongly disagree.
> 
> It's very easy to determine whether a particular datum is
> subject to concurrent access based on understanding the
> underlying algorithms used.
> 

It can be easy to determine what data needs protected by mutexes, but 
not nearly as easy to determine when the mutexes should be locked and 
unlocked in sequences that are maximally efficient.  If a thread takes a 
lock, and is doing two different things with the data, should it release 
the lock and re-take it in the middle?  Doing so costs time for that 
thread, as the release and re-lock is not free.  But /not/ doing so 
could hinder progress for another thread.  Then you have questions about 
how fine-grained your mutexes should be, and how to coordinate cases 
where you need multiple mutexes.  And of course you have the bigger 
architectural questions - should the data be shared and locked by a 
mutex, or use a message queue, or atomics, or duplicate copies of the 
data, or some other sharing and synchronisation solution?

So yes, determining what data to protect is usually easy.  Determining 
how best to do that is the fun part.

[toc] | [prev] | [next] | [standalone]

#123628

On 3/19/2026 2:20 AM, David Brown wrote:
> On 18/03/2026 22:24, Scott Lurndal wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> On 3/18/2026 1:09 PM, Bonita Montero wrote:
>>>> Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
>>>>
>>>>> If C++ is too complex for a programmer then the programmer is not
>>>>> a good programmer.
>>>>
>>>> I'm a good C++ programmer but I admit that C++ is much less readable
>>>> as for example Rust. And both languages server the same purpose. But
>>>> I still like C++.
>>>>
>>>>> The only exception to that is multiple thread software. That stuff
>>>>> is dadgum complicated. But the multiple thread software is not used
>>>>> very often in my circles.
>>>>
>>>> Most MT-algoritms are easy (embarassingly parallel).
>>>
>>> Spinning off threads is easy.  Deciding which variables to mutex is not.
>>
>> As someone with four decades of multitheaded programming experience
>> at both the lowest levels (OS) and highest levels (applications),
>> I strongly disagree.
>>
>> It's very easy to determine whether a particular datum is
>> subject to concurrent access based on understanding the
>> underlying algorithms used.
>>
> 
> It can be easy to determine what data needs protected by mutexes, but 
> not nearly as easy to determine when the mutexes should be locked and 
> unlocked in sequences that are maximally efficient.  If a thread takes a 
> lock, and is doing two different things with the data, should it release 
> the lock and re-take it in the middle? 

Shit man. TRY to never execute a call back into unknown user code while 
holding a lock. Unless, well, shit. never... ;^) I have had to debug 
nightmare scenarios! Ouch.



  Doing so costs time for that
> thread, as the release and re-lock is not free.  But /not/ doing so 
> could hinder progress for another thread.  Then you have questions about 
> how fine-grained your mutexes should be, and how to coordinate cases 
> where you need multiple mutexes.  And of course you have the bigger 
> architectural questions - should the data be shared and locked by a 
> mutex, or use a message queue, or atomics, or duplicate copies of the 
> data, or some other sharing and synchronisation solution?
> 
> So yes, determining what data to protect is usually easy.  Determining 
> how best to do that is the fun part.
> 
> 

[toc] | [prev] | [next] | [standalone]

#123534

On 09/03/2026 07:27, Marcel Mueller wrote:

> C++ has become too complex for many programmers. This is an economic
> disadvantage from the business point of view. So people move to a newer,
> simpler language with less features. Until it becomes too complex, of
> course. New hardware (to compensate for performance) is always cheaper
> that programmers, who write efficient code.


Not to mention the compiler can achieve greater efficiency from
constraints. All that dance formalism all over memory is silly.

C++ has the advantage of an international standard. Rust and programs
expressed only in Rust might not be permitted in some contexts because
of that lack but then why not Ada instead of Rust?

-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

[toc] | [prev] | [next] | [standalone]

#123560

Lynn McGuire <LynnMcGuire5@GMail.com> wrote:
|-------------------------------------------------------------------------|
|"“Is C++ Dead?”                                                          |
|   https://deepengineering.substack.com/p/is-c-dead                      |
|                                                                         |
|“[. . .]                                                                 |
|[ . .] C++ is the main                                                   |
|programming language used in many critical systems, including hospitals, |
|cars, and airplanes. [. . .]                                             |
|[. . .]                                                                  |
|[. ..]”"                                                                 |
|-------------------------------------------------------------------------|

Oh dear!
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

[toc] | [prev] | [next] | [standalone]

#123576

On 12/03/2026 19:46, Nioclás Pól Caileán de Ghloucester wrote:
> Lynn McGuire <LynnMcGuire5@GMail.com> wrote:
> |-------------------------------------------------------------------------|
> |"“Is C++ Dead?”                                                          |
> |   https://deepengineering.substack.com/p/is-c-dead                      |
> |                                                                         |
> |“[. . .]                                                                 |
> |[ . .] C++ is the main                                                   |
> |programming language used in many critical systems, including hospitals, |
> |cars, and airplanes. [. . .]                                             |
> |[. . .]                                                                  |
> |[. ..]”"                                                                 |
> |-------------------------------------------------------------------------|
> 
> Oh dear!
> (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)


Yes it's terrifying.

There are industry standard restrictions in place, organisation
restrictions, project restrictions, and requirements from customers
often list specific segments of code that must be used as a consequence
of previous failures where a fix was decided was thereafter a must (I
suppose that's just for liability's sake, it takes more than mere usage
of a code segment to confer safety consequences on a project's outputs).

Processes use lots of tools, testing and review methods, it's not just
coding and job-done. There are literally dozens of studious, expensive
steps and that's just in automotive, the lowliest of the fields
quoted-in above. Training and other knowledge-management and
habit-forming techniques are applicable throughout.

It's still hair-raising despite that. I worked in automotive software
engineering for a time and it gave me fewer hairs to raise and I didn't
stay long enough to get combed into an automotive software engineer -
just long enough to recognise the incredible breadth and depth of
problems, expertise, focus, risk-management, steadfastness, pushback,
pace, etc... If you meet an engineer in those fields do not be surprised
that they earn more than you.

Safe software engineering is almost nothing to do with C++; I suspect
C++ is used for reasons of historical evolution of assurance combined
with matters of the employment market rather than any other reasons. I
feel very few people understand anything of what makes safety-critical
software engineering safe and it has almost nothing to do with the
language chosen for the encoding of machine instructions because
ultimately it's a process of translation of /requirements/ to machine
instructions. In fact it's a process of translation of goals and market
gambles into requirements even before that.

AI in those fields has unique challenges other than mere high-level
system control-logic encoding which C++ /does/ /NOT/ lend itself to, I
doubt Ada does either. Test discipline is very important there and I
would expect if I went back by now I'd find no low-level coding tools
used for AI project engineering processes (only for the tools used).



-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

[toc] | [prev] | [next] | [standalone]

#123578

In comp.lang.ada Tristan Wibberley
<tristan.wibberley+netnews2@alumni.Manchester.ac.UK> wrote:
|----------------------------------------------------------------------|
|"[. . .] I worked in automotive software                              |
|engineering for a time and it gave me fewer hairs to raise"           |
|----------------------------------------------------------------------|

Dear Doctor Wibberley,

What does this mean?

|----------------------------------------------------------------------|
|" and I didn't                                                        |
|stay long enough to get combed into an automotive software engineer - |
|just long enough to recognise the incredible breadth and depth of     |
|problems, expertise, focus, risk-management, steadfastness, pushback, |
|pace, etc..."                                                         |
|----------------------------------------------------------------------|

I do not work on cars, but perhaps Doctor Wibberley gives cars workers
too much credit. A car-software programmer who is worryingly ignorant
of the compiler that he uses (which I used to use) disturbs me. I know
a dangerous risk taker who works on automotive electronics, who
falsely professes to be an electronic engineer.

I encountered C# cars workers who dangerously misbehave.

An electronic-engineering lecturer said that BMW or Mercedes
outsources cars work to him, but that he is too poor to buy a car from
this manufacturer such that it is not as big a problem to him if these
cars are not safe.

|----------------------------------------------------------------------|
|"Safe software engineering is almost nothing to do with C++;"         |
|----------------------------------------------------------------------|

Safe software has nothing to do with C++. Software engineering has
nothing to do with C++.

|----------------------------------------------------------------------|
|" I suspect                                                           |
|C++ is used for reasons of historical evolution of assurance combined |
|with matters of the employment market rather than any other reasons." |
|----------------------------------------------------------------------|

C++ is used because managers are anti-engineering chancers. C++ is
used instead of plain C because Bjarne Stroustrup decides to win over
C hackers by choosing against good
decisions. Cf. \cite{The_Design_and_Evolution_of_C++}.

@book{The_Design_and_Evolution_of_C++,
 author = {Bjarne Stroustrup},
 title = {{The Design and Evolution of C++}},
 edition = {first printing of the first},
 year = {1994},
 isbn = {0201543303},
 publisher = {Addison-Wesley},
 address = {},
 }

C is used because 1 of the 1st non-country non-university users of
computers made C.

Anti-engineering chancers managers choose C++ because many persons
enroll in a C++ course and few persons enroll in Ada courses. These
managers do not appreciate that engineers instead of bugs makers use
Ada instead of C++, such that the big supply of C++ hackers is not a
benefit. Dr. Rainer Gerlich (
HTTPS://WWW.GSSE.biz/experience/cv_Rainer_Gerlich.html
) and Doctor Richard Riehle fail to make these idtiotic managers act
intelligently. You can easily find such complaints by Richard Riehle
in the Team-Ada LISTSERV and in comp.lang.ada.

|----------------------------------------------------------------------|
|" I                                                                   |
|feel very few people understand anything of what makes safety-critical|
|software engineering safe"                                            |
|----------------------------------------------------------------------|

True.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

[toc] | [prev] | [next] | [standalone]

#123580

On 15/03/2026 13:35, Nioclás Pól Caileán de Ghloucester wrote:
> In comp.lang.ada Tristan Wibberley
> <tristan.wibberley+netnews2@alumni.Manchester.ac.UK> wrote:
> |----------------------------------------------------------------------|
> |"[. . .] I worked in automotive software                              |
> |engineering for a time and it gave me fewer hairs to raise"           |
> |----------------------------------------------------------------------|
> 
> Dear Doctor Wibberley,

I'm not a Dr., just a Mr.

You can call me Tristan on usenet, since all s***slanging forums are
necessarily informal.


> What does this mean?

It refers to "hair-raising" - the effect of an exciting experience - and
hair loss, the effect of a stressfully exciting experience.



> |----------------------------------------------------------------------|
> |" and I didn't                                                        |
> |stay long enough to get combed into an automotive software engineer - |
> |just long enough to recognise the incredible breadth and depth of     |
> |problems, expertise, focus, risk-management, steadfastness, pushback, |
> |pace, etc..."                                                         |
> |----------------------------------------------------------------------|
> 
> I do not work on cars, but perhaps Doctor Wibberley gives cars workers
> too much credit. A car-software programmer who is worryingly ignorant
> of the compiler that he uses (which I used to use) disturbs me. I know
> a dangerous risk taker who works on automotive electronics, who
> falsely professes to be an electronic engineer.
> 
> I encountered C# cars workers who dangerously misbehave.

I thought lots of people were very professional and knowledgeable. Lots
of Germans in particular.


> An electronic-engineering lecturer said that BMW or Mercedes
> outsources cars work to him, but that he is too poor to buy a car from
> this manufacturer ...

I earned enough to buy such (but I didn't buy one because I'm not a
carfool, I'm a steakfool). The location manager (who was not a chancer)
had a Mazerati but also he had been in Aerospace before. One of the best
engineers (a man of many skills) had old second-hand cars, sometimes
little runabouts and sometimes coupe's - he does satellite testing work now.


> ... such that it is not as big a problem to him if these
> cars are not safe.
> 
> |----------------------------------------------------------------------|
> |"Safe software engineering is almost nothing to do with C++;"         |
> |----------------------------------------------------------------------|
> 
> Safe software has nothing to do with C++. Software engineering has
> nothing to do with C++.

heh, nice one.


> |----------------------------------------------------------------------|
> |" I suspect                                                           |
> |C++ is used for reasons of historical evolution of assurance combined |
> |with matters of the employment market rather than any other reasons." |
> |----------------------------------------------------------------------|
> 
> C++ is used because managers are anti-engineering chancers.

That is true. Group leaders in Matrix Management systems sometimes
exist. I bet they are better.


> C++ is
> used instead of plain C because Bjarne Stroustrup decides to win over
> C hackers by choosing against good
> decisions. Cf. \cite{The_Design_and_Evolution_of_C++}.

C++ is used over C because /some/ of its features can be easily used to
reduce plain old boilerplate and spend less time - both of which afford
better quality work. Some of its expressions are eliminated as I mentioned.


> C is used because 1 of the 1st non-country non-university users of
> computers made C.

Like I said: history of the programming market. C/C++ is used where
autosar isn't a good choice.


> Anti-engineering chancers managers choose C++ because many persons
> enroll in a C++ course and few persons enroll in Ada courses.

Yes. For what ever reason they choose humans to map design and
requirements to imperative code and the humans that think they know C++
are readily available.


> These
> managers do not appreciate that engineers instead of bugs makers use
> Ada instead of C++, such that the big supply of C++ hackers is not a
> benefit.

As I mentioned, it is not the coding that makes things safe, but the
wider process. I know that there are lots and lots of Germans working
studiously and cynically toward excellent components.

I suspect that once upon a time they used linker+c but boilerplate
reduction and the gradual obsolescence of linker scripts to control
memory layout lead to C++ and custom layout tools.


-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

[toc] | [prev] | [next] | [standalone]

#123586

In comp.lang.ada Tristan Wibberley
<tristan.wibberley+netnews2@alumni.Manchester.ac.UK> wrote:
|------------------------------------------------------------------------|
|"I thought lots of people were very professional and knowledgeable. Lots|
|of Germans in particular."                                              |
|------------------------------------------------------------------------|

Dear Tristan,

Lots of people are very professional and knowledgeable. They may
include Germans.

|------------------------------------------------------------------------|
|"[. . .] working                                                        |
|studiously and cynically toward excellent components."                  |
|------------------------------------------------------------------------|

I think that this sentence does not need "cynically".
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

[toc] | [prev] | [next] | [standalone]

#123593

On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:

> I suspect that once upon a time they used linker+c but boilerplate
> reduction and the gradual obsolescence of linker scripts to control
> memory layout lead to C++ and custom layout tools.

Where is there an industrial-strength linker that doesn’t support
scripts? GNU ld certainly does, and that is heavily used in
cross-platform and embedded scenarios. I think the GNU tools have
become dominant in that whole segment.

Of course you need custom build scripts as well, to get things into
the right format for a bootloader, or even to build the bootloader.

[toc] | [prev] | [next] | [standalone]

#123603

On 15/03/2026 22:23, Lawrence D’Oliveiro wrote:
> On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
> 
>> I suspect that once upon a time they used linker+c but boilerplate
>> reduction and the gradual obsolescence of linker scripts to control
>> memory layout lead to C++ and custom layout tools.

eh, well, they're were still there internal to the build processes when
I was working in automotive but they were often machine-translations
from other sources, even via attributes and toolchain flags (because
command-orientation is a common human trait).


-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

[toc] | [prev] | [next] | [standalone]

#123605

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:
>On 15/03/2026 22:23, Lawrence D’Oliveiro wrote:
>> On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
>> 
>>> I suspect that once upon a time they used linker+c but boilerplate
>>> reduction and the gradual obsolescence of linker scripts to control
>>> memory layout lead to C++ and custom layout tools.
>
>eh, well, they're were still there internal to the build processes when
>I was working in automotive but they were often machine-translations
>from other sources, even via attributes and toolchain flags (because
>command-orientation is a common human trait).
>

There is still a lot of standalone (sans-OS) code written
in both C and C++, and linker scripts are far from obsolete.

[toc] | [prev] | [next] | [standalone]

#123609

On 16/03/2026 15:58, Scott Lurndal wrote:
> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:
>> On 15/03/2026 22:23, Lawrence D’Oliveiro wrote:
>>> On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
>>>
>>>> I suspect that once upon a time they used linker+c but boilerplate
>>>> reduction and the gradual obsolescence of linker scripts to control
>>>> memory layout lead to C++ and custom layout tools.
>>
>> eh, well, they're were still there internal to the build processes when
>> I was working in automotive but they were often machine-translations
>>from other sources, even via attributes and toolchain flags (because
>> command-orientation is a common human trait).
>>
> 
> There is still a lot of standalone (sans-OS) code written
> in both C and C++, and linker scripts are far from obsolete.
> 

"non-hosted" C and C++.

In general, linker scripts are far from obsolete. In the field (at least
the growth segment of ADAS), specialisation was obsoleting them
progressively to the point lots and lots of people had never heard of
them. They had product-architecture-specific toolchain interfaces.

-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web