Thursday, May 12, 2016

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

bleachbot <bleachbot@httrack.com>: May 12 04:20PM +0200

bleachbot <bleachbot@httrack.com>: May 12 07:46PM +0200

bleachbot <bleachbot@httrack.com>: May 13 12:01AM +0200

bleachbot <bleachbot@httrack.com>: May 13 12:14AM +0200

bleachbot <bleachbot@httrack.com>: May 13 12:35AM +0200

Ramine <ramine@1.1>: May 12 03:36PM -0700

Hello,
 
Now that i have finished extending my C++ sychronization objects
library and now that i have explained to you my inventions that
are my sychronization algorithms of my C++ sychronization objects
library, so from now on i will not post in this C++ group.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 12 03:15PM -0700

Hello....
 
 
I have told you before that C++ was dangerous for parallelism,
because of its memory model that is weaker than the x86 architecture
memory model, but i have finally avoided this problem by implementing
my inventions with FreePascal and Delphi compilers that doesn't
reorder loads and stores even with compiler optimization, and
this is less error, so i have finally compiled my algorithms
implementations into Dynamic Link Libraries that
are used by C++ in a form of my great C++ Object Synchronization
Library. So C++ has become great again.
 
You can download my new and extended C++ Synchronization objects library:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 12 03:01PM -0700

Hello......
 
My C++ Synchronization objects library was extended...
 
My previous invention was a scalable Asymmetric Distributed
Reader-Writer Mutex that uses a technic that looks like Seqlock without
looping on the reader side like Seqlock, and this has permited the
reader side to be costless.
 
I have finished implementing another implementation of a new algorithm
of mine, this one is a scalable Asymmetric Reader-Writer Mutex that is
not distributed, and it uses a technic that looks like Seqlock without
looping on the reader side like Seqlock, and this has permited the
reader side to be costless, and this one calls the windows
FlushProcessWriteBuffers() just one time, but the my asymmetric
distributed algorithm calls FlushProcessWriteBuffers() many times.
 
 
My scalable Asymmetric Distributed Reader-Writer Mutex and
my scalable Asymmetric Reader-Writer Mutex are suitable for
reatime critical systems, and i have just included them
my C++ Synchronization objects library.
 
 
You can download my new and extended C++ Synchronization objects library:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
Author: Amine Moulay Ramdane
 
Email: aminer@videotron.ca
 
Description:
 
This library contains 9 synchronization objects, first one is my
scalable SeqlockX that is a variant of Seqlock that eliminates the
weakness of Seqlock that is "livelock"of the readers when there is more
writers, and second is my scalable MLock that is a scalable
lock , and third is my SemaMonitor that combines all characteristics
of a semaphore and an eventcount and also a windows
Manual-reset event and also a windows Auto-reset event, and fourth
is my scalable DRWLock that is a scalable reader-writer lock that is
starvation-free and it does spin-wait, and five is is my scalable
DRWLockX that is a scalable reader-writer lock that is
starvation-free and it doesn't spin-wait, but it waits on the Event
objects and my SemaMonitor, so it is energy efficient, and six one is
my scalable asymmetric DRWLock that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the
reader side, so it look like RCU, and it is fast. This scalable
Asymmetric Distributed Reader-Writer Mutex is FIFO fair on the
writer side and FIFO fair on the reader side and of course it is
starvation-free and it does spin-wait, and seven one is my scalable
asymmetric DRWLockX that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the reader side, so it
look like RCU, and it is fast. This scalable Asymmetric Distributed
Reader-Writer Mutex is FIFO fair on the writer side and FIFO fair on the
reader side and of course it is starvation-free, and it does not
spin-wait, but it waits on Event objects and my SemaMonitor, so it
is energy efficient, and eight is my LW_Asym_RWLockX that is a
lightweight scalable Asymmetric Reader-Writer Mutex that uses a technic
that looks like Seqlock without looping on the reader side
like Seqlock, and this has permited the reader side to be costless,
it is FIFO fair on the writer side and FIFO fair on the reader side and
it is of course Starvation-free and it does spin-wait, and nine is my
Asym_RWLockX, a lightweight scalable Asymmetric Reader-Writer Mutex that
uses a technic that looks like Seqlock without looping
on the reader side like Seqlock, and this has permited the reader
side to be costless, it is FIFO fair on the writer side and FIFO fair on
the reader side and it is of course Starvation-free and it does not
spin-wait, but waits on my SemaMonitor, so it is energy efficient.
 
If you take a look at the zip file , you will notice that it contains
the DLLs Object pascal source codes, to compile those dynamic link
libraries source codes you will have to download my SemaMonitor Object
pascal source code and my SeqlockX Object pascal source code and my
scalable MLock Object pascal source code and my scalable DRWLock Object
pascal source code from here:
 
https://sites.google.com/site/aminer68/
 
I have compiled and included the 32 bit and 64 bit windows Dynamic Link
libraries inside the zip file, if you want to compile the dynamic link
libraries for Unix and Linux and OSX on (x86) , please download the
source codes of my SemaMonitor and my scalable SeqlockX and my scalable
MLock and my scalable DRWLock and compile them yourself.
 
My SemaMonitor of my C++ synchronization objects library is
easy to use, it combines all characteristics of a semaphore and an
eventcount and also a windows Manual-reset event and also a windows
Auto-reset event, here is its C++ interface:
 
class SemaMonitor{
public:
SemaMonitor(bool state, long2 InitialCount1=0,long2
MaximumCount1=INFINITE);
~SemaMonitor();
 
void wait(unsigned long mstime=INFINITE);
void signal();
void signal_all();
void signal(long2 nbr);
void setSignal();
void resetSignal();
long1 WaitersBlocked();
};
 
So when you set the first parameter that is state of the constructor to
true. it will add the characteristic of a Semaphore to the to the
Eventcount, so the signal will not be lost if the threads are not
waiting for the SemaMonitor objects, but when you set the first
parameter of the construtor to false, it will not behave like a
Semaphore because if the threads are not waiting for the SemaCondvar or
SemaMonitor the signal will be lost..
 
the parameters InitialCount1 and MaximumCount1 is the semaphore
InitialCount and MaximumCount.
 
The wait() method is for the threads to wait on the SemaMonitor
object for the signal to be signaled.
 
and the signal() method will signal one time a waiting thread on the
SemaMonitor object.
 
the signal_all() method will signal all the waiting threads on the
SemaMonitor object.
 
the signal(long2 nbr) method will signal nbr number of waiting threads
 
the setSignal() and resetSignal() methods behave like the windows Event
object's methods that are setEvent() and resetEvent().
 
and WaitersBlocked() will return the number of waiting threads on
the SemaMonitor object.
 
As you have noticed my SemaMonitor is a powerful synchronization object.
 
Please read the readme files inside the zip file to know more about them..
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and OSX on (x86)
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 12 10:47AM -0700

Hello.....
 
A new algorithm is coming...
 
My previous invention was a scalable Asymmetric Distributed
Reader-Writer Mutex that uses a technic that looks like Seqlock without
looping like Seqlock, and this has permited the reader side to be costless.
 
I am finishing another implementation of a new algorithm of mine,
this one is a scalable Asymmetric Reader-Writer Mutex that is
not distributed, and it uses a technic that looks like Seqlock without
looping like Seqlock, and this has permited the reader side to be
costless, and this one calls the windows FlushProcessWriteBuffers() just
one time, but the my asymmetric distributed algorithm calls
FlushProcessWriteBuffers() many times.
 
 
So stay tuned my new inventions are coming soon...
 
 
 
Thank you,
Amine Moulay Ramdane.
Jerry Stuckle <jstucklex@attglobal.net>: May 11 11:11PM -0400

On 5/11/2016 4:18 PM, Ian Collins wrote:
 
>> And how has ignoring helped? Has it stopped him from posting?
 
> No and nether has responding which is why news servers consider it to be
> spam.
 
But he does respond to posts. It helps significantly if multiple people
are consistent in condemning his actions.
 
>> Just because YOU don't see his posts doesn't mean everyone else doesn't.
 
> No one using decent servers such as news.Individual.net and
> news.aioe.org see its postings, just the pointless replies.
 
So you're saying the only "decent" servers out there are ones which drop
his posts? ROFLMAO! Just what I would expect from you, Ian.
 
Here's a clue. There are lots of "decent" news servers out there. Some
of them might even drop YOUR posts.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
David Brown <david.brown@hesbynett.no>: May 12 12:40PM +0200

On 12/05/16 05:11, Jerry Stuckle wrote:
>> spam.
 
> But he does respond to posts. It helps significantly if multiple people
> are consistent in condemning his actions.
 
He responds to occasional posts, but not many. And he does not respond
to posts asking him to stop posting, or at least to stop making large
numbers of multiple posts in inappropriate newsgroups, starting new
threads for each post. He appears to simply ignore any such post.
 
Having multiple people condemn someone's posting habits can sometimes
help - and it is worth trying with a new "bad" poster. But in this
case, it has been tried many times, and failed.
 
> his posts? ROFLMAO! Just what I would expect from you, Ian.
 
> Here's a clue. There are lots of "decent" news servers out there. Some
> of them might even drop YOUR posts.
 
I would not consider a public news server that dropped Ian's posts to be
"decent". But certainly there are many good servers (such as the very
popular news.eternal-september.org) that don't drop Ramine's posts, as
it is unlikely that they fall foul of the basic requirements for
blacklisting. After all, he is not posting phishing links, or adverts
for body part enhancements, or anything of that sort. He is posting
about software and algorithms in software development groups - some
people may find his posts interesting (despite his terrible posting
habits), and it should be up to individuals to choose to filter him or not.
 
Individuals may also choose to have local news client rules that kill
all threads or subthreads started by particular posters, so that they
skip replies as well as posts.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 12 01:52PM +0100

On Thu, 12 May 2016 12:40:40 +0200
 
> Individuals may also choose to have local news client rules that kill
> all threads or subthreads started by particular posters, so that they
> skip replies as well as posts.
 
Eternal september don't filter him because he is using their news
servers to propagate his spam from his Eternal September account.
However he seems to be breaking their terms of use at
http://www.eternal-september.org/index.php?showpage=terms on two
grounds.
 
First, which is something of a technicality, he is giving an invalid
address in his From header which is not in the permitted
"name@domain.invalid" format.
 
Secondly there seem reasonable arguments that he is spamming according
to their definition, namely "(To spam means to send many identical or
nearly-identical messages separately to a large number of Usenet
newsgroups.)" I suppose it depends a bit on what "large number"
means. He multi-posts identical posts to at least four groups which I
know of: comp.programming, comp.programming.pascal.misc,
comp.programming.threads and now comp.programming.c++. There may be
others (I don't know). He kills off each of these groups he posts to
apart from (as yet) comp.programming.c++, which may have enough other
turnover to resist that.
 
For French speakers, he posted this one
https://groups.google.com/forum/#!topic/comp.programming.threads/a3nxEdBrrvI
explaining his condition (in rather poor French) as appearing to suffer
from secret mind control technologies, although he subsequently said he
sent it to the wrong group.
 
Maybe we should be more compassionate, I don't know. But the frequent
multi-posting with garbage posts to multiple groups is obnoxious, even
if he is subject to impulses he finds himself unable to control.
 
Chris
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 12 06:02AM -0700

On Thursday, May 12, 2016 at 8:53:31 AM UTC-4, Chris Vine wrote:
> know of: comp.programming, comp.programming.pascal.misc,
> comp.programming.threads and now comp.programming.c++. There may be
> others (I don't know).
 
He also posts to at least comp.lang.c, and comp.arch.
 
Best regards,
Rick C. Hodgin
Jerry Stuckle <jstucklex@attglobal.net>: May 12 09:11AM -0400

On 5/12/2016 8:52 AM, Chris Vine wrote:
 
> First, which is something of a technicality, he is giving an invalid
> address in his From header which is not in the permitted
> "name@domain.invalid" format.
 
A common misconception. All Eternal September requires is a valid
address in the registration so they can contact you if they want. An
invalid address in the From: header is permitted.
 
> others (I don't know). He kills off each of these groups he posts to
> apart from (as yet) comp.programming.c++, which may have enough other
> turnover to resist that.
 
The problem here is what is a "large number"? It could be argued that 4
is not a large number; at the same time it could be argued that it is a
large number.
 
> multi-posting with garbage posts to multiple groups is obnoxious, even
> if he is subject to impulses he finds himself unable to control.
 
> Chris
 
I agree - he is very obnoxious. And his code is crap. But I don't find
that to be surprising.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 12 06:14AM -0700

On Thursday, May 12, 2016 at 8:53:31 AM UTC-4, Chris Vine wrote:
> Maybe we should be more compassionate, I don't know.
 
I feel the same way. He is obviously a very hard worker, dedicated, devoted
to his cause. He appears to be posting thoughts that need frequent editing,
which are not well-served by Usenet. He would do better to post a link to
his article on a blog, and then periodically update or refresh the article
as needed so those happening across his pages can read his content if they
desire.
 
> But the frequent
> multi-posting with garbage posts to multiple groups is obnoxious, even
> if he is subject to impulses he finds himself unable to control.
 
I wouldn't mind his posts if he would post a single topic for each mainstay
subject, and then reply with regards to that subject on that post only. The
part that bothers me is that he posts multiple posts which should be replies
to the original posts. On comp.arch there are currently over 50 separate
posts on the first page in Google Groups alone.
 
Here are the post titles of the first dozen:
 
This was my last post on this group
I have benchmarked my new algorithm
Read this , it is important
To be more precise, read more...
Look at this scalable Asymmetric rw_mutex from Dmitry Vyukov
A memory barrier is needed
Here is my final words about C++
I correct, read again...
I must be more clearer...
I will make my way of thinking more clear...
Finally my great updated C++ synchronization objects library is here...
I will quit this comp.arch group
 
Only one of them has more than one post, and that was someone who is
chastising him for his multiple posts.
 
I'm all for hard work and devotion. I think it's commendable. But the
fact that there are so many posts which should be replies ... that's what
bothers me. I have personally emailed him at least twice to ask him to
post replies rather than new posts. He did not reply to my emails, and
seemed to only amp up his multiple postings after my email.
 
At this point, I have resolved to simply mark his posts spam, and to not
reply to him.
 
Best regards,
Rick C. Hodgin
Jerry Stuckle <jstucklex@attglobal.net>: May 12 09:16AM -0400

On 5/12/2016 6:40 AM, David Brown wrote:
 
> Having multiple people condemn someone's posting habits can sometimes
> help - and it is worth trying with a new "bad" poster. But in this
> case, it has been tried many times, and failed.
 
Sometimes it needs to be kept up for a while. And sometimes it doesn't
work..
 
But what I do know is that ignoring a problem *never* makes it go away.
I've seen newsgroups killed by posters such as Ramine. Look at
alt.computer.consultants, for instance. It used to be a great group for
consultants, with lots of on-topic posts daily. Now it's completely
dead because people like Ramine drove everyone away.
 
> about software and algorithms in software development groups - some
> people may find his posts interesting (despite his terrible posting
> habits), and it should be up to individuals to choose to filter him or not.
 
You might not consider it "decent", but someone else might. It's all a
matter of perspective.
 
> Individuals may also choose to have local news client rules that kill
> all threads or subthreads started by particular posters, so that they
> skip replies as well as posts.
 
Which only solves the symptom. It does not cure the problem. And these
types of posts have a tendency to drive new people away.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 12 02:37PM +0100

On Thu, 12 May 2016 06:02:22 -0700 (PDT)
> > comp.programming.threads and now comp.programming.c++. There may be
> > others (I don't know).
 
> He also posts to at least comp.lang.c, and comp.arch.
 
Yes, it appears he has been multi-posting his recent posts to comp.arch
also, but it appears not to comp.lang.c (that may be his next target).
So that makes 5 known groups multi-posted with his recent onslaught.
 
It is difficult to believe that this is consistent with any reasonable
terms of use, but the interpretation is up to Eternal September I
guess. They must presumably have posting records for all groups.
 
Chris
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 12 06:38AM -0700

On Thursday, May 12, 2016 at 9:37:18 AM UTC-4, Chris Vine wrote:
 
> It is difficult to believe that this is consistent with any reasonable
> terms of use, but the interpretation is up to Eternal September I
> guess. They must presumably have posting records for all groups.
 
He does not CC his posts to comp.lang.c, but he also posts there in the
same fashion. Here's his latest post:
 
https://groups.google.com/forum/#!topic/comp.lang.c/0O_pMI-Plw4
 
Best regards,
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: May 12 04:18PM +0200

On 12/05/16 15:16, Jerry Stuckle wrote:
 
> Sometimes it needs to be kept up for a while. And sometimes it doesn't
> work..
 
> But what I do know is that ignoring a problem *never* makes it go away.
 
No, you don't "know" that.
 
I fully agree that it is worth trying to reason with a person when they
are doing something that many people dislike - in many cases, they are
unaware of the problem, and are happy to try to change to suit others.
But persistently and repeatedly moaning at the same poster is highly
unlikely to help. Certainly I have never seen it helping, and certainly
I have seen it aggravating the problem and irritating many other people.
For most people, there is little practical difference between the
person regularly posting nonsense, and the person posting a reply to
every nonsense post.
 
And while some problem-posters (such as Ramine) don't seem to be at all
concerned about whether people read, reply to or ignore his posts, there
are many who only post to bug people and provoke them. In such cases,
they will continue to post as long as they get replies - when they are
consistently ignored, they will go elsewhere.
 
> alt.computer.consultants, for instance. It used to be a great group for
> consultants, with lots of on-topic posts daily. Now it's completely
> dead because people like Ramine drove everyone away.
 
Certainly Ramine and his like are a problem in Usenet. But the solution
is for others to make other posts and discussions, rather than to get
overly concerned about such characters. There is no reason to suppose
that alt-computer.consultants would have survived as a viable group even
if Ramine was not around - many groups die off through lack of
interesting posts, rather than due to an excess of pointless posts. It
is simply that when there are few good posts, the bad ones stand out more.
 
>> habits), and it should be up to individuals to choose to filter him or not.
 
> You might not consider it "decent", but someone else might. It's all a
> matter of perspective.
 
True.
 
>> skip replies as well as posts.
 
> Which only solves the symptom. It does not cure the problem. And these
> types of posts have a tendency to drive new people away.
 
Sometimes treating the symptom is the best we can do.
 
There is no possibility that complaining to Ramine will help in this
case. But by all means contact news.eternal-september.org and report
him as a spammer - if they cut his access, then that will cure the
problem (at least for a while, and in this particular case).
Jerry Stuckle <jstucklex@attglobal.net>: May 12 01:20PM -0400

On 5/12/2016 10:18 AM, David Brown wrote:
>> work..
 
>> But what I do know is that ignoring a problem *never* makes it go away.
 
> No, you don't "know" that.
 
Sorry, you have no idea what I "know", so your statement is fallacious.
 
> For most people, there is little practical difference between the
> person regularly posting nonsense, and the person posting a reply to
> every nonsense post.
 
Unlike you, I have seen it help, and have seen people stop because of
it. And I have seen posters being ignored and totally killing a
once-popular newsgroup.
 
> are many who only post to bug people and provoke them. In such cases,
> they will continue to post as long as they get replies - when they are
> consistently ignored, they will go elsewhere.
 
That is the case for some trolls, that is true.
 
> if Ramine was not around - many groups die off through lack of
> interesting posts, rather than due to an excess of pointless posts. It
> is simply that when there are few good posts, the bad ones stand out more.
 
That doesn't work when the folks like Ramine become so obnoxious that
they drive others away. Rather than argue, people leave. And when new
people start reading a newsgroup and see crap like that, they often go
other places.
 
Yes, the lack of interesting posts can kill a newsgroup. But so can too
much off-topic junk.
 
People here have Ramine in a killfile. That's fine for them. But it
doesn't help the group, and it doesn't help new people looking at the group.
 
> case. But by all means contact news.eternal-september.org and report
> him as a spammer - if they cut his access, then that will cure the
> problem (at least for a while, and in this particular case).
 
You can complain, also. Maybe if enough people here complained, Ray
would do something about it. However, even if it's off topic, just
posting to 3-4 newsgroups may not be considered spamming.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Ramine <ramine@1.1>: May 12 07:20AM -0700

Hello.......
 
Here is my new invention that is my new algorithm..
 
I have invented a new algorithm of my scalable Asymmetric Distributed
Reader-Writer Mutex, and this one is costless on the reader side,
this one doesn't use any atomic operations and/or StoreLoad style memory
barriers on the reader side, my new algorithm have
added a technic that looks like Seqlock, but this technic doesn't
loop as Seqlock. Here is my algorithm:
 
On the reader side we have this:
 
--
procedure TRWLOCK.RLock(var myid:integer);
 
var myid1:integer;
id:long;
begin
 
 
myid1:=0;
id:=FCount5^.fcount5;
if (id mod 2)=0
then FCount1^[myid1].fcount1:=1
else FCount1^[myid1].fcount1:=2;
if ((FCount3^.fcount3=0) and (id=FCount5^.fcount5) and
(FCount1^[myid1].fcount1=1))
then
else
begin
LockedExchangeAdd(nbr^.nbr,1);
if FCount1^[myid1].fcount1=2
then LockedExchangeAdd(FCount1^[myid1].fcount1,-2)
else if FCount1^[myid1].fcount1=1
then LockedExchangeAdd(FCount1^[myid1].fcount1,-1);
event2.wait;
LockedExchangeAdd(FCount1^[myid1].fcount1,1);
LockedExchangeAdd(nbr^.nbr,-1);
end;
end;
--
 
 
The writer side will increment FCount5^.fcount5 like does
a Seqlock, and the reader side will grap a copy of FCount5^.fcount5
and copy it on the id variable, if (id modula 2) is equal to zero
that means the writer side has not modified yet Fcount3^.fcount3,
and the reader side will test again if FCount3^.fcount3 equal 0, and
if id=FCount5^.fcount5 didn't change and if FCount1^[myid1].fcount1 that
we have assigned before didn't change and that means that we are
sure that the writer side will block on FCount1^[myid1].fcount1 equal 1.
 
And notice with me that i am not looping like in Seqlock.
 
And the rest of my algorithm is easy to understand.
 
This technic that look like Seqlock without looping like Seqlock
will allow us to be sure that alThough the x86 architecture will reorder
the loads of the inside reader critical section , the loads
inside the reader critical section will not go beyond the load of
FCount5^.fcount5 and this will allow my algorithm to work correctly.
 
My algorithm is FIFO fair on the writer side and FIFO fair on the
Reader side , and of course it is Starvation-free, and it is
suitable for realtime critical systems.
 
I have just updated my C++ synchronization library with
the implementation of my new algorithm..
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
You will find the source code of my new algorithm here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
The source
 
 
It is the version 2 that is my own algorithm.
 
 
 
Thank you,
Amine Moulay Ramdane.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 12 01:48AM +0200

On 11.05.2016 08:01, Stuart Redmann wrote:
>> should IMHO discuss the PIMPL idiom.
> [snip]
 
> I'm pretty sure that Juha knows about The pimpl pattern as well.
 
That's a pretty obscure comment. What (the fuck) do you think he meant
then? We seem to have eliminated all possible sources of his confusion.
 
Cheers!,
 
- Alf
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)