Wednesday, December 9, 2020

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

David Brown <david.brown@hesbynett.no>: Dec 09 08:58AM +0100

On 09/12/2020 03:58, Brian Wood wrote:
 
> Services are here to stay. Code generators are here
> to stay. My software could be much better than it
> already is if the community admitted this 10 years ago.
 
"Software as a service" is well-known and well established, and has been
for a long time. And code generators have existed for decades (how old
is yacc?).
 
There are also on-line services for generating code of various sorts.
In my line of work, I can think of two cases where I have used them.
 
One was for a very specialised co-processor that was used for timer
channels in a microcontroller. The development tools were very
expensive (being extremely niche), but the manufacturer offered a
service letting you select a few standard routines and have them
compiled and linked together to a binary blob. That was quite handy.
 
The other is for generating SDK's that are specialised for your
particular choice of microcontroller, peripherals, etc., that are built
and can then be downloaded. To be honest, it is a real PITA - I would
much prefer to download a bigger package with all the parts I need.
 
I've also seen lots of locally run code generators for microcontrollers
- "wizards" (or some such term) attached to an IDE that you use to
generate the code. Again, a real PITA and far more cumbersome than
plain code modules.
 
 
So what is it that makes you so convinced that your online code
generator is "the future" and "here to stay" ? I've seen no indication
that it is a significant trend (but maybe I have just missed it). All
I see about it is regular posts from you, begging for people to use it
or look at it, offering bribes for using it (when you give the price of
your work as "less than worthless", it's not good advertising) and
unsubstantiated claims that the technology is great.
 
If you are going to convince anyone, you are going to have to give some
evidence or reasoning.
"Öö Tiib" <ootiib@hot.ee>: Dec 09 06:13AM -0800

> Services are here to stay. Code generators are here
> to stay. My software could be much better than it
> already is if the community admitted this 10 years ago.
 
You snipped ".. but at the end it does not matter."
 
Command line tool can be turned with week or
two into "cloud service". So it is cheap to make
inconvenience you made, why should community
care about it, if they do not need that code?

I repeat: Matters if the code (however it was produced)
is making whole product that uses it competitive or not
and in what use cases.
scott@slp53.sl.home (Scott Lurndal): Dec 09 02:57PM


>"Software as a service" is well-known and well established, and has been
>for a long time. And code generators have existed for decades (how old
>is yacc?).
 
Slightly older than LINC (https://en.wikipedia.org/wiki/LINC_4GL).
Brian Wood <woodbrian77@gmail.com>: Dec 09 01:20PM -0800

On Wednesday, December 9, 2020 at 8:13:20 AM UTC-6, Öö Tiib wrote:
 
> I repeat: Matters if the code (however it was produced)
> is making whole product that uses it competitive or not
> and in what use cases.
 
You sound like Hillary Clinton: "What difference does it
make?" One difference is the work is being done by a
"band of theologians" rather than by various companies.
Quality software is hard to produce and getting more so
with Corona/Wuhan. Sorry, but for those outside the ark,
prospects are bleak.
 
 
Brian
Ebenezer Enterprises - In a place where there are no men,
strive to be a man! Pirkei Avot 2:6
https://www.chabad.org/library/article_cdo/aid/2011/jewish/Chapter-Two.htm
Juha Nieminen <nospam@thanks.invalid>: Dec 09 10:01AM

> I disagree. I find <namespace>:: peppered all over the code annoying and messy.
> There's a reason the "using" command was included as part of the standard.
 
The "std::" prefix makes the code more readable because it acts as a visual
clue that something from the standard library is being used there. With a
quick visual scan you can immediately see where standard library utilities
are being used. Without the prefix it requires a deeper look, and a deeper
experience and knowledge of what's from the standard library and what isn't.
 
The "std::" prefix also conveys information that makes it easier to
undestand what code is doing, or gives you immediately a hint of where to
look. For example, suppose you see a line of code like this:
 
if(equal(a, b, c))
 
what does that mean? Without further knowledge it's hard to say. Is that
"equal()" function some custom function (or even macro) somewhere else
in the code? Maybe it's declared in some header file? An IDE would tell
you quickly, but you don't always have an IDE at hand.
 
The name alone also doesn't tell you much about what it's doing. Maybe
it's comparing if all three parameters are equal? What is the type of
the parameters?
 
However, consider if the line had been written like this instead:
 
if(std::equal(a, b, c))
 
that change alone conveys an enormous amount of useful information,
which you can discern without having to see anything else in the code.
You immediately know that it's a standard library function. Even if
you don't know what it does, you immediately know where to look for it.
 
If you do know what std::equal() does, you also know what it's doing
there and, moreover, what kind of variables a, b and c are.
(Particulary, they are iterators of some kind.)
 
The line of code did not become harder to read and understand by the
addition of the prefix, but the exact opposite.
spuddy@isnotyourbuddy.co.uk: Dec 09 10:41AM

On Wed, 9 Dec 2020 10:01:09 +0000 (UTC)
>quick visual scan you can immediately see where standard library utilities
>are being used. Without the prefix it requires a deeper look, and a deeper
>experience and knowledge of what's from the standard library and what isn't.
 
Everyone is different I suppose. I disagree completely - I find a screen full
of std:: everywhere is just useless visual noise and clutter that detracts from
being able to read the code but perhaps because I started with C decades ago
I'm used to just knowing unqualified names. If I see vector its more readable
than std::vector but each to their own.
Richard Damon <Richard@Damon-Family.org>: Dec 09 07:31AM -0500

> being able to read the code but perhaps because I started with C decades ago
> I'm used to just knowing unqualified names. If I see vector its more readable
> than std::vector but each to their own.
 
I grew up as a C programmer, and used to think that same way. Finally I
realized that the typical C program and the typical C++ program were
very different. C++ programs get MUCH bigger and more complicated, and
code ends up looking into more scopes for name resolution, so habitually
adding the std:: can be a useful cognitive load reducing agent.
 
It somewhat depends on how well the problem partitions. If you can break
the problem into a whole lot of little files it is less needed, but even
with small 'files' the includes may bring in a lot of context. If your
using statements are limited (using std::equal; instead of using std;)
then at least a simple search will find where it is coming from.
 
The next step past this, where the prefix becomes ::std:: is in my mind
a bit too far, but then I don't create foo.std namespaces, so I don't
need that level of protection. If this became somewhat common, then I
could see the need.
spuddy@isnotyourbuddy.co.uk: Dec 09 02:35PM

On Wed, 9 Dec 2020 07:31:10 -0500
>I grew up as a C programmer, and used to think that same way. Finally I
>realized that the typical C program and the typical C++ program were
>very different. C++ programs get MUCH bigger and more complicated, and
 
Do you want to take take a guess at which language the 28 million line
linux kernel is written in? Ditto Windows and MacOS.
 
>code ends up looking into more scopes for name resolution, so habitually
>adding the std:: can be a useful cognitive load reducing agent.
 
I'm not saying it can't be useful if there's a potential name clash, but
generally I just find it irritating.
Richard Damon <Richard@Damon-Family.org>: Dec 09 01:19PM -0500

>> very different. C++ programs get MUCH bigger and more complicated, and
 
> Do you want to take take a guess at which language the 28 million line
> linux kernel is written in? Ditto Windows and MacOS.
 
Not saying that there aren't massive C programs, but the typical
application / module that was written in C is going to be smaller than a
typical project done in C++.
 
Also, its been a while since I browsed kernal code, but my memory is
that it isn't what most would think of as 'typical' C code,
>> adding the std:: can be a useful cognitive load reducing agent.
 
> I'm not saying it can't be useful if there's a potential name clash, but
> generally I just find it irritating.
 
It isn't just to resolve clashes, but to reduce the cognative load to
decide if this is referring to a local concept or some global standard one.
 
If I see just string, does my local namespace provide an enhanced
version, or is this the standard one.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 09 09:53PM +0100

On 08.12.2020 21:32, Christian Gollwitzer wrote:
> was borrowed from Haskell. Python is a very complex language today, just
> like C++ it got features after features, but because it started from a
> more recent base it is less crufty than C++.
 
Corresponding O(n^2) non-failure-checking code is somewhat but not much
more complex in C++:
 
 
int product = []{ for( int x: values ) for( int y: values ) if( x +
y == 2020 ) { return x*y; } }();
 
 
However C++ requires a minimum of standard scaffolding around that, like
 
 
#include <stdio.h>
auto main() -> int
{
int product = []{ for( int x: values ) for( int y: values ) if( x +
y == 2020 ) { return x*y; } }();
printf( "%d\n", product );
}
 
 
> Python is often 100 times slowere than the equivalent C++ program, but
> for tasks where the programmer time takes longer than the computation,
> it is really handy.
 
For a large data set (which is where it counts) the main slowness of the
Python one-liner in this case is the O(n^2) behavior.
 
Python code with I believe the same O(n) behavior as the posted C++
code, and about the same failure detection, could go like this:
 
 
values = {
1310,
# ...
}
 
for v in values:
other = 2020 - v
if other in values:
print( v*other )
exit()
raise Exception( "No such value" )
 
 
For comparison, that earlier posted O(n) C++ code, sans the outer
scaffolding:
 
 
const int data[] =
{
1310,
// ...
};
 
void cpp_main()
{
const auto values = unordered_set<int>( begin( data ), end( data ) );
for( const int v: values ) {
const int other = 2020 - v;
if( values.count( other ) > 0 ) {
out << v*other << endl;
return;
}
}
fail( "No such value" );
}
 
 
One little difference is that with Python the presumably constant time
lookup structure (here a key -> value dictionary without values) can be
expressed as a simple literal, the curly braces, while in C++ it has to
be constructed from more fundamental data.
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Dec 09 08:57AM +0100


> That is a rather naive statement. Humm... Why do you think split
> counters were invented? Why do you think RCU was invented? Well,
> to get rid of atomic RMW's and memory barriers. ;^)
 
What you saying here has nothing to do what I did.
scott@slp53.sl.home (Scott Lurndal): Dec 09 02:55PM


>That is a rather naive statement. Humm... Why do you think split
>counters were invented? Why do you think RCU was invented? Well, to get
>rid of atomic RMW's and memory barriers. ;^)
 
Try not to feed the troll.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 09 04:50PM +0100

>> counters were invented? Why do you think RCU was invented? Well,
>> to get rid of atomic RMW's and memory barriers. ;^)
 
> Try not to feed the troll.
 
I'm not trolling. Handing over a queue-item to another thread is so
expensive, that 20 cycles don't hurt.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 09 11:52AM -0800

On 12/9/2020 6:55 AM, Scott Lurndal wrote:
>> counters were invented? Why do you think RCU was invented? Well, to get
>> rid of atomic RMW's and memory barriers. ;^)
 
> Try not to feed the troll.
 
Its difficult because it can mislead others. Her statements on this seem
to be naive at best. Sometimes I think she knows better.
olcott <NoOne@NoWhere.com>: Dec 09 09:16AM -0600

On 12/9/2020 8:22 AM, Ben Bacarisse wrote:
 
>> Pardon my English: I meant journals, not magazines.
 
> Except he has no intention of publishing in a proper journal. The usual
> intent of Usenet cranks is to get attention, and PO is no exception.
 
Stop baselessly disparaging me and my work.
 
Point out an error in the following or admit that you cannot because
there are none.
 
Last night your basis was contradicting your own words:
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.
 
The following is shown to be decided on the basis of the above criteria:
 
This input to the Microsoft C compiler produces a COFF object file that
is directly emulated by an x86 emulator.
 
void Confound_Halts(u32 P)
{
if (Halts(P, P))
while (1);
}
 
 
#define HALT __asm hlt
int main()
{
Halts((u32)Confound_Halts, (u32)Confound_Halts);
HALT;
}
 
_Confound_Halts()
[0000063c](01) 55 push ebp
[0000063d](02) 8bec mov ebp,esp
[0000063f](03) 8b4508 mov eax,[ebp+08]
[00000642](01) 50 push eax
[00000643](03) 8b4d08 mov ecx,[ebp+08]
[00000646](01) 51 push ecx
[00000647](05) e800feffff call 0000044c
[0000064c](03) 83c408 add esp,+08
[0000064f](02) 85c0 test eax,eax
[00000651](02) 740b jz 0000065e
[00000653](05) ba01000000 mov edx,00000001
[00000658](02) 85d2 test edx,edx
[0000065a](02) 7402 jz 0000065e
[0000065c](02) ebf5 jmp 00000653
[0000065e](01) 5d pop ebp
[0000065f](01) c3 ret
 
_main()
[0000066c](01) 55 push ebp
[0000066d](02) 8bec mov ebp,esp
[0000066f](05) 683c060000 push 0000063c
[00000674](05) 683c060000 push 0000063c
[00000679](05) e8cefdffff call 0000044c
[0000067e](03) 83c408 add esp,+08
[00000681](01) f4 hlt
[00000682](01) 5d pop ebp
[00000683](01) c3 ret
 
Output_Debug_Trace() Trace_List.size(18)
[0000066c](01) 55 push ebp
[0000066d](02) 8bec mov ebp,esp
[0000066f](05) 683c060000 push 0000063c
[00000674](05) 683c060000 push 0000063c
[00000679](05) e8cefdffff call 0000044c // CALL Halts()
[0000063c](01) 55 push ebp
[0000063d](02) 8bec mov ebp,esp
[0000063f](03) 8b4508 mov eax,[ebp+08]
[00000642](01) 50 push eax
[00000643](03) 8b4d08 mov ecx,[ebp+08]
[00000646](01) 51 push ecx
[00000647](05) e800feffff call 0000044c // CALL Halts()
[0000063c](01) 55 push ebp
[0000063d](02) 8bec mov ebp,esp
[0000063f](03) 8b4508 mov eax,[ebp+08]
[00000642](01) 50 push eax
[00000643](03) 8b4d08 mov ecx,[ebp+08]
[00000646](01) 51 push ecx
[00000647](05) e800feffff call 0000044c // CALL Halts()
The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped:
 
Every time that the same function is called from the same machine
address a second time without any control flow instructions in-between
is a case of infinite recursion.
 
This is shown at execution trace lines 12-19 above.
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Dec 09 09:41AM -0600

On 12/9/2020 9:25 AM, Malcolm McLean wrote:
> H and H_Hat to be Turing machines. If you allow a supervisor program to
> intervene and halt runaway recursion, that's a way out of the paradox, but
> you've broken one of the rules.
 
I have not frigging broken the rules.
When my system is adapted to be performed using Turing machines we
merely execute the program under test using a UTM that has been adapted
to use my method of halt deciding.
 
The key innovation of my system of defining a halt decider is the
application of this halt deciding criteria:
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.
 
Notice that in both of the above quotes future tense is used:
[would not halt]
 
As soon as the above halt deciding criteria is met the simulator can
stop its simulation and report not-halting. This criteria correctly
decides: {Linz, Sipser, Kozen and Hofcroft}.
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Bonita Montero <Bonita.Montero@gmail.com>: Dec 02 07:14PM +0100

There are two things you must be aware if you define member-operators:
1. The operator only applies to objects of the defined class and its
descendants and not convertible classes.
2. With external operators you can attach semantics to a class like
if you would have defined a member-operator.
Tim Woodall <news001@woodall.me.uk>: Dec 09 10:08AM

> serialise the containing class (and on further experimentation I can't
> see what use it is, you have to write object << std::cout)
 
> But you've given me an idea...
 
:-) I wish I was better at communicating... your idea is exactly what I
was trying to communicate (except that I was suggesting using XML::T and
JSON::T rather than XML::XML_A and JSON::JSON_A)
 
Bonita Montero <Bonita.Montero@gmail.com>: Dec 09 12:36PM +0100

>> They have to be global and for your purpose they might be friend
>> of a class.
 
> Read the thread again. Including the title.
 
I don't have to read again. A two parameter member-operator includes
the object as the left operand. So you can' define a member operator
with two parameters inside the class.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 09 12:40PM +0100

> Darnn it's ugly.
 
No that's not ugly since you can extend the operators acting on a class
without modifying the class. the io_manip-objects work that way. And a
further advantage is, that both objects can be of converted objects, so
this operators bekome symmetrical in that way.
If you want a member-operator, define the member-operator with one
operand and you get what you want.
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)