Monday, October 7, 2019

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

Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 07 09:23PM

On Tue, 2019-10-01, Öö Tiib wrote:
> On Tuesday, 1 October 2019 10:20:29 UTC+3, David Brown wrote:
...
>> that programmers themselves are not inclusive people.
 
> I see plenty of female programmers here, in my previous team there was
> 3.
 
I see almost none here. Some female testers, yes; many women leading
teams, working with requirements and so on. But almost no
programmers.
 
I also have met no openly gay or transgender programmers.
 
And yet the programmers I've met are a weird and interesting bunch of people
who don't match any particular stereotype.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
scott@slp53.sl.home (Scott Lurndal): Oct 07 10:20PM


>I see almost none here. Some female testers, yes; many women leading
>teams, working with requirements and so on. But almost no
>programmers.
 
I've seen the programmer ratio change a lot over the last forty years. In the early 80's,
it was about 50/50 (at least at the Burroughs mainframe California
operations); including at the first level of management in the programming
activity. The ratio was much lower in the hardware engineering (processor
and peripheral design) groups.
 
Now, the ratio significantly favors males even in programming, and it has for
a couple of decades.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 07 09:00AM -0400

On 10/4/19 10:50 AM, Frederick Gotham wrote:
> On Friday, October 4, 2019 at 3:43:47 PM UTC+1, Scott Lurndal wrote:
 
>> int main(int argc, const char **argv) is just fine.
 
> That's as bad as using a C-style cast instead of static_cast
 
Using a C-style cast when a static_cast<> should be able to do what you
intend to do, has the disadvantage that it can do a great many things
that a static_cast<> can't, and you will therefore fail to get the
warnings that a C++ implementation is required to give you if you try to
use static_cast<> to do one of those things.
 
What is the corresponding disadvantage of using that syntax?
 
You give the strong impression of using the newer syntax in a context
where it isn't needed, solely for the reason that it's new. That's not a
sufficiently good reason to criticize other peoples decision to do
otherwise. It's not the reason that C++'s named casts are preferred over
C-style casts.
"Öö Tiib" <ootiib@hot.ee>: Oct 07 12:43PM -0700

On Saturday, 5 October 2019 00:24:59 UTC+3, Mr Flibble wrote:
 
> >> What's that? Baiting the cognoscenti?
 
> > You have to admit it looks pretty damn cool, especially if you're been writing "int main" for a decade or two or three.
 
> You neglected to mention the fourth reason: you're a fucktard.
 
It takes one to know one. ;)
"Öö Tiib" <ootiib@hot.ee>: Oct 07 01:12PM -0700

On Saturday, 5 October 2019 14:00:27 UTC+3, David Brown wrote:
 
> at the start of header files for decades, so that they can be used in C
> and C++ compilation. Are you telling me that hasn't worked for MSVC
> until recently?
 
That did work but the value of __cplusplus was always 199711L.
Projects that use previous versions of VC as one of targets have
to check value of MS-specific macro (_MSC_VER) to do detailed
workaround of quirks and annoyances in those. VC++2003, VC++2005,
VC++2008 and VC++2010 were all supposed to support C++03 but
did it in slightly different ways. Some Boost library headers are
still quite full of such checks I trust.
"Öö Tiib" <ootiib@hot.ee>: Oct 07 12:14PM -0700

On Saturday, 5 October 2019 14:09:15 UTC+3, David Brown wrote:
> If the bug is in your code or your understanding,
> then /you/ will learn something - as might others following the thread.
 
The OP question was about why such novice coding defect does not
compile. Answers got usual snarky, boring and boneheaded replies.
Who has patience to follow such threads? There are no gems in
that trash.
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 07 12:48AM -0700

On Friday, October 4, 2019 at 5:14:10 PM UTC+1, Scott Lurndal wrote:
 
> of Moores Law has pretty much killed that argument.
 
> There is no problem supporting parallel makes in a recursive make enviroment
> either.
 
 
Recursive 'make' is ok, but I'm thinking of doing things a little differently.
 
When I get this Makefile perfect I'm going to have directories nested about 3 or 4 levels deep with programs and libraries to be compiled. So then in the root folder, I might write a script to perform a parallel build something like:
 
find -name Makefile ! -type d -printf "%d \"%h\"\n" | sort -r -n | cut -d ' ' -f 2 | xargs -n1 -P 0 make -C
 
This will build the program starting from the deepest folders moving up the directory tree.
 
Also, instead of copying my 'perfect' Makefile to each folder, I'll just have symbolic links to it so that I can change it in one place.
 
Of course I have a few things to consider, like what happens if one of the Makfiles higher up the tree gets executed before one of the deeper one's has finished.
Ian Collins <ian-news@hotmail.com>: Oct 07 09:06PM +1300

On 07/10/2019 20:48, Frederick Gotham wrote:
 
> Of course I have a few things to consider, like what happens if one
> of the Makfiles higher up the tree gets executed before one of the
> deeper one's has finished.
 
Or just use a tool that takes care of this for you!
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Oct 07 10:46AM +0200

On 07/10/2019 09:48, Frederick Gotham wrote:
 
> Of course I have a few things to consider, like what happens if one
> of the Makfiles higher up the tree gets executed before one of the
> deeper one's has finished.
 
That sounds horrendous, a maintenance disaster, and it is crying out for
problems with cross-directory dependencies. I strongly recommend that
you scrape the whole idea.
 
Write /one/ Makefile. Put it in the root directory. Call it with
"make", or "make -j" for parallel builds. Have that include
directory-specific parts if you want, but have that one Makefile control
the others. Make sure all your files in all the subdirectories have
dependency files generated automatically so that you get the right
re-compiles when headers change, regardless of the directories.
Ideally, your dependency files should also be updated automatically
rather than needing a manual "make depends" step.
 
If you really can't avoid recursive makes - perhaps because you are
using third-party project parts that have their own makefiles - then
call these makes from within your main makefile.
 
The aim should always be that typing "make -j" will give you a correct
build, no matter what has changed, and no matter what order the parallel
tasks run in - all ordering requirements should be given in the makefile.
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 07 08:31AM -0700

With regard to linking, I want "g++" to be used if there were any C++ source files, otherwise I want to use "gcc" for linking if all the source files were C.
 
I think I would do this as follows. . .
 
ifeq ($(SRC_FILES_CXX),)
LINKER = $(CC)
else
LINKER = $(CXX)
endif
aminer68@gmail.com: Oct 06 04:45PM -0700

Hello,
 
 
 
As you have noticed i am a white arab, and this post of mine is about
Arabs:
 
 
Research: Arab Inventors Make the U.S. More Innovative
 
It turns out that the U.S. is a major home for Arab inventors. In the five-year period from 2009 to 2013, there were 8,786 U.S. patent applications in our data set that had at least one Arab inventor. Of the total U.S. patent applications, 3.4% had at least one Arab inventor, despite the fact that Arab inventors represent only 0.3% of the total population.
 
Read more here:
 
https://hbr.org/2017/02/arab-inventors-make-the-u-s-more-innovative
 
 
Even Steve Jobs the founder of Apple had a Syrian immigrant father called Abdul Fattah Jandal.
 
 
Read more here about it:
 
https://www.macworld.co.uk/feature/apple/who-is-steve-jobs-syrian-immigrant-father-abdul-fattah-jandali-3624958/
 
 
 
Thank you,
Amine Moulay Ramdane.
Juha Nieminen <nospam@thanks.invalid>: Oct 07 07:43AM

> It turns out that the U.S. is a major home for Arab inventors. In the five-year period from 2009 to 2013, there were 8,786 U.S. patent applications in our data set that had at least one Arab inventor. Of the total U.S. patent applications, 3.4% had at least one Arab inventor, despite the fact that Arab inventors represent only 0.3% of the total population.
 
So? Who cares what the ethnicity of those people are? Are you a racist
or something?
Real Troll <real.troll@trolls.com>: Oct 07 08:30AM -0400

On 07/10/2019 08:43, Juha Nieminen wrote:
>> It turns out that the U.S. is a major home for Arab inventors. In the five-year period from 2009 to 2013, there were 8,786 U.S. patent applications in our data set that had at least one Arab inventor. Of the total U.S. patent applications, 3.4% had at least one Arab inventor, despite the fact that Arab inventors represent only 0.3% of the total population.
> So? Who cares what the ethnicity of those people are? Are you a racist
> or something?
 
He keeps telling everybody that he is "white Arab". Is that racism?
You decide!!. The current climate is so bad that any opinion can be
misconstrued.
woodbrian77@gmail.com: Oct 06 04:39PM -0700


> I guess DCCP doesn't provide reliable in-order delivery so
> that's not an option. I'll try SCTP for now.
 
I've made a little progress with using SCTP:
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
 
. One thing that has eluded me though is figuring out how
to increase the heartbeat interval. From what I can tell
the interval is 30 seconds on both FreeBSD and openSUSE.
I've guessed that you can adjust it via setsockopt and have
searched for sctp and setsockopt, but so far haven't figured
it out. I even tried using something other than Duckduckgo
to search, but that didn't help.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
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)