Saturday, January 5, 2019

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

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: