Friday, January 27, 2017

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 27 01:48PM -0800

On Friday, January 27, 2017 at 10:51:38 AM UTC-5, Rick C. Hodgin wrote:
 
> So ... how do templates allow the my_qsort_compare block of code so
> that it could be generated at compile time in a generic manner able
> to be copied into qsort_block() (to save the function call overhead)?
 
FWIW, I don't think this ability exists in C or C++. I believe this
is a new idea that doesn't have a standard, common, and commensurate
ability in established compilers, toolchains, and OSes.
 
What's at issue is the ability to leverage the compiler's abilities
to create essentially a block of data which can be wielded as easily
as data, but that it is actually binary code which can be overlain
where needed, replacing a purposefully inserted block of nops, for
example, resulting in code that works without the need for callbacks,
and even with functions linked to at runtime.
 
For multi-threads you allocate a block for each thread. For single-
threaded apps you can use the one function instance in memory.
 
I'd be interested to hear if this ability already exists because I
do not believe it does.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 27 02:04PM -0800

On Friday, January 27, 2017 at 4:48:29 PM UTC-5, Rick C. Hodgin wrote:
> threaded apps you can use the one function instance in memory.
 
> I'd be interested to hear if this ability already exists because I
> do not believe it does.
 
This idea also goes along with an idea I had in an extension in
hardware, whereby the move takes place transparently to real memory
as by something called and SMCB protocol:
 
Hardware Architecture and Self-Modifying Code
https://groups.google.com/d/msg/comp.arch/-T_Gam9_TvY/xZ4hyl1FAAAJ
 
In this protocol, portions of memory can be overlain over other areas
of memory, effectively allowing for self-modifying code. The hardware
provides facilities which allow this, allowing a single qsort_block()
function to be written and used, with only the relevant compare block
being overlain, and it is done so contextually per thread, and per
instance based on information stored currently on the stack. In this
way the hardware-visible expression of software changes contextually
based on the dynamic runtime needs of the program, yet without actually
affecting the underlying code.
 
I'm very keen to know if this ability already exists in hardware or
software.
 
Thank you,
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 28 12:22AM +0100

On 27.01.2017 17:45, Mr Flibble wrote:
 
> You see I know the answer to your question but I am not going to give
> you it unless you promise to stop with the Christian bullshit posts to
> this newsgroup. I hope others will follow my lead.
 
I agree. Rick, you've spammed this group with fundamentalist religious
postings, and you're still doing that, even in a follow-up to Mr.
Sausage here. Of course in a matter of life and death we'll help you,
but not for something less. I guess four months or so of normal behavior
would suffice to forgive (but not forget) your behavior.
 
Cheers & hth.,
 
- Alf
Ian Collins <ian-news@hotmail.com>: Jan 28 10:37AM +1300

On 01/28/17 09:42 AM, Christopher J. Pisz wrote:
 
> I derive from a std::exception, I can just constuct my string when I
> need it, and who cares about the copy? It's an exception, which should
> occur exceptionally.
 
Indeed. The cost of throwing far outweighs the cost of generating a string.
 
--
Ian
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 27 11:21PM +0100

On 27.01.2017 16:17, Christopher J. Pisz wrote:
 
[snip]
> How complex is std::find(substr, offset)?
> I wonder if I am barking up the wrong tree.
 
It's clear that your task is finding a substring, possibly just a string
prefix, and `std::find` does not support either of those tasks. The
title of the post also indicates that you meant to refer to
`std::basic_string::find` here. I.e., `s.find( substr, offset )` with
`s` a `std::basic_string<T>` for some suitable character type `T`.
 
`std::basic_string::find` has four overloads, two of which match the
informal argument specification above.
 
The complexity is not specified by the standard, but with simplest
possible straightforward implementation a call `s.find( t )` has complexity
 
O(SL*length(t))
 
where SL = max( length(s) - length(t), 0).
 
This is then the worst case.
 
For the best case a quality implementation should tend to complexity
O(SL), by never examining a character in s more than once. Wikipedia on
the Knuth-Morris-Pratt: "the expected complexity of searching string S[]
of length k is on the order of k comparisons or O(k)". However, the
expected complexity, what you'll usually get, is not the worst case,
whcih is as noted above. I don't know how likely the worst case is.
 
As I recall it I first became familiar with the KMP algorithm via an
article in Scientific American by Niklaus Wirth (!), about how one could
apply simple transformations to algorithms. But I may possibly have a
false memory there, because I've never been able to find that article
again. On the other hand I've not searched for it lately.
 
 
Cheers & hth.!,
 
- Alf
Ramine <toto@toto.net>: Jan 27 10:07PM -0500

Hello...
 
 
About my projects in C++ and Object Pascal..
 
You have to know that i have also used the following method of testing
called black box testing:
 
https://en.wikipedia.org/wiki/Black-box_testing
 
This is why i have written this:
 
I have thoroughly tested and stabilized more my projects for many years,
and now i think that they are more stable and efficient, so i think that
you can be more confident with them, i have also followed the black box
testing also with them...
 
For race conditions , i think for an experienced programmer in parallel
programming like me, this is not a so difficult task to avoid race
conditions.
 
For sequential consistency i have also written this:
 
I have implemented my inventions with FreePascal and Delphi compilers
that don't reorder loads and stores even with compiler optimization, and
this is less error prone than C++ that follows a relaxed memory model
when compiled with optimization, so i have finally compiled my
algorithms implementations with FreePascal into Dynamic Link Libraries
that are used by C++ in a form of my C++ Object Synchronization Library.
 
So this is much easier to make a correct sequential consistency with
Delphi and Freepascal because it is less error prone.
 
Other than that you have to know that i am an experienced programmer in
parallel programming also, so i think that my projects are more stable
and fast.
 
You can download all my C++ and Object Pascal projects from:
 
https://sites.google.com/site/aminer68/
 
 
 
Thank you,
Amine Moulay Ramdane.
woodbrian77@gmail.com: Jan 27 01:49PM -0800

On Friday, January 27, 2017 at 2:43:48 PM UTC-6, Christopher J. Pisz wrote:
 
> I learned more C++ here then in any college course or any book.
> A lot of the original crew hasn't shown up as often or at all anymore
> though.
 
I miss James Kanze.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 27 03:50AM +0100

On 27.01.2017 03:20, Marc Beauchesne wrote:
 
>> ==== a.cpp ===========
>> #include "std_lib_facilities.h"
 
>> int main(void)
[snip]
 
Please don't top-post.
 
It's often a good idea to read the FAQ before posting; see <url:
http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.4>.
 
However, when the FAQ was migrated to isocpp.org/faq it became a general
C++ FAQ, and the netiquette stuff for this group was removed. But it's
still there in the countless mirrors of the original FAQ. Including
Dietmar's, linked to above (Dietmar Kuehl was one of the moderators of
clc++m.)
 
 
Cheers & hth.,
 
- Alf
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.

No comments: