- Hell is real, so is Heaven - 6 Updates
- My C++ synchronization objects library was just updated - 1 Update
- atomic xchg based stack, for learning... - 3 Updates
- Range-aware modulo operator -% - 6 Updates
- Func-var members - 4 Updates
- Add integer value 38 operator ~..~ - 1 Update
- Shorthand ~> pointers - 1 Update
- if cargo blocks - 3 Updates
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 10:30AM Don't be fooled by the peddlers of fake religions and fake gods. Follow the one true god: The Flying Spaghetti Monster. Hell is real: hell is distance from pasta sauce. Heaven is real: heaven is to be at one with pasta sauce. But I need proof that your religion is the correct one! I hear you shout... The Flying Spaghetti Monster is the one true god because it is so written in The Bible of the Church of the Flying Spaghetti Monster and The Bible of the Church of the Flying Spaghetti Monster is correct because it is so written in The Bible of the Church of the Flying Spaghetti Monster -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
gazelle@shell.xmission.com (Kenny McCormack): Dec 29 01:00PM In article <y1IVD.422856$qL3.74163@fx29.fr7>, >in The Bible of the Church of the Flying Spaghetti Monster and The Bible >of the Church of the Flying Spaghetti Monster is correct because it is so >written in The Bible of the Church of the Flying Spaghetti Monster It really is funny the fact that Rick is so stupid that he is incapable of realizing how accurate this post is - and how much his own religion is no better (and no worse) than yours. Point of fact: They're all the same. And as the wise man sayeth: They can't all be right. But they can all be wrong. -- People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf. George Orwell |
Melzzzzz <Melzzzzz@zzzzz.com>: Dec 29 01:08PM > better (and no worse) than yours. > Point of fact: They're all the same. > And as the wise man sayeth: They can't all be right. But they can all be wrong. Rick is brainwashed cultist. No point in discussing with him... -- press any key to continue or any other to quit... |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 03:04PM On 29/12/2018 14:21, Rick C. Hodgin wrote: [snipped TL;DR] Jesus believed the Old Testament was the commandment of God (Matthew 15:3) ergo Jesus believed that homosexuals should be put to death (Leviticus 20:13). Do you agree with Jesus that homosexuals should be put to death or not? If Jesus is wrong about putting homosexuals to death then what else is Jesus wrong about? I thought gods were supposed to be infallible. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 03:04PM On 29/12/2018 04:03, Rick C. Hodgin wrote: [snipped TL;DR] Jesus believed the Old Testament was the commandment of God (Matthew 15:3) ergo Jesus believed that homosexuals should be put to death (Leviticus 20:13). Do you agree with Jesus that homosexuals should be put to death or not? If Jesus is wrong about putting homosexuals to death then what else is Jesus wrong about? I thought gods were supposed to be infallible. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 03:05PM On 29/12/2018 14:49, Rick C. Hodgin wrote: [snipped TL;DR] Jesus believed the Old Testament was the commandment of God (Matthew 15:3) ergo Jesus believed that homosexuals should be put to death (Leviticus 20:13). Do you agree with Jesus that homosexuals should be put to death or not? If Jesus is wrong about putting homosexuals to death then what else is Jesus wrong about? I thought gods were supposed to be infallible. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
Horizon68 <horizon@horizon.com>: Dec 29 06:04AM -0800 Hello.. My C++ synchronization objects library was just updated, now it is more enhanced and more stable and fast, it contains many of my inventions such as my scalable RWLock that is starvation-free and my SemaMonitor and my scalable MLock and many others of my inventions.. You can download the new updated version from: https://sites.google.com/site/scalable68/c-synchronization-objects-library Thank you, Amine Moulay Ramdane. |
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 04 06:37PM -0800 On 12/28/2018 11:30 PM, Chris M. Thomasson wrote: > waiting. The algorithm can be improved upon quite a bit. I have some > "interesting" ideas for it. Well, here is the code in the form of a > Relacy unit test: [...] Fwiw, I finally found the time to code this experimental implementation up in c++11. Here is the code: https://pastebin.com/raw/j41cPT9S (raw text, C code, no ads...) ____________________________________ // Simple XCHG based Atomic Stack // By: Chris M. Thomasson #include <iostream> #include <atomic> #include <mutex> #include <thread> #include <functional> #include <cassert> // sorry about the macros... #define THREADS 42 #define ITERS 100000 #define CT_MB_RLX std::memory_order_relaxed #define CT_MB_ACQ std::memory_order_acquire #define CT_MB_REL std::memory_order_release // HACK! Humm... #define CT_WAIT ((ct_work*)(0xDEADBEEFU)) // Just to track all the dynamic allocations... static std::atomic<unsigned long> g_allocs(0); static std::mutex g_cout_mtx; // A work node struct ct_work { std::atomic<ct_work*> m_next; std::thread::id m_data; ct_work(std::thread::id data) : m_next(nullptr), m_data(data) {} void process() { // Simulate just a tiny little work? g_cout_mtx.lock(); std::this_thread::yield(); std::this_thread::yield(); std::this_thread::yield(); std::thread::id local = std::this_thread::get_id(); if (m_data == local) { // std::cout << "processing local = " << m_data << // " from " << std::this_thread::get_id() << "\n"; } else { std::cout << "processing foreign = " << m_data << " from " << std::this_thread::get_id() << "\n"; } std::this_thread::yield(); std::this_thread::yield(); std::this_thread::yield(); g_cout_mtx.unlock(); } ct_work* get_next() const { ct_work* w = nullptr; while ((w = m_next.load(CT_MB_RLX)) == CT_WAIT) { // we can spin, or even do other work right here... std::this_thread::yield(); } return w; } }; // Easy Stack, only uses XCHG struct ct_estack { std::atomic<ct_work*> m_head; ct_estack() : m_head(nullptr) {} void push(ct_work* n) { n->m_next.store(CT_WAIT, CT_MB_RLX); ct_work* head = m_head.exchange(n, CT_MB_REL); // release n->m_next.store(head, CT_MB_RLX); } ct_work* flush_try() { return m_head.exchange(nullptr, CT_MB_ACQ); // acquire } }; // Consume an Easy Stack... void ct_consume( ct_estack& estack ) { ct_work* w = estack.flush_try(); while (w) { // Process FIRST! w->process(); // Now, we can gain the next pointer. ct_work* next = w->get_next(); // Okay, we can delete the work delete w; g_allocs.fetch_sub(1, CT_MB_RLX); // dec w = next; } } // Our shared state struct ct_shared { ct_estack m_estack; }; // Produce some work... void ct_produce( ct_estack& estack ) { ct_work* w = new ct_work(std::this_thread::get_id()); g_allocs.fetch_add(1, CT_MB_RLX); // inc estack.push(w); } // Do some work... void ct_worker(ct_shared& shared) { for (unsigned int i = 0; i < ITERS; ++i) { ct_produce(shared.m_estack); ct_produce(shared.m_estack); ct_produce(shared.m_estack); std::this_thread::yield(); // little spice... ct_consume(shared.m_estack); } ct_consume(shared.m_estack); } int main(void) { { ct_shared shared; std::thread threads[THREADS]; for (unsigned long i = 0; i < THREADS; ++i) { threads[i] = std::thread(ct_worker, std::ref(shared)); } for (unsigned long i = 0; i < THREADS; ++i) { threads[i].join(); } } if (g_allocs.load(CT_MB_RLX) != 0) { std::cout << "\n\nLEAKED!!!!\n"; } std::cout << "\n\nFIN!\n"; return 0; } ____________________________________ Can anybody get this sucker to compile and run to completion? If so, can you show me some of the output? I am getting some data like in GCC: ____________________________________ processing foreign = 33 from 32 processing foreign = 33 from 32 processing foreign = 33 from 32 processing foreign = 41 from 26 processing foreign = 41 from 26 [...] ____________________________________ And some like the following in MSVC, the thread ids are larger there: ____________________________________ processing foreign = 15644 from 9844 processing foreign = 15644 from 9844 processing foreign = 18092 from 19964 processing foreign = 18092 from 19964 ____________________________________ Any thoughts? |
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 04 06:40PM -0800 On 1/4/2019 6:37 PM, Chris M. Thomasson wrote: > up in c++11. Here is the code: > https://pastebin.com/raw/j41cPT9S > (raw text, C code, no ads...) [...] Fwiw, it boils down to the following code: ________________________________ // A work node struct ct_work { std::atomic<ct_work*> m_next; std::thread::id m_data; ct_work(std::thread::id data) : m_next(nullptr), m_data(data) {} void process() { // [...] // real work... } ct_work* get_next() const { ct_work* w = nullptr; while ((w = m_next.load(CT_MB_RLX)) == CT_WAIT) { // we can spin, or even do other work right here... std::this_thread::yield(); } return w; } }; // Easy Stack, only uses XCHG struct ct_estack { std::atomic<ct_work*> m_head; ct_estack() : m_head(nullptr) {} void push(ct_work* n) { n->m_next.store(CT_WAIT, CT_MB_RLX); ct_work* head = m_head.exchange(n, CT_MB_REL); // release n->m_next.store(head, CT_MB_RLX); } ct_work* flush_try() { return m_head.exchange(nullptr, CT_MB_ACQ); // acquire } }; ________________________________ Fairly simple? |
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 28 11:30PM -0800 Here is the original link: https://groups.google.com/d/topic/lock-free/wwsAmcuAefA/discussion This experimental algorithm uses only XCHG at the cost of having a consumer wait for the next pointer to be set in a node. However, it allows for real work to be done before any waits are performed. So, the "real" work should provide a "natural backoff" that might minimize the waiting. The algorithm can be improved upon quite a bit. I have some "interesting" ideas for it. Well, here is the code in the form of a Relacy unit test: Notice the "hand off" comments and 0xDEADBEEF, this can be made to work much better... Relacy Unit Test, C++ ____________________________ // Simple Atomic Stack // For Academic and Experimental things... // Beginner, Moderate? // In Good Ol' Relacy! Nice as always. //_______________________________________________ //#define RL_DEBUGBREAK_ON_ASSERT //#define RL_MSVC_OUTPUT //#define RL_FORCE_SEQ_CST //#define RL_GC #include <relacy/relacy_std.hpp> #include <iostream> // Simple macro based redirection of the verbose std membars. #define CT_MB_ACQ std::memory_order_acquire #define CT_MB_REL std::memory_order_release #define CT_MB_RLX std::memory_order_relaxed #define CT_MB_ACQ_REL std::memory_order_acq_rel #define CT_MB_SEQ_CST std::memory_order_seq_cst #define CT_MB(mp_0) std::atomic_thread_fence(mp_0) // Some global vars directing the show... #define THREADS 3 #define ITERS 2 // Experimental Stack struct ct_ecstack { #define WAITNEXT ((node*)0xDEADBEEF) struct node { std::atomic<node*> m_next; VAR_T(unsigned int) m_data; node(unsigned int data) : m_next(nullptr), m_data(data) {} void process() { // simulate some work? rl::yield(1 + rl::rand(2), $); // ;^) } node* next_wait() { node* next = nullptr; while ((next = m_next.load(CT_MB_RLX)) == WAITNEXT) { // Humm, we can actually do other work right here... // Hand off... rl::yield(1, $); } return next; } }; std::atomic<node*> m_head; ct_ecstack() : m_head(nullptr) {} void push(node* n) { n->m_next.store(WAITNEXT, CT_MB_RLX); node* head = m_head.exchange(n, CT_MB_REL); // release n->m_next.store(head, CT_MB_RLX); } node* flush_try() { return m_head.exchange(nullptr, CT_MB_ACQ); // acquire } }; // Relacy Stack Test... struct ct_ecstack_test : rl::test_suite<ct_ecstack_test, THREADS> { ct_ecstack g_ecstack; void process() { ct_ecstack::node* n = g_ecstack.flush_try(); // flush all while (n) { // Process n first, acts like a backoff for the next wait // Hand off some other nodes? Future note... n->process(); // Wait for the next pointer, or hand off? ct_ecstack::node* next = n->next_wait(); // Destroy delete n; // Loop on... n = next; } } void thread(unsigned int tidx) { for (unsigned int i = 0; i < ITERS; ++i) { g_ecstack.push(new ct_ecstack::node(tidx)); g_ecstack.push(new ct_ecstack::node(tidx)); g_ecstack.push(new ct_ecstack::node(tidx)); process(); g_ecstack.push(new ct_ecstack::node(tidx)); } process(); } }; // Test away... Or fly? Humm... int main() { { rl::test_params p; p.iteration_count = 10000000; //p.execution_depth_limit = 33333; //p.search_type = rl::sched_bound; //p.search_type = rl::fair_full_search_scheduler_type; //p.search_type = rl::fair_context_bound_scheduler_type; rl::simulate<ct_ecstack_test>(p); } return 0; } ____________________________ It is very simple, but might be "interesting". ct_ecstack is what I am focusing on. Producer's use ct_ecstack::push to add a node to the stack, and Consumers use ct_ecstack::flush_try to remove all of the nodes in one shot. All of the atomic operations use XCHG. There is a special caveat that this can create... The consumers need to use ct_ecstack::node::next_wait to gain next pointers wrt their iteration process. A consumer can consume more than one node, so it needs to iterate. One point, real work is performed before any wait is performed. For instance, take a look at ct_ecstack_test::process: ____________________________ void process() { ct_ecstack::node* n = g_ecstack.flush_try(); // flush all while (n) { // Process n first, acts like a backoff for the next wait // Hand off some other nodes? Future note... n->process(); //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ // We process before we: // Wait for the next pointer, or hand off? ct_ecstack::node* next = n->next_wait(); // Wait. Might be beneficial... // Destroy delete n; // Loop on... n = next; } } ____________________________ Might be pretty cool wrt its simplicity, and no use of CAS! ;^) |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 08:10AM -0500 On 12/28/2018 7:29 AM, Bart wrote: > Both behaviours are useful for different purposes. But the simplest thing to > do is to just keep it as a function, as like that it will work /now/ on a > hundred compilers. I think -% is a truly fundamental operation and should have operator support. It has utility in various cases. > behaviour. The modulo nature of your range_modulo disappears. You may wish to > use abs(m) inside that function, and perhaps re-apply the sign to the result, > if that is important.) Interesting. I've never used a negative value that way, so it never occurred to me. -- Rick C. Hodgin |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 11:44AM -0500 On 12/28/2018 10:25 AM, Richard Damon wrote: > ... The issues come when you > try to insist that others need to follow or value your efforts. Where have I ever insisted that anyone needs to follow or value my efforts? I have told people recently, "Don't use [CAlive]... You won't hurt my feelings." I have only ever asked people to come and help. They will when the time is right if this task is for me to complete. If not, it will still have been my best attempt at giving back to the Lord what He first gave me, and there is no failure in that pursuit. ----- If you'd like to help formalize CAlive's design, come on board and do so. It's not my forte, but I know it's other people's. I truly admire people like Keith Thompson, who can have so much of the standard memorized and be able to recall it appropriately on command. I am that way on Star Trek in many areas. :-) But, not for things I must read to absorb. I welcome people to come on board and help. It's a design given over to holiness and prayer, serving the Lord's goals in this world, meaning we don't go by a pursuit of profit-seeking, or money-making. We are designing things correctly from inception, with the goal being truly to empower people by giving them the source code in the Public Domain. It is a goal to replace busi- ness models with helping-one-another models. It is a goal to use our talents to remove the burdens and shackles of proprietary software and hardware models (as my goals extend not just to CAlive and RDC, but also to a new operating system (one similar to a modernized version of OS/2), as well as new hardware (I have a CPU design called Inspire that's revolutionary in how it ap- proaches data processing), and I want to provide people with a full hardware and software stack that allows us to manufacture things together, for one another, and not for avarice, greed, or personal gain, but that our gains would all come in helping one another achieve more and succeed in their personal goals and in- terests, and then to teach them to have the same goals and inter- ests in the things they pursue in their life. It's a goal of togetherness. It's the motto I've used since about 2013 on my project: In God's sight, we've come together. We've come together to help each other. Let's grow this project up ... together! In service and Love to The Lord, forever It is a full-on vision of "Thy Kingdom come, Thy will be done, on Earth as it is in Heaven." These are the areas to which I have interest and expertise. I pursue them, but my goals are to teach other people to use their personal interests and areas of expertise to serve the Lord from where they are, in their station, with their calling. It is a grand vision. It is in my heart, soul, mind, and pressed hard upon my spirit ... and I am pursuing it. Others will come on board to help when they are so moved to do so. -- Rick C. Hodgin |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 12:16PM -0500 On 12/28/2018 10:25 AM, Richard Damon wrote: > Neither of these work 'right' if m can be negative, and for that we need > to come up with a real definition of what it means to have a negative > modulus. I'm all for creating an encompassing algorithm. I only ever use a positive m in my code, and my values of v should never be more than relatively small integers away from 0 positive or negative, so it's not a large need in my specific task. But, if it works another way, I'm all for it. > 'precedence' so the compiler would know how to parse the expression, the > simplest would likely be to define them to act like and existing type of > operator, so How many new symbols have I created, or implemented in CAlive? When I post things here, it is to gain knowledge about C/C++, so I can learn something I may not know (most times I'm pretty sure the thing I'm in pursuit of doesn't already exist) ... and then also to convey the thought I have so that other people can take it, modify it, extend it, revise it, and implement it however they want to. With CAlive, I'm moving forward as I am doing. With C/C++, these are all offerings given to spark the minds and creative resources of those people involved in authoring their compilers for those languages, or those who are influential in moving things this way or that way within the ecosystem. People are free to disregard (or mock, as Leigh does), my posts to their full pleasure. While it sometimes hurts and is annoying, I'm pretty tough. I can take it. I have a solid foundation in knowing who it is I serve, and my goals are to please Him first, the rest of the world will either see value in what I do/post or not. That's not up to me. I do my best at all points continuously, and I still fail a lot. But my heart's intent is right, true, proper, and is becoming even more honed over time. It is from that place, sanctified and focused unto the Lord, that I continue with all of these efforts. It's a real thing. Not a trifle. Not a joke. Not a delusion. And I do not have one negative thing at work in any of my intents or goals. I may make mistakes, but that's different from a purposeful intent away from doing all things positive. I stand before the Lord regularly in prayer asking Him if this is for me to do, being willing many times to walk away from it all because it is such a big task. Every time, literally every time I've begun to have those thoughts, something comes along to re-encourage me, and I go back into prayer and again ask the Lord if I am to continue as I press in again toward the goal. My life is not just lived. I have a purpose in the things I do. They are not for trivial wants, wishes, desires, etc. I am truly seeking to give the world something better than it has, and to lift people up from their pressed-down place by entities that focus on money-interests, on proprietary goals. I am seeking to free everyone from those chains with my labor, my talent focused to improve and augment and enhance their personal lives. It is a proper goal on all accounts, and it's the one I've been pursu- ing now for seven years this Spring, and formally as an effort seven years on July 12, 2019. -- Rick C. Hodgin |
Richard Damon <Richard@Damon-Family.org>: Dec 28 05:08PM -0500 On 12/28/18 12:16 PM, Rick C. Hodgin wrote: >> simplest would likely be to define them to act like and existing type of >> operator, so > How many new symbols have I created, or implemented in CAlive? Looking over the past 6 months of messages, I see suggested: min/max: \/ /\ \/= /\= swap: >< shortcut indirect: ~> which later became ~~ modulus: -% and that doesn't count syntax changes like a < b < c I don't know how many have actually been implemented (and is CAlive actually far enough along to 'implement' something? > I'm in pursuit of doesn't already exist) ... and then also to convey > the thought I have so that other people can take it, modify it, extend > it, revise it, and implement it however they want to. But you DON'T ask to gain knowledge. You post that there should be a way to do xyz, and then state how you think it will work in CAlive. > my heart's intent is right, true, proper, and is becoming even more > honed over time. It is from that place, sanctified and focused unto > the Lord, that I continue with all of these efforts. But this is comp.lang.c and comp.lang.c++ so extensive discussion of CAlive is really off topic in both of these, as CAlive is NOT either of these languages, or even a minor variation/extension on it like gcc c/c++ (many of those extension are still conformant to the C/C++ Standards.) You seem to want to pretend that you are offering 'legitimate' ideas for extensions to C and/or C++ but seem to have zero understanding of the hows and whys these languages are the way they are, and you don't seem to care. It would be one thing if you came here asking HOW to implement some feature of CAlive in your chosen implementation language in the appropriate group (but choose the language to use, and thus the group to ask, as things are done significantly differently between those two languages). You could also ask about general language design issues in a different appropriate group (NOT clc or clc++). > It is a proper goal on all accounts, and it's the one I've been pursu- > ing now for seven years this Spring, and formally as an effort seven > years on July 12, 2019. Scripture tells us to obey the rules of the land. The one exception given is if those rules tell you to do something that directly contradicts a rule of God. One of these rules is that these groups have a defined topic space, which is discussion of things closely related to the C or C++ languages and their use. Unless you can find some direct command of God that following this rule will make you violate, you should try to follow that rule, for to do otherwise inflicts a bad report onto your God. Your posts as 'offerings' are really nothing but SPAM, which is not something I think God wants, nor does he want to be thought of as connected to a spammer. |
Richard Damon <Richard@Damon-Family.org>: Dec 28 05:26PM -0500 On 12/28/18 10:56 AM, Bart wrote: > start to parse. (I understand one feature of CAlive is that definitions > for all these can come later.) > This doesn't help the human reader much either. First, yes using functions (as currently available) is currently available, and in C++ you can use overloaded functions, and in C you can use _Generics to build such expressions. The issue is that building an equation with explicit function calls can get hard to read also. That is why C++ included opererator overloading and the C added _Generics. And expression like: assign(d, mult( diff(ax, bx), diff(ay, by))); just gets hard to read, compare to d = (ax - bx) * (ay - by); is much clearer. Yes, misused it can make things an unreadable mess, but an expression like e(b(a, c(d)), g(f,h)); isn't really any more readable, maybe you know a bit more about what the various symbols are, but you still need to explore each of them to figure out what is what. Using good names is always important. New operators, being effectively globals, would need to be used sparingly, and well named. |
Sjouke Burry <burrynulnulfour@ppllaanneett.nnll>: Dec 28 11:45PM +0100 On 28-12-2018 23:26, Richard Damon wrote: > figure out what is what. Using good names is always important. > New operators, being effectively globals, would need to be used > sparingly, and well named. In a c newsgroup, why are you blabbering about c++? |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 09:06AM -0500 I had a programming situation today where I'm iterating through some- thing using a standard int as access into a character string. I have need at various points to use reference variables to its current value (as it iterates), to later refer back to the prior value to determine the length, etc. I was parsing something like this: aaaa = bbbb + cccc; I encounter "a" and proceed forward while it's a letter, then I en- counter a whitespace, and continue forward while it's a whitespace, and then "b", and then ws, then plus, then ws, then "c", etc. It was a simple loop, but I had to do it using disparate parts. It made me think about some abilities that could be added to aid devel- opers, namely the ability to easily encapsulate variables and functions related to those variables, both related to their parent, on-the-fly, something I named "Func-var members" in the subject. Consider: int i, i_start, len; // Iterate through something[] until maxlen (defined // elsewhere) is attained for (i = 0; i < maxlen; ) { if (something[i] == whatever) { // Iterate for (i_start = i, ++i; something[i] == whatever; ) ++i; // Right now, we have i_start, and i is pointing to // the first character after. len = i - i_start; printf("%d bytes\n", len); } else { ++i; } } Here we see i, i_start, and len, all being related, but there's no clear indicator of that until you read the code. What if instead we had the ability to define combination member- functions + member-variables, using a syntax like this below, using func() to run the code, or the value itself to reference its value. The values can also be set using something like i.start = 5; It can be defined locally, in context, and very simply: int i { start { i; ++i }; // Create i.start as this operation len { i - start }; // Create i.len as this operation }; // Iterate through something[] until maxlen (defined // elsewhere) is attained for (i = 0; i < maxlen; ) { if (something[i] == whatever) { // Iterate for (i.start(); something[i] == whatever; ) ++i; // Right now, we have i_start, and i is pointing to // the first character after. i.len(); // Set the value printf("%d bytes\n", i.len); // Reference the value } else { ++i; } } This has the benefit of encapsulating related variables, defining their operations locally, and creating both functions and variables with the same name, referenced to their parent where needed: int i { // Syntax here is name, followed by {..}, with the lines // conveying values being assigned to the name, and actual // code being run as it's encountered start { i; ++i }; // Creates i.start as this operation // Usable as i.start() to run, i.start // to reference its value len { i - start }; // Creates i.len as this operation // Usable as i.len() to run, i.len to // reference its value }; If a type override is needed, prefix the name and set it, otherwise it uses the default type of the parent: int i { start { i; ++i }; len { i - start }; float proportion { (float)i.len / (float)maxlen }; // Creates i.proportion as this operation }; Above, start and len are assumed int, while proportion's type is dif- ferent, so it's explicitly named. -- Rick C. Hodgin |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 09:29AM -0500 On 12/28/2018 9:06 AM, Rick C. Hodgin wrote: > start { i; ++i }; // Create i.start as this operation > len { i - start }; // Create i.len as this operation > }; These should probably be defined as: int i { start { i++ }; // Loads value, then increments len { i - start }; // Current i minus the start value }; -- Rick C. Hodgin |
Bart <bc@freeuk.com>: Dec 28 04:39PM On 28/12/2018 14:06, Rick C. Hodgin wrote: > It can be defined ... very simply: It's simplicity is eluding me right now... > }; > Above, start and len are assumed int, while proportion's type is dif- > ferent, so it's explicitly named. So here: int i { fred{++i}}; // declare special function fred i = 10; i.fred(); // call fred(), evaluate and store // ++i, ie. 11 i = 20; i.fred; // retrieve the value 11 i.fred(); // evaluate ++i (21) and store. ? If so, what is the advantage to just doing this: int i, i_fred; i=10; i_fred=++i; i=20; i_fred; i_fred=++i; This seems to be mixing up several concepts: lambdas, function pointers (if i.start() calls a function, i.start is usually a pointer), local functions and, I think, closures. For example what happens here: int a=6; int i {fred {i+a}}; { a=8; double a=9876; i=10; i.fred(); .... Does i.fred store 16,18, or 9886.0? -- bart |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 28 11:53AM -0500 On 12/28/2018 11:39 AM, Bart wrote: > // ++i, ie. 11 > i = 20; > i.fred; // retrieve the value 11 The use of "i.fred;" would be the same as "i;" on a line by itself. It has no impacting operation. > i.fred(); // evaluate ++i (21) and store. > ? Your example would be unfurled as you indicate: > i=20; > i_fred; > i_fred=++i; Encapsulation, in that "fred" relates to i, and is contextual to i. It has a direct relationship there, and is encapsulated thusly. It's also a simple syntax easily conveyed right there at use. It doesn't require use of #defines to do things. It's not a class defined else- where. It's for short, local encapsulation of things that are rele- vant or needed only there in the immediate vicinity. > i.fred(); > .... > Does i.fred store 16,18, or 9886.0? Whatever's most local in scope to each instance use, so it would store: fred = (int)((double)i + a/*9876.0*/); -- Rick C. Hodgin |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 28 04:35PM Hi! I propose the addition of the following operator to C++ (and also for my own amazing C/C++-like language I am working on due to mental illness): Add integer value 38 operator: ~..~ Rationale There is a quite a common need to add the integer value 38 to something ergo there is a need to provide that facility as a built-in operator. Usage int n = 1; std::cout << "38 + 1: " << ~..~n << std::cout; outputs: 38 + 1: 39 To increase its utility beyond just the number 38 (sometimes other integers are needed) arithmetic can be used on it: (~..~-(~..~/~..~))n; // 37 + n With the help of the one true god (The Flying Spaghetti Monster) I hope this important proposal is ratified by the C++ ISO committee. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 01:35PM +0100 >> Do you have only such superfluous, idiotic and obfuscating ideas? > I suppose the answer to that question is a matter of subjective opinion. Of course, but most programmers would consider this like that. |
seeplus <boardmounrt@gmail.com>: Jan 04 03:43PM -0800 On Saturday, January 5, 2019 at 8:56:59 AM UTC+11, Rick C. Hodgin wrote: > I want you to go > on after you leave this world, alive, prospering, in God's own > Kingdom. So then you will have an eternity to commit to memory all those CAlive rules and operations. |
fir <profesor.fir@gmail.com>: Jan 04 03:55PM -0800 W dniu piątek, 4 stycznia 2019 23:51:02 UTC+1 użytkownik fir napisał: > im not friend to psyhopaths, dik.. it would be like friendship with a zombie (and zombie 'defines' this friendship as a feeding his friends with bulshit, and eating his friends brains... so no, tnx to be honest im closer to think that maybe i should some 'account' to you make you to pay for all that preposterous bulshit you impose on people but probably some judges, would say then that youre medically disabled ... still level of your stupidity surprises me very negatively.. |
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 04 05:15PM -0800 On 1/4/2019 10:03 AM, Queequeg wrote: >> Rick's rather bizarre theology, or other such generalisations from >> single outlying cases. > Thanks, David. I appreciate that. Very nice. |
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