Thursday, February 20, 2020

Digest for comp.lang.c++@googlegroups.com - 14 updates in 5 topics

Christian Gollwitzer <auriocus@gmx.de>: Feb 20 07:50AM +0100

Am 20.02.20 um 00:06 schrieb Lynn McGuire:
>> cares
>> about the actual contents of strings.
 
> Anything that calls the Win32 API or opens a file ...
 
Migrate to Linux?
 
SCNR
 
But it's true - fopen("blöä€λκΠни", "r") simply works as expected on any
modern Linux system.
"Öö Tiib" <ootiib@hot.ee>: Feb 20 12:07AM -0800

On Thursday, 20 February 2020 08:51:01 UTC+2, Christian Gollwitzer wrote:
> >> about the actual contents of strings.
 
> > Anything that calls the Win32 API or opens a file ...
 
> Migrate to Linux?
 
That will only open new (likely smaller) market and not
resolve the issue on Lynn's current, Windows-using market.
 
Windows-API-calling code-base of described size (together
with unit-tests and other support stuff) can take tens
of man-years to migrate to Mac and/or Linux. So couple
millions of budget is needed for to start.
 
Lynn McGuire <lynnmcguire5@gmail.com>: Feb 20 01:22PM -0600

On 2/20/2020 12:50 AM, Christian Gollwitzer wrote:
 
> SCNR
 
> But it's true - fopen("blöä€λκΠни", "r") simply works as expected on any
> modern Linux system.
 
None of my customers are running Linux on their desktops. All are
businesses running Windows. But, who knows what the future will bring.
 
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Feb 20 01:23PM -0600

On 2/20/2020 2:07 AM, Öö Tiib wrote:
 
>> SCNR
 
>> But it's true - fopen("blöä€λκΠни", "r") simply works as expected on any
>> modern Linux system.
 
Thanks for understanding the issues of working in a very small shop. We
actually want to go to the cloud but that is a total disaster for us.
 
Lynn
Bart <bc@freeuk.com>: Feb 20 07:45PM

On 20/02/2020 19:22, Lynn McGuire wrote:
>> any modern Linux system.
 
> None of my customers are running Linux on their desktops.  All are
> businesses running Windows.  But, who knows what the future will bring.
 
I was last writing commercial software in the 90s, to run on Windows
because that was what everybody had. Windows PCs could also be bought
anywhere off-the-shelf, ready to go, and with a vast number of
peripherals available, that could be trusted to just work.
 
I had no idea at the time where one would even buy a Linux PC.
 
Perhaps one in a thousand asked about running on Linux, but it wasn't
worth it to us to do anything about that. Some had success though
emulating Windows on Macs.
 
20-25 years on, I'm not sure that much has changed; I still have no idea
where one would buy an actual Linux desktop PC. (Tablets and phones are
a completely different market, not really suitable for the kind of
software we wrote.)
 
Even if Linux PCs were everywhere - each one is running a different
version of Linux. Each could have a different processor. How do you even
distribute binaries on such systems? That is also a different world.
 
It's only on newsgroups like this that Windows developers are in a minority.
David Brown <david.brown@hesbynett.no>: Feb 20 09:48PM +0100

On 20/02/2020 20:45, Bart wrote:
> distribute binaries on such systems? That is also a different world.
 
> It's only on newsgroups like this that Windows developers are in a
> minority.
 
Usually you don't buy a Linux PC. You buy a PC, and install Linux on
it. Some PC's can be bought without an OS, and some few specialist
places sell them with Linux installed already (usually Ubuntu). Often
you get the option of no OS or your preference of Linux from sites that
let you build your own configuration. The same applies to machines you
build yourself from parts. And of course, any company or organisation
buying in enough quantity gets to make their own choices.
 
But for the solid majority of cases, you get a PC with Windows and
either dual-boot or scrub Windows, and install Linux yourself.
Economics is a weird thing - it is cheaper for most manufacturers to
sell a PC with Windows than one without, even when they have to pay for
the Windows license. If they sell you Windows, they offset the cost of
the license by installing crapware - time-limited versions of MS Office,
internet "security" software, and all the other limited and demo
software that can take hours to clear out. These are adverts, and the
manufacturer makes money from the deal. So they lose out if you want a
system without Windows.
 
Installing a common Linux system - such as Ubuntu, Red Hat, or Mint (my
personal favourite for desktops) is generally a simple business, and I
find it takes a lot less time than getting many Windows systems
installed from their hard disk, configured (with all the painful process
of persuading it to work without giving Microsoft the keys to your
life), and removing the crapware. And then you have to start installing
a proper browser or two, email program, office package, compiler,
editor, and so on - things that come out of the box on any Linux
desktop. Windows and Linux each have their advantages and
disadvantages, and each are far from perfect - but there is no doubt in
my mind that Linux is normally a great deal faster to go from
out-of-the-box to usable system.
 
You worry about different versions of Linux on different systems - that
is a valid concern. For most software it is not a big issue, but it is
certainly quite an effort if you want your software to look good on a
range of systems - people can use very different desktops, for example.
(Equally, for some kinds of software it can be difficult supporting all
the different Windows versions around.)
 
Linux desktops will invariably be x86 systems, and all but the oldest
will be 64-bit - just as in the Windows world. cpus are only a concern
if you want to take advantage of special features, the latest SIMD
instructions, and so on - again, just like for Windows.
 
The solid majority of user desktop systems are Windows, with Mac's in a
low second place, and Linux behind. For laptops, ChromeOS is a growing
market share - it is Linux. But most programs written for it will be
higher level languages or web applications, and work on any system.
 
On servers, especially more powerful ones, Linux is a lot more common.
I don't think we've used Windows on a new server since the turn of the
century.
 
You see Linux on the desktop or laptop in more specialist use. You see
it a lot in software development - it is simply a hugely more efficient
environment for most software development tasks. For anyone involved in
IT or networking, Linux is the natural choice for anything except
perhaps managing Windows servers. High power software - simulations,
modelling, big data, high-end CAD, etc., is often done on *nix of some kind.
 
As for people in a newsgroup like this, I think a lot of it is a
generation thing. Much of the "old guard" started with Unix systems
(some were pre-Unix), and many will have moved to Linux. The middle
group will mostly be from a Windows-dominated age, while newer
programmers are on Linux again.
"Öö Tiib" <ootiib@hot.ee>: Feb 20 02:00AM -0800

On Monday, 17 February 2020 00:38:35 UTC+2, Keith Thompson wrote:
> person has a very long history of posting hundreds of off-topic
> articles. Asking him to stop has never had any effect. I suggest a
> killfile (which may have to be updated as he changes his email address).
 
He just seems to forget his previous promises not to post his off-topic posts
here.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 20 11:02AM +0100

> He just seems to forget his previous promises not to post his off-topic posts
> here.
 
He is manic and his impulses are stronger than his inhibitions.
Cholo Lennon <chololennon@hotmail.com>: Feb 19 10:45PM -0300

On 2/19/20 1:40 AM, Daniel wrote:
> I've been following the "Union type punning in C++" posts with some interest,
> but not exactly sure of the conclusion.
 
Just for the record: there is a nice talk from CppCon 2019 about "Type
punning in modern C++"
 
https://youtu.be/_qzMpk-22cc
 
--
Cholo Lennon
Bs.As.
ARG
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 20 01:08AM -0500

Öö Tiib wrote:
 
> Yes, the classes are standard layout and therefore in tag()
> you could just return *reinterpret_cast<uint8_t const*>(&data_);
> as well.
I do not think this code has specified behavior as I could not find in the
Standard any additional guarantee about reinterpret_cast results conditioned on
the involved types' being having standard-layout.
 
The only thing that seem to be guaranteed about reinterpret_cast (except for
some cases of its application to the pointer to an object of class derived from
the class to which cast is done or other way around where it is guaranteed to
behave like static_cast) is that under certain conditions reverse cast of the
pointer received from the direct cast yields the original value of the pointer.
 
In other words, I think the result of reinterpret_cast of a pointer (with the
exception mentioned above) can only be useful to cast it back to the pointer to
the object of its original type. The above code relies on de-referenced result
of reinterpreted_cast so I think its behavior is unspecified.
 
> Yes, when you are unsure if certain member in your B or C
> is standard layout or not then check std::is_standard_layout
> about the member or about whole B or C.
 
HTH
-Pavel
"Öö Tiib" <ootiib@hot.ee>: Feb 19 11:00PM -0800

On Thursday, 20 February 2020 08:08:54 UTC+2, Pavel wrote:
> I do not think this code has specified behavior as I could not find in the
> Standard any additional guarantee about reinterpret_cast results conditioned on
> the involved types' being having standard-layout.
 
I copy-paste from C++2017:
 
| Two objects a and b are pointer-interconvertible if:
| —(4.1) they are the same object, or
| —(4.2) one is a standard-layout union object and the other is a non-static data member of that object, or
| —(4.3) one is a standard-layout class object and the other is the first non-static data member of that object, or, if the object has no non-static data members, the first base class subobject of that object, or
| —(4.4) there exists an object c such that a and c are pointer-interconvertible, and c and b are pointerinterconvertible.
|
| If two objects are pointer-interconvertible, then they have the same address, and it is possible to obtain a pointer to one from a pointer to the other via a reinterpret_cast
 
 
> exception mentioned above) can only be useful to cast it back to the pointer to
> the object of its original type. The above code relies on de-referenced result
> of reinterpreted_cast so I think its behavior is unspecified.
 
I am quite certain that the reinterpret_cast is not so useless as you put it.
 
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 20 12:02AM -0500

Bonita Montero wrote:
>> I have never said it had bad readability. I said your "nice thing" serving
>> no purpose was an obfuscation pretending to be simple while not being so. ...
> Whoever finds the contradiction may keep it.
Yes, if they inherit obfuscated code they will suffer.
 
>>      return TSX_ABORTED_DONT_RETRY;
>> }
 
> That's a matter of taste.
Rather it is vital matter for any entity that have to maintain their code base.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 20 07:47AM +0100

> Rather it is vital matter for any entity that have to maintain their code base.
 
The code I've given is simple and readable.
aminer68@gmail.com: Feb 19 04:35PM -0800

Hello,
 
 
I am like a genius, because i have invented many scalable algorithms and i am inventing many scalable algorithms, you have to see me to believe, this is why i am talking here, i have showed you some of my scalable algorithms that i have invented, but this is not all, because i have invented many other scalable algorithms that i have not showed you here, and here is one more new invention that i have just
invented right now:
 
If you have noticed i have just implemented my EasyList here:
 
https://sites.google.com/site/scalable68/easylist-for-delphi-and-freepascal
 
But i have just enhanced its algorithm to be scalable in the Add() method and in the search methods, but it is not all , i will use for
that my just new invention that is my generally scalable counting networks, also its parallel sort algorithm will become much much more scalable , because i will use for that my other invention of my fully my scalable Threadpool, and it will use a fully scalable parallel merging algorithm , and read below about my just new invention of generally scalable counting networks:
 
Here is my new invention of a scalable algorithm:
 
I have just read the following PhD paper about the invention that we call counting networks and they are better than Software combining trees:
 
Counting Networks
 
http://people.csail.mit.edu/shanir/publications/AHS.pdf
 
And i have read the following PhD paper:
 
http://people.csail.mit.edu/shanir/publications/HLS.pdf
 
So as you are noticing they are saying in the conclusion that:
 
"Software combining trees and counting networks which are the only techniques we observed to be truly scalable"
 
But i just found that this counting networks algorithm is not generally scalable, and i have the logical proof here, this is why i have just come with a new invention that enhance the counting networks algorithm to be generally scalable. And i think i will sell my new algorithm of a generally scalable counting networks to Microsoft or Google or Embarcadero or such
software companies.
 
So you have to be careful with the actual counting networks algorithm that is not generally scalable.
 
My other new invention is my scalable reference counting and here it is:
 
https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references
 
And my other new invention is my scalable Fast Mutex that is really powerful, and here it is:
 
About fair and unfair locking..
 
I have just read the following lead engineer at Amazon:
 
Highly contended and fair locking in Java
 
https://brooker.co.za/blog/2012/09/10/locking.html
 
So as you are noticing that you can use unfair locking that can have starvation or fair locking that is slower than unfair locking.
 
I think that Microsoft synchronization objects like the Windows critical section uses unfair locking, but they still can have starvation.
 
But i think that this not the good way to do, because i am an inventor and i have invented a scalable Fast Mutex that is much more powerful , because with my Fast Mutex you are capable to tune the "fairness" of the lock, and my Fast Mutex is capable of more than that, read about it on my following thoughts:
 
More about research and software development..
 
I have just looked at the following new video:
 
Why is coding so hard...
 
https://www.youtube.com/watch?v=TAAXwrgd1U8
 
 
I am understanding this video, but i have to explain my work:
 
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
 
Read the following of the senior research scientist that is called Dave Dice:
 
Preemption tolerant MCS locks
 
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
 
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:
 
1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance
5- And it has a good preemption tolerance.
 
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there implementations, and i think i will sell some of them to Microsoft or to Google or Embarcadero or such software companies.
 
 
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)