- C++ templates - 3 Updates
- Adding a function to std::exception and company - 1 Update
- string::find complexity - 1 Update
- About my projects in C++ and Object Pascal.. - 1 Update
- Very good newsgroup! - 1 Update
- (learning) Two types in template but using only one? - 1 Update
"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:
Post a Comment