Sunday, May 8, 2016

Digest for comp.lang.c++@googlegroups.com - 24 updates in 10 topics

bleachbot <bleachbot@httrack.com>: May 08 06:22PM +0200

bleachbot <bleachbot@httrack.com>: May 08 09:19PM +0200

bleachbot <bleachbot@httrack.com>: May 08 10:44PM +0200

bleachbot <bleachbot@httrack.com>: May 08 10:47PM +0200

bleachbot <bleachbot@httrack.com>: May 09 01:14AM +0200

Ramine <ramine@1.1>: May 08 07:15PM -0700

Hello....
 
Read this about Dmitry Vyukov lockfree concurrent Skiplist:
 
http://www.1024cores.net/home/parallel-computing/concurrent-skip-list
 
 
I think that this lockfree algorithm is bad for realtime critical
systems, because there is a loop around a CAS in the writer side, that
makes the writer side not free from starvation. So it is not suitable
for realtime critical systems. So we can generalize this and say
that lockfree algorithms are not suitable for realtime critical systems.
 
This is why locks and FIFO fairness are useful in realtime critical systems.
 
 
Thank you,
Amine Moulay Ramdane.
red floyd <no.spam.here@its.invalid>: May 08 10:19AM -0700

On 5/8/2016 8:26 AM, Jerry Stuckle wrote:
>> including, as you know, *appearing* to "work properly".
 
> That is correct. It is undefined behavior. But it is not illegal, and
> it can happen - despite Rick's claim.
 
But once UB has occurred, it doesn't matter what the output is. It's
just as perfectly legal for said program to segfault. Then you wouldn't
get your "correct output".
Wouter van Ooijen <wouter@voti.nl>: May 08 08:03PM +0200

> Since you didn't get it, I'll be more clear: my point was the compiler
> should try to reference data at the pointer's location before assigning
> it to a reference.
 
That would catch only a small subset of illegal pointers/references. You
can of course implemented it in your own language, but for me that
language would not be acceptable as a high-performance (in terms of
execution speed) systems programming language. I am glad C++ has not
taken that route.
 
You might argue that with increasing CPU performance the
high-preformance issue will become irrelevant over time, but
- single-CPU perfromance is stalling
- whatever the level of performance, some uses will require the last
drop of juice from the metal, so we need a language that does exactly
that. This might not be the language for everyone, but hey, there is C#,
Java, Python, and your language might be the next! (But it will probably
not be my language)
 
Wouter van Ooijen
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 08 12:23PM -0700

On Sunday, May 8, 2016 at 2:03:29 PM UTC-4, Wouter van Ooijen wrote:
> > should try to reference data at the pointer's location before assigning
> > it to a reference.
 
> That would catch only a small subset of illegal pointers/references.
 
To my consideration on this matter, it would catch all that would be the
result of the compiler directly passing along something that it knows is
invalid. All other cases where there are illegal pointers/references
would come only from the application not following a proper protocol for
the use of resources. But this particular one stems from the compiler
failing to enforce something that must be true (that the reference
cannot be non-NULL).
 
> language would not be acceptable as a high-performance (in terms of
> execution speed) systems programming language. I am glad C++ has not
> taken that route.
 
It would require one cache read, which the application is likely doing
anyway. And, there could be an optimization flag which removes those
checks in favor of execution speed.
 
> Java, Python, and your language might be the next! (But it will probably
> not be my language)
 
> Wouter van Ooijen
 
I appreciate your input and thinking. I consider such things, but I
value the time spent by developers in writing software more than final
execution speed.
 
My compiler framework is called "Rapid Development Compiler," which is
RDC for short. It is that part which has strong ties to debugging. I
ultimately intend to also create a follow-on product called "Rapid
Engine Compiler" which is designed around creating exceedingly highly
optimized code, with RDC maintaining only _some_ optimization abilities.
 
My goals are in helping developers write good code. Once they get it
debugged, then it should go to the next phase. It's an evolution,
starting with exceedingly high debugging tools and abilities first, and
then moving through a migration into raw performance which, all things
being equal, will continue with the source code not being changed. But,
at each optimization level there can be introduced new aspects of the
code's implementation which do introduce bugs.
 
It's where I'm headed with CAlive. They're my ultimate goals for those
tools.
 
Best regards,
Rick C. Hodgin
Wouter van Ooijen <wouter@voti.nl>: May 08 09:52PM +0200

Op 08-May-16 om 9:23 PM schreef Rick C. Hodgin:
 
> I appreciate your input and thinking. I consider such things, but I
> value the time spent by developers in writing software more than final
> execution speed.
 
In that case you should probably look more in the direction of managed
languages. When I must do non-critical desktop work I prefer Python.
 
> code's implementation which do introduce bugs.
 
> It's where I'm headed with CAlive. They're my ultimate goals for those
> tools.
 
Succes. If you ever target small micro-controllers I might try it. But
on those chips a heap is a definite no-no, and everything that is less
efficient than C (in speed or size) is frowned upon. Even C++ is often
(falsly) considered a bad idea.
 
Wouter
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 08 01:12PM -0700

On Sunday, May 8, 2016 at 3:52:43 PM UTC-4, Wouter van Ooijen wrote:
> > execution speed.
 
> In that case you should probably look more in the direction of managed
> languages. When I must do non-critical desktop work I prefer Python.
 
I have defined a managed type in my language as well. I also have a var
type which takes on the identity of the last thing that was stored into
it, including some built-in classes. In order to be used in context, it
is consistently type checked against the target making it take a small
performance hit, but where the ability to have a managed, discriminating
type is desirable, it can be quite nice.
 
> efficient than C (in speed or size) is frowned upon. Even C++ is often
> (falsly) considered a bad idea.
 
> Wouter
 
Unlike C or C++, with CAlive I intend to create a core compiler which is a
fully compliant language implementation in a VM. As such, my design tools
will allow people to write code and test it in the VM as per the needs of
the language, and then ultimately port it to their favorite existing tool
which can be used on whatever the target is.
 
I have some alternate syntax extensions which can be suppressed by using
various flags, but if they are use I intend to write a tool which can
generate an output file with the commensurate C/C++ code as applicable.
 
We'll see how it goes. It's been a long time in the planning. I'm
currently working on a set of precursor tools for it (assembler and
basic C compiler) which will be used to create the rest of the toolkit.
My goals are to have it beginning to work next year, and completed by
2020. If I get other people helping me, it would go faster... but we'll
see how that pans out over time.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 08 01:38PM -0700

On Sunday, May 8, 2016 at 4:12:56 PM UTC-4, Rick C. Hodgin wrote:
> will allow people to write code and test it in the VM as per the needs of
> the language, and then ultimately port it to their favorite existing tool
> which can be used on whatever the target is.
 
To be clear about this part, I will release with each release of the CAlive
spec, a VM that possesses all of the support for the language, so people
can immediately test out their code changes without having to wait for the
actual machine-specific compiler to be implemented. Though, for all of
the platforms I intended to personally support (i686, AMD64, ARM), they
will also be released almost immediately after the VM is fully functional.
 
Best regards,
Rick C. Hodgin
Jerry Stuckle <jstucklex@attglobal.net>: May 08 06:42PM -0400

On 5/8/2016 12:57 PM, Rick C. Hodgin wrote:
 
>> No, it is not illegal.
 
> Scarcely a difference, Jerry. And it still fits my definition of when
> references can be NULL.
 
Yes, there is a huge difference between "illegal" and "undefined behavior".
 
> Here's something for you to try to educate yourself:
 
> Create a legal and valid coding example (one that doesn't involve
> UB) where you can legitimately create a NULL reference in C++.
 
As I said - the code was legal. Legal is NOT the same as undefined
behavior.
 
> by doing a simple memory read at that address. It would prevent this hole
> you've exploited via the arena of illegal coding practices, which you
> will say is only "UB" and not "illegal."
 
No, it is not a flaw in the compiler or the C++ standard. You may think
is is a flaw, but the standards committee disagrees. And yes, even the
standard says it is undefined behavior.
 
> It's fundamental.
 
Yes - it is fundamentally undefined behavior.
 
> I don't want 40 more years to pass by and we're still using legacy
> baggage designed in the 1970s because of the limitations of those
> machines back in the day.
 
No, you're looking at WHAT YOU THINK IT SHOULD BE DOING. If you want to
change the standard, you need to get on the standards committee and
convince others your way is better. Continually bitching here does not
good and annoys others.
 
> the core you address specific needs of data processing on the target
> for which that core was written (a two's complement machine with same-
> sized pointers, for example).
 
Fine. Then create your own newsgroup for your new language. This one
is about C++, not something you want to create.
 
 
> In this case, that was my point exactly, because we're dealing with what
> exists today in C++. You should've checked for NULL so as to never have
> created the illegal reference in the first place.
 
Once again, it's not illegal. It's undefined behavior. Two different
things. And whether I should have checked it or not is immaterial - you
said it was impossible to get a reference to NULL. I just pointed out
where you are wrong.
 
 
> I have no desire to wallow in what we have today, Jerry. I'm looking at
> fundamental requirements of data processing, and I'm constructing CAlive
> to begin there.
 
Then create a new newsgroup for your CAlive and discuss it there. In
case you haven't noticed, this is a C++ newsgroup.
 
>> required, it is the responsibility of the programmer.
 
> In C/C++ that's the case. I'm looking to the future. I'm looking for
> more. I wonder if you'll ever be able to grasp that concept, Jerry?
 
Then create your own newsgroup for CAlive.
 
 
> Since you didn't get it, I'll be more clear: my point was the compiler
> should try to reference data at the pointer's location before assigning
> it to a reference.
 
I get it, Rick. But you don't get it. Part of the design of both C and
C++ is that the compiler does not test for things like this. These are
programmer errors, and both require more of the programmer.
 
> before the Lord, Jerry. And then go forth.
 
> Best regards,
> Rick C. Hodgin
 
Rick, if you were a true Christian, you would follow Matthew 7:1 and
Luke 6:37.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: May 08 06:44PM -0400

On 5/8/2016 1:19 PM, red floyd wrote:
 
> But once UB has occurred, it doesn't matter what the output is. It's
> just as perfectly legal for said program to segfault. Then you wouldn't
> get your "correct output".
 
I never said anything about "correct output". Once again - I just
pointed out that it is possible.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
woodbrian77@gmail.com: May 08 03:18PM -0700

On Friday, April 29, 2016 at 2:35:38 AM UTC-5, Wouter van Ooijen wrote:
> Bible. It is made of cedar and pine and was built atop a steel barge ..."
 
> So even at half the size and with modern woodcraft, they didn't try to
> built it from wood. It is essentially a big cabin on top of a steel ship.
 
 
Noah built a quality vessel/ark with G-d's help. I'm not
surprised it is difficult to duplicate it today even with
modern woodcraft.

 
> (We did try, but in the end maintaining the Dykes was deemed more
> important. Living next to a (different-)religious neighbour is to be
> preferred over being dead on the bottom of a sea.)
 
I'm okay with having neighbors that don't believe the same as me.
 
> Wouter "objects? No thanks!" van Ooijen
 
What does that mean?
 
Brian
Ebenezer Enterprises - "Trust in the L-rd with all your heart
and lean not on your own understanding." Proverbs 3:5
Ramine <ramine@1.1>: May 08 04:45PM -0700

Hello Sir and Madam.....
 
 
We have to be smart...
 
 
My scalable DRWLock and my scalable DRWLockX of my
C++ synchronization objects library are scalable
but they have a cost of 10 cycles on the reader side, so
if you are reading memory or reading from the disk
this cost will be amortized a lot, but if your reader
section is smaller than 10 cycles , please use my
scalable SeqlockX that is very efficient and costless
on the reader side, my scalable SeqlockX that is a variant
of Seqlock that eliminates the weakness of Seqlock that is
"livelock" of the readers when there is more writers.
 
So as you have noticed C++ synchronization objects library is
powerful and great.
 
You can download C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 08 04:48PM -0700

On 5/8/2016 4:45 PM, Ramine wrote:
 
> My scalable DRWLock and my scalable DRWLockX of my
> C++ synchronization objects library are scalable
> but they have a cost of 10 cycles on the reader side, so
 
I mean 10 CPU cycles.
 
 
Leonardo <leonardo@no-spam.please>: May 08 10:38PM +0300

On 05/04/2016 08:12 PM, Rick C. Hodgin wrote:
> have it.
 
> Best regards,
> Rick C. Hodgin
 
In what scenario would a function call be insecure? When malware or a
debugger calls it outside the regular program flow?
 
If so, couldn't the said program check the CMP instruction of a function
to get access to the secure token? Or better yet, stop it from jumping
to the insecure part?
 
--
Leonardo
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 08 01:19PM -0700

On Sunday, May 8, 2016 at 3:39:07 PM UTC-4, Leonardo wrote:
> > have it.
 
> In what scenario would a function call be insecure? When malware or a
> debugger calls it outside the regular program flow?
 
When it is called without knowing the token.
 
The idea is the compiler generates a random token when it creates the
executable. Every known call to that function will setup the token to
be tested by the called function. If you call through a pointer to the
function's address, you won't have the token setup except by something
like random luck or a brute-force attack. And, because of that
possibility, I think the better solution would be for the OS loader to
do some load-time linking on the binary and introduce random values for
each secure function, so that every time the binary is loaded, it has
a new set of random values.
 
> If so, couldn't the said program check the CMP instruction of a function
> to get access to the secure token? Or better yet, stop it from jumping
> to the insecure part?
 
It would require the code be loaded into and running from an execute-only
block of memory. By doing that, no external application would be able to
gain access to the raw binary/machine code to be able to determine the
token, and the front-end could be created in such a way that only a proper
landing point, with a proper token or not, would be valid entry into the
function.
 
Different kinds of tokens could be created. However, I think for speed
reasons the need to test a 64-bit value would be sufficient. The odds of
happening onto the exact 64-bit random value assigned during this binary's
launch ... it's just unlikely.
 
Best regards,
Rick C. Hodgin
"Chris M. Thomasson" <nospam@nospam.no>: May 08 12:34PM -0700


> FWIW, some, IMHO, fairly interesting C++ code for Field Based DLA:
> https://plus.google.com/101799841244447089430/posts/am5EpMHcmig
> https://github.com/ChrisMThomasson/CT_fieldDLA
 
FWIW, here are some new renderings I created using a
mutated version of the DLA field code:
 
https://plus.google.com/101799841244447089430/posts/9bz3jgBxAPf
 
https://plus.google.com/101799841244447089430/posts/7LQhwQVi86V
 
https://plus.google.com/101799841244447089430/posts/YUBEPZTE5hN
 
IMVVVHO, this is interesting, and C++ is wonderful medium!
 
:^)
Ramine <ramine@1.1>: May 08 03:21PM -0700

Hello.....
 
 
My C++ synchronization objects library was updated..
 
I have just corrected a minor bug in my scalable DRWLock and
scalable DRWLockX, i have updated them to version 1.48
 
And i have tested my library thoroughly, and now i think
that it is more stable and fast.
 
You can download C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 08 06:53PM +0100

On Sun, 8 May 2016 09:50:12 -0700 (PDT)
"K. Frank" <kfrank29.c@gmail.com> wrote:
[snip]
> Well, yes, this is certainly true. But my question is
> driven by why you would want to use a concept.
 
That wasn't your original question (but it is a reasonable one to ask).
 
The main purpose is to provide reasonable diagnostics from the compiler
which approximate to the diagnostics you get from C++'s type system with
respect to non-template types.
 
You can also use type classes for choosing function overloads based on
the type constraints imposed and for ambiguity resolution. I don't know
if the C++ concepts proposal does that (it probably does). It quite
probably also does other things that I don't know about, for which you
can find papers. They have been a moving target, which apparently will
miss C++17, which is a shame.
"Öö Tiib" <ootiib@hot.ee>: May 08 11:13AM -0700

On Sunday, 8 May 2016 19:50:26 UTC+3, K. Frank wrote:
> that permit or encourage classes to formally specify
> which concepts they intend to satisfy (and will be
> verified to satisfy)?
 
Not to my knowledge. Generally we assume that certain patterns are
used when we talk about "compile-time polymorphism". Patterns like
for example CRTP. CRTP example from C++ standard library:
 
class Device : std::enable_shared_from_this<Device>
{
// ...
};
 
As result we have a class Device that indeed fulfills certain constraints
but if we want to have a concept about those constraints then we will
still need to define it separately. Also my impression is that patterns
like CRTP will remain in use after concepts.
Ramine <ramine@1.1>: May 08 12:24PM -0700

Hello.....
 
My C++ synchronization objects library was extended..
 
I have just included a Threadpool based on Pthread
inside my C++ synchronization objects library..
 
You can download my C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
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)