Friday, March 3, 2023

Digest for comp.lang.c++@googlegroups.com - 18 updates in 5 topics

Muttley@dastardlyhq.com: Mar 03 09:53AM

On Thu, 2 Mar 2023 11:08:54 -0800 (PST)
>What, specifically, does that document say about dereferencing null pointer=
>s
>and adding non-zero quantities to null pointers?
 
Whooosh....
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 03 12:57PM -0800

On 2/21/2023 1:41 PM, Paavo Helde wrote:
 
>> 100 threads? I am wondering what they are all doing. ;^)
 
> Mostly waiting for each other, or for external events.
 
Waiting for work to be pushed into a distributed work queue? I am
assuming that "external events" are io, file, mouse
clicks/movements/ect...?
 
 
> physical CPU cores, or somewhat higher if there is hyperthreading. So
> the number of actively running threads is usually less than 20 or 30,
> the rest are waiting.
 
Fwiw, back when I was creating some custom server software (nt4.0), I
would start off with 2 threads per cpu. Then the server would go into
stress testing mode, and try to self calibrate itself to the current
system it is running on. This was done during the setup process.
 
 
> I'm sure it ought be possible to reduce the number of needed threads
> several times by code reorganization, but the cost/benefit ratio does
> not seem to encourage this work.
 
Fair enough. :^)
Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 03 09:44PM


> If functions are functions then the bits on function entry define the
> state of the bits on function exit, and if they match, the function is
> correct.
 
I think the first "functions" refers to C function but second does not
refer to either mathematical functions nor, say, functions in Haskell so
I think you are talking about what I once referred to as
Malcolm-functions. Unfortunately I don't remember enough about what you
mean by the term to do anything but agree with the consequent.
 
> much slower for any likely N than a naive O(N squared) function. However
> normally you have to either be perverse or to be using a weird and wonderful
> recasting of the problem to do this.
 
I think you are agreeing: that a specification should be taken to be,
loosely speaking, minimal.
 
> something (execution speed, clarity, size of data accepted, code size)
> before it is "to specification". But maybe we can say that it mustn't
> grossly pessimise anything.
 
Yes. That was my point. Your example did not meet the specification
because is was perversely not a minimal implementation.
 
> teacup would meet the instruction. But not a sporting trophy filled
> with tea. I'd legitimately complain that my instructions had been
> interpreted perversely.
 
Yes. I think we are having an agreement.
 
--
Ben.
Jivanmukta <jivanmukta@poczta.onet.pl>: Mar 03 05:11PM +0100

Uczę się C++.
Jeżeli zamiast pisać:
 
class C {
int m;
public:
C(int v) : m(v) {}
};
 
możemy pisać:
 
class C {
int m;
public:
C(int v) { m = v; }
};
 
to po co w ogóle jest lista inicjalizacyjna w kontruktorze?
 
--
Ta wiadomość e-mail została sprawdzona pod kątem wirusów przez oprogramowanie antywirusowe AVG.
www.avg.com
Paavo Helde <eesnimi@osa.pri.ee>: Mar 03 07:05PM +0200

03.03.2023 18:11 Jivanmukta kirjutas:
>     C(int v) { m = v; }
> };
 
> to po co w ogóle jest lista inicjalizacyjna w kontruktorze?
 
Antud näite puhul ei ole erilist vahet, mida kasutada, aga üldiselt
tuleks initsialiseerimiseks kasutada initsialiseerijate loendit, selle
jaoks on see mõeldud.
Christian Gollwitzer <auriocus@gmx.de>: Mar 03 09:50PM +0100

Am 03.03.23 um 18:05 schrieb Paavo Helde:
 
> Antud näite puhul ei ole erilist vahet, mida kasutada, aga üldiselt
> tuleks initsialiseerimiseks kasutada initsialiseerijate loendit, selle
> jaoks on see mõeldud.
 
I can't read the Finish one, but the Polish question (probably
accidentally) asks what is the difference between the initializer and
what is it good for, if we can simply use the assignemnt.
 
The answer is that in some cases, there is a difference between calling
the constructor and assigning. E.g.
 
std::vector<int> v(30);
 
vs.
 
std::vector<int> v;
 
v = ... ; // now what?
 
In this case it might simply be inefficient, in other cases impossible
to assign - e.g. with a reference variable.
 
 
Christian
Bonita Montero <Bonita.Montero@gmail.com>: Mar 03 07:51PM +0100

Use this thread-queue:
 
#pragma once
#include <deque>
#include <mutex>
#include <condition_variable>
#include <utility>
#include <concepts>
#include <list>
#include <deque>
#include "xscope.h"
 
template<typename Entity, typename Allocator = std::allocator<Entity>>
struct thread_queue
{
thread_queue();
explicit thread_queue( Allocator const &alloc );
thread_queue( thread_queue const & ) = delete;
thread_queue( thread_queue &&other );
thread_queue &operator =( thread_queue const & ) = delete;
thread_queue &operator =( thread_queue &&other );
bool empty() const;
size_t size() const;
void shrink_to_fit();
void clear();
template<typename ... Args>
#if defined(__cpp_concepts)
requires std::is_constructible_v<Entity, Args ...>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)