> >> THORSTEN OTTOSEN <nesotto@cs.auc.dk> writes
> >> >int foo( char* start, char* end )
> >> >{
> >> >    if( start > end )
> >> >      return 1;
> >> >    if ( compare( start, end ) )
> >> >       return foo( ++start, --end );
> >> >    return 0;
> >> >
> >> >char arr[10] = ...; // allocate on stack
> >> >foo( arr, &arr[9] );

> > francis.glassborow@ntlworld.com (Francis Glassborow) wrote:
> >> Meta-comment, the code you give seems seriously flawed in its design
> >> because nothing done in it will have any external effects. Also note
> >> that by convention compare returns 0 if the compared values are equal.

> John Potter <jpotter@falcon.lhup.edu> writes
> >I assume that you refer to the result not being used?  If the convention
> >is being followed, foo is return start > end || (end - start) % 2.  :)

francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> Well yes, But I bet that that was not anywhere near what was the
> intention of the programmer writing that code. Actually it is hard to
> imagine what was the intent but I am speculating that the author was
> making the standard mistake of miscounting the levels of indirection
> provided by the parameters.

Suppose compare was renamed "less_than". And suppose this was legacy
code from before type "bool" existed (so they were using int as
true/false flags). This function then returns true if, for any pair
x[i], x[n-i] (where n is the array length minus 1), x[i] is always
less than x[n-i].

This is not a full implementation of is_sorted(), but I can imagine
situations where it might be useful...

('Course, I would have coded it differently... but that doesn't
mean it's "seriously flawed.") And a return value IS an external
effect, at least potentially. Or would you say that strcmp() is
"seriously flawed?"

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi All,

During my work as a teaching assistant in a C course, a saw a program that
relied on comparison of array addresses.
The code was something similar to this:

int foo( char* start, char* end )
{
    if( start > end )
      return 1;
    if ( compare( start, end ) )
       return foo( ++start, --end );
    return 0;
}

char arr[10] = ...; // allocate on stack
foo( arr, &arr[9] );

Now, does the standard guarantee portability of this? I couldn't find much
in section 8.3.4 about it.
Could a compiler reverse the end/begining of the array and implement
operator++ and decrement?

regards

Thorsten, AAU




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message news:<b7cqd2$pdm$1@sunsite.dk>...
> Hi All,
>
> During my work as a teaching assistant in a C course, a saw a program that
> relied on comparison of array addresses.
> The code was something similar to this:
>
> int foo( char* start, char* end )
> {
>     if( start > end )
>       return 1;
>     if ( compare( start, end ) )
>        return foo( ++start, --end );
>     return 0;
> }
>
> char arr[10] = ...; // allocate on stack
> foo( arr, &arr[9] );
>
> Now, does the standard guarantee portability of this? I couldn't find much
> in section 8.3.4 about it.
> Could a compiler reverse the end/begining of the array and implement
> operator++ and decrement?
>
> regards
>
> Thorsten, AAU
>

The place to look is section 5.9, Relational Operators, and the
following 5.10 on equality comparisons.  Everything is spelled out
quite clearly there, and it seems that the code you supply should be
fine, as long as the pointers really are in the same array.  Not sure
what your final question means, or why it would be an issue.  Perhaps
you can clarify?

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <b7cqd2$pdm$1@sunsite.dk>, THORSTEN OTTOSEN
<nesotto@cs.auc.dk> writes
>Hi All,
>
>During my work as a teaching assistant in a C course, a saw a program that
>relied on comparison of array addresses.

First of all this is a pure C question and should really have been
posted to comp.std.c.

>The code was something similar to this:
>
>int foo( char* start, char* end )
>{
>    if( start > end )
>      return 1;
>    if ( compare( start, end ) )
>       return foo( ++start, --end );
>    return 0;
>}
>
>char arr[10] = ...; // allocate on stack
>foo( arr, &arr[9] );
>
>Now, does the standard guarantee portability of this? I couldn't find much
>in section 8.3.4 about it.
>Could a compiler reverse the end/begining of the array and implement
>operator++ and decrement?

No, the semantics of arrays in C requires that the builtin operator++
step through an array in the direction from start to end.

Meta-comment, the code you give seems seriously flawed in its design
because nothing done in it will have any external effects. Also note
that by convention compare returns 0 if the compared values are equal.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi Thorsten!

THORSTEN OTTOSEN schrieb:

> Hi All,
>
> During my work as a teaching assistant in a C course, a saw a program t=
hat
> relied on comparison of array addresses.
> The code was something similar to this:
>
> int foo( char* start, char* end )
> {
>     if( start > end )
>       return 1;
>     if ( compare( start, end ) )
>        return foo( ++start, --end );
>     return 0;
> }
>
> char arr[10] =3D ...; // allocate on stack
> foo( arr, &arr[9] );
>
> Now, does the standard guarantee portability of this? I couldn't find m=
uch
> in section 8.3.4 about it.
> Could a compiler reverse the end/begining of the array and implement
> operator++ and decrement?
>
> regards
>
> Thorsten, AAU
>

The given pointer comparison should portably work, provided, that both st=
art
and end are pointers
to the same object or one past the end of the array and none of them is a=
 null
pointer constant.

The relevant chapter in C++ is chapter 5.9 (relational operators) in Our =
Holy
Standard:

Read the paragraph 2 carefully. Here are some essentials from it:

"=97 If two pointers p and q of the same type point to the same object or
function, or both point one past the
end of the same array, or are both null, then p<=3Dq and p>=3Dq both yiel=
d true
and p<q and p>q both
yield false."

"=97 If two pointers p and q of the same type point to different objects =
that
are not members of the same
object or elements of the same array or to different functions, or if onl=
y one
of them is null, the results
of p<q, p>q, p<=3Dq, and p>=3Dq are unspecified."

"=97 If two pointers point to data members of the same union object, they
compare equal (after conversion to
void*, if necessary). If two pointers point to elements of the same array=
 or
one beyond the end of the
array, the pointer to the object with the higher subscript compares highe=
r."

Greetings from Bremen,

Daniel Spangenberg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote (abridged):
> int foo( char* start, char* end )
> {
>     if( start > end )
>       return 1;
>     if ( compare( start, end ) )
>        return foo( ++start, --end );
>     return 0;
> }
>
> char arr[10] = ...; // allocate on stack
> foo( arr, &arr[9] );

The comparisons are fine, as other people have said. You might want to
watch the decrements. Eg depending on what compare() does,

    foo( arr, arr );

may decrement end past the beginning of the array, which is undefined
behaviour.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 14 Apr 2003 17:53:59 +0000 (UTC), francis.glassborow@ntlworld.com
(Francis Glassborow) wrote:

> In article <b7cqd2$pdm$1@sunsite.dk>, THORSTEN OTTOSEN
> <nesotto@cs.auc.dk> writes

> >int foo( char* start, char* end )
> >{
> >    if( start > end )
> >      return 1;
> >    if ( compare( start, end ) )
> >       return foo( ++start, --end );
> >    return 0;
> >}
> >
> >char arr[10] = ...; // allocate on stack
> >foo( arr, &arr[9] );

> Meta-comment, the code you give seems seriously flawed in its design
> because nothing done in it will have any external effects. Also note
> that by convention compare returns 0 if the compared values are equal.

I assume that you refer to the result not being used?  If the convention
is being followed, foo is return start > end || (end - start) % 2.  :)

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I will answer all three replies below.

Randy Maddox:
> > Could a compiler reverse the end/begining of the array and implement
> > operator++ and decrement?
[snip]
>  Not sure
> what your final question means, or why it would be an issue.  Perhaps
> you can clarify?

sure, I meant "implement operator++ *as* decrement. What if a compiler
generated arrays where assert( &array[0] > &array[9] ) holds? Then I
imagined
that the compiler might translate &array[0] + 1 into &array[0] - 1.
 I guess my question could be
restated as an assertion:

{
    int array[10];

    assert( array < &array[9] ); // will this hold on all compilers? yes, it
will.
}

Francis Glassborow:
>
> First of all this is a pure C question and should really have been
> posted to comp.std.c.
my apologies for this.

> >Could a compiler reverse the end/begining of the array and implement
> >operator++ and decrement?
>
> No, the semantics of arrays in C requires that the builtin operator++
> step through an array in the direction from start to end.

Ok, I see I might have asked the wrong question. My focus should have been
on < and not
on pointer increment of pointers.

Daniel Spangenberg:
[snip]
>If two pointers point to elements of the same array or
>one beyond the end of the
>array, the pointer to the object with the higher subscript compares
higher."

ah yes, this was the baby I was looking for.

"danke" to all of you

Thorsten





--
Thorsten Ottosen, Aalborg University
nesotto@cs.auc.dk
---------------------------------------------------
C++:

my_map[key]++;

Java:

if ( !my_map.containsKey( key ) )
    my_map.put( key, new Integer( 1 ) );
else
{
    Integer count = ( Integer )my_map.get( key ) );
    int icount = count.IntValue();
    my_map.put( key, new Integer( ++icount ) );
}


"Daniel Spangenberg" <dsp@bdal.de> wrote in message
news:3E9AA242.E270D0F6@bdal.de...
Hi Thorsten!

THORSTEN OTTOSEN schrieb:

> Hi All,
>
> During my work as a teaching assistant in a C course, a saw a program that
> relied on comparison of array addresses.
> The code was something similar to this:
>
> int foo( char* start, char* end )
> {
>     if( start > end )
>       return 1;
>     if ( compare( start, end ) )
>        return foo( ++start, --end );
>     return 0;
> }
>
> char arr[10] = ...; // allocate on stack
> foo( arr, &arr[9] );
>
> Now, does the standard guarantee portability of this? I couldn't find much
> in section 8.3.4 about it.
> Could a compiler reverse the end/begining of the array and implement
> operator++ and decrement?
>
> regards
>
> Thorsten, AAU
>

The given pointer comparison should portably work, provided, that both start
and end are pointers
to the same object or one past the end of the array and none of them is a
null
pointer constant.

The relevant chapter in C++ is chapter 5.9 (relational operators) in Our
Holy
Standard:

Read the paragraph 2 carefully. Here are some essentials from it:

"- If two pointers p and q of the same type point to the same object or
function, or both point one past the
end of the same array, or are both null, then p<=q and p>=q both yield true
and p<q and p>q both
yield false."

"- If two pointers p and q of the same type point to different objects that
are not members of the same
object or elements of the same array or to different functions, or if only
one
of them is null, the results
of p<q, p>q, p<=q, and p>=q are unspecified."

"- If two pointers point to data members of the same union object, they
compare equal (after conversion to
void*, if necessary). If two pointers point to elements of the same array or
one beyond the end of the
array, the pointer to the object with the higher subscript compares higher."

Greetings from Bremen,

Daniel Spangenberg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8p7m9vcqit7vh5vik5280epcr1idmg2hhs@4ax.com>, John Potter
<jpotter@falcon.lhup.edu> writes
>On Mon, 14 Apr 2003 17:53:59 +0000 (UTC), francis.glassborow@ntlworld.com
>(Francis Glassborow) wrote:
>
>> In article <b7cqd2$pdm$1@sunsite.dk>, THORSTEN OTTOSEN
>> <nesotto@cs.auc.dk> writes
>
>> >int foo( char* start, char* end )
>> >{
>> >    if( start > end )
>> >      return 1;
>> >    if ( compare( start, end ) )
>> >       return foo( ++start, --end );
>> >    return 0;
>>> >
>> >
>> >char arr[10] = ...; // allocate on stack
>> >foo( arr, &arr[9] );
>
>> Meta-comment, the code you give seems seriously flawed in its design
>> because nothing done in it will have any external effects. Also note
>> that by convention compare returns 0 if the compared values are equal.
>
>I assume that you refer to the result not being used?  If the convention
>is being followed, foo is return start > end || (end - start) % 2.  :)

Well yes, But I bet that that was not anywhere near what was the
intention of the programmer writing that code. Actually it is hard to
imagine what was the intent but I am speculating that the author was
making the standard mistake of miscounting the levels of indirection
provided by the parameters.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]