Friday, December 28, 2018

Digest for comp.lang.c++@googlegroups.com - 22 updates in 5 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 27 09:09PM -0500

I think C/C++ needs to have a range-aware modulo operator that will
continue ranging properly when it encounters negative values.
 
We have this:
i = (i + 1) % 10; // Always ranges 0..9
 
But what if you try this when i = 0:
i = (i - 1) % 10;
 
It won't produce the same result in the same pattern seen when you
started at a positive i and tended toward 0. It begins a new trend,
one which is useful, but not always desirable.
 
A range-aware modulo operator would know that it should always be
in the range 0..9 (from the example above), and also that it should
continue the pattern seen in the positive integers, such that when
given a negative input value, it handles the processing differently:
 
// v=value, m=modulo number
int range_modulo(int v, int m)
{
if (v >= 0) return (v % m);
else return ((m + (v % m)) % m);
}
 
int i;
for (i = 12; i >= -12; --i)
printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
 
-----
I propose the -% symbol for the operator.
 
It would allow things that are sometimes needed in video games,
as just one example, when a player hits the left button instead
of the right button, and you need it to go the other way, AND you
want it to just work while using the same math.
 
Just sayin'... :-)
 
--
Rick C. Hodgin
Richard Damon <Richard@Damon-Family.org>: Dec 27 09:34PM -0500

On 12/27/18 9:09 PM, Rick C. Hodgin wrote:
> of the right button, and you need it to go the other way, AND you
> want it to just work while using the same math.
 
> Just sayin'... :-)
 
It used to be that an implementation was allowed to define -1 % 10 to be
9, but they standard changed the rule for division so that that wasn't
allowed anymore. (It required -1/10 == -1)
 
The key fact is that given i, j, m, n as integral types and no overflow
occurring.
 
If i = m / n and j = m % n
then i * n + j == m
 
for j to always be positive, i needs to be the floor of the division,
not from round to 0.
 
The key to remember is that % is NOT the modulus operator, but the
remainder operator (which work the same for positive numbers).
 
It is simple enough to define a mod function that gets the results you
want, so not that much need for a new operator.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 28 03:05AM


> I think C/C++ needs to have a range-aware modulo operator that will
> continue ranging properly when it encounters negative values.
 
It's just the modulus operator. I don't think there's a need for
another name, but 'range-aware' seems like an odd suggestion.
 
Modern C's % is the remainder operator defined to complement C's integer
division: (a/b)*b + a%b = a. (This was not guaranteed in C90.)
 
Some languages (e.g. Haskell) also have two division operators and two
corresponding 'remainder' operators.
 
(a `quot` b) * b + (a `rem` b) == a
(a `div` b) * b + (a `mod` b) == a
 
> We have this:
> i = (i + 1) % 10; // Always ranges 0..9
 
except when i < -1.
 
<snip>
--
Ben.
Robert Wessel <robertwessel2@yahoo.com>: Dec 27 09:31PM -0600

On Fri, 28 Dec 2018 03:05:43 +0000, Ben Bacarisse
>another name, but 'range-aware' seems like an odd suggestion.
 
>Modern C's % is the remainder operator defined to complement C's integer
>division: (a/b)*b + a%b = a. (This was not guaranteed in C90.)
 
 
I think that's wrong. C89/90 did guarantee that relationship, but did
not guarantee the sign of the reminder. IOW, -3/2 could result in
either -1 or -2, with a remainder of -1 or +1 respectively. That
changed in C99.
 
 
>> i = (i + 1) % 10; // Always ranges 0..9
 
>except when i < -1.
 
><snip>
 
 
Forth does something similar.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 28 04:20AM


>>Modern C's % is the remainder operator defined to complement C's integer
>>division: (a/b)*b + a%b = a. (This was not guaranteed in C90.)
 
> I think that's wrong.
 
So do I!
 
> C89/90 did guarantee that relationship, but did
> not guarantee the sign of the reminder.
 
Yes, I was remembering the wrong difference. Thanks.
 
<snip>
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 28 05:37AM +0100

On 28.12.2018 03:34, Richard Damon wrote:
 
> It used to be that an implementation was allowed to define -1 % 10 to be
> 9, but they standard changed the rule for division so that that wasn't
> allowed anymore. (It required -1/10 == -1)
 
Yes, C++11 narrowed the permissible behavior of integer division to
always round towards zero.
 
In contrast, Python always rounds towards negative infinity, like the
mathematical floor function.
 
So, in Python:
 
 
---------------------------------------------------------------------
n_persons = int( input( "How many persons? " ) )
max_per_taxi = int( input( "Maximum passengers per taxi? " ) )
n_taxis = -(-n_persons//max_per_taxi)
print( "You need {} taxis. :)".format( n_taxis ) )
---------------------------------------------------------------------
 
 
But in C++:
 
 
---------------------------------------------------------------------
#include <iostream>
#include <stdexcept>
#include <stdlib.h> // EXIT_...
#include <string>
using namespace std;
 
auto fail( const string& s ) -> bool { throw runtime_error( s ); }
 
auto line_from( istream& stream )
-> string
{
string result;
getline( stream, result ) or fail( "Bah, getline" );
return result;
}
 
auto input( const string& prompt )
-> string
{
cout << prompt;
return line_from( cin );
}
 
void doit()
{
const int n_persons = stoi( input( "How many persons? " ) );
const int max_per_taxi = stoi( input( "Maximum passengers per taxi?
" ) );
const int n_taxis = (n_persons + max_per_taxi - 1)/max_per_taxi;
cout << "You need " << n_taxis << " taxis. :)" << endl;
}
 
auto main() -> int
{
try
{
doit();
return EXIT_SUCCESS;
}
catch( const exception& x )
{
cerr << "!" << x.what() << endl;
}
return EXIT_FAILURE;
}
---------------------------------------------------------------------
 
 
Main test case that 13 persons and max 4 per taxi gives 4 taxis, but 12
persons and max 4 per taxi gives 3 taxis.
 
 
> not from round to 0.
 
> The key to remember is that % is NOT the modulus operator, but the
> remainder operator (which work the same for positive numbers).
 
Yes.
 
 
> It is simple enough to define a mod function that gets the results you
> want, so not that much need for a new operator.
 
 
---------------------------------------------------------------------
#include <iostream>
#include <stdexcept>
#include <stdlib.h> // EXIT_..., div
#include <string>
using namespace std;
 
auto fail( const string& s ) -> bool { throw runtime_error( s ); }
 
auto line_from( istream& stream )
-> string
{
string result;
getline( stream, result ) or fail( "Bah, getline" );
return result;
}
 
auto input( const string& prompt )
-> string
{
cout << prompt;
return line_from( cin );
}
 
namespace math
{
auto is_negative( const int x )
-> bool
{ return (x < 0); }
 
auto div( const int a, const int b )
-> int
{
const div_t r = ::div( a, b );
return (r.quot < 0 and r.rem != 0? r.quot - 1 : r.quot);
}
 
auto mod( const int a, const int b )
-> int
{ return a - b*div( a, b ); }
} // namespace math
 
void doit()
{
const int n_persons = stoi( input( "How many persons? " ) );
const int max_per_taxi = stoi( input( "Maximum passengers per taxi?
" ) );
const int n_taxis = -math::div( -n_persons, max_per_taxi );
cout << "You need " << n_taxis << " taxis. :)" << endl;
}
 
auto main() -> int
{
try
{
doit();
return EXIT_SUCCESS;
}
catch( const exception& x )
{
cerr << "!" << x.what() << endl;
}
return EXIT_FAILURE;
}
 
---------------------------------------------------------------------
 
 
Considering that what C++ offers over Python for this task, is strong
type checking, I wonder if that extreme verbosity and effort is worth it?
 
Well I'm working on a little C++ band aid library that reduces the above to
 
 
---------------------------------------------------------------------
#include <cppx-band-aid/_all_.hpp>
namespace math = cppx::math;
using namespace std;
using cppx::input_line;
 
void doit()
{
const int n_persons = stoi( input_line( "How many persons? " ) );
const int max_per_taxi = stoi( input_line( "Maximum passengers per
taxi? " ) );
const int n_taxis = -math::div( -n_persons, max_per_taxi );
cout << "You need " << n_taxis << " taxis. :)" << endl;
}
 
auto main() -> int { cppx::run_app( doit ); }
---------------------------------------------------------------------
 
 
Standardizing such band-aid functionality for students could be of
interest to the new working group on supporting C++ in education. But I
think I remember that they got a very narrow mandate, next to worthless?
 
 
Cheers!,
 
- Alf
Bart <bc@freeuk.com>: Dec 28 12:29PM

On 28/12/2018 02:09, Rick C. Hodgin wrote:
> as just one example, when a player hits the left button instead
> of the right button, and you need it to go the other way, AND you
> want it to just work while using the same math.
 
I used this loop to better show the differences:
 
for (i = 12; i >= -12; --i) {
if (i==0) puts("");
printf("rmod(%3d,10) = %3d, %3d%%10 = %3d\n", i,
range_modulo(i, 10),i,i%10);
if (i==0) puts("");
}
 
The % operator [which in my language is called 'rem'] shows symmetrical
behaviour around zero, while your range_modulo doesn't.
 
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.
 
"-%" is unlikely to ever work on any. Apart from which, there's already
enough confusion as to exactly what "%" does, let alone "-%", especially
with the /four/ combinations of negative operands.
 
(Note that when m is negative, eg. i/(-10), then both appear to have the
same 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.)
 
--
bart
"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
Richard Damon <Richard@Damon-Family.org>: Dec 28 10:25AM -0500

On 12/28/18 8:10 AM, Rick C. Hodgin wrote:
>>>          if (v >= 0)    return (v % m);
>>>          else           return ((m + (v % m)) % m);
>>>      }
 
In my mind, a cleaner (and actually working) version would be more like:
 
int modulo(int v, int m) {
int mod = v % m;
if (mod < 0) mod += m;
return mod;
}
 
This will work even if v is less than -m and not need multiple divide
operations. (For machines with fast divide but bad behavior for
branching, your expression (m + (v % m) % m could also be used all the
time, if you are going to use the conditional, you don't need the second
% if you do it right.
 
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.
 
>> work /now/ on a hundred compilers.
 
> I think -% is a truly fundamental operation and should have operator
> support.  It has utility in various cases.
 
There are LOTS of operations that could be argued are worthy of operator
support for some applications. There actually is a language that tried
to give them all operator symbols, the language APL. Many consider APL a
write only language, because it can be nearly impossible to read and
understand a program written in APL if you didn't just write it recently.
 
Rather than create a bunch of new symbols as part of the language, I
have thought it would be interesting if C++ allowed the creation of new
operators with NAMES, like operator mod(int v, int m) so you could say
something like v mod m. You would need to be able to define their
'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
 
>> 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.
 
Let me make a small comment about what I see in CAlive. It seems that
you are trying to define what you want to call a 'Language' by going
something (a bit crudely) like:
 
Lets start with something like C (which I don't really fully
understand), and then remove these features that don't make sense to me
so I could never make them work right.
 
Lets then mix in some bits of C++, but not too much, because that
langauge is so complicated that I can't understand it much of it.
 
Lets then add in all sorts of nifty little micro-tricks that I wish were
in C and/or C++, not worrying about how they might interact.
 
I can't understand formal documentation, so I can't write anything like
that myself, so I will document the language as with just a list of the
Hodge-podge rules that I built it with, but that's ok, the formal
specification will be the program I will eventually write (which I guess
means there can't be problems in the language definition, as the
language definition will be exactly as what that implementation did)
 
I have nothing against the idea that you want to create this new
programming environment with all the nifty bells and whistles that you
want. When (and if) it is done, it may even be useful to others, IF you
are able to produce a coherent set of documentation that tells people
how to use it. What does bother me a bit is the idea that you have that
this is somehow something very important (or should be to others). From
what I have heard you describe, your Grand Design is enormous, and very
likely beyond your reach and ability.
 
There actually isn't anything wrong with aiming for something you likely
can't reach, as long at the journey to it is something that can be
worthwhile (as in the story of Don Quixote). The issues come when you
try to insist that others need to follow or value your efforts.
Bart <bc@freeuk.com>: Dec 28 03:56PM

On 28/12/2018 15:25, Richard Damon wrote:
> '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
 
I think, to start with, it would be more useful to have overloaded
functions. That means you can write this new feature as mod(v,m), so no
issues with precedence. And you don't get the problem of parsing an
expression that looks like this:
 
a b c d e f g h
 
of which some are variables, and some are operators (a mix of prefix,
infix and postfix), but you have to resolve all of them before you can
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.
 
> this is somehow something very important (or should be to others). From
> what I have heard you describe, your Grand Design is enormous, and very
> likely beyond your reach and ability.
 
I think the problem is also the proliferation of weird and wonderful
features, which are hard to understand, look hard to use, and would make
any code that uses them completely unreadable:
 
https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
Whether these all these features can interact with each other is another
matter.
 
--
bart
"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."
woodbrian77@gmail.com: Dec 28 08:04AM -0800

On Wednesday, December 26, 2018 at 3:55:56 PM UTC-6, Mr Flibble wrote:
> > Linux, winStart() is a no-op. 2019 would be a
> > good time to clean that up!
 
> Just use boost.asio.
 
That library has the same wart. Also, my program is
intended to be very portable. It's 35 lines and doesn't
have any external dependencies.
 
> [snip]
 
> /Flibble
 
Brian
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.
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)