Thursday, June 21, 2018

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

David Brown <david.brown@hesbynett.no>: Jun 21 02:39PM +0200

On 21/06/18 14:03, Rick C. Hodgin wrote:
 
> I think the issue isn't our code affecting pass, as it will not. But
> it would be an overwrite of data on the stack or something else going
> haywire due to unexpected things.
 
If that is your risk, then checking "pass" for validity is a tiny issue.
All sorts of things can go wrong when your stack is unreliable - it is
a desperate hope to think that maybe it will change "pass" to something
other than 1..3 but otherwise leave your system running. Basically, you
can't trust /anything/ to be valid if your stack is overwritten.
 
Look at running with some of the sanitizers or debug facilities in clang
and gcc (MSVC may have something similar too), or with stack checking
features.
 
 
> As you know perfectly well and could teach a class on, a const value
> can still be updated externally by something that doesn't honor its
> const state (provided it's in read/write memory).
 
No, that is often not correct. Compilers will regularly assume that a
"const" value cannot change, and optimise accordingly. In code like
above, "pass" is not even going to be put in memory as such - it will be
in a register, and overflow to the stack if necessary. It won't be
separate from "_pass". And the compiler might unroll the loop and have
no register or memory variable "pass" or "_pass" at all.
 
It is true that with enough effort (like casts) you can make code that
looks like you are changing a const value - but you can never do so
reliably.
 
>> the scope of the loop.)
 
> That's an excellent idea. I will implement it. This is the second
> idea you've suggested that I've implemented. The first was namespaces.
 
Given how many things I have suggested you include in CAlive, and how
many things I have suggested you /don't/ include, I don't have a good
track record here!
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 21 09:03AM -0400

On 6/21/2018 8:39 AM, David Brown wrote:
> a desperate hope to think that maybe it will change "pass" to something
> other than 1..3 but otherwise leave your system running. Basically, you
> can't trust /anything/ to be valid if your stack is overwritten.
 
I agree. The goal would be to catch the potential error when it's visible
to the program, and with as minimal an impact as possible.
 
> Look at running with some of the sanitizers or debug facilities in clang
> and gcc (MSVC may have something similar too), or with stack checking
> features.
 
MSVC comes with a code analyzer which does similar things. And there's
a third-party plug-in PVS-Studio Analyzer written by:
 
https://www.viva64.com/en/pvs-studio/
https://groups.google.com/d/msg/comp.lang.c++/q_C_rGEdKxc/KeFdBHwqBwAJ
 
It is excellent. It caught about 300 things in my app. Some of them
were invalid for various reasons (it doesn't know about my coding
philosophy of using i*() and ii*() functions where the i*() functions
have to test input parameters for being valid, and the ii*() functions
do not, and other similar protocols I enforce on my code which can make
something that seems like it could be invalid actually valid because the
invalid test was already performed with recovery handled elsewhere ...
but about 6 were actual bugs I had overlooked.
 
I have also used sanitizers on GCC before. Kostya Serebryany is one of
my favorite developers:
 
2013: https://www.youtube.com/watch?v=Q2C2lP8_tNE
2014: https://www.youtube.com/watch?v=V2_80g0eOMc
2015: https://www.youtube.com/watch?v=qTkYDA0En6U
2016: https://www.youtube.com/watch?v=FzaR3iH2iZs
https://www.youtube.com/watch?v=Zc8Jk7pX6n0
2017: https://www.youtube.com/watch?v=k-Cv8Q3zWNQ
https://www.youtube.com/watch?v=n6kP-CWO_0Q
 
Haven't seen any in 2018 yet.
 
> "const" value cannot change, and optimise accordingly. In code like
> above, "pass" is not even going to be put in memory as such - it will be
> in a register, and overflow to the stack if necessary.
 
That's no guarantee. It depends upon the other code there.
 
> It won't be
> separate from "_pass". And the compiler might unroll the loop and have
> no register or memory variable "pass" or "_pass" at all.
 
Again, no guarantee. Only a probability.
 
> It is true that with enough effort (like casts) you can make code that
> looks like you are changing a const value - but you can never do so
> reliably.
 
In my experience you can (in MSVC primarily).
 
 
> Given how many things I have suggested you include in CAlive, and how
> many things I have suggested you /don't/ include, I don't have a good
> track record here!
 
The Bible teaches one to hear the things one hears, but only cling to
that which is good. :-)
 
--
Rick C. Hodgin
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 21 02:42PM +0100

On Thu, 21 Jun 2018 12:39:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
[snip]
> humans with a brain capable of rational thinking and a fine set of
> reproductive organs - but not enough blood to use them both at the same
> time?
 
Speak for yourself!
scott@slp53.sl.home (Scott Lurndal): Jun 21 01:56PM


>No, that is not evidence for intelligent design - not remotely so. It
>is evidence that our theories about how the cosmos is put together are
>incomplete.
 
Or evidence that our cosmos followed billions of failed cosmoses (zat a word?)
where the various cosmological constants didn't play well together - universal
evolution...
David Brown <david.brown@hesbynett.no>: Jun 21 04:21PM +0200

On 21/06/18 14:30, Alf P. Steinbach wrote:
 
> A factor with over a hundred digits for improbability of coincidence, or
> mismatch of theory with reality, as as strong evidence as you get.
 
> You can't get it stronger.
 
Agreed - but it is strong evidence for a mismatch of theory and reality
(or at least, a missing part of the theory). It is /not/ evidence for
intelligent design or that there is any kind of plan or design behind
the universe.
 
> per m^3. Theory, the standard model of physics (QED) plus the Planck
> constant, according to the same article, predicts 10^113 joules per m^3.
> That's 122 orders of magnitude difference between reality and theory.
 
What we know about the cosmological constant, and its effects here, is
based on observations, some basic assumptions, and theories formed from
them. What we know about the standard model of QED is based on
observations, some basic assumptions, and theories formed from them.
 
Both sets of theories fit observations and predictions remarkably well
in their areas. But they fail to match up on certain overlapping
points. Situations with very high gravitational densities in very small
spaces - like black holes - are a serious sticking point. So is the
energy of a vacuum. But there is no basis for claiming that one of
these is "reality" and the other is "theory". They are our current best
approximations to model reality in a wide range of circumstances, and we
know they both fail to cover /all/ circumstances.
 
 
 
> You can be certain that reality is correct, that our estimate of it is
> nearly correct (we have measures of various effects to compare it to),
> and that it's the theory that's wrong by some 120+ order of magnitude.
 
Reality is correct, obviously. Our idea of what is "real" for something
like this is based on theory - and that theory could be wrong.
 
>> all the answers and a full picture (no news there) - it is not evidence
>> for any kind of designer or intelligence being involved.
 
> You need intelligence to make that large an error.
 
The universe doesn't have an error here - our theories do. You need
intelligence to make such theories, with or without such errors, so here
you have evidence that scientists are intelligent but the work of
science is not finished.
 
 
> I get tired of the arguments of "no evidence against" the FSM, say. For
> any given such hypothesis one can construct an opposite hypothesis, with
> the same zero weight of evidence. They cancel and there's nothing.
 
Exactly. It is pointless to suggest that there is an intelligent
designer behind the universe - you might as well say you think it was
the flying spaghetti monster that made it. (This is the whole point of
the FSM.) There is no evidence or observation that gives the slightest
indication or justification for thinking the universe was designed -
merely some interesting facts that some people misinterpret.
 
 
> Yes. The shark's nearly perfect eye design (blood vessels on back of
> retina) versus the human botched eye design (vessels on front of retina)
> is a case point. What retarded designer did the human eyes?
 
It is also "designed" to focus under water, and has added hacks (the
lens) to compensate. And our distant ancestors lost most of the colour
resolution in order to improve night vision sensitivity - more recent
ancestors evolved massive brainpower to re-create the missing data when
they moved to a daytime lifestyle. Of course, the big brains have come
in handy for humans, but in terms of a vision system, we have this daft
system of a massively inferior input sensor (compared to, say, an eagle,
a shrimp, a squid, or even a fly) connected to a huge processing unit
designed to fill in all the information that is missing from the sensor.
It's a marvellous system in many ways, but a terrible design.
 
 
> Or models are what we believe the universe to be.
 
> And that construct is clearly artificial. If we had done it right it
> would have been natural. Some surprises here and there but no 10^122.
 
I'm sure we can figure it out eventually - if we can afford to make the
machines big enough for the experiments needed.
 
David Brown <david.brown@hesbynett.no>: Jun 21 04:24PM +0200

On 21/06/18 15:03, Rick C. Hodgin wrote:
>> looks like you are changing a const value - but you can never do so
>> reliably.
 
> In my experience you can (in MSVC primarily).
 
No, you can't do so reliably. If you disable all optimisation (and
warnings, and static error checking) then you can often make code look
like you are successfully changing "const" values, even there it will
not always work.
 
But reliable or not, you shouldn't try!
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 21 03:37PM +0100

>> }
 
>> so it's easy to check the pass is not assigned.
 
> CAlive has several features which allow something like this.
 
You mean it will have or maybe might have. And since your language is
bound to end up having loops and function calls, it will obviously allow
something like this. I think you mean it will allow the above to be
written in a more complex way.
 
> ... I actually spent time last
> evening considering a way to do what you suggest here, to create
> code accessibly by array and run it.
 
If it is intended to be a superset of C, it will support arrays of
function pointers so you would have had to be planning to ban the above
in some way.
 
In C, the functions whose pointers get put into the array have to be
named (non anonymous functions) and they can't be nested (no access to
names declared in an outer function) so the pattern above is much more
clumsy than it need be. If you are extending C, I would consider give
it proper function support before considering anything else. Maybe
that's what you meant -- you are considering ways to make function more
general than they are in C.
 
--
Ben.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 21 10:50AM -0400

On 6/21/2018 10:37 AM, Ben Bacarisse wrote:
> it proper function support before considering anything else. Maybe
> that's what you meant -- you are considering ways to make function more
> general than they are in C.
 
My goals are to make coding easier for developers, and more rapid and
pleasant. I want to simplify things for development, and open up some
opportunities for coding methodologies that are not so easy today.
 
We'll see what I come up with. CAlive is still a work in progress.
 
--
Rick C. Hodgin
Manfred <noname@invalid.add>: Jun 21 07:56PM +0200

On 6/21/2018 4:21 PM, David Brown wrote:
> (or at least, a missing part of the theory). It is /not/ evidence for
> intelligent design or that there is any kind of plan or design behind
> the universe.
 
Since this has started, I will indulge too in some deep off-topicality here.
 
Swinging aside of the religious viewpoint, and taking instead a more
philosophical approach, this kind of discussion has been long debated -
although not been given any definite answer - as the juxtaposition
between materialism on one side and idealism on the other, both being
wide families of philosophies.
 
Personally I have always considered a pure materialistic approach as
quite superstitious:
The position is: there is no truth other than physical matter, because I
can't /see/ nor /touch/ anything but matter, and the fact that I can
/think/ of some truth beyond matter is just me being stupid.
 
On the other hand, when investigating for answers for fundamental
questions (substance of matter, origin of the world, what a human being
is), while the physical investigation provides more questions than
answers, the materialistic approach simply says: the answer is in the
matter and only in the matter, we just can't /see/ it yet!
 
I mean, really? The only truth is in what I can see and touch, and if I
can't find a definite answer in the physical matter, I have to /believe/
that the answer is there, I just can't /see/ it (yet)?
 
Not convincing enough for me, sorry. Instead, it sounds as superstitious
as some animistic cultures where the local shaman was believed to be
able to read the future in the ashes. In the end, if it has to come to a
/belief/, what's the point?
 
Obviously this does not diminish the value of physical sciences - all
I'm saying is that I don't think that they are all there is to say about
knowledge.
Mechanistic logic is /one/ side of human knowledge, but there can be
(and I think there is) more to that: most commonly the understanding of
what is right or wrong is not simply a matter of applying a formula to a
problem.
This seems slippery floor (leaving the safety of numbers is
frightening), but still this is what we humans do: thankfully, we make
choices that are very well more than the result of an algorithm.
 
Back to the (off-topic) point: I am convinced too that there is some
intelligent design in the organization of the world. What I find curious
is why this vision is so harshly opposed: besides the "this is the
truth" argument (objected above), even if in the past such "higher
level" design has been used to impose some "higher level" authority on
the masses, nowadays it is not any more so: my own freedom is in no way
diminished by such design.
 
Final note: I have kept intentionally away from religion (which is a
personal matter) because I think it is quite different from philosophy
(which is rather a kind of science), and also I am nearly as much
allergic to the materialistic superstition as I am to the "ipse dixit"
attitude of those who say "this is the truth because somewhere it is
written it is so"
 
 
 
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 21 10:00PM +0100

On Thu, 21 Jun 2018 19:56:54 +0200
Manfred <noname@invalid.add> wrote:
[snip]
> allergic to the materialistic superstition as I am to the "ipse dixit"
> attitude of those who say "this is the truth because somewhere it is
> written it is so"
 
I do not thing it is "harshly opposed". And it is all very well
complaining about "materialistic superstition", but that is all we
have to go on outside the arena of religious faith.
 
For my own part I would just say that it is almost certainly going to
be unprovable one way or the other. I remember Richard Dawkins, for
whom I have great respect, saying some 30 years ago (I am that old)
that we will have a "theory or everything" within 10 years (ie by 20
years ago) which we will be able to write on our t-shirts. That struck
me as ridiculous at the time and it still does so now. As a biologist
he is also unqualified to make such predictions.
 
The building blocks of the universe are very, very strange. We live in
a universe comprised of a weird superposition of probabilities which can
slip into and out of deterministic resolution in a way which almost
requires pre-cognition. We haven't even got to the first stage of
understanding consciousness. Leaving aside Rick's ridiculous 6,000 year
old universe, which is provably false[1], there is no evidence for or
against intelligent design in its broadest sense. Complexity, and the
fact that the universe is finely balance (in the sense that small
changes in the fundamental physical constants would make the universe
unviable), which seems to be Alf's point, is no proof at all, so we
don't need to have an anthropomorpic principle to answer it[2]. And we
will probably never be able to probe scientifically into what lies
"behind" the Big Bang in order to determine whether there is a
"purpose" or a "God" behind it all.
 
To bring this more on topic, the theory that we are the manifestation
of the running of a complex computer simulation is as compelling as any
other explanation, and leaves as many questions unanswered, as does
pastafarianism.
 
Science can however disprove religious dogma. The doctrine of the
fall, which was a means of blaming us and not God for the deficiencies
of the things around us, by proposing that the universe was created as
perfect and it is Adam and Eve's fault (ie our fault) that it is not
so now, is only believed literally today by a small percentage of
Christians. Most Christians would now say that the fall is a
meaningful myth which engages issues of free will and so forth. So we
have to come up with other reasons why, for some people, life is a
struggle, and we are all the better for it.
 
[1] Except in his assertion that the universe was constructed in an
"as-if 11 billion years old" state some 6,000 years ago. That cannot be
either contradicted or proved.
 
[2] Except in the unlikely event that we can prove the existence of a
multiverse.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 21 02:10PM -0700

If any of you were truly wrong about your beliefs in how the universe
formed, or how we got here ... would you want to know?
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 21 10:14PM +0100

On 21/06/2018 22:10, Rick C. Hodgin wrote:
> If any of you were truly wrong about your beliefs in how the universe
> formed, or how we got here ... would you want to know?
 
Speed of light mate.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jun 21 03:25PM -0700

On 6/21/2018 12:56 AM, David Brown wrote:
> On 20/06/18 23:05, Rick C. Hodgin wrote:
>> On Wednesday, June 20, 2018 at 3:59:31 PM UTC-4, Scott Lurndal
>> wrote:
[...]
> sole example of intelligence in the universe), but that we have found no
> evidence to suggest it. Distorting his words and taking things out of
> context does not change what he believes and says.
[...]
 
I think Dawkins does not totally outright reject the idea of Aliens
acting like a God... In a sense:
 
http://www.bbc.com/future/story/20141020-dawkins-what-are-aliens-like
 
http://www.jasoncolavito.com/blog/did-richard-dawkins-just-endorse-alien-gods
legalize+jeeves@mail.xmission.com (Richard): Jun 21 05:33PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>Bjarne participated in this group some ten to fifteen years ago. He
>continued to participate in clc++m a while longer. But today he just
>isn't here, as far as I know, and clc++m is dead.
 
Yeah, I don't know why he thinks this barely read newsgroups is the
place to respond to Stroustrup.
 
 
>You will have a hard time cutting features from any language.
 
>Python did it, in the transition from 2.7 to 3.x, but it was a drawn out
>and painful process.
 
...and my impression is that Python3 uptake is a long, slow slog.
--
"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>
woodbrian77@gmail.com: Jun 21 12:37PM -0700

On Thursday, June 21, 2018 at 4:19:14 AM UTC-5, Bo Persson wrote:
 
> looks a lot clearer to me. And also works for things other than arrays.
 
> Having been around for 7 years it is hardly "a new construct". It is
> actually two language revisions old.
 
Due to their compact form, range `for` loops are useful from
an on-line code generation standpoint. The C++ Middleware
Writer requires users to have a compiler that supports them.
 
 
Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards
jacobnavia <jacob@jacob.remcomp.fr>: Jun 21 11:29PM +0200

Le 21/06/2018 à 19:33, Richard a écrit :
> [Please do not mail me a copy of your followup]
 
OK. I didn't.
 
> <pgertg$9q1$1@dont-email.me> thusly:
 
>> On 21.06.2018 00:50, jacobnavia wrote:
>>> Dear Sir:
 
Well, why not?
 
>> Bjarne participated in this group some ten to fifteen years ago. He
>> continued to participate in clc++m a while longer. But today he just
>> isn't here, as far as I know, and clc++m is dead.
 
Social media appear and disappear. Usenet was the first one, and, I
still think written conversations are great for discussing general
interest stuff.
 
 
> Yeah, I don't know why he thinks this barely read newsgroups is the
> place to respond to Stroustrup.
 
Well, I do not think that's important to the discussion. Since I do not
follow the party line, if the commander in chief is here or not, it
doesn't change the discussion.
 
He used the example of a top-heavy ship that sank. Well, I have been
saying exactly the same thing here and in the C group.
 
To illustrate that, he uses in a very strange way the example I showed.
 
Let's see that in more detail.
 
<quote again>
In C and C-style C++, that might look like this:
 
for (int i=0; i<MAX; i++) ++v[i];
// increment each element of the array v
<end of the repeated quote>
 
This statement can be written in C++, using the old syntax.
 
I wrote:
 
So, the "C-style C++" should be written:
 
for (int i=0; i<v.size(); i++) ++v[i];
// increment each element of the array v
 
What is wrong with this way of writing software?
 
1) It is very clear
2) No new construct is needed.
 
 
Some objections were raised, for instance that plain arrays wouldn't
work, they do not have a size() method.
 
Strange. C++ doesnt have something? Hard to believe...
 
Well, obviously a top-heavy ship needs a more broad base to be able to
support that so heavy top. C++, like C, doesn't have an array type and
plain arrays are stored without size information.
 
Instead of solving THAT problem C++ develops a way of hiding it under
the carpet of a new syntax for "containers".
 
One of the oldest containers is precisely the array TYPE. An easy to
learn and use array type would be nice, isn't it?
 
Plain arrays are stored with size information and the .size() method
works for them too.
 
As for any container.
 
General rules simplify the language. Arrays are objects like others, and
can answer simple requests like size() and maybe others.
 
This doesn't affect the speed of the generated code since array access
isn't at all modified, and the syntax is kept the same. The array type
would be plain arrays
jacobnavia <jacob@jacob.remcomp.fr>: Jun 21 11:49PM +0200

Le 21/06/2018 à 08:38, Öö Tiib a écrit :
> It does not work with raw array. That works (since C++17) ...:
 
> for (size_t i=0; i<std::size(v); i++) ++v[i];
 
> ... but neither works with std::set because there are no operator[].
 
If there is no operator[] that should be a compile time error of course.
 
But what are you doing when incrementing each element of a set?
 
A set... maybe you just mixed up something?
 
Coming back to the original discussion, what I do not understand is why
you have to write:
 
std::size(v)
 
instead of
 
v.size()
 
????
 
The foundations must be broader to accomodate that heavy top, I repeat.
 
Why v.size() doen't work?
 
If we store size information together with the array, we can get at run
time the size of the array.
 
For instance we could set a class of arrays, using plain arrays as a
base of a more rational approach to bounds checking, run time
optimizations, and other things.
 
You can at run time choose some algorithm for small matrices that
doesn't scale but is great for small data sets using the size information.
jacobnavia <jacob@jacob.remcomp.fr>: Jun 22 12:12AM +0200

Le 21/06/2018 à 11:19, Bo Persson a écrit :
> It is definitely not very clear.
 
> You have to mention i four times, each time inviting you to write j by
> mistake. Same for v, used twice.
 
Sure.
 
You can do a typing mistake.
 
Do we need new syntax to avoid typing mistakes?
 
The new syntax must be learned and remembered by all users of the language.
 
The typing mistake is easily fixed, in most cases. And please consider:
 
for (int& elemnt : container) ++element;
 
is just as wrong...
 
:-)
 
> And, of course, the typical newbie error is to write <= instead of < in
> the comparison.
 
Sure. Newbies make all kinds of mistakes. Should a new syntax be
introduced that is newbie-proof???
 
> In that view
 
>   for (int& element : container) ++element;
 
> looks a lot clearer to me. And also works for things other than arrays.
 
The index variable is now lost. How is this thing iterated? A whole new
syntax must be learned to subclass this thing by specifying a range,
what is not very easy and means YET ANOTHER thing to learn. The specs
are complicated, see for instance:
https://en.cppreference.com/w/cpp/experimental/ranges/range/Range
 
And those ranges are supposed to be continuous. How do you do a set of
elements like "pair numbered" ?
 
You want to specify a filter? Learn how ranges are constructed and used
in the new syntax. Forget about:
 
for (int i=0; i<MAX; i++)
if (i&1) continue; // Treat only pair numbered pixels
 
You can here easily specify filters without learning any new syntax.
 
But that is "C like" and obsolete.
 
> Having been around for 7 years it is hardly "a new construct". It is
> actually two language revisions old.
 
Yes, C++ programmers are used that there is each 2-3 years a bunch of
new syntax to learn. Fancy constructs where you learn to do the same
things with new syntax.
jacobnavia <jacob@jacob.remcomp.fr>: Jun 22 12:23AM +0200

> Due to their compact form, range `for` loops are useful from
> an on-line code generation standpoint.
 
If you are generating code, the difference between generating a slightly
longer ascii output or a shorter one is meaningless.
Tim Rentsch <txr@alumni.caltech.edu>: Jun 21 01:00PM -0700

Tiib writes:
 
 
> Stroustrup did somewhere explain that 'this' is a reference that uses
> pointer's syntax because reference wasn't yet invented when 'this' was
> introduced into language.
 
The distinction between a pointer and a reference is not
important to what I was saying.
Tim Rentsch <txr@alumni.caltech.edu>: Jun 21 01:11PM -0700

>> that 'this' is a pointer rather than a value.
 
> I quite often use object-oriented programming, sometimes with virtual
> functions and all, without handling objects by pointer, but by value.
 
I think you are confused. Virtual functions don't work if the
receiver of a message send is a value ratther than through a
pointer/referece.
 
> 'this' might act similarly to a const pointer, but it's rare to even
> need to refer to it explicitly.
 
Explicitness is irrelevant to my comment.
 
> Even when you do, it can be the only exception.
 
Fine but the exception is crucial! The message recipient being
referred to by pointer or reference is what makes the receiver
an object.
Tim Rentsch <txr@alumni.caltech.edu>: Jun 21 01:14PM -0700

> r: (final executed basic block: state := 0)
> esac
> od
 
Do you have a point here?
 
If your point is that arbitrary control flow can be simulated
by a loop and a case statement, that is true, and also
obvious. But it is quite beside the point of my comment.
Do you see why?
Siri Cruise <chine.bleu@yahoo.com>: Jun 21 01:51PM -0700

In article <kfnmuvn99t7.fsf@x-alumni2.alumni.caltech.edu>,
> > esac
> > od
 
> Do you have a point here?
 
You can use gotos even when the language doesn't have gotos.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
Tim Rentsch <txr@alumni.caltech.edu>: Jun 21 01:18PM -0700


>> FWIW that is how the statement struck me when I read your
>> posting. Just fyi.
 
> It matched to tone of the OP...
 
Responding in kind serves to legitimize his comment. Better
to answer in a calm and rational way, and very plainly not
overstate the case. Otherwise you are just proving his
point.
woodbrian77@gmail.com: Jun 21 10:12AM -0700

On Thursday, June 21, 2018 at 2:32:37 AM UTC-5, Juha Nieminen wrote:
> among the three-dozens-or-so other "better C++'s" out there already.
> Name it Z++ or something. Have it fade to obscurity before it's even
> completed.
 
If anyone wants to take that route, I suggest they make
it, at least partially, closed source.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
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: