Saturday, February 15, 2020

Digest for comp.lang.c++@googlegroups.com - 16 updates in 9 topics

aminer68@gmail.com: Feb 15 12:59PM -0800

Hello,
 
 
Embarcadero Launches LearnDelphi.org ...
 
As you have noticed , i am also programming in Delphi and Freepascal,
and now i will invite you to read the following news about Delphi:
 
Embarcadero Launches LearnDelphi.org, a Delphi-Centric Learning Ecosystem, to Promote Delphi Education
 
Read more here:
 
https://apnews.com/Business%20Wire/0524383998734d05a34d5900fdfa0058
 
And here is the new website of LearnDelphi.org:
 
https://www.learndelphi.org/
 
 
NASA is also using Delphi, read about it here:
 
https://community.embarcadero.com/blogs/entry/want-moreexploration-40857
 
 
The European Space Agency is also using Delphi, read about it here:
 
https://community.embarcadero.com/index.php/blogs/entry/delphi-s-involvement-with-the-esa-rosetta-comet-spacecraft-project-1
 
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Feb 15 10:09AM -0800

Hello,
 
 
Here is my new inventions that are my new variants of Scalable RWLocks that are powerful..
 
Author: Amine Moulay Ramdane
 
Description:
 
A fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, the scalable LW_RWLockX does spin-wait, and also a fast and scalable and starvation-free and fair Multiple-Readers-Exclusive-Writer Lock called RWLockX, the scalable RWLockX doesn't spin-wait but uses my portable SemaMonitor and portable event objects , so it is energy efficient.
 
The parameter of the constructors is the size of the array of the readers , so if the size of the array is equal to the number of parallel readers, so it will be scalable, but if the number of readers are greater than the size of the array , you will start to have contention, please look at the source code of my scalable algorithms to understand.
 
 
I have used my following hash function to make my new variants of RWLocks scalable:
 
---
 
function DJB2aHash(key:int64):uint64;
var
i: integer;
key1:uint64;
 
begin
Result := 5381;
for i := 1 to 8 do
begin
key1:=(key shr ((i-1)*8)) and $00000000000000ff;
Result := ((Result shl 5) xor Result) xor key1;
end;
end;
 
---
 
You can download them from:
 
https://sites.google.com/site/scalable68/new-variants-of-scalable-rwlocks
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Feb 15 10:30AM -0800

> Hello,
 
Please do not post about your Pascal code here, it is not topical.
In world there are programs that are written in Pascal but we are
not participating in any of those projects.
Juha Nieminen <nospam@thanks.invalid>: Feb 15 07:38AM

> Up until now, the user has had to explicitly run the program as an Administrator (or as "root"). So if they run it as a normal user, it will load up and say "Failed to open network interface". I want to change this. If my program is run as a normal user then I want the user to be prompted to elevate to Administrator (or "root") and to input their password as necessary.
 
So a unix user runs your program, the program asks for the root password,
the user quickly kills the program and never runs it again.
 
No sane person would ever, in a million years, just enter a root password
simply because a program asks for it.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 15 08:05AM

On Sat, 2020-02-15, Juha Nieminen wrote:
> the user quickly kills the program and never runs it again.
 
> No sane person would ever, in a million years, just enter a root password
> simply because a program asks for it.
 
I agree it's a crazy thing to do, but I think systemd and some other
new software (yum?) tries to teach users to happily do exactly this.
 
Personally I only give it to su(1) or to a local login prompt.
 
But it's all offtopic here. Comp.unix.programmer would be a better fit.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Frederick Gotham <cauldwell.thomas@gmail.com>: Feb 15 10:02AM -0800

David Brown wrote:
 
> to run as root, and delete it afterwards?
> Can you imagine a better way to make
> the program look like malware?
<interpostal snip>
> Faff around with creating binaries on the fly,
> and other weird ideas, and you can be
> confident that distros will reject it.
 
 
Are you arguing, in general, that a person who has good intentions should refrain from doing something if there is the possibility that an observer might think that they are up to no good?
 
How do you feel about BitTorrent? Should people who have good intentions avoid using BitTorrent for fear that an observer will think that they're doing something wrong?
 
The piece of software that I'm writing is a GUI network analysis tool. My application doesn't do anything malicious (like deleting users' documents or scrambling the master boot record) nor does it do anything invasive of privacy or copyright (e.g. copying a user's personal collection of short stories, or online banking passwords, to a remote server). My program is benign.
 
When trying to implement functionality in my program, it should not matter how much my programming techniques resemble the techniques of a hacker with bad intentions. Loading CPU instructions into a shared memory object to execute it isn't inherently malicious or in any dishonest. It's not like I'm trying to gain root access by deception -- I want the user to willingly enter their password to grant access.
 
If users were to start emailing me saying that their anti-virus software is quarantining my program, then okay I might have to look into that and maybe even contact the antivirus software company to inform them that their software is generating a false positive on my application. And if the anti-virus company don't reply to me, or if they reply to tell me that they won't relax their detector (nor add my program to an inclusion list) then I suppose I might have to come up with a new idea. Until that happens though, I don't think that I should restrict my own programming techniques because of how much or how little they resemble the techniques of a person with bad intentions. I actually think that the runtime generation of executable code is pretty cool.
 
By the way, these fanciful techniques like playing around with interprocess memory and so forth are only for the 'portable' versions of my program. I'm happy to also supply the user with a vanilla installer for their operating system that does everything in the canonical way for their operating system if that's what they want.
 
I think you're being overly and unnecessarily restrictive by advising people not to do something simply because it resembles something bad.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 15 05:30AM -0800

> to say about it since your post was itself interesting and clearly not
> trivial to write. Unfortunately I failed, but such a thoughtful post
> merits a reply, even if the reply is not thoughtful.
 
Thanks, I appreciate the followup.
 
(for Ben: I sent you an email earlier this week. Did you get that
or did it fall through the cracks?)
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 15 04:39PM

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
<cut>
> (for Ben: I sent you an email earlier this week. Did you get that
> or did it fall through the cracks?)
 
I replied a 3 days ago.
 
--
Ben.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 14 11:50PM -0500

Bonita Montero wrote:
>>          return code & _XABORT_RETRY ? 0 : -1;
>            return (code & (_XABORT_RETRY | _XABORT_EXPLICIT)) == _XABORT_RETRY ?
> 0 : -1;
try
 
return -(!((code & (_XABORT_RETRY | _XABORT_EXPLICIT)) == _XABORT_RETRY));
 
to satisfy Alf's dislike of conditional expressions but not int return values :-)
 
hth but almost kidding..
 
-Pavel
 
Bonita Montero <Bonita.Montero@gmail.com>: Feb 15 10:03AM +0100

> return -(!((code & (_XABORT_RETRY | _XABORT_EXPLICIT)) == _XABORT_RETRY));
 
That's obfuscation.
I like the ternary operator and in contrast to C++ you can do
some nice things like this "++(xyz == CMP ? a : b)" with it.
That's compact and not unreadable like the above.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 15 04:59PM +0100

> That's obfuscation.
> I like the ternary operator and in contrast to *** you can do
C
Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 15 05:56AM -0800

>>> guarantees.
 
>> Or just size_t(-1)/2+1.
 
> Or ~(size_t(-1)/2).
 
In practice that is highly likely to work, but strictly speaking
it is not guaranteed (at least not in C; I believe that holds
also in C++ but I am less well-versed in the C++ standard than
the C standard). The reason is size_t is not required to be at
least as wide as int, so the ~ could produce a negative value.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 15 06:44AM -0800


>> To me this alternative is worse than the original. Just a
>> personal reaction.
 
> Yes, must be personal...
 
I meant only that I am representing only my own viewpoint.
Did you think I meant something else?
 
>> }
 
> With the original example, this rewrite would be valid in C where 'A;'
> contained mutex locking and 'D;' contained mutex unlocking code.
 
Yes, I was talking about such cases.
 
> might not support recursive locking, and even if it does, the
> recursive call would call first part of A ('flush_workqueue(wq);')
> under the mutex lock, which would be all wrong I suspect.
 
Right. When there is behavior resulting from destructor calls, trying
to use (what looks like) a recursive tail call is very likely a bad
idea even if it isn't outright wrong, which it certainly could be.
 
> So, is this a case where using a 'goto' would be in some sense more
> justified in C++ than in C?
 
I think I would say using a 'goto' is more likely to be justifiable
in cases like this one (that is, more likely in C++ than in C). It
may be that there are other ways of coding the needed functionality
that do not use a 'goto'. But considering that pending destructor
behavior can eliminate this one alternative, it looks like C has an
option available that C++ does not, at least not in practical terms.
And that could result in using a 'goto' being the most attractive
alternative available in C++ but not in C.
 
> BTW, in my own code I have several times encountered similar awkward
> "backward goto" scenarios needed only for unlocking a mutex. And the
> result has always been a mess I'm afraid.
 
That's interesting. Is that always because of pending destructor
behavior? If it is, that suggests that the RAII pattern using
standard constructor/destructor semantics has some shortcomings,
which may indicate a need for other behavior choices. For example,
the funky() function above could be writeable using a new 'creturn'
construct, written as
 
creturn funky();
 
where 'creturn' means first run any pending destructors, and only
after they finish execute the (implied) return statement. Doing
that avoids all the nested locking problems, and also makes the
apparent "tail call" be a true tail call, and so could be optimized
to reuse the stack frame. What other kinds of constructs might make
your troublesome mutex uses more tractable?
"Öö Tiib" <ootiib@hot.ee>: Feb 15 06:41AM -0800

On Tuesday, 11 February 2020 23:06:12 UTC+2, Frederick Gotham wrote:
> > mofile >> std::noskipws;
 
> I looked at the differences in "meld" and it has loads of "0x20" bytes highlighted, which is the ASCII value for a space.
 
> Looks like you're right. I might try those extra flags when I'm at a PC tomorrow.
 
So ... did "mofile >> std::noskipws;" help? I checked that stack owerflow
contains several suggestions to std::copy files without any mention
of std::noskipws.
James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 15 09:12AM -0500

On 2/14/20 3:15 AM, Chris M. Thomasson wrote:
...
> Speaking of C++20... I am existed to see:
^^^^^^...
> https://en.cppreference.com/w/cpp/atomic/atomic_wait
 
Seeing that brought you into existence? Wow! ;-)
Nikki Locke <nikki@trumphurst.com>: Feb 14 11:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
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)