Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67072 > unrolled thread

Why does this work on Xcode ???

Back to article view | Back to comp.lang.c++

Contents

  Why does this work on Xcode ??? Bob Langelaan <bobl0456@gmail.com> - 2019-07-16 22:03 -0700
    Re: Why does this work on Xcode ??? Paavo Helde <myfirstname@osa.pri.ee> - 2019-07-17 08:46 +0300
    Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 00:06 -0700
      Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 01:44 -0700
    Re: Why does this work on Xcode ??? Juha Nieminen <nospam@thanks.invalid> - 2019-07-17 07:46 +0000
    Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-17 09:12 -0400
    Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 17:01 +0200
      Re: Why does this work on Xcode ??? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-07-17 22:15 +0100
        Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 23:29 +0200
          Re: Why does this work on Xcode ??? Christian Gollwitzer <auriocus@gmx.de> - 2019-07-19 08:27 +0200
            Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:09 +0200
              Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:24 +0200
              Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 11:18 -0700
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-10 21:05 +0200
                  Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-22 10:28 -0700
                    Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 19:50 +0200
                      Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-22 23:45 +0100
                        Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 07:22 +0200
                          Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-23 13:12 +0100
                            Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 16:02 +0200
                            Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-18 08:50 -0700
                          Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 09:28 -0400
                            Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-23 16:37 +0200
                              Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 23:07 +0200
                                Re: Why does this work on Xcode ??? Richard Damon <Richard@Damon-Family.org> - 2019-08-23 19:10 -0400
                                  Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:49 +0200
                                Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 19:49 -0400
                                  Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:45 +0200
                                    Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 12:06 +0200
                                      Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:25 +0200
                                        Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:11 +0200
                                          Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 17:12 +0200
                                            Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 23:32 +0200
                                              Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-26 11:51 +0200
                                                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-26 13:26 +0200
                                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 11:36 +0200
                                  Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:27 +0200
                                    Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:15 +0200
                                    Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-26 00:43 -0400
                          Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-24 04:58 -0700
                      Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-26 09:53 -0700
                      Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-28 18:03 -0700
            Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-19 00:20 -0700
            Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 07:41 -0700
        Re: Why does this work on Xcode ??? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-24 19:49 +0200
      Re: Why does this work on Xcode ??? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-21 11:41 +0000
        Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 09:29 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#67952

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> On 22.08.2019 19:28, Tim Rentsch wrote:
>
>>  You are
>> very much swimming upstream here:  do you really want to say you are
>> smarter than all the people who have participated in the C and C++
>> working groups to standardize these languages?

I am still in the process of reading through the cascade of
downstream messages, but I wanted to respond to this one item
and try to get it out of the way.

> There are 3 main things wrong with that statement:
>
> * The idea that I'm arguing a view at odds with the standard.  I'm
> not.  Check how many in this group agree with your view of UB:  that's
> 0.

The comment of mine quoted above has nothing to do with undefined
behavior or your ideas about it.  You have misunderstood the context
of the comment.

> * The idea that /if/ one believes the standard is sub-optimal or
> wrong, one must believe that one is smarter than all the people blah
> blah.  If that were the case then all those non-committee members who
> have filed Defect Reports against the standard, must be megalomaniacs
> who think they're very very smart.  That's just not so.

First, I never said you think you're smarter than everyone who
has worked on the C or C++ standards.  Second, I never said
someone who thinks the Standard is flawed in some way (and thus
in contradiction to all the committee members who have worked on
it) must be wrong about that.  You have misheard me.  ISTM that
often what you hear doesn't match what I said;  whether or not
it happens often, it did happen in this case.

As regards defect reports, several items are worth noting.  One,
most defect reports are filed by people either who are on the
committee or who have spent extensive time working with them.
Two, a lot of defect reports are responded to by saying, in
essence, "this isn't a problem, the standard is fine."  (I don't
know what the percentages are, for any of the classes of filers.)
Three, most defect reports involve issues that are odd corner
cases in one way or another, and probably just got overlooked.
In contrast, the notion of observable behavior is a core issue,
and undoubtedly one that has been given a lot of attention and
serious thought.  The people who worked on C89-C99 are by nature
a practical, pragmatic bunch, and not particularly given to
academic flights of fancy.  Given that the notion of observable
behavior (not the name, but the ideas behind it) has survived
essentially unchanged to the present day, the idea that it is
impractical or overly academic in nature is rightly regarded
with some skepticism.  And that's all I was saying.


> * It's a purely social argument.

It isn't a social argument;  rather it is an argument of
technical competence and one reflecting the nature of the people
who worked on the early C standards.

If anything, your argument that my ideas about undefined behavior
must be wrong because no one in comp.lang.c++ agrees with me is
a social argument.  Even if it were true (which it isn't) that no
one here agrees with me, comp.lang.c++ is a social collection of
people, as are the subsets that choose to participate in various
threads and topics.  So if anyone is making a social argument,
it's you.

[toc] | [prev] | [next] | [standalone]

#67983

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

I have now carefully read through all your responses in the
cascade of messages downstream of my message two upthread.

> I may address the rest of your posting later, trying to give the
> examples etc.  you ask for, because I feel you mean this seriously.

I do mean it seriously, and not at all confrontationally.  I am
interested to read your further followup (ie, as mentioned above)
if you choose to post one.


> And I don't think you think you're smarter than everybody else in
> this group just for holding an opinion on UB that nobody else here
> shares.

For the most part I don't think about whether I am smarter than
any particular person, let alone everyone in the group, partly
because "smart" is a multi-dimensional quantity, and it's very
rare (if indeed it has ever happened at all) that I find a person
where I think I am smarter along all axes.  Even if it were true
that my opinion on a subject were not shared by any other
contributor in the group, that would not affect my sense of what
"smarter" means.


> I think you're simply convinced that you're right,

In my view the word "right" does not apply, because I take both
of our statements as expressing opinions about how the standards
"should" be interpreted.  Opinions are never right or wrong, they
just are whatever they are.

> that your distinctions are meaningful,

I do think the distinctions I have been trying to explain are
meaningful.

> and somehow my and others' arguments have failed to move your
> conviction.

I think an essential first step is missing.  For my views to
change as a result of what you say (or vice versa), I must first
understand what you mean and why you think what you do (similarly
vice versa).  Right now I think we are not understanding each
other.  Key example:  the term "undefined behavior".  Even though
we both use the term "undefined behavior", I think what you mean
by the term is not the same as what I mean by it.  If that is so
then obviously it gets in the way of us communicating.  Normally
in discussions like this one, my efforts are directed at trying
to convey what I think and why, and not to try to convince the
other participant(s) to change their minds.


> Which I think means we're not good enough at presenting our
> view.  Not, that we're wrong. ;-)

Again, I don't think either of our views is right or wrong.  I
agree though that explaining what it is you think should be given
more emphasis than trying to convince me that you're right.

[toc] | [prev] | [next] | [standalone]

#67115

On Friday, 19 July 2019 09:27:15 UTC+3, Christian Gollwitzer  wrote:
> Am 17.07.19 um 23:29 schrieb Alf P. Steinbach:
> > On 17.07.2019 23:15, Mr Flibble wrote:
> >> The whole point of using tail recursion is that is doesn't use up 
> >> stack space, silly boy.
> > 
> > Unfortunately the C++ standard gives you no such guarantee.
> > 
> > But a particular compiler may.
> > 
> > It's difficult to predict because it may not be documented for the 
> > compiler, and the compiler may optimize or not based on criteria that 
> > only make sense internally (e.g., is the return type floating point?).
> 
> Is it true that it depends on the type of something in practical cases? 

Not to my knowledge. It is (like any other optimization) just not
required. It is not hard to implement. 

Likely reason is that dummies are constantly confused when debugging
optimized programs. OTOH dummies are also confused when stack is
exhausted. Finally, when all works then they are confused that
programs fully instrumented for debugging are so sluggish.

So C++ just does not suit dummies and all efforts have been in vain.

[toc] | [prev] | [next] | [standalone]

#67485

Christian Gollwitzer <auriocus@gmx.de> writes:

> Am 17.07.19 um 23:29 schrieb Alf P. Steinbach:
>
>> On 17.07.2019 23:15, Mr Flibble wrote:
>>
>>> The whole point of using tail recursion is that is doesn't use
>>> up stack space, silly boy.
>>
>> Unfortunately the C++ standard gives you no such guarantee.
>>
>> But a particular compiler may.
>>
>> It's difficult to predict because it may not be documented for
>> the compiler, and the compiler may optimize or not based on
>> criteria that only make sense internally (e.g., is the return
>> type floating point?).
>
> Is it true that it depends on the type of something in practical
> cases?

The short answer is yes.  (more below)

> I thought that tail recursion can be mechanically translated
> like this:
>
> ===========
> type myfunc(x, y, z) {
>     ....
>
>     return myFunc(a, b, c);
> }
> ===========
>
> becomes
>
> ==========
> type myfunc(x, y, z) {
>     start:
>
>     ...
>
>     x=a, y=b, z=c;
>     goto start;
>
> }
> ==========
>
> Since I can do this at the source code level, I don't see why it
> can't be done for every function.  Of course, for mutual tail
> recursion I can't do that because of the non-local goto, but for
> the compiler that should also be easy.

I switch pretty easily (in C or C++) between functional style
code and imperative style code.  So I routinely write small
functions using self-recursion, or sometimes mutual recursion
although that is less common.  Of course I also want my code
to be practical so I do look at how the code is compiled,
sometimes with a visual inspection and sometimes using a
filter on the generated assembly to see where tail recursion
is compiled "badly", as a recursive call, rather than being
turned into a loop.

My experience is that direct tail recursion almost always[*] gets
turned into loops rather than recursive calls, if all the types
involved are scalar types (or references in C++).  That also
holds for mutual recursion in cases where the functions involved
all have the same type (that is, the same return type and also
the same argument types, or at least "similar" argument types).
When the functions involved in a mutual recursion have different
numbers of arguments the results are not as reliable.

An important case that does *not* get compiled as iterative code
is when the return type is a struct (which I think also includes
unions).  For some reason that happens even when the struct is
"simple", such as having only one member (and which has scalar
type).  In C, using struct types for arguments is usually okay,
provided of course that they aren't too hairy.  In C++, using
struct types for arguments often inhibits getting iterative
compiled code, even for "plain" structs.  (Disclaimer:  I haven't
explored what goes on when struct argument types are involved,
or more accurately I haven't explored it too deeply.)

On the flip side, a C++ case where recursion works great is
when constexpr functions are used to calculate constexpr
values.  This property is important if one needs to write
constexpr functions that work in C++11 (and some people still
do), as in nearly all cases iterative code can be turned into
equivalent recursive code that adheres to the more restrictive
constraints for constexpr functions in C++11.


[*] Using gcc, clang, or g++, at optimization levels -Os/-O2 or
higher.  Also, all the foregoing statements should be read as
most often true but not as absolutely true - there are always
the odd corner cases that can pop up, as with all things
programming.

[toc] | [prev] | [next] | [standalone]

#67926

> The whole point of using tail recursion is that is doesn't use up stack 
> space, silly boy.

You can realistically rely on that a compiler will convert a tail
-recursion into an iteration when the code is optimized. But with
debug-code no compiler will convert the tail-recursion into an
iteration.

[toc] | [prev] | [next] | [standalone]

#67139

On Wed, 2019-07-17, Alf P. Steinbach wrote:
> On 17.07.2019 07:03, Bob Langelaan wrote:
>> Several of my students have submitted the following solution (or
>> something very similar) for a recursive function to add the contents
>> of an array:
>
> The presented code doesn't “add the contents”, I guess that's just typo.
>
>
>> // Returns true if the supplied value is found in the array of values
>> // and false otherwise
>> template <typename type, size_t size>
>> bool isMember(const array<type,size> & myArray, const int n, const type value)
>> {
>> 	if ( n < 0 )
>> 	{
>> 		return false;
>> 	}
>> 	else if ( myArray[n] == value )
>> 	{
>> 		return true;
>> 	}
>> 	return isMember( myArray, n - 1, value );
>> }
>
> The two main problems with this function are:
>
> * Passing `value` by value may incur severe copying inefficiency.
> * The tail recursion may easily consume all stack space and yield UB.

It's also fairly sad and inelegant use of recursion, with the extra
cursor being passed around.  The way I learned recursion, you start by
seeing an array as either empty, or having a head element, and then:

  // vaguely Haskell-like pseudo-code
  ismember(value, []) -> false
  ismember(value, head:tail) -> value==head || ismember(value, tail)

My point is, I'm not sure the students will appreciate recursion
properly based on that code, if that's the intention.  (Perhaps not
based on any C++ code.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#67530

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Wed, 2019-07-17, Alf P. Steinbach wrote:
>
>> On 17.07.2019 07:03, Bob Langelaan wrote:
>>
>>> Several of my students have submitted the following solution (or
>>> something very similar) for a recursive function to add the contents
>>> of an array:
>>
>> The presented code doesn't ?add the contents?, I guess that's just typo.
>>
>>
>>> // Returns true if the supplied value is found in the array of values
>>> // and false otherwise
>>> template <typename type, size_t size>
>>> bool isMember(const array<type,size> & myArray, const int n, const type value)
>>> {
>>> 	if ( n < 0 )
>>> 	{
>>> 		return false;
>>> 	}
>>> 	else if ( myArray[n] == value )
>>> 	{
>>> 		return true;
>>> 	}
>>> 	return isMember( myArray, n - 1, value );
>>> }
>>
>> The two main problems with this function are:
>>
>> * Passing `value` by value may incur severe copying inefficiency.
>> * The tail recursion may easily consume all stack space and yield UB.
>
> It's also fairly sad and inelegant use of recursion, with the extra
> cursor being passed around.  The way I learned recursion, you start by
> seeing an array as either empty, or having a head element, and then:
>
>   // vaguely Haskell-like pseudo-code
>   ismember(value, []) -> false
>   ismember(value, head:tail) -> value==head || ismember(value, tail)
>
> My point is, I'm not sure the students will appreciate recursion
> properly based on that code, if that's the intention.  (Perhaps not
> based on any C++ code.)

These comments strike me as somewhat odd.  Certainly it is true
that recursive functions often offer a good fit to recursive data
types.  That doesn't mean recursion is a bad fit in other cases.
On the contrary, using recursion often gives a definition that is
simpler and easier to understand than a non-recursive version.  A
well-known example is finding the greatest common divisor of two
numbers, which might be written as follows (with gcd(0,0) to
return the value 1):

    unsigned
    gcd( unsigned a, unsigned b ){
        return  a == 0 ?    b != 0 ? b : 1
            :   gcd( b%a, a );
    }

Writing a nicely tail-recursive function often entails passing
arguments besides just the primary data item.  This happens with
arrays in C and C++ because arrays are not recursive data types in
C or C++ (nor are they in many functional languages).  Furthermore
we may want not one additional "cursor" but more than one.  Here
is a function to determine if a sorted array contains a given
value:

    bool
    contains( int *v, size_t base, size_t limit, int item ){
        if(  base == limit  )  return  false;

        size_t mid = base + (limit-base)/2;

        if(  v[mid] < item  )  return  contains( v, mid+1, limit, item );
        if(  v[mid] > item  )  return  contains( v, base,  mid,   item );

        return  true;
    }

In later versions of C++ we might choose to write this function
differently, using 'span' (disclaimer: I am not an expert on
span!).  Doing that would very likely give a nicer function.  But
I wouldn't say the non-span version is "inelegant".  It's just a
reflection of how the language-provided data types work.  Do I
remember right that you are one of the people who is still
working (or forced to work) with C++11?  Anyone in that boat
might choose a function definition like the one above, until such
time as better language facilities are available so it could be
re-written more attractively.

I guess my main point is that recursion is more broadly applicable
than just those situations where recursive data types are
involved.  In fact, in languages like C and C++, it is much more
likely to encounter a good fit for recursion that does not make
use of recursive data types, simply because C and C++ typically do
not define data types recursively.  Recursion is more fundamental
than just the cases where recursive data types are used.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web