Sunday, September 13, 2020

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

olcott <NoOne@NoWhere.com>: Sep 12 06:33PM -0500

On 9/12/2020 5:00 PM, Keith Thompson wrote:
 
> "Fair Use" seems to be a widely misunderstood concept. I suggest that
> doing your own research or seeking out a forum where it's topical would
> be more productive that trying to discuss it here.
 
Fair Use varies across jurisdictions. For example Germany is a little
more restrictive than the USA.
 
--
Copyright 2020 Pete Olcott
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 12 04:35PM -0700


> Yes, so by Fair use you can download and use if for yourself. If you
> want to give it to someone else, you give them the link to the ISO site
> and they can download it themselves.
 
That is not consistent with my limited understanding of what "Fair Use"
actually means.
 
> link that if you click on it will download the file to your computer
> implies that you give permission for people to down load it to their
> computer.
 
I agree that that's a reasonable assumption. I don't know how or
whether that assumption is supported legally I would assume that, given
the huge number of files that have been publicly shared on the Internet,
there is ample legal precedent, but I have no idea what that precedent
says.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 12 06:58PM -0700


> So I'm wondering what the C standard says about the above construct.
> Is the compiler allowed to assume that 'sz' is a compile-time constant
> and, thus, make 'vs' into a "regular" array (rather than a VLA)?
 
We might consider a case that does not involve a variable:
 
static int
one_hundred(void){
return 100;
}
 
void foo(void){
char vs[ one_hundred() ];
...
}
 
A compiler could easily deduce that the array dimension of vs
must be 100, and cannot vary. Despite that, the array vs is
a variable length array, and must be treated as such during
semantic processing in the compiler.
 
When it comes time to generate code, there is nothing stopping
the implementation from treating the variable vs as if it were
declared 'char vs[100];' and producing code accordingly, but
for the purpose of program semantics vs is a VLA. The same
statement applies in the earlier version of foo(), and also
in this version:
 
void foo(void) {
int sz = 100;
char vs[sz];
...
}
 
In each of these cases 'vs' must be treated as a VLA, but
may have code generated as if it were 'char vs[100];'.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 12 07:31PM -0700

> need to treat it different.
 
> For instance &vs does NOT match the type of a pointer to char[100], but
> only to a pointer to char[sz]
 
The last statement is misleading. The two types aren't the same
but they are compatible, and can be used mostly interchangeably.
Example:
 
int
whee_ha( void ){
int k = 100;
char a[ 100 ];
char vla[ k ];
return &a == &vla;
}
 
This code must be accepted in C99. In particular, comparing the
two pointer values is allowed, and has defined behavior. If the
value of 'k' were, say, 97 instead of 100, then the two types are
still compatible, and thus no constraints are violated (so it
should compile cleanly); actually calling the function gives
rise to undefined behavior (because 97 != 100), but if the
function is never called then there isn't anything wrong with it
(meaning it could be part of a strictly conforming program).
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 13 09:06AM -0700

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
 
[...concerning the question of undefined behavior
of treating malloc'ed memory as an array ...]
 
> the C++20 IS, and that the latter portion be deferred to C++23."
 
> Maybe N4860 is C++20 plus defect report but it looks like the final
> version. No doubt in due course all will be revealed.
 
The impression I got from the quoted section there is that the
authors wanted it to be treated as a defect rather than a change,
and so meant to apply retroactively to C++17 (ie, after approval).
Does anyone have more context to offer on this notion?
David Brown <david.brown@hesbynett.no>: Sep 13 10:19PM +0200

On 13/09/2020 00:00, Keith Thompson wrote:
 
> "Fair Use" seems to be a widely misunderstood concept. I suggest that
> doing your own research or seeking out a forum where it's topical would
> be more productive that trying to discuss it here.
 
I believe you are correct in this (both about the limitations you think
"fair use" has, and that it is a widely misunderstood concept). In
particular, "fair use" does /not/ mean "something that the copyright
holder appears to imply because of how they publish the work". When the
copyright owner puts a document on a public server, and says "here is
the latest draft document", you can well argue that you have an implied
licence to read it, save copies, pass them around, print them out, quote
them, etc. But that is an implied or assumed license, not "fair use".
 
Actual "fair use" varies a lot between jurisdictions (as with all this
kind of thing), and not all jurisdictions have the concept at all.
Typically it includes making quotations as part of a review, making
parodies, and that kind of thing.
 
(And don't take /my/ word for this either!)
Juha Nieminen <nospam@thanks.invalid>: Sep 13 07:05AM

> There is a fundamental argument
> for the simplicity of a language.
 
I always hate it when people talk about the "simplicity" of C,
equating the length of its standard with the "simplicity" of
the language itself.
 
If the length of the language definition were everything that's
needed to know whether a programming language is "simple" to use
or not, then you could take any of the esoteric languages out there
that consist of something like 6 commands and which language
specification can be written in one page, and talk about the
"simplicity" of that language and how it makes it better than C++.
 
Length of the language specification does in no way correlate to
the simplicity of use or understanding the language. The esoteric
programming languages are a perfect proof of this.
 
C is a very complicated language compared to many others, both in
terms of fully understanding it, as well as using it.
 
For example, pointer syntax and arithmetic in C is really obscure.
It's so obscure, in fact, that not many even expect C (or C++),
who may have actively programmed in it for decades, still remember
by heart the syntax of, for example, "a pointer to a 2-dimensional
array where the second dimension is 100". Heck, some such programmers
might not even know such a thing is possible at all! Even though they may
have been programming in C (or C++) for decades. I kid you not.
 
Many experienced C programmers may be more familiar with pointers to
functions (because in C they are very often used), but even then you
can write really complex pointer declarations that hare extraordinarly
hard to decipher. Certainly not something you can decipher at a quick
glance.
 
C programmers also seem to be, for some reason, not very intimate with
the newer versions of the C standard, even though they add relatively
little to the language. For example, C99 introduced the 'inline'
keyword for function declarations. Even to this day, 20 years later,
you can still find newly-written C code where the programmer wrote,
in a header file, a 'static inline' function (instead of just 'inline'),
no doubt because of the old habit of thinking that if a function
definition in a header does not have the magic 'static' keyword then
it may cause linker errors, without understanding that 'inline' takes
care of that, and does it better than 'static'. (Yes, 'inline' functions
in C work in the same way as in C++, with regards to linking.)
 
(The problem with 'static inline' functions is that they will be
instantiated in every single compilation unit where they are used.
If the compiler ends up not actually inlining them, then their code
will be needlessly duplicated, increasing the binary size, and eg.
pointers to the function will point to different places. Declaring
the function as merely 'inline' is the better option because in this
case duplicates are discarded for the final executable.)
 
And, of course, don't let me get even started with how complicated
memory management is in C, for such a "simple" language. I have witnessed
first-hand how exasperating it can be to write complicated several levels
deep dynamic data structures in C. (I have eg. had to help a friend going
through a C programming class to implement exercises involving such data
structures. His final conclusion after the course was, essentially,
"C is not for me" and he moved to Javascript, Haxe and C#.)
 
C is *not* a simple language. Not in the sense of being simple to
understand and use. May be "simple" in the same sense as when that
word is used to describe a person.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 13 08:04AM

On Sun, 2020-09-13, Juha Nieminen wrote:
 
> I always hate it when people talk about the "simplicity" of C,
> equating the length of its standard with the "simplicity" of
> the language itself.
 
(Cross-post to comp.lang.c dropped)
 
Me too. But I've decided it's harmless if a few people sit in
comp.lang.c and invent theories explaining why they don't use C++.
 
You cannot change their minds, and they are no major threat to C++
programmers.
 
[snip]
 
Good text, but I thought you were going to repeat your argument that
it's better to have the complexity in the language than in your own
code. That's a strong argument (but not, I think, enough to convince
someone who made his mind up thirty years ago).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Sep 13 08:46PM +1200

On 13/09/2020 19:05, Juha Nieminen wrote:
> can write really complex pointer declarations that hare extraordinarly
> hard to decipher. Certainly not something you can decipher at a quick
> glance.
 
void (*signal(int sig, void (*disp)(int)))(int);
 
:)
 
Great post.
--
Ian.
olcott <NoOne@NoWhere.com>: Sep 13 10:41AM -0500

On 9/13/2020 2:05 AM, Juha Nieminen wrote:
> programming languages are a perfect proof of this.
 
> C is a very complicated language compared to many others, both in
> terms of fully understanding it, as well as using it.
 
The essence of C is very simple.
 
> array where the second dimension is 100". Heck, some such programmers
> might not even know such a thing is possible at all! Even though they may
> have been programming in C (or C++) for decades. I kid you not.
 
The essence of pointer syntax is very simple:
int N;
int *M;
&N // Address of N
*M // Data that M points to
 
> can write really complex pointer declarations that hare extraordinarly
> hard to decipher. Certainly not something you can decipher at a quick
> glance.
 
Function pointers can produce very efficient code when a selector index
is the subscript to any array of function pointers.
 
> C programmers also seem to be, for some reason, not very intimate with
> the newer versions of the C standard, even though they add relatively
 
If it ain't broke don't fix it.
 
> memory management is in C, for such a "simple" language. I have witnessed
> first-hand how exasperating it can be to write complicated several levels
> deep dynamic data structures in C. (I have eg. had to help a friend going
 
That is when it is time to switch to C++ classes.
 
 
> C is *not* a simple language. Not in the sense of being simple to
> understand and use. May be "simple" in the same sense as when that
> word is used to describe a person.
 
When I created post this the idea that I presented was that when you
intentionally restrict yourself to the most useful subset, even C++ is
very simple.
 
--
Copyright 2020 Pete Olcott
David Brown <david.brown@hesbynett.no>: Sep 13 10:12PM +0200

On 13/09/2020 09:05, Juha Nieminen wrote:
> pointers to the function will point to different places. Declaring
> the function as merely 'inline' is the better option because in this
> case duplicates are discarded for the final executable.)
 
While I appreciate (and agree with) your general points about C, I don't
agree with your points about "static inline" functions.
 
In practice compilers will not generate a non-inlined version of a
"static inline" function unless there is overriding reason why it cannot
inline the function (recursion, taking and using its address, that kind
of thing). Thus the risk of duplication should normally be zero (and if
you have a compiler with a warning like gcc's -Winline, it is actually
zero). The advantage of making the function "static inline" is you know
the compiler will always use that definition, and will never end up
calling an external non-inlined version of the function - without the
"static", it is unspecified when this might happen.
 
In C, "static inline" and "inline" functions behave differently with
respect to non-const static local variables and in their reference to
file-scope static identifiers (these are allowed in a "static inline"
function, but not in an "inline" function - except in C++).
 
If you have a function that you almost always want to be inlined, but
very occasionally may need non-inlined, then "static inline" lets you do
so with the single definition (in a header) - a file-static non-inlined
version of the function will be generated if needed, from that
definition. If you have used "inline" alone, and need a non-inlined
version, you can't get that from the original inline definition - you
need to re-declare it in a non-inline version.
 
"Inline" does not work exactly the same in C99 and C++. There is also a
third commonly-used meaning of "inline" - the gcc extension in pre-C99
modes. The differences are subtle, but "static inline" functions are
identical in all cases. That may be good enough reason for a C
programmer to choose "static inline" rather than plain"inline".
 
<https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Inline.html>
 
In short, there are many good reasons for a C programmer to /choose/
"static inline", rather than just "inline". It's quite possible that in
many cases the choice is habit or copying someone else, rather than
actively choosing it. But please don't assume the use of "static
inline" is an indicator that the programmer does not understand C99.
 
 
> C is *not* a simple language. Not in the sense of being simple to
> understand and use. May be "simple" in the same sense as when that
> word is used to describe a person.
 
Agreed - "small" does not equate to "simple".
olcott <NoOne@NoWhere.com>: Sep 12 07:23PM -0500

On 9/12/2020 6:48 PM, Ben Bacarisse wrote:
> just misspoke. What did you mean to say you will soon have? Another
> one, sufficiently more complex than the original that you hope it will
> bamboozle your readers?
 
The one that I will soon have will be a fully executable version of the
exact same code that I wrote 2018-12-13 @ 7:00 PM. I had to create a
full operating system infrastructure to make that one fully executable.
 
Because of the full operating system infrastructure that makes it very
easy to examine theory of computation problems in a high level language
my partial halt decider is easily extensible.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 13 10:13AM -0500

On 9/13/2020 6:18 AM, Ben Bacarisse wrote:
> you said you had a fully encoded Turing machine you did not mean a
> "snippet of C like code" as you now claim. It is perfectly clear you
> meant a Turing machine as described in the book you keep referencing.
 
On 12/15/2018 1:28 AM, peteolcott wrote:
> the UTM to execute this code, that should not take very
> long. The key thing is the H and Ĥ are 100% fully
> encoded as actual Turing machines.
 
A more technically accurate update that includes actual execution:
 
*I will soon have a partial halt decider sufficiently equivalent
*to the Linz H correctly deciding halting on the Linz Ĥ proving
*that Ĥ on input Ĥ is halting decidable.
 
Recent primary research indicates that any C or x86 computation having
all the memory that it needs is equivalent to a Turing machine
computation in that it produces equivalent output for equivalent input
or fails to halt on equivalent input.
 
Since I know that you believe that I believe the above more technically
accurate claim and this new claim is a paraphrase of the original claim
your insistence that I have lied or am lying looks quite foolish.
 
Because I really do intend to seek publication in an academic journal I
must henceforth be very careful to use the technical terms of the art
accurately conveying their conventional meaning.
 
All that you have to do to get me to never call you a liar ever again it
make sure that all of your words very accurately convey objective truth
without bias.
 
 
--
Copyright 2020 Pete Olcott
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 13 07:03AM -0700

> (including it appears Richard's).
 
> Fully type-checked dynamically typed languages such as python or lisp
> can also be said to be strongly typed.
 
Some further comments regarding these terminology questions.
 
Like what I said earlier, the description above is reversed with
respect to "strictly typed" and "type safe". "Type safe" is about
whether something is well defined (like what the earlier statement
from David Brown says). "Strictly typed" is about how liberal or
restrictive the typing rules are. Whether an operation (or
language) is type safe is an objective condition: if undefined
behavior can arise it is not safe, and conversely. In contrast,
whether an operation (or language) is strictly typed is a
subjective condition: some developers may find a certain type
rule overly restrictive, whereas others may find the same rule not
restrictive enough. Some languages, including C++, provide more
than one way of defining similar types, with the different ways
having different degrees of type strictness.
 
The word "sound" comes from mathematical logic. A logic is
/sound/ if it is consistent. It is important for the rules of a
language and its type logic to be sound, as otherwise nonsensical
results could be derived.
 
The terms "strong typing" and "strongly typed" unfortunately have
become little more than marketing phrases. I think the original
idea (ie, from the Liskov and Zilles paper) was that "strongly
typed" would mean something like what type safe means today.
However, the terms were co-opted by virtue of being used the DoD
requirements documents Steelman, Ironman, etc (and eventually
leading to Ada), to mean something closer to having restrictive
typing rules, which is to say more along the lines of being
strictly typed. The meaning of the terms was diluted to the
point where these days it can mean whatever an author wants it to
mean. A good meta-rule is this: if a language description says
the language is "strongly typed" but doesn't define the term,
there is a good chance that the term is pretty much meaningless.
A sad state of affairs, but empirically it seems to apply more
often than it doesn't.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 12 08:22PM -0700

On 9/9/2020 11:43 PM, David Brown wrote:
>> push buttons... Would that kind of be useful to you?
 
> I realise that kind of thing can be useful for some embedded work - but
> not for the kind of thing I usually do.
 
A 100% full blown device simulator. The GUI has 3d graphics. The device
can be played with. Programs can can be uploaded to the real hardware at
will. Then tested, and see if the simulator was correct after all in
real time.
 
 
> with a screen attached to an embedded Linux system. That is certainly
> the kind of thing some of our customers are interested in, but nothing I
> am expecting to be working on in the foreseeable future.
 
Damn.
olcott <NoOne@NoWhere.com>: Sep 12 06:30PM -0500

On 9/12/2020 5:57 PM, Richard Damon wrote:
 
> SO there are basically 3 binary facts that are interesting, H(H^,H^)
> result, What H^(H^) did, and perhaps we will want what the copy of H
> inside H^ returned,
 
That is a great analysis, yet possibly incorrect if the whole idea of
the halting problem proofs are anchored in a fundamental misconception.
 
--
Copyright 2020 Pete Olcott
Richard Damon <Richard@Damon-Family.org>: Sep 12 08:48PM -0400

On 9/12/20 7:30 PM, olcott wrote:
 
> That is a great analysis, yet possibly incorrect if the whole idea of
> the halting problem proofs are anchored in a fundamental misconception.
 
And I don't understand what a working simulation of a Turing Machine
will help if you intend to invalidate the basic rules of logic used to
describe them.
olcott <NoOne@NoWhere.com>: Sep 12 08:00PM -0500

On 9/12/2020 7:48 PM, Richard Damon wrote:
 
> And I don't understand what a working simulation of a Turing Machine
> will help if you intend to invalidate the basic rules of logic used to
> describe them.
 
Your analysis was very good. I don't invalidate the basic rules of logic
to refute the halting problem proofs.
 
I did point out that the mathematical definition of incompleteness
applied to formal systems does decide that a formal system is incomplete
on the basis that it cannot prove a self-contradictory statement.
 
A theory T is incomplete if and only if there is some sentence φ such
that (T ⊬ φ) and (T ⊬ ¬φ).
 
--
Copyright 2020 Pete Olcott
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)