Friday, February 1, 2019

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

Elephant Man <conanospamic@gmail.com>: Feb 01 05:43PM

Article d'annulation émis par un modérateur JNTP via Nemo.
Elephant Man <conanospamic@gmail.com>: Feb 01 09:14PM

Article d'annulation émis par un modérateur JNTP via Nemo.
Elephant Man <conanospamic@gmail.com>: Feb 01 09:14PM

Article d'annulation émis par un modérateur JNTP via Nemo.
Elephant Man <conanospamic@gmail.com>: Feb 01 09:40PM

Article d'annulation émis par un modérateur JNTP via Nemo.
Elephant Man <conanospamic@gmail.com>: Feb 01 10:22PM

Article d'annulation émis par un modérateur JNTP via Nemo.
Horizon68 <horizon@horizon.com>: Feb 01 02:03PM -0800

Hello,
 
Read this:
 
 
About my scalable algorithms..
 
My scalable algorithms that i have invented are working now on x86.
 
But i will port them smartly soon to other CPU architecture like ARM..
 
I think i will port just my scalable MLock and my scalable AMLock for
Delphi and Freepascal so that my scalable algorithms work on ARM CPU
architecture, ARM that is of a weak memory model, here is the Memory
ordering of ARM:
 
https://en.wikipedia.org/wiki/Memory_ordering
 
 
Here is my scalable MLock and my scalable AMLock that i have invented:
 
https://sites.google.com/site/scalable68/scalable-mlock
 
and here:
 
https://sites.google.com/site/scalable68/scalable-amlock
 
 
I think x86 is TSO and is the same as Sparc TSO.
 
 
About memory models and sequential consistency:
 
As you have noticed i am working with x86 architecture..
 
Even though x86 gives up on sequential consistency, it's among the most
well-behaved architectures in terms of the crazy behaviors it allows.
Most other architectures implement even weaker memory models.
 
ARM memory model is notoriously underspecified, but is essentially a
form of weak ordering, which provides very few guarantees. Weak ordering
allows almost any operation to be reordered, which enables a variety of
hardware optimizations but is also a nightmare to program at the lowest
levels.
 
Read more here:
 
https://homes.cs.washington.edu/~bornholt/post/memory-models.html
 
 
Memory Models: x86 is TSO, TSO is Good
 
Essentially, the conclusion is that x86 in practice implements the old
SPARC TSO memory model.
 
The big take-away from the talk for me is that it confirms the
observation made may times before that SPARC TSO seems to be the optimal
memory model. It is sufficiently understandable that programmers can
write correct code without having barriers everywhere. It is
sufficiently weak that you can build fast hardware implementation that
can scale to big machines.
 
Read more here:
 
https://jakob.engbloms.se/archives/1435
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Feb 01 01:38PM -0800

Hello...
 
Read this:
 
 
About memory models...
 
I wrote about memory models, and i think that
Delphi and FreePascal had the necessary to make it
easier even if they have no memory model, here
is the functions that you need:
 
For Delphi there is a function called System.MemoryBarrier
and here it is:
 
http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.MemoryBarrier
 
 
And for FreePascal there three functions called:
 
- ReadWriteBarrier
- WriteBarrier
- ReadBarrier
 
Here they are:
 
https://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html
 
 
So as you have noticed my scalable algorithms works on x86 ,
but with the above functions i will make them more easily portable
to ARM and to other CPU architetures.
 
And I have just taken a look at the following algorithm invented by
Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
Notice that it is using FlushProcessWriteBuffers() , and notice on the
following what said Chris Thomasson about FlushProcessWriteBuffers()
 
==
 
Well, the thing with FlushProcessWriteBuffers() is that it will generate
a lot of traffic in the sense of sending the interrupts to all the CPUS
in the processes affinity mask. This is an "active" form of quiescent
state auto-detection. As of now, vZOOM uses "passive" detection
technique on Windows; It does not need to interrupt CPU activity.
 
AFAICT, that is the only advantage I can see to passive epoch detection,
rather than active. Also, for PDR, the epochs should be detected on a
frequent enough basis to keep the deferred object lists from backing up
too much. The frequency of epochs in an active system will be creating a
lot of IPI traffic, while the passive system will be creating none.
 
Read more here:
 
https://groups.google.com/forum/#!topic/comp.programming.threads/E0gGTkg46HE
==
 
 
But I i have just invented a new scalable RWLock algorithm that is
"better" than the above because it doesn't need
FlushProcessWriteBuffers() and it doesn't use any membar or lock in the
readers side and it is starvation-free and it is FIFO fair on the
readers side and FIFO fair on the writers side, and i will implement my
new scalable algorithm in C++ and Delphi and Freepascal.
 
 
 
 
Thank youm
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Feb 01 12:40PM -0800

Hello...
 
I have just taken a look at the following algorithm invented by
Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
Notice that it is using FlushProcessWriteBuffers() , and notice on the
following what said Chris Thomasson about FlushProcessWriteBuffers()
 
==
 
Well, the thing with FlushProcessWriteBuffers() is that it will generate
a lot of traffic in the sense of sending the interrupts to all the CPUS
in the processes affinity mask. This is an "active" form of quiescent
state auto-detection. As of now, vZOOM uses "passive" detection
technique on Windows; It does not need to interrupt CPU activity.
 
AFAICT, that is the only advantage I can see to passive epoch detection,
rather than active. Also, for PDR, the epochs should be detected on a
frequent enough basis to keep the deferred object lists from backing up
too much. The frequency of epochs in an active system will be creating a
lot of IPI traffic, while the passive system will be creating none.
 
Read more here:
 
https://groups.google.com/forum/#!topic/comp.programming.threads/E0gGTkg46HE
==
 
 
But I i have just invented a new scalable RWLock algorithm that is
"better" than the above because it doesn't need
FlushProcessWriteBuffers() and it doesn't use any membar or lock in the
readers side and it is starvation-free and it is FIFO fair on the
readers side and FIFO fair on the writers side, and i will implement my
new scalable algorithm on C++ and Delphi and Freepascal.
 
 
 
 
Thank youm
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Feb 01 10:39AM -0800

Hello...
 
 
My C++ synchronization objects library for Windows and Linux was again
updated ..
 
Now i think it is fast and it is working correct..
 
 
You can download it from:
 
https://sites.google.com/site/scalable68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Feb 01 01:32AM -0800

On Thursday, 31 January 2019 22:42:39 UTC+2, Bart wrote:
 
> No it's not questionable. Most of the big programs I've written have
> involved recursive data. (CAD systems, windows-based GUIs, compilers and
> interpreters. Even file systems are recursive.) Obviously yours don't.
 
"Mutually recursive" about modules means that the modules have
circular dependency. The modules depend on existence of each other.
That is not strongly tied to recursive data of our programs.
 
Data where object of some type may have elements (or elements of
elements) of same type is recursive. That does not mean that
modules declaring these types are mutually recursive. Module A
of GUI widgets does not need to know anything about module B
of GUI widgets despite a program can use widgets from A and B as
subwidgets of each other. Instead in typical architecture both A
and B depend on module W that defines common loose-coupling
interfaces between super- and sub-widgets.
 
Circular dependency between modules indicates that the modules
were either separated pointlessly, incorrectly, not enough or
that the interfaces are too intrusive.
IOW it can be these should be joined, split even more, the
responsibilities clarified and/or the interfaces made more
generic.
 
The circular dependencies in GUIs is typically result of having
the program logic and often also parts of data leaked into GUIs.
That should not be blamed upon recursive nature of GUI. Damage
done by spaghetti-programmers is not easy to clean up and
can take years. C++ modules can help there as abstract
framework of architecture.
David Brown <david.brown@hesbynett.no>: Feb 01 11:33AM +0100

On 31/01/2019 22:42, Bart wrote:
 
> But if you are going to add lists to the set of recursive data
> structures, then that would just increase the number of programs that
> use mutual recursion.
 
Recursive data structures do not always require mutually recursive
functions. You often want a simple recursive function (for lists, you
are likely to use iteration - but you might prefer recursion), applying
a visitor function as you move through the structure.
 
Again, I am not saying that mutual recursive functions are not useful,
or denying that they are a good choice for some programming constructs.
All I am saying is that they aren't needed much - writing an occasional
forward function declaration to support them really is not a hardship.
Wolfgang Kilian <kilian@invalid.com>: Feb 01 11:50AM +0100

On 31.01.2019 22:17, Thomas Koenig wrote:
> write it) is only one aspect. Another aspect is the question
> of how to handle #defines which are in force when a module is
> used...
 
It looks like the C++ module proposal as such is reasonable and rather
similar to Fortran's most recent module/submodule system. (Apart from
the C++ habit of creating incomprehensible syntax.) The problem seems
to be the interaction with the preprocessor.
 
One of the best decisions of the Fortran committee in the past was to
*not* include a preprocessor in the standard. (Sorry, couldn't resist.)
 
-- Wolfgang
 
--
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo
Bart <bc@freeuk.com>: Feb 01 11:48AM

On 01/02/2019 10:50, Wolfgang Kilian wrote:
> to be the interaction with the preprocessor.
 
> One of the best decisions of the Fortran committee in the past was to
> *not* include a preprocessor in the standard.  (Sorry, couldn't resist.)
 
The preprocessor (here I mainly mean macro processing and conditional
code) should have no effect on a /proper/ module system. Someone writes:
 
import A
 
then the interface imported from module A (from A.c, A.cpp, or some file
that has been generated) should be entirely unaffected by anything that
has gone before in this module.
 
If the proposed C++ module scheme is just a development of C's
text-based #include mechanism, then that's not going to cut it.
 
Further, you should be able to write:
 
import A
import A
import A
 
and the last two lines should be ignored. This doesn't need intervention
here, nor inside A (eg. "pragma once"). This stuff is the job of the
module system.
 
You should also be able to write either:
 
import A
import B
 
or:
 
import B
import A
 
with no difference. (If B itself imports A, then that's its business.)
 
If a module imports A, and A imports C, then in this module:
 
import A
 
nothing from C should be visible, or affect anything in this file.
 
If A exports something which has elements of C and that is needed being
able to use A, then then it may be necessary to import C too.
 
(It's not clear what my own implementation [not for C++] does. If A
exports a struct containing members of a type exported from C, then this
struct can be used normally from the main program, those members can be
accessed by name etc.
 
But the name of the type is not visible unless C is imported directly.
However that is not needed for the normal use of that exported type.)
 
--
bart
David Brown <david.brown@hesbynett.no>: Feb 01 01:47PM +0100

On 01/02/2019 12:48, Bart wrote:
 
> then the interface imported from module A (from A.c, A.cpp, or some file
> that has been generated) should be entirely unaffected by anything that
> has gone before in this module.
 
That is the intention of C++ modules.
 
It is also possible with well-designed C headers - but you do need to
design them appropriately.
 
 
> If the proposed C++ module scheme is just a development of C's
> text-based #include mechanism, then that's not going to cut it.
 
Everyone knows that. Text-based #include was simple to implement in the
early days of C, and very flexible - but you pay the price of not
knowing the preprocessor environment when a header is processed. C++
modules will not see macros defined by other files when they are
compiled, and they will not export the macros defined within the
modules. (Compiler "builtin" macros will, of course, be available.)
 
 
> and the last two lines should be ignored. This doesn't need intervention
> here, nor inside A (eg. "pragma once"). This stuff is the job of the
> module system.
 
This should be fine. (It is also fine with well-designed C headers.)
 
 
> or:
 
>   import B
>   import A
 
This should be fine. (It is also fine with well-designed C headers.)
 
 
> If a module imports A, and A imports C, then in this module:
 
>   import A
 
> nothing from C should be visible, or affect anything in this file.
 
I am not sure on that. Certainly it cannot be as simple as you suggest.
 
Suppose module C provides a type "foo", and module A provides a type
that has a field of type "foo". Then clearly users of module A need
access to C's "foo" type.
 
It is reasonable that if A imports C for its implementation only, then
those parts are not visible in something that imports A. (I mean
visible to the user code - the compiler can see it, and use it in
optimisation, inlining, etc.)
 
It is a while since I have read the proposals for C++ modules, and they
are somewhat in flux - so I don't know how they handle this.
 
> accessed by name etc.
 
> But the name of the type is not visible unless C is imported directly.
> However that is not needed for the normal use of that exported type.)
 
I think it is strange that /you/ don't know what /your/ implementation
of /your/ language does. What do the specification documents for your
language say?
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 03:28PM +0200

On 1.02.2019 14:47, David Brown wrote:
 
> I think it is strange that /you/ don't know what /your/ implementation
> of /your/ language does. What do the specification documents for your
> language say?
 
I'm not surprised at all, the amount of details one can hold in one's
head is not infinite. And specification documents for not so formal
projects have the unfortunate habit to go out of date in 15 minutes.
Bart <bc@freeuk.com>: Feb 01 01:55PM

On 01/02/2019 12:47, David Brown wrote:
 
> Suppose module C provides a type "foo", and module A provides a type
> that has a field of type "foo". Then clearly users of module A need
> access to C's "foo" type.
 
Yes, this my example from below. But why should A need access to "foo"?
That is, named access to that type.
 
Accessing only a field of that type, whatever A needs to do that is
taken care of. The implementation will need to know those details and
/it/ has access to all the modules.
 
 
 
> I think it is strange that /you/ don't know what /your/ implementation
> of /your/ language does. What do the specification documents for your
> language say?
 
This area is defined by the implementation, which means I have to try it
out to see what happens. Generally I see very few problems (but then I
also don't bother with 'public' and 'private' members).
 
I think what it does in this example is that top-level names exported by
C, which are visible to A, are not visible to the main program.
 
Slightly more elaborate example:
 
======================
c.m
======================
global record point = (int16 x,y) # 'global' is needed to export
 
======================
a.m
======================
import c
global record line = (point p,q)
 
======================
prog.m
======================
import a
line v = ((10,20),(30,40))
 
proc start=
println "V=", v.p.x, v.p.y, v.q.x, v.q.y
println =v.p.bytes
println =v.p.typestr
println =v.p.x.bytes
println =v.p.x.typestr
end
======================
 
The output is:
V= 10 20 30 40
BYTESIZE(V.P)= 4
TYPESTR(V.P)= record(i16 x,i16 y)
BYTESIZE(V.P.X)= 2
TYPESTR(V.P.X)= i16
 
So everything actually needed to make use of A's 'line' type is
available. But if I try and write:
 
point a,b
 
in prog.m, it doesn't work unless I import C.
 
Simpler example:
 
c.m contains: global const xyz = 77
a.m contains: import c; global const abc = xyz+100
prog.m contains: import a; ... print abc
 
Output is '177' which incorporates the value of xyz. But I can't
directly use 'xyz' unless I import C.
 
--
bart
David Brown <david.brown@hesbynett.no>: Feb 01 03:12PM +0100

On 01/02/2019 14:55, Bart wrote:
>> access to C's "foo" type.
 
> Yes, this my example from below. But why should A need access to "foo"?
> That is, named access to that type.
 
Maybe you want to make a new object of that same type? (Though "auto"
and "decltype" might handle it for you). If the type is an enumeration,
you'll want access to the enumeration constants too.
 
> Accessing only a field of that type, whatever A needs to do that is
> taken care of. The implementation will need to know those details and
> /it/ has access to all the modules.
 
That will often be the case, yes.
 
> also don't bother with 'public' and 'private' members).
 
> I think what it does in this example is that top-level names exported by
> C, which are visible to A, are not visible to the main program.
 
I didn't need details of how it is implemented - I am not a user of your
language. I merely thought it was odd that you didn't know.
David Brown <david.brown@hesbynett.no>: Feb 01 03:19PM +0100

On 01/02/2019 14:28, Paavo Helde wrote:
 
> I'm not surprised at all, the amount of details one can hold in one's
> head is not infinite. And specification documents for not so formal
> projects have the unfortunate habit to go out of date in 15 minutes.
 
As far as I understand it, Bart has done professional work using this
language. To me, that means that the delivery of the code to the
customer has to include everything necessary for the customer to
maintain the code, even if the original developer is no longer
available. That normally means the code has to be in an established
language - the customer has to be able to hire a developer who knows the
language, and they need to be able to acquire the development tools. If
the language is obscure (and a single person home-made language is
obscure), the customer delivery would include the compiler/translator,
and at least basic specifications, documentation, examples, etc., so
that a new developer can learn what they need to know.
 
Perhaps Bart has a different sort of relationship or agreement with his
customers, or perhaps the generated C code is considered good enough as
"source code".
 
If this particular language is just for fun and hobby use, then I
understand how the details can be forgotten - not many people see
writing detailed language specifications or implementation manuals as
fun, and I fully appreciate it he has not written them.
Bart <bc@freeuk.com>: Feb 01 02:50PM

On 01/02/2019 14:19, David Brown wrote:
>> projects have the unfortunate habit to go out of date in 15 minutes.
 
> As far as I understand it, Bart has done professional work using this
> language.
 
(No, only older versions of it from 80s to early 2000s. They didn't have
this module system but something much cruder (although still more
sophisticated that C's headers!).)
 
> understand how the details can be forgotten - not many people see
> writing detailed language specifications or implementation manuals as
> fun, and I fully appreciate it he has not written them.
 
(I did actually put something together recently, but you're right, it
was a bit of a slog, and not properly finished needing lots of editing:
 
https://github.com/sal55/mx/blob/master/mdocs.md
 
And it won't be finished because I'm already working on a new
replacement language. That will include many elements that are found in
C++ (eg. built-in flex arrays) but it will be dramatically simpler to
use and should still compile instantly. However, I have yet to actually
do it ...)
David Brown <david.brown@hesbynett.no>: Feb 01 04:29PM +0100

On 01/02/2019 15:50, Bart wrote:
 
> (No, only older versions of it from 80s to early 2000s. They didn't have
> this module system but something much cruder (although still more
> sophisticated that C's headers!).)
 
Fair enough.
 
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 06:37PM +0200

On 1.02.2019 16:19, David Brown wrote:
> understand how the details can be forgotten - not many people see
> writing detailed language specifications or implementation manuals as
> fun, and I fully appreciate it he has not written them.
 
I fully agree that in an ideal world each professionally used program
and especially each compiler language should have a complete detailed
specification. But that's in an ideal world.
 
In the real world I guess the most prominent example of a language not
having a formal specification and relying on a reference implementation
only is Python, hyped to heaven and used professionally by millions.
 
PHP did not have a formal specification until 2014 either.
David Brown <david.brown@hesbynett.no>: Feb 01 06:02PM +0100

On 01/02/2019 17:37, Paavo Helde wrote:
> having a formal specification and relying on a reference implementation
> only is Python, hyped to heaven and used professionally by millions.
 
> PHP did not have a formal specification until 2014 either.
 
There are different levels of specification and documentation - often
you don't need very detailed or formal specifications. You just need
information about how the language works and what the features and
libraries do.
Horizon68 <horizon@horizon.com>: Feb 01 08:15AM -0800

Hello..
 
 
My C++ synchronization objects library for Windows and Linux was updated..
 
You can download it from:
 
https://sites.google.com/site/scalable68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Rosario19 <Ros@invalid.invalid>: Feb 01 08:56AM +0100

On Mon, 28 Jan 2019 21:52:20 +0000, Vir Campestris
 
>I don't see how code clarity can be improved by hiding the type of a
>variable.
 
>Andy
 
i assume "generic type" == "C++ key word auto"
 
i never used "auto" key word, but in some other language i mature
convinction that in a function the type of variable in input can be a
generic type (the same its result... )... it is important that all
operation in function are applicabile to that argument of function and
all the type in function are ok in using with that argument of
function (even run time ok for the type in input (compiler or pheraps
interpreter set all not definite types in variables of that function
for to be ok for the argument type passed to function))...
"Öö Tiib" <ootiib@hot.ee>: Feb 01 02:08AM -0800

On Friday, 1 February 2019 09:49:18 UTC+2, Rosario19 wrote:
> >variable.
 
> >Andy
 
> i assume "generic type" == "C++ key word auto"
 
From where you took that "generic type" in above text?
Usually by "generic type" we mean templates of classes.
 
The auto is just placeholder where we either know too
well or do not care at all what the concrete type is.
Otherwise C++ is statically typed.
 
auto asterisks = std::setfill('*');
 
What is the type of asterisks? It is concrete type but we
typically do not know and do not care what exactly.
What we care is what it does. It manipulates stream to fill
unused width with asterisks, but it can be tricky to read
that out from its type.
 
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)