Saturday, October 13, 2018

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

Juha Nieminen <nospam@thanks.invalid>: Oct 13 08:19AM

> It is perfectly fine for abstract base classes to have member variables
> unless the class is representing an *interface* in which case the
> idiomatic thing to do is to not have any member variables.
 
Why shouldn't interfaces have member variables? Just because other
languages don't support them? Why limit yourself, and let yourself
be governed by the limitations of other languages?
Thiago Adams <thiago.adams@gmail.com>: Oct 13 04:56AM -0700

On Thursday, October 11, 2018 at 7:04:11 PM UTC-3, JiiPee wrote:
> age*. So lets assume that 100% all animals will have age-variable (they
> need it). But its logical that Animal is pure virtual. So, where should
> age_ belong to if not inside Animal class?
 
Inheritance causes a LOT of coupling. (Traditional OOP as well)
Using inheritance for implementation(data, algorithm) creates even
more coupling. This is the reason to avoid data member in interfaces
and avoid inheritance using composition.

Because of this coupling the answer for your question
"Where is the correct place for age_ " can be only given
when the software is complete. But even after that,
if you have the perfect balance you will end up with
classes that are hard to reuse because the balance you
did was for the original problem.
 
Think in a case where you have 10 classes "balanced"
and using some data member from base classes.
Now, software requisites changes and you need to add
a new class that doesn't need to use some of the data
members. So to add one more object you need to reevaluate
all your code and maybe make changes in your existing
classes.
 
This problem can happen even with interfaces without any
data members. When you add some class and the implementation
of some virtual doesn't make sense this is a sign. The set
of classes and virtual functions is broken and you need
redesign globally.
 
Interfaces are good when you need to make "plugins".
A new class can be added without have access to
the other classes in an independent way. The interface
contract should be small and very direct.
But it can change, then you need a new interface, let´s say
Interface2 or InterfaceEx.
 
When I have access to all objects that will implement
some behavior then I use a different approach.
 
 
Basically instead of use interfaces I say
"Animal is a pointer to Cat or Dog".
'Dog' or 'Cat' don´t know 'Animal' and this creates
much less coupling. The couple caused is to add
new algorithm but this is done automatically by
the tool.
 
See
http://thradams.com/web/cprime.html
 
the polymorphism sample.
Thiago Adams <thiago.adams@gmail.com>: Oct 13 05:22AM -0700

On Saturday, October 13, 2018 at 8:56:16 AM UTC-3, Thiago Adams wrote:
...
 
 
> See
> http://thradams.com/web/cprime.html
 
> the polymorphism sample.
 
I think this feature could be added into C++.
 
Some syntax to specify the pointer
 
union Animal = Dog | Cat;
 
Dog and Cat must have some RTTI.
(today this is only activated by virtuals,
so imagine a virtual destructor)
 
 
class Dog {
public:
void talk() {
cout << "auau";
}
};
 
 
class Cat {
public:
void talk() {
cout << "Meouw";
}
};
 
 
union Animal = Dog | Cat;
Animal* p = new Dog();
 
p->talk(); //<--------
 
the p->talk would instantiate the selection function
similarly of template instantiation.
 
This instantiation checks if Dog and Cat have the talk()
function with the same signature.
 
The declaration
union Animal = Dog | Cat;
checks if Dog and Cat have rtti.
 
 
Non member functions also should work and double dispatch
is possible as well.
 
union Shape = Box| Circle;
 
Intercept(pShape1, pShape2); //select instantiation
 
Selects:
Intercept(Box*, Box*);
Intercept(Box*, Circle*);
etc...
"Öö Tiib" <ootiib@hot.ee>: Oct 13 06:14AM -0700

On Saturday, 13 October 2018 15:22:33 UTC+3, Thiago Adams wrote:
> I think this feature could be added into C++.
 
> Some syntax to specify the pointer
 
> union Animal = Dog | Cat;
 
C++17 already added it as std::variant. Its "visit" can become bit
cryptic when to put wildly different stuff into variant (like examples
often love to do) but on given case it is almost self-explanatory:
 
#include <iostream>
#include <variant>
#include <vector>

struct Bee {
void talk() {
std::cout << "buzz";
}
};

struct Bear {
void talk() {
std::cout << "growl";
}
};

struct Bird {
void talk() {
std::cout << "chirp";
}
};

using Animal = std::variant<Bee, Bear, Bird>;

int main() {
std::vector<Animal> animals;
animals.emplace_back(Bird{});
animals.emplace_back(Bee{});
animals.emplace_back(Bear{});

auto thingTalk = [](auto&& thing) { thing.talk(); };
 
for (auto a: animals) {
visit(thingTalk, a);
}
}

Seems to work too:
http://coliru.stacked-crooked.com/a/597d761be7b750cb
 
It may become even better with concepts or not ... future will show.
Thiago Adams <thiago.adams@gmail.com>: Oct 13 06:19AM -0700

On Saturday, October 13, 2018 at 9:22:33 AM UTC-3, Thiago Adams wrote:
> Intercept(Box*, Box*);
> Intercept(Box*, Circle*);
> etc...
 
Template functions also could be polymorphic
 
For instance:
 
class Dog
{
template<class T>
void Eat(T & v) {...}
};
 
class Cat
{
template<class T>
void Eat(T & v) {...}
};
 
//let's say this is the syntax to
//create the pointer to cat or dog
 
union * Animal : Cat , Dog
{
//we can declare the functions here
//and the compiler can check Cat and Dog
//to see if the function is present
template<class T>
void Eat(T & v);
};
 
 
Animal * p = new Dog();
 
p->Eat(1); //instantiation
 
the instantiation will create a version of Eat
that will make runtime time selection (like switch and cases).
This instantiation will instantiate the dog Eat and cat Eat
as well.
Thiago Adams <thiago.adams@gmail.com>: Oct 13 06:44AM -0700

On Saturday, October 13, 2018 at 10:14:44 AM UTC-3, Öö Tiib wrote:
 
> Seems to work too:
> http://coliru.stacked-crooked.com/a/597d761be7b750cb
 
> It may become even better with concepts or not ... future will show.
 
I think the 'tag' that differentiate objects is inside the
std::variant. This is bad for this kind of use.
(I think rust has a similar feature and problem)
 
My suggestion is only for pointers and the 'tag' is rtti must
be inside the object.
I can say Animal is a pointer to Dog or Cat. It doesn't hold dog
or cat memory . I cannot instantiate an Animal object, just a pointer.
 
This sample shows some problem (it is not composable and
if it was it was going to have multiple 'tags')
 
 
#include <variant>
#include <iostream>
#include <variant>
#include <vector>
 
 
struct Bee {
void talk()
{
std::cout << "buzz";
}
void serialize()
{
std::cout << "serialize";
}
};
 
struct Bear {
void talk()
{
std::cout << "growl";
}
void serialize()
{
std::cout << "serialize";
}
};
 
struct Bird {
void talk()
{
std::cout << "chirp";
}
void serialize()
{
std::cout << "serialize";
}
};
 
using Animal = std::variant<Bee, Bear, Bird>;
 
struct Car {
void serialize()
{
std::cout << "serialize";
}
};
 
using Items = std::variant<Animal, Car>;
 
 
int main()
{
std::vector<Items> items;
items.emplace_back(Bird{});
items.emplace_back(Bee{});
items.emplace_back(Bear{});
items.emplace_back(Car{});
 
//error C2039: 'serialize': is not a member of
//'std::variant<Bee,Bear,Bird>'
 
auto f = [](auto&& thing) { thing.serialize(); };
 
for (auto a : items)
{
visit(f, a);
}
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 13 04:24AM +0200

On 12.10.2018 21:09, Paul wrote:
> The code below is from Hackerrank. It looks suspicious to me because
> the memory is allocated with new but freed with free.
 
> Is it ok?
 
For portable code it's just Undefined Behavior.
 
However, what's formal UB can be useful defined behavior with a given
implementation. It's often exploited by the (compiler-specific)
implementation of the standard library, e.g. in the `offsetof` code. But
the ordinary programmer has to consider several levels of defined-ness:
 
* Defined by the C++ standard.
* Defined by a large number of compilers (e.g. `#pragma once`, or
`__COUNTER__`), a /de facto/ standard. However don't use that term over
on Stack Overflow. They're too lazy, or maybe arrogant, to look up
things they don't know, and I note that the care that one must exercise
there has been adopted over on cppreference, which doesn't talk about de
facto standards.
* Defined by the compiler, and documented.
* Defined by the compiler, but not documented (e.g., that you've found
code from the compiler vendor that relies on some specific behavior).
* No source other than your own testing indicates that this thing works.
 
Usually, in discussions about C++ portable code is assumed, and so only
code that passes via the first and second points above is considered OK.
 
But one's portability goals can be much more limited, and for example,
but even though I recall one such situation this must be very very rare,
one may have to pass a `new`-allocated thing to a C routine that will
`free` whatever it gets, and for efficiency avoid an extra `malloc` +
copying. Then one may decide to go with one of the two last points. But
I think that should be documented: "NOTE: NOT USING STRDUP BECAUSE
MEASUREMENTS SHOWED THAT WAS TOO SLOW, AND BORKA C++ NEW /IS/ MALLOC".
 
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Oct 13 03:37AM -0700

On Saturday, 13 October 2018 05:24:29 UTC+3, Alf P. Steinbach wrote:
 
> However, what's formal UB can be useful defined behavior with a given
> implementation. It's often exploited by the (compiler-specific)
> implementation of the standard library, e.g. in the `offsetof` code.
 
Yes, but that standard library may change with next patch. Are there
any ways to detect in code that it did?
 
> * Defined by the compiler, but not documented (e.g., that you've found
> code from the compiler vendor that relies on some specific behavior).
> * No source other than your own testing indicates that this thing works.
 
Major issue there is lack of standardized way to detect compile time
the implementation-defined, some-other-standard-defined, compiler-defined
or compiler-option-defined features. So portable (in practice) code is
often full of preprocessor slices and obscurely unreadable static_assert
conditions.
 
> one may have to pass a `new`-allocated thing to a C routine that will
> `free` whatever it gets, and for efficiency avoid an extra `malloc` +
> copying.
 
Hmm ... but anything that C library can use and free must be dynamically
allocated POD and so there had to be possibility to malloc or calloc
storage for it instead?
 
> Then one may decide to go with one of the two last points. But
> I think that should be documented: "NOTE: NOT USING STRDUP BECAUSE
> MEASUREMENTS SHOWED THAT WAS TOO SLOW, AND BORKA C++ NEW /IS/ MALLOC".
 
Willfully going with one of the last two when some other bullet
explicitly documented it as "undefined behavior" (as on current case)
is considered "black magic". It will be nuisance later when it leads
into one of several inconveniences and difficulties. Most typical
difficulties that manifest are:
 
* choice of other useful tools (and platforms for running those) is
limited
* portability to newer versions of compiler is harder
* certain very desirable compiler flags (like optimizations) break it
* further maintainability of module is harder
 
When such difficulties manifest then with 100% our own code it "just
sucks". With others we are guilty. Admit personal fallibility, agree
that it was programming defect and help to remove the difficulties.
Any argument can bring lost trust, reputation, contracts and fame as
the evil author of "cursed legacy". What must be the alleged benefits
that make it worth that? No one did monitor if the end users were
happy about it or not. ;)
Bo Persson <bop@gmb.dk>: Oct 13 01:43PM +0200

On 2018-10-13 12:37, Öö Tiib wrote:
>> implementation of the standard library, e.g. in the `offsetof` code.
 
> Yes, but that standard library may change with next patch. Are there
> any ways to detect in code that it did?
 
In this particular case, all the major compilers now have a
__bultin_offsetof "magic" function.
 
So the old null-pointer hack might no longer be supported. Who knows?
 
 
Bo Persson
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 13 03:03PM +0200

On 13.10.2018 12:37, Öö Tiib wrote:
> the evil author of "cursed legacy". What must be the alleged benefits
> that make it worth that? No one did monitor if the end users were
> happy about it or not. ;)
 
Well, that brings up an interesting case, and an issue re definedness
that I forgot to address. I forget too much these days, sorry. Namely,
the case of
 
* defined by the standard, but not implemented or incorrectly
implemented by at least one major compiler.
 
When Petru Marginean and co-author Andrei Alexandrescu published the now
classic ¹Scope Guard article in Dr Dobbs Journal, they chose to use the
standard `__LINE__` macro to generate unique names for the scope guard
variables. They could have used de facto standard `__COUNTER__`, which I
think even at that time was supported by all the major compilers. The
choice of `__LINE__` meant that their code just didn't work with the
default settings of a Visual Studio project, because with the Visual C++
option for "Program Database for Edit and Continue", `/ZI`, Visual C++
expanded `__LINE__` to some gobbledygook, not valid in an identifier.
 
They never agreed that it was a programming defect, never fixed it. For
that matter, Andrei never agreed that it was a programming defect to
just silently swallow exceptions in the Scope Guard cleanup code. And
nobody now (well except me) remembers Petru Marginean... :)
 
 
Cheers!,
 
- Alf
 
Notes:
¹ <url:
http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758>
Tim Rentsch <txr@alumni.caltech.edu>: Oct 12 09:36PM -0700


> Then I get in return that I was changing the subject, as if I was not
> comfortable with the current subject. That's a not nice behavior. I
> want you to improve in that regard.
 
My perception is you were changing the subject. If you had a
different idea of what the subject was, then you may very well
have thought you were keeping on the same subject. Sorry if
there was a misunderstanding.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 13 01:19PM +0100

On Fri, 12 Oct 2018 22:05:45 -0700
> when encountering [u]int8_t,"
 
> to which I pointed out that there are other reasons why a C
> implementation might make such a choice.
 
OK. That's still not a strawman argument though. It is a prediction
which can be falsified by someone bringing your compiler into
production. A strawman argument requires a misrepresentation or some
similar intellectual dishonesty (the "straw man") to avoid answering
the issue in point. The real issue was answered; you just found the
answer unsatisfying.
 
> specific that would motivate someone else to take the same view.
> Am I wrong about that? Are you offering something more than just
> your opinion? If so what is it?
 
Just my opinion? I don't think you wrote your posts with the (bogus)
reference to straw man arguments and something being "just my opinion"
in order to patronize or issue half-disguised insults, but one could
reach just an opinion that it might have been. Practically everything
posted to this newsgroup (including by you) is, at the end of the day,
a matter of someone's opinion. Certainly the "correct" reading of the
C++ standard is.
 
My point was no more than (i) in the standard many things are left to
implication or to the natural meaning of words, not least what are the
fundamental properties of an "integer" type, and (ii) some additional
meaning might be carried by the word "extended". You will recall that
when I said "I am not even sure that that would be legal" I was not
expressing the position with any great certainty.
 
I can accept that the fact that two standard integer types (say, int and
long) can and often do have the same size and representation without
being typedefs to each other is an argument that the word "extended"
does not carry much (or any) additional significance. On reflection I
think that is the most telling argument against the point I made, and on
another day might persuade me. On the other hand I object to the
dogmatic insistence on the issue (not so far by you) by reference to
something which was akin to biblical exegesis of the C++ standard, most
of which was in my view irrelevant and (in my view) does not represent
the method by which the standard is intended to be read.
 
You asked for a response for clarification and I am giving it to you.
Please do not start rearguing all this. (I stand by my prediction by
the way.)
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 13 06:58AM


> Yeek, we use sparse object distribution with copy on write. Rust sounds
> like it would be a total disaster for that whereas C++ handles it easily.
 
I am not familiar with that term. google is not helpfull ;)
 
 
--
press any key to continue or any other to quit...
"Öö Tiib" <ootiib@hot.ee>: Oct 13 04:49AM -0700

On Saturday, 13 October 2018 09:58:48 UTC+3, Melzzzzz wrote:
 
> > Yeek, we use sparse object distribution with copy on write. Rust sounds
> > like it would be a total disaster for that whereas C++ handles it easily.
 
> I am not familiar with that term. google is not helpfull ;)
 
The internet is full of "copy on write" but "sparse object distribution"
gave only about dozen very mildly related to each other results.
Tim Rentsch <txr@alumni.caltech.edu>: Oct 05 08:45AM -0700

>> defined, then where is it defined?"
 
> For stack overflow, the behavior might be defined by the
> implementation.
 
In fact the behavior is already defined by the Standard(s).
Please see my longer reply just recently posted.
 
> documentation.
 
> Note that if the behavior were defined by the C++ standard, MSVC++
> could not implement their own behavior (at least not legally).
 
I think you're assuming that behavior being defined implies
correct execution. That isn't the case. This distinction
is touched on in my other posting. Please let me know if
you would like some clarification.
"Öö Tiib" <ootiib@hot.ee>: Oct 13 04:22AM -0700

On Saturday, 13 October 2018 07:32:00 UTC+3, Tim Rentsch wrote:
> "impose a requirement", that is, singular or plural makes no
> difference. Can you tell me what your answer to this question
> is?
 
The implied answer was that A and B are required to return 0,
if and what the C, D and E are required to return is
implementation-defined most likely also 0, and F is not required
to return anything but can also return 0.
 
The motivation behind your deliberate avoidance of "behavior" versus
"imposes requirements" is unclear because normative definition of
"undefined behavior" in [defns.undefined] appears to be "behavior for
which this International Standard imposes no requirements".
What a program is required to return if it is required to return
something is (part of) its behavior.
Juha Nieminen <nospam@thanks.invalid>: Oct 13 08:15AM

> But if you have to know, I think you're either working with C structs,
> or (my case) trying to understand broken code. It's almost always
> better to let the class itself decide what should be initialized.
 
In general, in the vast majority of cases, it's a good idea, and
good design, to always have all members initialized to known
default values.
 
However, there may be some fringe cases where utmost and absolute
efficiency is required and you really *don't* want to default-
initialize millions of objects with values that won't get used
anyway (most usually because they are immediately after assigned
new values, and the original default values aren't used for
anything.)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:52PM -0400

On 10/07/2018 04:44 PM, Rick C. Hodgin wrote:
> sick mind that designed hell, unless it is the sorely limited mind that
> has failed to describe heaven, except as a place of worldly comfort,
> eternal tedium, or the continual relish in the torture of others.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
You can read about Heaven and Hell in the book of Revelation,
in the teachings of Christ who described it as paradise, by
Paul who described someone being caught up to the third Heaven
(the first Heaven in the Bible is the air, the second is the
stars, and there's a third Heaven beyond that which we do not
yet know).
 
You can read about Hell in Revelation. The beast and the
false prophet are cast into Hell at the start of the 1,000
year reign of Christ, and when Satan is cast into Hell 1,000
years later, the Bible records, "Where the beast and the
false prophet are," indicating they are still there, in the
fire, being consumed, etc.
 
Hell is a special place crafted by God to contain sin. It
is a place of eternal confinement, which holds all eternal
beings (of which we (mankind) are each an eternal soul) for
all-time, separating them from God's Kingdom forever.
 
All who enter into Hell will be tormented day and night for-
ever. There is no parole. No release for good behavior.
It is only punishment as we've been given a trial and a test
here on Earth as to who we are and what we'll believe.
 
All who will be saved will be saved. The rest will perish
and be cast into eternal Hellfire.
 
It's why Christians teach these things ... because today all
people world-wide can ask forgiveness for sin. But when
they leave this world, it's too late.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:42PM -0400

On 10/07/2018 04:36 PM, Rick C. Hodgin wrote:
> maintain that all religions are versions of the same untruth, but I hold
> that the influence of churches, and the effect of religious belief, is
> positively harmful.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
Each religion on Earth, except Biblical Christianity, is based
on some kind of works. You have to attain some purity, seek
some quest to rid yourself of this, or receive another thing.
 
Only Biblical Christianity teaches that you are not good enough
to approach God based on your sin, and that you need a savior
to make a way out of your guilt.
 
Jesus is that savior. He came to be that very savior. His
name literally means "God who saves" in the same way the name
Shoemaker means "one who makes shoes."
 
Jesus will forgive your sin and give you eternal life, and go
on with you for the rest of your days here on this Earth to
reach others, teach others, and to sanctify the things in your
life which are not pleasing to God.
 
You will discern true Christians separate from the multitudes
of people who think they are Christians by their fruit. Those
who are Christ's will teach of Christ, and (over the course of
their life) be continually revamping the things of their life
to be more and more like Christ Himself.
 
--
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Oct 05 09:40PM

Supersedes: <requires-20181005223530@ram.dialup.fu-berlin.de>
[correction of concept definition]
 
> representation at compile. */
>template< typename T >concept UsesTwosComplementRepresentation =
>::std::is_same< T, int >::value || ::std::is_same< T, long >::value;
 
Maybe something like the following?
 
template< typename T >
concept UsesTwosComplementRepresentation =
requires{ new int[ -( T( -5 )!=(( ~T( 5 ) )+ 1 ) )]; };
ram@zedat.fu-berlin.de (Stefan Ram): Oct 05 07:04PM

>+1
 
If it's important that a type has a two's complement
representation, can't this be expressed by a concept?
 
(The following example assumes a C++-Implementation where
»int« and »long« have a two's complement representation.)
 
#include <type_traits>
 
/* The following concept has to provided/adjusted for each
implementation when it's using a list with »is_same«.
Maybe a requires clause can be used to figure out the
representation at compile. */
template< typename T >concept UsesTwosComplementRepresentation =
::std::is_same< T, int >::value || ::std::is_same< T, long >::value;
 
void example( UsesTwosComplementRepresentation auto x ){}
ram@zedat.fu-berlin.de (Stefan Ram): Oct 05 08:40PM

>physics breaks down, because we've never been able to conduct
>experiments in fields that strong. That's acknowledged by most of the
>authorities in the field.
 
It's true for linguistic reasons alone because "a place
where our understanding of physics breaks down" is the
/meaning/ of the world "singularity".
 
>However, that time and space axes undergo distortion due to
>strong gravitational fields is a fundamental aspect of the
>General theory of Relativity (GR).
 
GR actually explains that the gravitational fields /is/
a distortion of spacetime. The cause is the energy-
momentum tensor (EMT). It does not matter how large the
EMT is, as long as it's not zero everywhere (and in fact
it is not zero everywhere).

>distinguishes GR from any proposed alternative, and the
>evidence they've collected fits GR better than any
>meaningfully different theory
 
Correct!
 
WRG to the subject: The eye today is seens as a protrusion
(i.e., a part) of the brain ("The mammalian eye is formed
from a collapsed ventrical of the brain." - CompVisNotes.pdf).
 
A photon can causes a cis-trans isomerization of the
11-cis-retinal chromophore in the G-protein coupled receptor
rhodopsin in this brain protrusion. This isomerization is
process which one might deem to be describable only with
quantum mechanics.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:31PM -0400

On 10/07/2018 04:26 PM, Rick C. Hodgin wrote:
> So if your wife is pregnant and you know it's not you, the only
> alternative is that it's the Holy Spirit?
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
You will see from the style of posts that the individual is quite
mad. He's jealous of the fact that I have something he doesn't,
and that I know where I'm going, and he still lives in fear.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 05 05:05PM -0700

On 10/5/2018 1:26 PM, Horizon68 wrote:
> can scale to big machines.
 
> Read more here:
 
> https://jakob.engbloms.se/archives/1435
 
Relaxed Memory Ordering can scale better in certain scenarios. These are
very delicate in nature! One has to know what they are doing. I always
thought of the extreme wrt sequential consistency everywhere to be akin
to putting corks on the forks to protect programmers from injuring
themselves.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:54PM -0400

On 10/07/2018 04:46 PM, Rick C. Hodgin wrote:
> And so ends tonight's teaching. Tune in tomorrow for more C++ related
> discussion.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
If you are unhappy with his spam, please send an email to abuse@
giganews.com. I have tried to get him suspended from giganews on
multiple occasions, but they will not listen to me.
 
I am tired of these slanderous attacks by a coward who has no idea
what he is doing to himself by attacking people in this way. I
would like to see them end forever, at the very least so he will
case from piling additional heaping burning coals upon his head.
 
--
Rick C. Hodgin
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)