Wednesday, December 6, 2017

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

Intelli2 <intelli2@mama.com>: Dec 06 02:54PM -0500

Hello,
 
 
I have scored above average on logical reasonning on IQ tests
 
So even with my handicaps , i can think correctly and i have invented
many scalable algorithms.
 
 
Thank you,
Amine Moulay Ramdane.
fir <profesor.fir@gmail.com>: Dec 06 09:41AM -0800

W dniu poniedziałek, 4 grudnia 2017 18:38:38 UTC+1 użytkownik Rick C. Hodgin napisał:
 
> --
 
> Thank you,
> Rick C. Hodgin
 
incidentally hodgin is an idiot,
some say god could get mercy for
idiots - but hodgin is also a troll
and harmmaking vandalizing moron
 
and at this point he becomes bad moron and i would wory being him
about being 'locked in hell' for
his quite reall harmmaking
trolling sins of heavy idiot (same with another brainless moron spammer ramine)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 06 10:10AM -0800

On Wednesday, December 6, 2017 at 12:41:51 PM UTC-5, fir wrote:
 
> > --
 
> > Thank you,
> > Rick C. Hodgin
 
I did not write the above, of course. Leigh Johnston is again
impersonating my identity.
 
> about being 'locked in hell' for
> his quite reall harmmaking
> trolling sins of heavy idiot (same with another brainless moron spammer ramine)
 
If I were truly spamming it might be as you say, fir. But today you
are not forgiven for your sin by Jesus Christ. Most other people in
these groups I post to are not either. As such, were any of you to die
today you would spend an eternity in Hell for your rebellion in sin.
 
I would save you from that Hellfire end, fir.
 
That is the extent of the messages I post:
 
1) You have sin.
2) You will be judged for your sin.
3) You will be found guilty and cast into Hellfire ... forever!
4) Jesus doesn't want that end for you (I don't either).
5) He came here as a man to do what we could not: save us.
6) He offers salvation to EVERYONE for free just for the asking.
7) I teach you that you NEED to ask Him to forgive you.
 
The information is before you, fir. It's before everyone else as well.
Your entire future depends on what you do with Jesus Christ.
 
I urge you to investigate it.
 
--
Rick C. Hodgin
Daniel <danielaparker@gmail.com>: Dec 06 10:22AM -0800

On Wednesday, December 6, 2017 at 1:10:46 PM UTC-5, Rick C. Hodgin wrote:
 
 
> I would save you from that Hellfire end, fir.
 
Have you sold all of your possessions and given them to the poor? Best to work
on yourself first.
 
Thanks,
Daniel
fir <profesor.fir@gmail.com>: Dec 06 10:47AM -0800

W dniu środa, 6 grudnia 2017 19:22:55 UTC+1 użytkownik Daniel napisał:
 
> > I would save you from that Hellfire end, fir.
 
> Have you sold all of your possessions and given them to the poor? Best to work
> on yourself first.
 
frst rule of talikng with idiot rick probably could be:
 
dick is idiot so treat him as an idiot, talk to him as he would be idiot as he really is
 
if you would try to assume he is normal ans intelligent/sane you will probably always feel cheated
(as this assumption will fail)
 
treat this moron as an idiot and
you got a bigger chance to make more reliable relation ;c
 
(anuway ofc making relations with such heavy morons may be unplesant andaestethically harmfull (becouse ge will feed you with a brainless trash constantly ruining quality of your environment ;c))
"Öö Tiib" <ootiib@hot.ee>: Dec 06 10:55AM -0800

On Wednesday, 6 December 2017 20:22:55 UTC+2, Daniel wrote:
 
> > I would save you from that Hellfire end, fir.
 
> Have you sold all of your possessions and given them to the poor? Best to work
> on yourself first.
 
Bjarne Stroustrup said very well about the likes of Rick:
"People who think they know everything really annoy those of us who know we
don't."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 06 06:59PM

On 06/12/2017 18:10, Rick C. Hodgin wrote:
>>> Rick C. Hodgin
 
> I did not write the above, of course. Leigh Johnston is again
> impersonating my identity.
 
If Leigh Johnston is again using satire to counter your off topic
religious spamming then he is doing it because you are making off topic
religious spam again. Pretty simple logic. Derp.
 
/Flibble
Intelli2 <intelli2@mama.com>: Dec 06 12:50PM -0500

Hello,
 
 
About my genetical handicaps..
 
I can not have a conversation with people because of a genetical
handicap that i have, i can not substain a conversation with people
because of my genetical handicap, but i can listen to conversations of
people and understand them correctly, also i can think correctly, it is
that i can not substain or have a conversation with people because
of my genetical handicap, also i am handicaped from my memory in my
brain, my memorization is very poor, it is another genetical handicap, i
have also other genetical handicaps also, so you have to know how to be
patience with handicaped people.
 
 
 
Thank you,
Amine Moulay Ramdane
fir <profesor.fir@gmail.com>: Dec 06 09:23AM -0800

recently i run some test with my friend girl assistant koteq/cybergoth
 
the test app was 2 dots in window one i move with mouse other my assistant move and the other-person coordinates was sent per frame (via tcp socket)
 
i think i would like to make some kind of peer-to-peer pong game (two paddles and one ball) but the problem may be i guess the delay betwean sending and incoming packets
 
(i know what i ask is basic in network programming vut i never was coding it so i think i must rethink those basics and overall it is/should be interesting for every c programmer that want to touch a network at all)
 
i guess the typical pessymistic delay
between a time of sending and time of receiving may be 100 (200?) ms ..
if game is moderatelly dynamic i think the element like paddle or ball may move with speed of one screen width/height a second so the difference in a position then could be
1/10 or 1/5 of size of screen
 
right now i got no idea how to make simple code for that game that would minimalize the inpact of this deley
to players
 
how to code that?
 
should i code it in some symmetric way
make the delay be halved on two players or what?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 06 12:43AM +0100

On 12/5/2017 4:43 PM, James R. Kuyper wrote:
> The expressions ++i and i++ both have side-effects (incrementing the
> value of i), and both perform value computations using the value of i.
> Therefore, this expression has undefined behavior.
 
You apparently didn't read what Stefan quoted.
 
In particular, C++17 §8.8/4, that he quoted, directly contradicts your
assertion that only `&&`, `||`, `?:` and the comma operator prescribe
the order of evaluation of their operands.
 
I don't understand why Stefan is asking because it's very clear that
with C++17 rules, as quoted, the expression is well defined.
 
The final draft n4659 has the exact wording he quoted.
 
And I seem to recall that getting the output statement well defined was
a major part of the rationale.
 
 
Cheers!,
 
- Alf
"James R. Kuyper" <jameskuyper@verizon.net>: Dec 05 07:31PM -0500

On 12/05/2017 06:43 PM, Alf P. Steinbach wrote:
 
> In particular, C++17 §8.8/4, that he quoted, directly contradicts your
> assertion that only `&&`, `||`, `?:` and the comma operator prescribe
> the order of evaluation of their operands.
 
You're correct. I somehow managed to miss that part, despite it's
prominent location in his message. I plead a shortage of sleep. I was
considering only his earlier citation of 16.3.1.2.
 
However, unless there's other new wording in C++17 that's relevant,
that's not sufficient to give this code defined behavior. 8.8p4 merely
implies that the evaluation of cout is sequenced before the evaluation
if ++i, and that the evaluation of cout << ++i is sequenced before the
evaluation of i++. Unless something else that's also relevant has
changed, that still leaves the evaluation of cout and the two
evaluations of i unsequenced relative to each other. In particular, the
evaluation of i for i++ could occur in any of three different orders
that are relevant:
1. before the evaluation of i for ++i
2. after the evaluation of i for ++i, but before the evaluation of ++i.
3. after the evaluation of ++i.
 
It's the fact that option 3 is permitted but not mandatory that makes
the behavior undefined.
 
If they changed << to imposes a sequence on it's operands, it's entirely
plausible to me that they might have changed something else that's also
relevant, but do you know any such change?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 06 02:43AM +0100

On 12/6/2017 1:31 AM, James R. Kuyper wrote:
> 3. after the evaluation of ++i.
 
> It's the fact that option 3 is permitted but not mandatory that makes
> the behavior undefined.
 
If I understand this right, you mean that when E1 is sequenced before E2
in E1 << E2, only the top level operation in E1 must be done before the
top level operation in E2, while the argument expressions to those
operations can be evaluated in any order. Alternatively, direct object
references can still be evaluated in any order. Or, three, …?
 
On what is that to me arbitrary & weird interpretation based?
 
One might argue superficially that the wording for e.g. E1 && E2 is far
more elaborate than simply "sequenced before", and that this could imply
that something else is meant by "sequenced before". But the wording for
E1 && E2 originated with C++98, where there was no such thing as
"sequenced before". C++98 and C++03 instead had sequence points, which
were not suitable for describing the evaluation of E1 && E2.
 
 
> If they changed << to imposes a sequence on it's operands, it's entirely
> plausible to me that they might have changed something else that's also
> relevant, but do you know any such change?
 
Stefan quoted one, C++17 §16.3.1.2/2, that when the arguments are of
class or enumeration type, possibly with a user defined operator, the
argument evaluation order is still as for the built-in operator.
 
 
Cheers!,
 
- Alf
James Kuyper <jameskuyper@verizon.net>: Dec 06 12:15AM -0500

On 12/05/2017 08:43 PM, Alf P. Steinbach wrote:
> operations can be evaluated in any order. Alternatively, direct object
> references can still be evaluated in any order. Or, three, …?
 
> On what is that to me arbitrary & weird interpretation based?
 
"Except where noted, evaluations of operands of individual operators and
of subexpressions of individual expressions are unsequenced. ... The
value computations of the operands of an operator are sequenced before
the value computation of the result of the operator." (1.9p15).
 
Thus, the sub-expressions of an expression are treated as separate
events that are sequenced before evaluation of the expression itself.
 
In every case where the standard does specify that something is
sequenced before something else, it's always the evaluation or
side-effects of the evaluation of a particular expression. It never says
that the evaluation of th expression and of all of its sub-expressions
are sequenced before the evaluation of the other expression and all of
it's sub-expressions.
 
This interpretation might seem weird to you, but it's pretty much the
standard interpretation I've seen used when experts discuss such issues
(non-experts use all kinds of other interpretations). I've been
participating in C and C++ newsgroups for a couple of decades now. I've
had more discussions of such issues in the context of C than in the
context of C++, but "sequenced before" was added to both standards at
about the same time with very similar wording in both standards - I
presume that the C and C++ committees deliberately worked together to
avoid having the two standards say incompatible things about such issues.
 
> E1 && E2 originated with C++98, where there was no such thing as
> "sequenced before". C++98 and C++03 instead had sequence points, which
> were not suitable for describing the evaluation of E1 && E2.
 
Before "sequenced before" was invented, the standard said that E1 and E2
were separated by a sequence point, and mandated that E2 must be
evaluated (if at all) after E1. The only operators that had associated
sequence points also all had wording specifying the relative order of
the things separated by those points. The current specification is an
improvement, but doesn't change what the earlier wording said (or more
precisely, failed to say) about the ordering of sub-expressions of
different expressions. The fact that A is sequenced before B, and that
the sub-expressions of A are sequenced before A, and that the
sub-expressions of B are sequenced before B, does not mean that the
sub-expressions of A are sequenced before the sub-expressions of B. That
was equally true back when those same facts were expressed using
sequence points.
 
 
> Stefan quoted one, C++17 §16.3.1.2/2, that when the arguments are of
> class or enumeration type, possibly with a user defined operator, the
> argument evaluation order is still as for the built-in operator.
 
When I said "something else", I meant something else other than the
clauses he'd already cited. Those clauses don't establish sequence
requirements sufficient to give the expression defined behavior.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 06 03:28PM

On Wed, 6 Dec 2017 00:15:42 -0500
James Kuyper <jameskuyper@verizon.net> wrote:
[snip]
> sub-expressions of A are sequenced before the sub-expressions of B.
> That was equally true back when those same facts were expressed using
> sequence points.
 
It is not a complete wild west out there. This depends on whether A and
B are full expressions:
 
"Every value computation and side effect associated with a
full-expression is sequenced before every value computation and side
effect associated with the next full-expression to be evaluated"
 
cout is not a temporary, and in 'cout << ++i << i++', isn't each
invocation of cout's operator<<() a separate full expression? By
virtue of §8.8/4 of C++17 the one with ++i as operand (which has two
side effects, the print and the increment of i) must be evaluated
before the one with i++ as operand (which also has two side effects)?
 
Having said that I find the definition of 'full expression' quite
difficult to follow.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 06 05:03PM

On Wed, 6 Dec 2017 15:28:36 +0000
> before the one with i++ as operand (which also has two side effects)?
 
> Having said that I find the definition of 'full expression' quite
> difficult to follow.
 
I have noticed something else. The text I quoted above appears as
§4.6/16 of C++17, and is also in §1.9/14 of C++11/14.
 
However, the last sentence of the preceding paragraph is new in C++17
and says this: "An expression X is said to be sequenced before an
expression Y if every value computation and every side effect
associated with the expression X is sequenced before every value
computation and every side effect associated with the expression Y".
 
So this seems to indicate that in C++17, where the standard specifies
that some expression is sequenced before another, all the associated
sub-expressions and side effects must also be so sequenced even if they
are not full expressions. Since §8.8/4 (also new in C++17) says that
with 'E1 >> E2' and 'E1 << E2', "the expression E1 is sequenced before
the expression E2" this seems to imply all side effects and
associated computations must also be so sequenced.
 
So I think this means that in C++17, 'cout << ++i << i++;' does actually
work.
 
Chris
jameskuyper@verizon.net: Dec 06 09:23AM -0800

On Wednesday, December 6, 2017 at 10:29:06 AM UTC-5, Chris Vine wrote:
> effect associated with the next full-expression to be evaluated"
 
> cout is not a temporary, and in 'cout << ++i << i++', isn't each
> invocation of cout's operator<<() a separate full expression?
...
> Having said that I find the definition of 'full expression' quite
> difficult to follow.
 
"A full-expression is an expression that is not a subexpression of another expression." (1.9p10). The first << expression is a sub-expression (namely, the left operand) of the second << expression, and therefore does NOT qualify as a full-expression. I don't find that a difficult definition to follow.
 
Examples:
int a[] = {b-c, d+e, f*g, h/j};
 
for(i=0; i<N; i++)
{
a[i] = b[i]+c[i];
total += a[i];
}
 
The full-expressions in that code are
1. b-c
2. d+e
3. f*g
4. h/j
5. i=0
6. i<N
7. i++
8. a[i] = b[i] + c[i]
9. total += a[i]
 
Full-expressions are most commonly expression-statements, or initializers, but it's quite commonplace for them to occur in other contexts, such as items 5-7 above.
Intelli2 <intelli2@mama.com>: Dec 06 12:13PM -0500

Hello,
 
 
Here are my genetical handicaps:
 
I can not have a conversation with people, if i talk and have a
conversation with people i will get mixed up in my brain, my brain can
not substain a correct conversation with people because of a genetical
handicap that i have, also i am handicaped from my memory in my brain,
my memorization is very poor, it is another genetical handicap, i have
also other genetical handicaps also, so you have to know how to be
patience with handicaped people.
 
Also a new fully scalable algorithm of mine is coming, i have just
invented it right now.
 
It is two fully scalable Threapools, my other Threadpools were not fully
scalable, my new scalable algorihms will be very powerful, they will use
a distributed technic that is truly scalable that will make my
Threadpools fully scalable (like my scalable FIFO queues that i have
invented and implemented in front of your eyes), and they will use also
scalable counting networks that are truly scalable.
 
So stay tuned , it will take me one day to implement this new fully
scalable algorithm that i have just invented !
 
Also, I am thinking to include many of my projects in Embarcadero Delphi
and C++ products , they can be included in a directory called Utils(that
means utilities) inside Embarcadero Delphi and C++ products
 
What i want to include in Embarcadero Delphi and C++ products is my
inventions like my scalable Parallel Varfiler and my scalable RWLocks
and my scalable MLock and and my scalable FIFO queues and my scalable
Threadpools and my SemaMonitor and my C++ Synchronization Objects
Library and my Parallel Compression Library etc.
 
I am an experienced programmer specialized in Parallel programming and
synchronization algorithms, it is why i have invented many scalable
synchronization algorithms.and such, i am not an expert on coding, this
is why i will let Embarcadero enhance the coding style of my projects etc.
 
 
Thank you,
Amine Mouly Ramdane.
 
Thank youm,
Amine Moulay Ramdane.
"Fred.Zwarts" <F.Zwarts@KVI.nl>: Dec 06 09:57AM +0100

"fir" schreef in bericht
news:1c76277b-d795-4fa1-b47d-832e1c6322f9@googlegroups.com...
 
> SOCKADDR_IN sin;
> sin.sin_family = PF_INET;
> ...
 
When developing new software, don't use such old (IPv4 only) code. Invest
some time (you don't need weeks) to write future proof code.
fir <profesor.fir@gmail.com>: Dec 06 09:09AM -0800

W dniu środa, 6 grudnia 2017 09:57:27 UTC+1 użytkownik F.Zwarts napisał:
> > ...
 
> When developing new software, don't use such old (IPv4 only) code. Invest
> some time (you don't need weeks) to write future proof code.
 
im a noob in networking at all,
at start i just need anythig that will work - right now im searching btw for a code snipped for firing non-blocking connect on client side
(some 2h of slow googling and reading dont show me that snippet, does anybody maybe have that? tnx)
Intelli2 <intelli2@mama.com>: Dec 06 11:44AM -0500

Hello,
 
 
Here is more information about me..
 
I am an handicaped person that has many genetical handicaps who has
invented many scalable algorithms and such, i was created like that with
many handicaps to show you that handicaped persons can invent scalable
algorithms and do interesting things.
 
Also a new fully scalable algorithm of mine is coming, i have just
invented it right now.
 
It is two fully scalable Threapools, my other Threadpools were not fully
scalable, my new scalable algorihms will be very powerful, they will use
a distributed technic that is truly scalable that will make my
Threadpools fully scalable (like my scalable FIFO queues that i have
invented and implemented in front of your eyes), and they will use also
scalable counting networks that are truly scalable.
 
So stay tuned , it will take me one day to implement this new fully
scalable algorithm that i have just invented !
 
Also, I am thinking to include many of my projects in Embarcadero Delphi
and C++ products , they can be included in a directory called Utils(that
means utilities) inside Embarcadero Delphi and C++ products
 
What i want to include in Embarcadero Delphi and C++ products is my
inventions like my scalable Parallel Varfiler and my scalable RWLocks
and my scalable MLock and and my scalable FIFO queues and my scalable
Threadpools and my SemaMonitor and my C++ Synchronization Objects
Library and my Parallel Compression Library etc.
 
I am an experienced programmer specialized in Parallel programming and
synchronization algorithms, it is why i have invented many scalable
synchronization algorithms.and such, i am not an expert on coding, this
is why i will let Embarcadero enhance the coding style of my projects etc.
 
 
Thank you,
Amine Mouly Ramdane.
 
Thank youm,
Amine Moulay Ramdane.
Intelli2 <intelli2@mama.com>: Dec 06 11:12AM -0500

Hello,
 
 
Here is a deal with Embarcadero, i want to sell to them my new scalable
algorithm of a fully scalable Threadpool , and i want to sell to them
another kind of Threadpools that are almost fully scalable , because
work-stealing is rare, and i want to sell to them many of my other
scalable algorithms and such, and i will let them enhance the coding
style of all my scalable algorithms implementations and such, i want to
sell many of my projects to Embarcadero because i want to make
Embarcadero better.
 
Here is the website of Emabarcadero:
 
https://www.embarcadero.com/?utm_source=google&utm_medium=cpc&utm_campaign=embcplusplus&utm_content=brand&utm_term=embarcadero
 
 
And i am making this announcement here.
 
 
Thank you,
Amine Moulay Ramdane.
Intelli2 <intelli2@mama.com>: Dec 06 11:11AM -0500

Hello,
 
 
Here is a deal with Embarcadero, i want to sell to them my new scalable
algorithm of a fully scalable Threadpool , and i want to sell to them
another kind of Threadpools that are almost fully scalable , because
work-stealing is rare, and i want to sell to them many of my other
scalable algorithms and such, and i will let them enhance the coding
style of all my scalable algorithms implementations and such, i want to
sell many of my projects to Embarcadero because i want to make
Embarcadero better.
 
Here is the website of Emabacadero:
 
https://www.embarcadero.com/?utm_source=google&utm_medium=cpc&utm_campaign=embcplusplus&utm_content=brand&utm_term=embarcadero
 
 
And i am making this announcement here.
 
 
Thank you,
Amine Moulay Ramdane.
Intelli2 <intelli2@mama.com>: Dec 06 11:00AM -0500

Hello,
 
 
Why i want to make you happy ?
 
Because i am from the old school of Borland Turbo Pascal, i was happy
when i first bought Borland Turbo Pascal professional in year 1991, and
i have worked with it and i have loved it and i have loved Borland, this
is why i want to make you happy, because friends of Turbo Pascal and
Delphi are my friends, but i have also ported some of my Delphi projects
to C++ compilers, i have compiled the Delphi projects that are my
inventions into Dynamic Link Libraries and i have used them from C++
compilers, and it has given my following C++ Libraries::
 
Look at my C++ synchronization objects library for Windows and Linux:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
And look at this scalable Library of mine for Windows and Linux:
 
Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
and also look at those Scalable FIFO queues of mine for C++ and for
Windows and Linux:
 
https://sites.google.com/site/aminer68/scalable-fifo-queues-for-c
 
 
Thank you,
Amine Moulay Ramdane.
Intelli2 <intelli2@mama.com>: Dec 06 10:55AM -0500

Hello..
 
 
A new fully scalable algorithm is coming, i have just invented it right now.
 
It is two fully scalable Threapools, my other Threadpools were not fully
scalable, my new scalable algorihms will be very powerful, they will use
a distributed technic that is truly scalable that will make my
Threadpools fully scalable (like my scalable FIFO queues that i have
invented and implemented in front of your eyes), and they will use also
scalable counting networks that are truly scalable.
 
So stay tuned , it will take me one day to implement this new fully
scalable algorithm that i have just invented !
 
Also, I am thinking to include many of my projects in Embarcadero Delphi
and C++ products , they can be included in a directory called Utils(that
means utilities) inside Embarcadero Delphi and C++ products
 
What i want to include in Embarcadero Delphi and C++ products is my
inventions like my scalable Parallel Varfiler and my scalable RWLocks
and my scalable MLock and and my scalable FIFO queues and my sxcalable
Threadpools and my SemaMonitor and my C++ Synchronization Objects
Library and my Parallel Compression Library etc.
 
I am an experienced programmer specialized in Parallel programming and
synchronization algorithms, it is why i have invented many scalable
synchronization algorithms.and such, i am not an expert on coding, this
is why i will let Embarcadero enhance the coding style of my projects etc.
 
 
Thank you,
Amine Mouly Ramdane.
woodbrian77@gmail.com: Dec 05 05:37PM -0800

> On Sunday, December 3, 2017 at 11:51:57 AM UTC-6, mche...@gmail.com wrote:
> Hi All
> Is rust going to replace C++? The world seems want to stay in C++
 
 
Without online code generation, I think Rust will languish.
 
However, I think C++ could benefit from drawing on ideas
from Rust and/or Swift:
 
http://foonathan.net/blog/2017/12/04/exceptions-vs-expected.html
 
. Ideally these things would be in C++ 2020.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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)