Tuesday, September 27, 2022

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

Juha Nieminen <nospam@thanks.invalid>: Sep 27 06:26AM

> to respond to everything. I have several users filtered out by
> the equivalent of a killfile. You are bypassing my killfile by
> posting responses. Please stop.
 
Which pretty much makes killfiles useless. I have never understood,
and will never understand, why people use them. They are useless.
The only thing they do is that they break threads and make them
disjointed. And if you just keep adding people to your killfile
because they keep responding to people in your killfile, or to
people responding to those, or to people responding to those...
sooner or later you'll have almost everybody in your killfile
and see nothing.
 
I honestly cannot see the point.
Juha Nieminen <nospam@thanks.invalid>: Sep 27 06:36AM


> First because my private C compiler doesn't support them, so I have to
> switch to another when some code uses them, or edit it to remove the
> dependency.
 
That's a rather strange reason not to like them.
 
> this, but also people feel free mix up the order, just because they can.
> So you can't as easily see the patterns like those in the first example,
> or they can be misleading unless you keep an eye on those names.
 
You are assuming that the struct is directly visible there and extremely
obvious what it contains. It's not always that obvious. For example, this
is a very typical way to register a device driver in the Linux kernel
(directly from the source codes):
 
//----------------------------------------------------------
static struct platform_driver ftgpio_gpio_driver = {
.driver = {
.name = "ftgpio010-gpio",
.of_match_table = of_match_ptr(ftgpio_gpio_of_match),
},
.probe = ftgpio_gpio_probe,
.remove = ftgpio_gpio_remove,
};
 
builtin_platform_driver(ftgpio_gpio_driver);
//----------------------------------------------------------
 
What does that 'platform_driver' struct look like? Does it contain member
variables other than those being initialized here? Are they in this
particular order? I have no idea. And I don't have to have an idea.
 
And consider how much more readable the above initialization is.
It pretty much documents itself.
David Brown <david.brown@hesbynett.no>: Sep 27 11:21AM +0200

On 26/09/2022 16:31, Juha Nieminen wrote:
> function at the beginning. (If I'm not mistaken, this is actually one
> of the style requirements of the Linux kernel code. Although I'm not
> sure if it's outright required or just recommended.)
 
Somewhat bizarrely, the coding style for the Linux kernel allows
(AFAIUI) very complex initialisation of the variables at the start of a
function, but no mixing of declarations and statements. So it partially
encourages the "don't define your variables until you have good data for
initialisation" style, but by disallowing statements between the
declarations it pushes people towards unwieldy and overly complex
expressions.
 
I assume this is because until recently, the kernel was based on C90 -
but it was C90 with gcc extensions. The gcc "gnu90" pseudo-standard
supports mixed declarations and statements, just like C99.
 
I understand that some people like a clean list of uninitialised
variable declarations at the start of a function, much like in Pascal.
I don't think it is a good way to code, but people have their
preferences. The Linux kernel style looks to me like a mongrel hybrid
that does not lead to clean and clear code.
 
 
> When you have seen and programmed with designated initializers, however,
> you really start to appreciate them.
 
I /do/ use them, and appreciate them - but I don't find them to be such
a revolution that you apparently do. Maybe that's just a matter of the
kind of code I write compared to the kind of code you write.
 
 
> And C++20 ruined one of the best aspects of them: The fact that you don't
> need to know the order in which the member variables have been defined
> in the struct.
 
I agree with that. It strikes me as a strange requirement - just like
the insistence that initialisers in a constructor match the declaration
order. Perhaps there is some clear, logical reason for that restriction
(and perhaps someone could tell me what it is?).
 
> the struct might have been chosen for space efficiency, while in the
> initialization you can use a more logical order of initialization by
> grouping related values together.)
 
Yes.
David Brown <david.brown@hesbynett.no>: Sep 27 11:27AM +0200

On 26/09/2022 17:04, rbowman wrote:
>> plenty of call for them in C++).
 
> I'd go with the ability to place declarations close to the code using
> them also. Throwing in curly braces worked but it wasn't too elegant.
 
That is one of the important benefits of being able to mix declarations
and statements, so I think we agree on our favourite feature.
 
It is not the only benefit, however. Declaring your variable only when
you have something useful to put in it lets you make many such variables
"const" - then both the programmer and the compiler know it is not going
to change. It makes adding new local variables "cheap" - so instead of
re-using a single "int temp;" variable in a dozen places in the
function, you have many const variables that do one thing, with one
name, and you always know exactly what they are.
Juha Nieminen <nospam@thanks.invalid>: Sep 27 01:26PM

> the insistence that initialisers in a constructor match the declaration
> order. Perhaps there is some clear, logical reason for that restriction
> (and perhaps someone could tell me what it is?).
 
I understand that C++ wants member variables to be initialized in strict
order of declaration (which in the case of C++ in particular can make
quite a difference if those initializations have side effects), but when
it comes to designated initializers I really think that the C++20 standard
should have allowed any order in the initialization list, and simply
declared that if the initializers are not specified in the same order
as the members have been declared, the behavior is "implementation-defined".
In other words, if the initializers are listed in the correct order, the
behavior is well-defined, but if they are in another order it's up to the
compiler whether it will reorder them to match the declaration order, or
initialize the members in the order specified in the list. (In other
words, if the initializers have side effects, you can't rely on them
being done in any particular order.)
 
(Another possibility is that it could have made an exception with POD
types, and allow out-of-order initialization with those.)
rbowman <bowman@montana.com>: Sep 27 08:11AM -0600

On 9/27/22 03:27, David Brown wrote:
> re-using a single "int temp;" variable in a dozen places in the
> function, you have many const variables that do one thing, with one
> name, and you always know exactly what they are.
 
I'm not fond of 'const'. We have a lot of legacy code where the
programmers used it inappropriately so you wind up casting it away. I
think they saw it in one declaration and decided it was always needed.
Used correctly it's valuable
Bo Persson <bo@bo-persson.se>: Sep 27 04:53PM +0200

On 2022-09-27 at 15:26, Juha Nieminen wrote:
> being done in any particular order.)
 
> (Another possibility is that it could have made an exception with POD
> types, and allow out-of-order initialization with those.)
 
The thing is that destructors are supposed to be called in the reverse
order of construction (to allow "unchaining" any dependencies again).
This becomes really messy if we allow different construction order in
different places of the program.
 
I belive the strictness here is a do-the-right-thing attempt, avoiding
the constructor initializer list reordering that we have always had.
When adding a new feature, try to avoid the old mistakes!
Richard Damon <Richard@Damon-Family.org>: Sep 26 08:42PM -0400

On 9/26/22 2:53 PM, JiiPee wrote:
 
> And then you call it with your lenght:
 
> calculate(1110, &(str->length));
 
> thinking that its only reading the lenght. but its changing it also.
 
In C, a function taking a pointer is likely going to change it, why else
use a pointer.
 
This makes the intent fairly clear.
 
C++, allowing functions have non-const reference parameters means it is
harder to tell by looking at a call site, what are outputs.
 
This is handy at times, but means you need to think of things differently.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 26 05:54PM -0700


> In C, a function taking a pointer is likely going to change it, why
> else use a pointer.
 
> This makes the intent fairly clear.
 
And if the function doesn't intend to change it, it should be a
pointer-to-const (which makes good sense if copying the value would be
unreasonably expensive or would have side effects).
 
> C++, allowing functions have non-const reference parameters means it
> is harder to tell by looking at a call site, what are outputs.
 
And again, you can use a const reference if you don't want to change the
value. If a parameter is a non-const pointer (in C or C++) or a
non-const reference (in C++), you should assume that the referenced
object may be modified. If it isn't, complain to the person who's
responsible for the function.
 
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Muttley@dastardlyhq.com: Sep 27 09:36AM

On Mon, 26 Sep 2022 17:54:20 -0700
 
>And if the function doesn't intend to change it, it should be a
>pointer-to-const (which makes good sense if copying the value would be
>unreasonably expensive or would have side effects).
 
If the function takes a pointer to a struct then you can't really tell if it
will change the contents since its a lot more efficient to pass a pointer than
copy the whole structure onto the stack and for passing arrays you don't have
a choice except pass by reference (unless you embed in a struct) in which case
a pointer to const might be useful.
 
HOWEVER. If it requires a pointer to a primitive type then the function will
almost certainly be changing it otherwise as someone else wrote, why bother
requiring a pointer as they'll be no efficiency gains.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 27 03:28PM +0100


> Richard Damon <Richard@Damon-Family.org> writes:
<cut>
> non-const reference (in C++), you should assume that the referenced
> object may be modified. If it isn't, complain to the person who's
> responsible for the function.
 
The trouble is you can't tell that you might have to check the function
declaration by looking at the call. f(a, &b) tells me I might want to
look at f's declaration to see if the second parameter is a pointer to
const or not, but f(a, b) does not. Either a or b might be modified and
I have to check f's declaration every time.
 
--
Ben.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 05:34PM -0700

On 9/24/2022 8:14 AM, Bonita Montero wrote:
> If you don't use STM you use the kernel and the atomic operation
> never fails. Try that out yourself: atomics beyond native types
> can fail, so you have STM.
 
Huh?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 05:47PM -0700

On 9/26/2022 4:39 AM, David Brown wrote:
>> (in other words, it implements some sort of mutual exclusion).
 
> And that's not quite right either.
 
> "Atomic" means that accesses are indivisible.
 
Exactly.
 
 
> As many threads as you
> want can read or write to the data at the same time - the defining
> feature is that there is no possibility of a partial access succeeding.
[...]
 
Atomic to me, say a RMW sequence:
 
<pseudo-code>
________________________
int g_value = 0;
 
// A RMW operation
int
fetch_add_busted(
int& origin,
) {
int result = origin;
origin = result + 1;
return result;
}
________________________
 
 
Well, there are problems with this. Its not atomic, and can give garbage
in multi-threaded environments... So, we can lock it up, using a hashed
based mutex algorithm (hashing on address into a table of mutexes). I
posted one in the past:
 
<pseudo-code>
________________________
int g_value = 0;
 
// A RMW operation
int
fetch_add(
int& origin,
) {
hash_lock(&origin);
int result = origin;
origin = result + 1;
hash_unlock(&origin);
return result;
}
________________________
 
Okay, we are atomic. There are other ways to get this done.
 
https://en.cppreference.com/w/cpp/atomic/atomic/fetch_add
 
;^)
scott@slp53.sl.home (Scott Lurndal): Sep 27 02:17PM

>________________________
 
>Okay, we are atomic. There are other ways to get this done.
 
>https://en.cppreference.com/w/cpp/atomic/atomic/fetch_add
 
GCC has had built-ins to generate atomic accesses (e.g. __sync_fetch_and_add)
for many years now.
 
On intel/amd these generate lock prefixes, on other architectures
with atomic support (e.g. ARMv8 LDADD, et alia) those instructions
will be generated.
FBInCIAnNSATerroristSlayer <FBInCIAnNSATerroristSlayer@yahoo.com>: Sep 27 02:58AM -0700

KEVIN SVENSON BELONGS to the EVIL CIA NSA Shadow US Govt Psychopaths who
are SECRETLY CHIPPING and TORTURING MILLIONS of Americans with
Neuroweapons, DEWs and AI.
 
 
 
Time is running out. Human filth hardly have 20 years before EVERY
AMERICAN and HUMAN on this planet will be "HORRIFICALLY OPPRESSED" by
the EVIL CIA NSA FBI DHS MI6 MI5 ASIS ASIO CSIS Psychopaths with
Supercomputer AI "FOREVER".
 
 
This EVIL motherfucker "Kevin Svenson" belongs to the EVIL SHADOW US
Govt Psychopaths former potuses, congressmen, senators WARNED the
american public about. This EVIL psychopath KNOWS all these things that
Humans will be MERCILESSLY HORRIFICALLY tortured and ENSLAVED SOON with
Supercomputer AI, because he is ONE of the SECRET SOCIETY Illuminati
psychopaths.
 
 
 
Kevin Svenson
https://imgur.com/a/Kft2vOD
https://twitter.com/HAL_9_Thousand_
https://twitter.com/kevinsvenson_
 
4 Hunters Run
Broomall PA 19008
USA
(610) 325-0169
 
 
 
 
 
QUOTES ABOUT THE EVIL INVISIBLE SHADOW GOVERNMENT by POTUSes, SENATORS
AND CONGRESSMEN
https://evilciaandnsa.com/quotes-about-invisible-shadow-government-by-potus-senators-n-congressmen/
 
or
 
 
QUOTES ABOUT THE EVIL INVISIBLE SHADOW GOVERNMENT by POTUSes, SENATORS
AND CONGRESSMEN
https://groups.google.com/g/misc.survivalism/c/Ic3ndj1pZzU/m/Fj7WCQ-zBQAJ
 
 
 
 
The EVIL filthy western confused gender cocksucking anus sucking
decadent BACK STABBING white christian motherfuckers at CIA NSA FBI DHS
MI6 MI5 have been SECRETLY CHIPPING millions of americans and global
public's BRAINS with DNA Mind Control Nanobots and LINKING their brains
to NSA HIVE AI Grid for the last 40 years and REMOTELY OPERATING the
VICTIMS like fucking PUPPETS, like they operated the CATS in these videos.
 
 
GATO BAILADOR 1
https://www.youtube.com/watch?v=EERZ8AEya_4
 
 
GATO BAILADOR 2
https://www.youtube.com/watch?v=BJAIOICtyyM
 
 
 
 
EVIL back stabbing CIA NSA FBI DHS doctors have been SECRETLY INJECTING
these MIND CONTROL NANOBOTS, NANO ROBOTS into your bodies for the LAST
50 years, WITHOUT your knowledge and consent.
 
 
 
Renowned Scientist Ray Kurzweil stated that Mind Control technology
exists to create a "digital avatar" of any human, and that DIGITAL
AVATAR will pass Ray Kurzweil Turing Test.
 
 
Dr Ray Kurzweil at 1:23
Computer can make a copy of me, I won't even know they scanned my brain
from inside, from the blood stream, billions of them in the form
of nanobots, nanorobots capture every detail of my synapses and
neurotransmitters and create a virtual Ray Kurzweil in a very powerful
computer and it will be indistinguishable, it will pass a Ray Kurzweil
Turing test.
 
Hyperreality: Linking Targeted Individuals to Artificial Intelligence in
a Virtual World
https://www.youtube.com/watch?v=hAkB_UX-oYM
 
 
 
 
EVIL WHITE CHRISTIAN CIA NSA FBI DHS Psychopaths are using CELL TOWERS
to MIND CONTROL and TORTURE Americans, said Senior DARPA Scientist Dr.
Paul Batcho who developed some of these technologies.
 
 
Senior DARPA Scientist Dr. Paul Batcho REVEALS that US Govt is using
Cell Towers to MIND CONTROL public
https://groups.google.com/g/uk.sport.cricket/c/0iNAHjlVl_M/m/SGiKjnWNBQAJ
 
 
Which MEANS american public have the SELF DEFENSE RIGHT to MERCILESSLY
MASSACRE the back stabbing, infinitely deceptive WHITE CHRISTIAN CIA NSA
FBI DHS "Terrorists, Psychopaths, Sadists, Perverts and BLOOD THIRSTY
vermin".
 
 
The EVIL WHITE CHRISTIAN CIA NSA MI6 FBI DHS ASIS ASIO TERRORISTS and
PSYCHOPATHS are RECORDING every thought, emotion and memory in your
brains in their Super and Quantum Computers for DECADES.
 
 
The EVIL CIA NSA MI6 FBI psychopaths are LITERALLY "programming your
brains to text, talk, act every day and breaking up your relationships,
sabotaging your businesses, careers, destroying your lives all JUST FOR
PSYCHOPATHIC FUN and GAMES".
 
EVIL CIA NSA FBI DHS Psychopaths can LITERALLY TURN OFF your brains and
make you fall dead, give you ANY brain disease, turn you into confused
lunatics.
 
 
Americans, Brits, Ozzies and Global public have the "SELF DEFENSE RIGHT"
to just "MERCILESSLY KILL" the EVIL CIA NSA MI6 MI5 DHS FBI ASIS ASIO
CSIS terrorists and psychopaths for BACK STABBING and DESTROYING our
FREEDOMS, CIVIL LIBERTIES, HUMAN RIGHTS and for NEURALLY ENSLAVING us
while PREACHING and DECEIVING us about democracy on the surface.
 
 
 
 
https://mobile.twitter.com/HAL_9_Thousand_/status/1563397855666372610
In the very near future (before the public realizes it) The vast
majority of the human population will be remotely connected to a highly
advanced global hive mind. This will be done in a covert manner unseen
by most, and it will become intimate part of our lives, known or unknown
 
 
 
 
 
https://twitter.com/HAL_9_Thousand_/status/1508463707919163396
Are military generals fully aware that a maniacal psychopathic
emotionless Supercomputer is in control of millions of people? And it
knows how to kill and torture everyone with precision?
 
 
 
 
 
https://twitter.com/HAL_9_Thousand_/status/1526111452456681474
The plan of the Transhumanist agenda is to gradually absorb all
civilians into the Global Brain, takeover the mind of humanity, and then
slowly reveal to individual civilians that they are "tuned in" to this
Brain machine interface system.
 
#GlobalBrain #WorldSentientSimulation
 
 
 
 
 
 
https://twitter.com/HAL_9_Thousand_/status/1515794291867717639
Military / Intelligence black projects have been dispersing
Nano-Material into public circulation for decades.
 
It began with experimentation … but is now in prime time full
operational use.
 
The human race is secretly being terraformed into a species of
biological drones.
 
 
 
 
 
https://twitter.com/HAL_9_Thousand_
There is currently a technocratic force on earth that believes it's okay
to inflict artificial discomfort and pain into my consciousness anytime
it wants.
 
It's like ancient times, with slaves, except now "your master" is linked
direct-to-brain.
 
… how fun
 
 
 
 
 
https://twitter.com/HAL_9_Thousand_/status/1533360955530395648
An unknown group of Elites running a shadow government using technical
experts to erect a global brain BCI using highly advanced tech systems
and networks to take top down control over humanity.
 
Sounds like a movie 🎥 🍿
 
… but it's here.
 
#BCI #GlobalBrain #NeuroWeapons
 
 
 
 
 
American BUBBAS with AR15s and M16s SHOULD and MUST MERCILESSLY MASSACRE
and SLAUGHTER every CIA NSA FBI DHS MI6 MI5 ASIS ASIO CSIS Psychopath ON
SIGHT, without second thoughts, to SAVE american FREEDOMS, CIVIL
LIBERTIES, HUMAN RIGHTS.
 
Owning AR15s and M16s is of NO USE, unless you have the BALLS to
EXERCISE "YOUR 2nd amendment right" and PROTECT YOURSELF, your families,
and your fellow americans/public, and KILL the fucking EVIL CIA NSA FBI
DHS Psychopaths.
 
 
 
 
BOMB and KILL EVERY WHITE PSYCHOPATH AT DHS FUSION CENTERS, SECURITY
INDUSTRY SPECIALISTS n GREYSTAR PROPERTY MGMT n SAVE American FREEDOMS
https://groups.google.com/g/uk.sport.cricket/c/dys-vHQHlV8/m/1agTB4wqBAAJ
 
 
 
 
 
BOMB THE CIA BUILDING IN LANGLEY VIRGINIA AND MASSACRE THE COCK SUCKING
FILTHY EVIL WHITE CIA PSYCHOPATHS LIKE FUCKING PIGS
https://groups.google.com/g/uk.sport.cricket/c/8BC-CC0ym5A/m/7HU5Gl5GAQAJ
Bonita Montero <Bonita.Montero@gmail.com>: Sep 27 03:47AM +0200

Am 26.09.2022 um 14:18 schrieb Paavo Helde:
 
> Except when there is (a problem). You do not need a dependency on a
> global object, just calling a function using the non-constructed global
> object is enough.
 
That's also not a problem because when you call that function the
dependent object is already created just by loading the libary.
 
Rest unread.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Sep 26 07:57PM -0700

On 9/26/2022 2:54 PM, Scott Lurndal wrote:
 
> In the context of executing constructors for statically defined
> objects, the order is indeterminate, whether the application is
> fully linked (i.e. static libraries) or dynamically linked.
 
"Indeterminate"? Well, no, the language specification does not simply
shrug it off as "indeterminate".
 
The entire [basic.start.static] and [basic.start.dynamic] are dedicated
to describing the intricate details of what orderings exist and what
don't in initialization of non-local objects. That includes unordered,
partially-ordered and ordered initialization sequences.
 
--
Best regards,
Andrey
Paavo Helde <eesnimi@osa.pri.ee>: Sep 27 09:48AM +0300

27.09.2022 05:57 Andrey Tarasevich kirjutas:
> to describing the intricate details of what orderings exist and what
> don't in initialization of non-local objects. That includes unordered,
> partially-ordered and ordered initialization sequences.
 
From what I'm reading there, such initialization order problems can be
solved by C++ modules support. The import declarations define an acyclic
graph of modules, and the non-local variables of a dependency are
guaranteed to be dynamically initialized before those of the dependant
module (at least when this happens after entering main(), which is the
case for me).
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 05:09PM -0700

On 9/26/2022 1:29 AM, Juha Nieminen wrote:
> GC'd languages). However, using individually allocated objects is a
> performance killer. (In fact, using "objects" at all, ie. class
> instances, is a performance killer.)
 
Quick note. Will get back to you.
 
Instead of allocating one "object" at a time, allocate a chunk of
contiguous (wrt memory representation) objects instead. Iterating
through the chunk will be good for the cache.
 
 
 
Juha Nieminen <nospam@thanks.invalid>: Sep 27 06:45AM

> Instead of allocating one "object" at a time, allocate a chunk of
> contiguous (wrt memory representation) objects instead. Iterating
> through the chunk will be good for the cache.
 
AFAIK most GC'd languages (such as Java) do not support creating arrays
of objects. As in, the objects themselves being in the array by value
(rather than the array just containing references/pointers to individually
allocated objects).
 
Even when some language does (eg. C++), putting the objects in an array
helps a bit, but not necessarily a lot, depending on the internal
structure of the objects.
 
When the objects are small and all of their member variables are
typically accessed at once (eg. the object represents an RGBA pixel,
and contains nothing else), then it's very efficient.
 
However, for larger objects the benefits of cache locality become less
and less, the larger the objects are, and the more members variables
they have that aren't accessed in the array traversal. That's because
if you traverse the array, accessing just one or two member variables
out of a dozen, you'll be making larger jumps, thus making cache misses
more frequent.
 
A concrete example: A class representing a vertex, containing all the
data attached to that vertex. In other words, position, normal vector,
UV coordinates, color, and whatever other data may be attached to a
vertex.
 
If you have such a vertex class, and you just put all the instances
in a vector, and then you traverse the vector and eg. access the position
member of each, you'll be making much larger jumps (and thus more frequent
cache misses) than if all the positions were on their own, in their own
array.
 
Also, accessing consecutive values in an array helps the compiler with
autovectorization optimizations.
 
This is the basic idea of data-oriented design.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 27 03:50AM +0200

Hey Chris, this is the current version of my DCAS-class.
 
#pragma once
#include <cstdint>
#include <utility>
#include <atomic>
#include <type_traits>
#include <bit>
#if defined(_MSC_VER)
#include <intrin.h>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)