Tuesday, October 8, 2019

Digest for comp.lang.c++@googlegroups.com - 19 updates in 6 topics

Juha Nieminen <nospam@thanks.invalid>: Oct 08 09:23AM


> I see almost none here. Some female testers, yes; many women leading
> teams, working with requirements and so on. But almost no
> programmers.
 
It should be completely inconsequential how many female (or any other
inconsequential characteristic you may choose) programmers there may
or may not be.
 
People should be treated as individuals, each with their own unique
talents, experience, knowledge, opinions, qualifications and flaws.
We should form an opinion of a person, or a group of people, only
when we get to know them. We should not form prejudicial opinions
about people based solely on inconsequential external characteristics.
It shouldn't matter what those external characteristics should be.
 
I consider sentiments like "we need more female programmers" to be
prejudicial and detrimental. People should be treated as individuals,
not as members of some demographic group, like sex or race. When someone
says "we need more female programmers", they are already categorizing
people into slots based in characteristics that should be completely
irrelevant and inconsequential when it comes to the subject in question
(ie. programming in this case).
 
People should be treated equally, with no discrimination nor preferential
treatmet. People should not be encouraged into a particular hobby or
professional career because of what they are (eg. "female"). All people
should be taught the same things and given the same opportunities, and
allowed to make their own choices about their own lives, hobbies and
careers based on their own interests and talents. People should have no
business in coaxing other people into a particular path, especially if
that coaxing is done for some identity politics reasons.
 
So, even if there are significantly more male programmers than there
are female ones, my response to that is: So what? Who cares? People
should be free to choose their own hobbies and their own careers.
I don't really care if more males choose programming than females.
It's their choice. Let people make their choice. Stop looking at
people's external characteristics, and start looking at them as that:
People. Unique individuals, not just as members of some particular
group.
 
A lot of harm is done by trying to coax people into career paths that they
wouldn't have chosen by themselves. It leads to dropping out of schools,
and unhappy lives working on a field they aren't necessarily so interested
in.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 08 07:47PM

On Tue, 2019-10-08, Juha Nieminen wrote:
> people into slots based in characteristics that should be completely
> irrelevant and inconsequential when it comes to the subject in question
> (ie. programming in this case).
 
Look at it this way: a lack of women in programming is a clear sign
that we're missing out on talented programmers: people who would be
good at it and who would enjoy it.
 
[snip]
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Oct 08 07:53PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>Look at it this way: a lack of women in programming is a clear sign
>that we're missing out on talented programmers: people who would be
>good at it and who would enjoy it.
 
What evidence do you have that:
a) we're missing out on talented programmers
b) they would be people that are good at it
c) they are people who would enjoy it
 
These all seem to be suppositions and not facts.
 
a) We can't know that we're missing out on talented programmers unless
they already demonstrated that they were talented programmers and
decided to stop programming for some reason. If they decided to stop,
then we're not missing out on them unless you plan on forcing them to
return to programming.
 
b) We can't know that they would be good at it until they try.
 
c) We can't presume to know their internal mental likes and dislikes
better than them -- this is the path of hubris. Instead, we can only
ask them after they have tried it if they enjoyed it. Until they try
and tell us whether they like it or not, it is only supposition.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 07:38AM -0700

On Friday, October 4, 2019 at 9:24:14 AM UTC-4, Bonita Montero wrote:
> > No, you haven't identified the real problem, just investigated it's
> > symptoms. ...
 
> That's a matter of definition.
 
Perhaps - but if it's a defect in the gcc compiler code, you can't tell
me what the defect in that code is, or where to find it. If it's a
defect in some other part of your own code that gives gcc permission to
behave this way, you don't know what that other part of your code is.
Either way, there's a gap in your knowledge related to this problem, and
you can't be sure what's the correct way to fix it until you've filled
that gap. It really doesn't matter what terms you use to describe that
gap.
 
I'm not saying that you're responsible for searching the gcc code for
the defect; you should rather file a defect report, and let gcc
developers investigate. However, if you were bothering to file such a
report, it should be accompanied by more information about the code that
triggers it than you've provided to us so far.
 
> > that triggers it.
 
> The problem is that the compiler odr-accesses a static const integral
> member like an odr-access-member. ...
 
That's just a symptom (combined with some guesses about how the symptom
is occurring). If it's a bug in the compiler, you don't know what
triggers that bug. If it's a defect in some other part of your code (the
part you refuse to show) which gives permission for gcc to behave this
way, you don't know what that defect is.
 
> ... If I see the same problem in other
> situations it is the same.
 
It's the same problem if it has the same cause, whether that cause is a
defect in the compiler or in your own code. Either way, until you know
what the defect is, you can't guarantee that the next time the defect
causes trouble, it will show the same symptoms; there's a decent chance
that it won't.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 04:46PM +0200

> triggers that bug. If it's a defect in some other part of your code (the
> part you refuse to show) which gives permission for gcc to behave this
> way, you don't know what that defect is.
 
 
Why should other code trigger that behaviour legally?
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 08:45AM -0700

On Tuesday, October 8, 2019 at 10:46:54 AM UTC-4, Bonita Montero wrote:
> > part you refuse to show) which gives permission for gcc to behave this
> > way, you don't know what that defect is.
 
> Why should other code trigger that behaviour legally?
 
Code anywhere else in your program that has undefined behavior can
legally change the behavior of any other part of your code, including
this one. This is not some pedantic, purely theoretical issue - in real
life the way code with undefined behavior actually behaves can be quite
odd and counter-intuitive; "common sense" is not necessarily a useful
guide to what's actually possible.
 
Unless and until you show us a complete program, preferably as simple as
possible, which demonstrates the problem you're having, we can't rule
out the possibility that the actual problem lies somewhere else in your
code. You can rule it out if you want to, and apparently have already
done so, but I doubt that your decision to do so was well-justified.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 05:56PM +0200

>> Why should other code trigger that behaviour legally?
 
> Code anywhere else in your program that has undefined behavior can
> legally change the behavior of any other part of your code, ...
 
No, not in this case. nd has always the same type and pinCounter is
a member which is uint32_t. And FREE_NODE is a static const uint32_t
member. So the code-pattern is always the same in different functions
(one constructor and several methods) and can be considered isolated
from everything else.
Ned Latham <nedlatham@woden.valhalla.oz>: Oct 08 11:26AM -0500

James Kuyper wrote:
> > > part you refuse to show) which gives permission for gcc to behave this
> > > way, you don't know what that defect is.
 
> > Why should other code trigger that behaviour legally?
 
I'm new here: missed the beginning of the thread, sorry.
 
> Code anywhere else in your program that has undefined behavior can
> legally change the behavior of any other part of your code, including
> this one.
 
I'm completeky lost here: how can source code affect gcc?
 
> life the way code with undefined behavior actually behaves can be quite
> odd and counter-intuitive; "common sense" is not necessarily a useful
> guide to what's actually possible.
 
Just what does that term "code with undefined behaviour" mean here? Do you
mean function pointers (surely you're not talking about self-modifying code)?
 
> out the possibility that the actual problem lies somewhere else in your
> code. You can rule it out if you want to, and apparently have already
> done so, but I doubt that your decision to do so was well-justified.
 
If you're talking about function pointers, it's not difficult to rule out
problems in source code. It's doable in self-modifying code too, for that
matter.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 09:27AM -0700

On Tuesday, October 8, 2019 at 11:56:49 AM UTC-4, Bonita Montero wrote:
> member. So the code-pattern is always the same in different functions
> (one constructor and several methods) and can be considered isolated
> from everything else.
 
Feel free to consider it isolated if you wish. However, code with
precisely those characteristics can (and often does) have it's behavior
affected by code elsewhere in the same program that gives the entire
program undefined behavior.
 
I can't even begin to imagine what might have caused the symptoms you
reported - there's way too many different possibilities. But if you
provided a complete compilable program that produces them, I could start
analysing it to see if it contains any such defects. And if it doesn't,
and you provided the gcc team with a bug report containing such a
program, they could start tracking down why gcc handles it incorrectly.
 
All that you achieve by relying upon your work-around is an unjustified
sense of safety. But I suppose that sometimes if feels good just to
think that you're safe, even if you actually aren't.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 06:32PM +0200

> precisely those characteristics can (and often does) have it's behavior
> affected by code elsewhere in the same program that gives the entire
> program undefined behavior.
 
No, "nd->pinCounter = FREE_NODE;" is semantically the same at any method
or constructor.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 12:48PM -0400

On 10/8/19 12:26 PM, Ned Latham wrote:
> James Kuyper wrote:
...
>> legally change the behavior of any other part of your code, including
>> this one.
 
> I'm completeky lost here: how can source code affect gcc?
 
gcc reads the source code, translates it in accordance with the
standard, and generates a program that meets the requirements that the
standard imposes on the results of translating such code. The standard
doesn't impose any requirements on the results of translating code that
has undefined behavior - so the fact that gcc's output meets those
non-existent requirements shouldn't give you the slightest feeling of
safety. None. Whatsoever.
 
>> odd and counter-intuitive; "common sense" is not necessarily a useful
>> guide to what's actually possible.
 
> Just what does that term "code with undefined behaviour" mean here?
 
"undefined behavior" is defined by the standard as identifying "behavior
for which this International Standard imposes no requirements" (3.27).
You actually have to read the standard to locate all of the places where
it says that the behavior is undefined, in order to determine what kinds
of code fall into that category. By my count, the latest draft of the
standard that I have access to, N4659.pdf, contains 68 occurrences of
that term. In itself, that's not quite as bad as it sounds - not all of
those occurrences represent distinct reasons for code to have undefined
behavior (though most of them do).
However, the C++ standard cross-references the C standard for virtually
the entire C standard library, so every occurrence of "undefined
behavior" in the C standard that applies to it's library might also
apply to C++. Also, keep in mind that the behavior of many parts of the
C++ standard library are defined in terms of the behavior of the C
standard library (for instance, <iostream> heavily cross-references
<stdio.h>). As a result, code which makes no direct use of the C
standard library might have undefined behavior for reasons that you
would have to look at the C standard to understand.
 
 
Do you
> mean function pointers (surely you're not talking about self-modifying code)?
 
There's many ways that function pointers can be involved when code has
undefined behavior. However, there's also many other ways the behavior
can be undefined.
 
>> code. You can rule it out if you want to, and apparently have already
>> done so, but I doubt that your decision to do so was well-justified.
 
> If you're talking about function pointers,
 
I wasn't.
 
> ... it's not difficult to rule out
> problems in source code. It's doable in self-modifying code too, for that
> matter.
 
Ruling out the existence of any problems in any significant body of code
is essentially impossible. Detecting problems is often easy, but being
certain that you've found and corrected all such problems is always the
result of self-delusion. You might happen to be right that there are no
remaining defects, but certainty about that fact can't be justified.
Such certainty is, however, a very popular delusion.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 12:17PM -0700

On Tuesday, October 8, 2019 at 12:32:31 PM UTC-4, Bonita Montero wrote:
> > program undefined behavior.
 
> No, "nd->pinCounter = FREE_NODE;" is semantically the same at any method
> or constructor.
 
No, if code elsewhere in the program renders the behavior of the entire
program undefined, then valid semantics for one occurrence of
nd->pincounter=FREE_NODE could include whistling Dixie, while a
different occurrence could have the semantics of counting down to a
blastoff.
 
You really don't appreciate how thoroughgoing the meaning of "undefined behavior" is. Pay attention to the key phrase: "no requirements". None
at all. In particular, there's no requirement that the specified piece
of memory to modified to hold the specified value. You cannot break a C
program into separate pieces and say: no error in piece A can affect
the behavior of the code in piece B. The language isn't defined in such
a compartmentalized fashion.
 
And that's not just theoretical - undefined behavior in other parts of
the code could allow optimizations to this code, which result in it not
being executed at all, or being executed out of sequence. It could also
cause the current instruction register to jump to just about any
location in program memory, and have whatever is in that location to
start being executed.
 
That's why it's essential, whenever one part of your program behaves
oddly (particularly if it behaves very oddly), to consider the
possibility that the behavior of the entire program is undefined due to
a defect in some other part of the program. The simplest way to deal
with that possibility is to remove all of the other parts of the program.
If you still see the odd behavior, then it is caused only by something
you didn't remove (but not necessarily by the thing that you think it
might be caused by). If the behavior ceases being odd, then the odd
behavior depends, at least in part, on something that you removed.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 01:33PM +0200

> because I'm thinking about to get an US-patent on it, but it is a
> exotic combination of locked and lock-free programming. It scales
> almost linear with the number of threads.
 
Shit, I didn't consider cacheline ping-pong. Here's the scaling with
the number of cores on my Ryzen 7 1800X: https://bit.ly/31YgDAV
The blue graph is the scaling of my algorithm and the red algorithm
is the scaling of my algorithm when I set a certain parameter to zero
so that my algorithm very closely behaves like like updating a LRU
-list with a single mutex.
This is the relative scaling of my algorithm over the scaling of the
standard algorithm when repeatedly fetching and pinning an LRU-entry,
thereby pushing it to the head of the LRU-list, and then unpinning it:
 
1: 101 %
2: 1809 %
3: 1898 %
4: 1736 %
5: 1353 %
6: 1253 %
7: 1259 %
8: 1256 %
9: 1241 %
10: 1204 %
11: 1182 %
12: 1157 %
13: 1155 %
14: 1137 %
15: 1141 %
16: 1153 %
"Öö Tiib" <ootiib@hot.ee>: Oct 08 08:31AM -0700

On Tuesday, 8 October 2019 14:34:01 UTC+3, Bonita Montero wrote:
 
> Shit, I didn't consider cacheline ping-pong. Here's the scaling with
> the number of cores on my Ryzen 7 1800X: https://bit.ly/31YgDAV
 
403
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 05:45PM +0200

>> Shit, I didn't consider cacheline ping-pong. Here's the scaling with
>> the number of cores on my Ryzen 7 1800X: https://bit.ly/31YgDAV
 
> 403
 
Try this: https://pasteboard.co/IB2vueb.png
woodbrian77@gmail.com: Oct 07 09:29PM -0700

Is there a prototype of static exceptions in Gcc or Clang?
Thanks in advance.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 08 02:31PM +0200

> Is there a prototype of static exceptions in Gcc or Clang?
 
Not as far as I know, but if you want to experiment then Boost has a
library only thing that provides close to the same functionality.
 
<url: https://boostorg.github.io/outcome/experimental.html>
 
- Alf
queequeg@trust.no1 (Queequeg): Oct 08 07:29AM


> So? Who cares what the ethnicity of those people are? Are you a racist
> or something?
 
Of course he is.
 
It's best to killfile this idiot, as I did. If you didn't respond,
I wouldn't even see his post.
 
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 08 12:05AM -0700

> else
> LINKER = $(CXX)
> endif
 
 
So here's what I've got now:
 
PROGRAM = super_cool_program
 
INC_DIRS += -I./
CFLAGS_CXXFLAGS_IN_COMMON += -pedantic -Wall -Wextra -rdynamic -funwind-tables -fno-omit-frame-pointer -fdump-rtl-expand -fno-common -Og -g -pthread
CFLAGS += $(INC_DIRS) $(CFLAGS_CXXFLAGS_IN_COMMON) -std=c99
CXXFLAGS += $(INC_DIRS) $(CFLAGS_CXXFLAGS_IN_COMMON) -std=c++17
 
LDFLAGS += $(CFLAGS_CXXFLAGS_IN_COMMON)
LDLIBS +=
 
SRC_FILES_C := $(wildcard *.c)
SRC_FILES_CXX := $(wildcard *.cpp)
 
#If there's no C++ files then use the C compiler to link
ifeq ($(SRC_FILES_CXX),)
LINKER = $(CC)
else
LINKER = $(CXX)
endif
 
OBJECTS += $(SRC_FILES_C:.c=.c.o) $(SRC_FILES_CXX:.cpp=.cpp.o)
 
DEPENDENCIES += $(OBJECTS:.o=.d)
 
.PHONY: all
all: $(PROGRAM) $(DEPENDENCIES)
 
#This rule runs the linker to combine object files into one executable binary file
$(PROGRAM): $(OBJECTS)
$(LINKER) $(LDFLAGS) $^ $(LDLIBS) -o $@
 
#This rule makes dependencies files for the source files
.PRECIOUS: %.c.d
%.c.d: %.c
$(CC) -MM -MT $(<:.c=.c.o) $< -MF $@
 
.PRECIOUS: %.cpp.d
%.cpp.d: %.cpp
$(CXX) -MM -MT $(<:.cpp=.cpp.o) $< -MF $@
 
#This rule compiles the source files to object files
%.c.o: %.c %.c.d
$(CC) $(CFLAGS) -o $@ -c $<
 
%.cpp.o: %.cpp %.cpp.d
$(CXX) $(CXXFLAGS) -o $@ -c $<
 
#This next line pulls in all the dependency files (if they exist, and it's not "make clean")
ifneq ($(MAKECMDGOALS),clean)
-include $(DEPENDENCIES)
endif
 
.PHONY: clean
clean:
$(RM) $(DEPENDENCIES) $(OBJECTS) $(PROGRAM) $(OBJECTS:.o=*.expand)
 
#These next two rules to (un)install are only for Linux
.PHONY: install
install: $(PROGRAM)
cp $< /usr/bin/
 
.PHONY: uninstall
uninstall:
$(RM) /usr/bin/$(PROGRAM)
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)