Wednesday, October 21, 2015

Digest for comp.lang.c++@googlegroups.com - 11 updates in 6 topics

bleachbot <bleachbot@httrack.com>: Oct 21 10:51PM +0200

bleachbot <bleachbot@httrack.com>: Oct 21 11:13PM +0200

bleachbot <bleachbot@httrack.com>: Oct 22 01:25AM +0200

Ramine <ramine@1.1>: Oct 21 07:26PM -0700

Hello.....
 
 
I want to share with you this wonderful music of Johannes Linstead:
 
 
https://www.youtube.com/watch?v=GUYfqlAEn1k
 
 
Thank you,
Amine Moulay Ramdane.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 21 02:45PM -0500

> #include LATEST_DECODE_METHOD
> Is including a file using a macro name not legal? Or am I running
> into a bug in MSVS 2012?
 
This is called "computed include" and appears to be pretty legal. Probably
this has nothing to do with the error what you see.
 
> The variable is declared in an included source file itself which has
> the include file using the variable.
 
Typically a variable is declared in the header file and used in the source
file, not vice versa as how you claim. Please check
http://www-igm.univ-mlv.fr/~dr/CPP/c++-faq/how-to-post.html#[5.7]
 
 
Cheers
Paavo
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 21 08:47PM +0100


> #define LATEST_DECODE_METHOD "decodeVer14.h"
 
> ...
 
> #include LATEST_DECODE_METHOD
 
That's fine in standard C++ (and in C for that matter).
 
 
> bool all_is_not_ok = false; // outer include file
> ...
> all_is_not_ok = true; // inner include file
 
I'm a bit lost by the inners and outers here, but you should be able to
construct a two or three file version (each with only one or two lines)
that illustrates the problem. Sometimes just doing that can reveal
something unexpected.
 
> undeclared identifier
 
> Is including a file using a macro name not legal? Or am I running
> into a bug in MSVS 2012?
 
It's legal (section 16.2 paragraphs 4 and 8). What's the smallest case
you can make that shows the problem? (If it turns out to be a bug,
you'll need a simple case to report it anyway.)
 
--
Ben.
Lynn McGuire <lmc@winsim.com>: Oct 21 04:45PM -0500

On 10/21/2015 2:20 PM, Lynn McGuire wrote:
 
> Is including a file using a macro name not legal? Or am I running into a bug in MSVS 2012?
 
> Thanks,
> Lynn
 
Sorry, my bad. I thought that the variable was declared in the code and it is not for one of the exe's built using the code. The
large exe compiles and links, the small exe does not. Turns out that I added a variable to the large exe and did not add it to the
small exe. Sigh.
 
Sincerely,
Lynn
Ramine <ramine@1.1>: Oct 21 05:14PM -0700

Hello,
 
I have to be more precise:
 
Object Pascal of the Delphi and FreePascal compilers on x86 doesn't do
any reordering of loads and stores , it just let the Strong Memory Model
of x86 Intel hardware do it, i am only supporting the x86 architecture
of AMD and Intel, so this is easying for me sequential consistency,
because i have only to take care of the following non-guarantee listed
in the x86 spec:
 
"Loads may be reordered with older stores to different locations"
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Oct 21 04:51PM -0700

Hello,
 
 
I will add to my previous post this:
 
 
Although C++ support the weak memory model that
is error prone for sequential consistency, you are
safe because you can use the following Synchronization
Algorithm Verificator for C++0x called Relacy Race Detector:
 
 
You can find it and download it from here:
 
http://www.1024cores.net/home/relacy-race-detector
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Oct 20 07:52PM -0700

Hello....
 
 
As you have noticed i have wrote my new algorithm versoin 1.31
of my scalable distributed reader-writer mutex, and just after that i
have made it sequential consistent, but you have to understand ladies
and gentlemen that i have implemented my new algorithm in Object Pascal
and i have ported it to FreePascal and Delphi, and they both (Delphi and
FreePascal compilers) respect the strong memory model of the x86
architecture, so it was much easier for me to make it sequential
consistent because you have only to take care of the following
non-guarantee listed in the x86 spec:
 
Loads may be reordered with older stores to different locations.
 
 
So i have made my new algorithm version 1.31 of my scalable distributed
reader-writer mutex sequential consistent with easy.
 
 
That's not the case for C++, C++ have made it difficult for sequential
consistency, because it respect the weak memory model that is much
difficult to reason about and that is prone to mistakes by programmers,
so becareful of C++ and languages that respect the weak memory model.
 
 
And also my new algorithm of a scalable reader-writer mutex version 1.31
take care of false-sharing and it is now sequential consistent and like
in Seqlock or RCU , my new scalable distributed reader-writer mutex
doesn't use any atomic operations and/or StoreLoad style memory barriers
on the reader side, so it's very fast and scalable..but you have to use
the define's option TLW_RWLockX or the define's option TRWLockX inside
the defines1.inc file for that.
 
 
You can download it from here:
 
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
 
 
Thank you,
Amine Moulay Ramdane.
Christopher Pisz <nospam@notanaddress.com>: Oct 20 06:51PM -0500

On 10/20/2015 9:52 PM, Ramine wrote:
> Hello....
 
> As you have noticed i have wrote my new algorithm versoin 1.31
 
 
One more spammy post and you're going on my blacklist.
You only need one post for one topic
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
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)