Thursday, August 23, 2018

Digest for comp.lang.c++@googlegroups.com - 9 updates in 3 topics

Sky89 <Sky89@sky68.com>: Aug 23 06:48PM -0400

Hello....
 
My next software projects..
 
As you have noticed i have implemented graphical Winmenus, it is an
interesting Widget that i have designed myself, i will enhance it more,
but as also you have noticed that the zipfile of my Winmenus using
Wingraph contains my 64 bit windows executabe demo called real3d1.exe
that makes you take a look at my Winmenus widget and it contains a 3D
Opengl demo and other demos , please execute this real3d1.exe to look at
how powerful is my graphical program, i have also made Wingraph
compatible with FreePascal and Delphi including Delphi tokyo, so that
you will be able to prototype rapidly 3D "Opengl" graphical programs,
you can download my graphical Winmenus using wingraph from:
 
https://sites.google.com/site/scalable68/winmenus-using-wingraph
 
 
And as i will enhance soon my graphical Winmenus
Here is my next software projects that i will implement and "invent":
 
Here is my other software project for Delphi and FreePascal that i will
finish soon:
 
1- I will support async and await
 
2- I will support futures
 
3- I will support "scalable" Parallel Foreach with priorities that will
be very "powerful" using my "scalable" Threadpools with and without
priorities.
 
Here is my Threadpool with priorities that i have invented and that
scales very well (i have invented another "fully" scalable Threadpool
that is really powerful), read about it and download it from here:
 
https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well
 
And here is my last project in FreePascal and Delphi(including Delphi
tokyo) that i have "invented", it is a "scalable" reference counting
with efficient support for weak references, you will not find it in C++
and you will not find it in Rust, read about it and download it from here:
 
https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references
 
 
I have also "invented" my C++ synchronization objects library,
read about it and download it from here:
 
https://sites.google.com/site/scalable68/c-synchronization-objects-library
 
You have to understand my work..
 
I have invented many scalable algorithms and there implementations, here
is some of them that i have "invented":
 
1- Scalable Threadpools that are powerful
 
2- Scalable RWLocks of different sorts.
 
3- Scalable reference counting with efficient support for weak references
 
4- Scalable FIFO queues that are node-based and array-based.
 
5- My Scalable Varfiler
 
6- Scalable Parallel implementation of Conjugate Gradient Dense Linear
System Solver library that is NUMA-aware and cache-aware, and also a
Scalable Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
7- Scalable MLock that is a scalable Lock.
 
8- Scalable SeqlockX
 
 
And there is also "many" other scalable algorithms that i have "invented".
 
You can find some of my scalable algorithms and there implementations in
Delphi and FreePascal and C++ on my website here:
 
https://sites.google.com/site/scalable68/
 
What i am doing by "inventing" many scalable algorithms and there
implementations, is wanting to make "Delphi" much better and making
FreePascal on the "Delphi" mode much better, my scalable algorithms
and there implementations are like HPC(high performance computing,
and as you have noticed i said also:
 
You will ask why have i invented many scalable algorithms and
there implementations? because also my work will permit us also to
"revolutionise" science and technology because it is HPC(high
performance computing), this is why i will also sell some of my scalable
algorithms and there implementations to companies such as Google or
Microsoft or Embarcadero.
 
Also HPC has revolutionised the way science is performed. Supercomputing
is needed for processing sophisticated computational models able to
simulate the cellular structure and functionalities of the brain. This
should enable us to better understand how our brain works and how we can
cope with diseases such as those linked to ageing and to understand more
about HPC, read more here:
 
https://ec.europa.eu/digital-single-market/en/blog/why-do-supercomputers-matter-your-everyday-life
 
And i think i will "sell" "some" of my scalable algorithms and there
implementations to Google or to Microsoft or to Embarcadero.
 
I will also enhance my Parallel archiver and my Parallel compression
Library that are powerful and that work with both C++Builder and Delphi
and to perhaps sell them to Embarcadero that sells Delphi and C++Builder.
 
About portability of my software projects
 
I have thought more, and as you have noticed i have written Intel
assembler routines for 32 bit and 64 bit for atomically incrementing and
and for atomically CompareExchange etc. so now they are working with x86
AMD and Intel processors for 32 bit and 64 bit, but i will soon make my
Delphi and FreePascal and C++ libraries portable to the other CPUs like
ARM(for Android) etc. for that i will use the following Delphi methods
for Delphi:
 
http://docwiki.embarcadero.com/Libraries/XE8/en/System.SyncObjs.TInterlocked.CompareExchange
 
and
 
http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.SyncObjs.TInterlocked.Exchange
 
 
And I will use the same functions that you find inside FreePascal, here
they are:
 
https://www.freepascal.org/docs-html/rtl/system/interlockedexchange64.html
 
and
https://www.freepascal.org/docs-html/rtl/system/interlockedexchange.html
 
and
 
https://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html
 
and
 
https://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange64.html
 
 
I will use them inside my scalable lock that is called scalable MLock
that i have "invented", so that it will be portable, here it is:
 
https://sites.google.com/site/scalable68/scalable-mlock
 
 
And when my scalable MLock will become portable on Delphi and FreePascal
i will port with it all my other libraries that uses atomically
increment and decrement etc., so my libraries will become portable to
the other CPUs like ARM for Android etc., so i think you will be happy
with my work.
 
About Extreme Scaling in CAE Applications..
 
I have just read the following about Ansys company:
 
https://en.wikipedia.org/wiki/Ansys
 
 
Notice that Ansys develops and markets finite element analysis software
used to simulate engineering problems.
 
I think that i have thought about this, and i have "invented"
a Scalable Parallel C++ Conjugate Gradient Linear System Solver Library,
in fact it scales "very" well, my library contains a Scalable Parallel
implementation of Conjugate Gradient Dense Linear System Solver library
that is NUMA-aware and cache-aware, and it contains also a Scalable
Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
Sparse linear system solvers are ubiquitous in high performance
computing (HPC) and often are the most computational intensive parts in
scientific computing codes. A few of the many applications relying on
sparse linear solvers include fusion energy simulation, space weather
simulation, climate modeling, and environmental modeling, and finite
element method, and large-scale reservoir simulations to enhance oil
recovery by the oil and gas industry.
 
Conjugate Gradient is known to converge to the exact solution in n steps
for a matrix of size n, and was historically first seen as a direct
method because of this. However, after a while people figured out that
it works really well if you just stop the iteration much earlier - often
you will get a very good approximation after much fewer than n steps. In
fact, we can analyze how fast Conjugate gradient converges. The end
result is that Conjugate gradient is used as an iterative method for
large linear systems today.
 
You can download my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from here:
 
https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
Read the following about Extreme Scaling in CAE Applications, this is
why i have invented my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library that scales very well:
 
https://www.cray.com/blog/extreme-scaling-in-cae-applications/
 
 
You can find some of my other software projects here:
 
https://sites.google.com/site/scalable68/
 
 
 
Thank you,
Amine Moulay Ramdane.
bitrex <user@example.net>: Aug 23 03:37PM -0400

On 08/23/2018 03:18 AM, Juha Nieminen wrote:
> than an external program. (Of course the drawback to this may be that
> the calculations would need to be done every single time that source
> code is recompiled, even if the calculated data itself remains the same.)
 
Post C++11 it's pretty dead-simple to generate entire lookup tables at
compile-time using templates and constexpr. It's a little more tricky
with C++11's tighter restrictions on constexpr but can still be done.
 
bitrex <user@example.net>: Aug 23 03:50PM -0400


> Brian
> Ebenezer Enterprises - Enjoying programming again.
> https://github.com/Ebenezer-group/onwards
 
Const pointers to mutable data make plenty of sense to me, but what do
when you want to write a move constructor for a class holding such a
pointer where the default-generated move constructor won't work for you.
You want to be able to assign the "other" class pointer to nullptr in
the move constructor body but can't, const-qualified pointers to mutable
data can only be modified in the initializer list.
 
Which is friggin' annoying because a const pointer to mustable data is
often just what you'd like to use in a move-only class, to enforce the
notion that this class is only reference-keeping for that member and not
actually copying data around. And unique ptr is not always appropriate
or even available.
Daniel <danielaparker@gmail.com>: Aug 23 12:50PM -0700

On Thursday, August 23, 2018 at 1:48:45 AM UTC-4, Juha Nieminen wrote:
 
> the constness of a member function should indicate that it's thread-safe to
> call it without a locking mechanism.
 
But "f() const" doesn't indicate that at all. You can't make any assumptions about whether f mutates state.
 
Daniel
legalize+jeeves@mail.xmission.com (Richard): Aug 23 09:16PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>IME, if you're not sure about such a member, you have an unclear
>overall picture of the class, or you're unconciously in the process of
>redesigning it.
 
+1
 
Most of the places where I see difficulty with the use of const on
members is that the class design doesn't follow Command/Query
Separation design guideline.
<https://martinfowler.com/bliki/CommandQuerySeparation.html>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Vir Campestris <vir.campestris@invalid.invalid>: Aug 23 11:13PM +0100

> It's nice to be able to agree with someone. Now I hope more
> people will sign the east const petition:
> http://slashslash.info/eastconst
 
Elsewhere we were talking about defects in the language. IMHO this is
one of them, along with the fact that
 
char* a,b;
 
declares two variables of different types.
 
I dare say back in the distant past this wasn't seen as a problem.
 
And constexpr? Like const, it should have been the default.
 
But it isn't, and we have to live with it.
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Aug 23 03:18PM -0700

On Thursday, 23 August 2018 22:13:03 UTC+3, Alf P. Steinbach wrote:
> [Sorry, I inadvertently first sent this follow-up as a reply mail.]
 
I use that mail box for registration (or resetting a password I
forgot) to random sites and so look into it rather rarely. Also
I have absent-mindedly cleaned it sometimes without reading anything.
 
 
> template<class T> using ptr_ = T*;
> template<class T> using ref_ = T&;
 
> But replacing `*` and `&` with such notation is too much for a formatter.
 
I can perhaps persuade team to accept ban to typedefing raw pointers
whatsoever but these ptr_<T> and ref_<T> are likely outside of my
abilities to convince people.
 
 
> In spite of the manifesto I think UTF-8 is the way to go now, after
> Visual C++ got support, but the support in Windows, for both g++ and
> Visual C++, is very incomplete.
 
Yes, it is indeed political. Very lot of text out there is UTF8.
https://w3techs.com/technologies/details/en-utf8/all/all
So tools that do not comply with UTF8 will share the fate of tools
that used RADIX50, EBCDIC and what were there by that trend.
 
> In particular,
 
> 1 with both g++ and Visual C++ the `main` arguments are encoded as
> Windows ANSI,
 
Yes, something like
 
echo 生きるか死ぬか
 
likely results with something like
 
生きるか死ぬか
 
So one has perhaps to Base64 a text to provide it as command line
argument in Windows.
 
> 2 there's no reasonably direct way to get UTF-8 console i/o (though one
> can use libraries like my header only ¹Wrapped stdlib), and
 
Thank you.
 
> 3 the standard library, e.g. `isspace`, is based on an assumption of
> fixed length encoding.
 
Figuring boundaries between words in text is rather non-trivial task.
Existence of `isspace` is illusion of it being doable simply.
 
> std::filesystem, which is designed with an assumption of Windows ANSI
> narrow encoding in Windows. So we need a kind of UTF-8 oriented wrapper.
> If anyone feels up to the task?
 
I have dropped any attempts in that direction since lot of tools
(including Microsoft's own) will choke at Unicode file names.
Perhaps real thing would be to rewrite ICU as header-only using
constexpr en masse to help C++ itself? Would be titanic task.
"Öö Tiib" <ootiib@hot.ee>: Aug 23 03:33PM -0700

On Thursday, 23 August 2018 22:50:27 UTC+3, Daniel wrote:
> > call it without a locking mechanism.
 
> But "f() const" doesn't indicate that at all. You can't make any
> assumptions about whether f mutates state.
 
I may be wrong but I got feeling that Juha was talking about a sane
agreement between developers what a const should indicate and not
what language should guarantee.
 
Otherwise yes C++ has well-formed ways to mutate data through const
pointer or to access private data of object. So language guarantees
nothing.
Sky89 <Sky89@sky68.com>: Aug 23 04:43PM -0400

Hello...
 
Read this:
 
 
My Winmenus using wingraph was updated to version 1.02
 
Now it is both compatible with Delphi and with FreePascal, now
it works with Delphi tokyo, but there is only one difference between
Delphi and FreePascal, the double click with the left button of the
mouse of freepascal is replaced in Delphi with a one click with the
middle button of the mouse to avoid a problem.
 
You can now download both the zipfiles for FreePascal and for Delphi.
 
You can download my Winmenus using wingraph from:
 
https://sites.google.com/site/scalable68/winmenus-using-wingraph
 
 
I have implemented Winmenus using wingraph, this one is graphical, i
have also included an Opengl demo and other demos , just execute the
real3d1.exe executable inside the zipfile to see how it is powerful, i
will soon enhance much more my Winmenus.
 
WinMenus using wingraph version 1.02
 
Author: Amine Moulay Ramdane
 
Description:
 
Drop-Down Menu widget using the Object Pascal wingraph unit , it
supports keyboard and mouse. Please look at the real3d1.pas demo inside
the zip file, i have included its 64 bit executable, please run it and
see(please double click with the mouse on the items to execute and click
on the middle mouse to stop the demo, and press escape to exit from the
demo).
 
And use the 'Up' and 'Down' and 'PageUp and 'PageDown' to scroll the menu..
And 'Enter' to select an item from the menu..
And the 'Esc' on the keyboard to exit from the menu..
 
and right arrow and left arrow to scroll on the left or on the right of
the menu
 
Winmenus is event driven, i have to explain it more to you to understand
more...
 
At first you have to create your Widget menu by executing something like
this:
 
Menu1:=TMenu.create(5,5);
 
This will create a Widget menu at the coordinate (x,y) in characters =
(5,5)
 
After that you have to set your callback function, cause my Winmenus is
event driven, so you have to add an item with AddItem() and set the
callback function at the same time, like this:
 
AddItem('First 3D opengl demo',test1);
 
test1 will be the callback function.
 
When you execute menu1.execute(false) with a parameter equal to false my
Winmenus widget will draw your menu without waiting for your input and
events, when you set the parameter of the execute() method to true it
will wait for your input and events, if the parameter of the execute
method is true and the returned value of the execute method ctExit that
means you have pressed on the Escape key to exit.
 
Language: FPC Pascal v2.2.0+ / Delphi 7+: http://www.freepascal.org/
 
Operating Systems: Windows..
 
Required FPC switches: -O3 -Sd
 
-Sd for delphi mode....
 
 
 
Thank you,
Amine Moulay Ramdane.
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.

No comments: