[Moderator's note: this has drifted off-topic.  Crossposted and
followups redirected to comp.lang.c++.  -fjh.]

In article <rf5g1yduxbn.fsf@vx.cit.alcatel.fr>, James Kanze
<james-albert.kanze@vx.cit.alcatel.fr> wrote:
...
>
>And if your looking for "surprizing" idioms, C style array's and
>indexing are a good place to look.  Don't forget that the [] operator is
>commutative, so that "index[ array ]" is legal.  This seems to be a
>regular feature of programs in the obfuscated C contest; I've yet to
>find another use for it, however.
>

A couple of odd indexing idioms that I use in throw-away code:

   // Convert a nibble to hex, very quickly.
   //
   cout << "0123456789ABCDEF"[i & 0x0f];

   // Print a true/false value from an integer as a character
   // (does the correct thing with non 0 or 1 values)
   // note that the "TF" is backwards, because of the "!"
   cout << "TF"[!var];


These generally confuse inexperienced programmers the first time
the see them.
--
Darron Shaffer
Darron.Shaffer@beasys.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze wrote:

>(and indexing a C style array with a negative number is a definite
>no-no).

Actually indexing (within) a C style array with a negative number works
fine, but of course you have to be sure there are elements "down there".
Array indexing is nothing more than address arithmetic followed by
dereferencing.

I first saw this in the yacc parser code -- surprized me.

I assume that C++ can do this also.

Jim McElroy
Bellevue, Washington
jimmc@ibm.net
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jimmc@ibm.net writes:

|>  James Kanze wrote:
|>
|>  >(and indexing a C style array with a negative number is a definite
|>  >no-no).
|>
|>  Actually indexing (within) a C style array with a negative number works
|>  fine, but of course you have to be sure there are elements "down there".
|>  Array indexing is nothing more than address arithmetic followed by
|>  dereferencing.
|>
|>  I first saw this in the yacc parser code -- surprized me.
|>
|>  I assume that C++ can do this also.

Yes.  I wouldn't consider this "indexing a C style array", however, but
"indexing a pointer".

And if your looking for "surprizing" idioms, C style array's and
indexing are a good place to look.  Don't forget that the [] operator is
commutative, so that "index[ array ]" is legal.  This seems to be a
regular feature of programs in the obfuscated C contest; I've yet to
find another use for it, however.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

jimmc@ibm.net wrote:
>
> James Kanze wrote:
>
> >(and indexing a C style array with a negative number is a definite
> >no-no).
>
> Actually indexing (within) a C style array with a negative number works
> fine, but of course you have to be sure there are elements "down there".
> Array indexing is nothing more than address arithmetic followed by
> dereferencing.

But array indexing differs from pointer indexing, in that the starting
point is inherently the start of an object, so a negative index always
takes you outside of the object.

>
> I first saw this in the yacc parser code -- surprized me.
>
> I assume that C++ can do this also.

Perhaps it was a pointer into an array that was being indexed, and not
the array itself? Maybe it was a function argument that was declared as
an array, which is equivalent to a pointer in that context.

There is one case where I would have expected negative indexing to be
safe:

 int array[3][2];
 int x;

 ...

 x = array[1][-1];

However, when I brought up a related case on comp.std.c, I was informed
that code like this can produce undefined behavior; a fully compliant
compiler could implement run-time bounds-checking using tagged pointers
that would balk at this code. Is it different in C++?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kuyper <kuyper@wizard.net> writes:

|>  jimmc@ibm.net wrote:
|>  >
|>  > James Kanze wrote:
|>  >
|>  > >(and indexing a C style array with a negative number is a definite
|>  > >no-no).
|>  >
|>  > Actually indexing (within) a C style array with a negative number works
|>  > fine, but of course you have to be sure there are elements "down there".
|>  > Array indexing is nothing more than address arithmetic followed by
|>  > dereferencing.
|>
|>  But array indexing differs from pointer indexing, in that the starting
|>  point is inherently the start of an object, so a negative index always
|>  takes you outside of the object.
|>
|>  >
|>  > I first saw this in the yacc parser code -- surprized me.
|>  >
|>  > I assume that C++ can do this also.
|>
|>  Perhaps it was a pointer into an array that was being indexed, and not
|>  the array itself? Maybe it was a function argument that was declared as
|>  an array, which is equivalent to a pointer in that context.

In the specific case of yacc, it is a pointer to the top of a stack that
is growing up that gets the negative indexes.  To avoid confusion in
such cases, I generally prefer to write "*(p - n)".  Yacc generated
code, however, is not meant for human eyes, and of course, my preference
is only a matter of taste anyway.

|>  There is one case where I would have expected negative indexing to be
|>  safe:
|>
|>   int array[3][2];
|>   int x;
|>
|>   ...
|>
|>   x = array[1][-1];
|>
|>  However, when I brought up a related case on comp.std.c, I was informed
|>  that code like this can produce undefined behavior; a fully compliant
|>  compiler could implement run-time bounds-checking using tagged pointers
|>  that would balk at this code. Is it different in C++?

I don't think so.  At least, I don't think it is the intent.  (And FWIW:
such implementations do exist.)

In my interpretation, in the above, the expression "array[1]" designates
a subobject which is itself an array; any address arithmetic applied to
this expression (such as indexing) must follow the rules of address
arithmetic on the subobject, i.e.: neither the results nor any
intermediate value may point outside of the subobject, except that they
may point to the first byte after the subobject.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stephen.Clamage@eng.sun.com (Steve Clamage) writes:

|>  In article 6e23389d@larrybr1, "Larry Brasfield"
|>  <SpamGuard_LarryBr@microsoft.com> writes:
|>  >Uwe Tantz <tau04037@rphc1.physik.uni-regensburg.de> wrote in article
|>  ><Pine.SOL.3.90.970219110132.27930A-100000@rphc2.physik.uni-regensburg.de
|>  >>
|>  >> return Table[reinterpret_cast<const unsigned char>(str1[i])] <
|>  >>        Table[reinterpret_cast<const unsigned char>(str2[i])];
|>  >>
|>  >> The compiler refuses this: "Invalid cast"
|>  >
|>  >It should have taken your reinterpret_cast.
|>
|>  No, the compiler is correct. Reinterpret cast is for casting pointers
|>  to other pointers, pointers to integers, integers to pointers. No other
|>  conversions are allowed for a reinterpret_cast.
|>
|>  > But why not use a static_cast instead?
|>
|>  Indeed. To cast among integral types, you need to use a static_cast,
|>  if you need a cast at all. (All conversions among integer types
|>  are allowed to be implicit.)

But to be implicit, the compiler has to know what he wants.  In this
case, Table is (presumably) a C style array, and the implicit cast is to
"int", which will not do what he wants, since it retains the signed
value (and indexing a C style array with a negative number is a definite
no-no).

In fact, my own solution would be to replace the C style array with an
array class which overloads operator[] to take a char, and do the right
thing with it.  Which, of course, means that there is no need for the
cast when indexing.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 6e23389d@larrybr1, "Larry Brasfield"
<SpamGuard_LarryBr@microsoft.com> writes:
>Uwe Tantz <tau04037@rphc1.physik.uni-regensburg.de> wrote in article
><Pine.SOL.3.90.970219110132.27930A-100000@rphc2.physik.uni-regensburg.de
>>
>> return Table[reinterpret_cast<const unsigned char>(str1[i])] <
>>        Table[reinterpret_cast<const unsigned char>(str2[i])];
>>
>> The compiler refuses this: "Invalid cast"
>
>It should have taken your reinterpret_cast.

No, the compiler is correct. Reinterpret cast is for casting pointers
to other pointers, pointers to integers, integers to pointers. No other
conversions are allowed for a reinterpret_cast.

> But why not use a static_cast instead?

Indeed. To cast among integral types, you need to use a static_cast,
if you need a cast at all. (All conversions among integer types
are allowed to be implicit.)

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]