Topic: &*E - Should *E be evaluated?
Author: David R Tribble <dtribble@technologist.com>
Date: 1999/01/08 Raw View
> In article <369364ED.ADA@pratique.fr>,
> Valentin Bonnard <bonnardv@pratique.fr> wrote:
> >
> > Andrew Koenig wrote:
> > >
> > > In article <3690FE26.480A@pratique.fr>,
> > > Valentin Bonnard <bonnardv@pratique.fr> wrote:
> > >
> > > > I think the rewrite rule &*E -> E in the C9X draft is silly
> > > > and shocking.
> > >
> > > It has one beneficial side effect, namely that in the scope of
> > >
> > > int x[100];
> > >
> > > the expression &x[100] is legal. It's undefined in C89 and C++,
> > > even though it is widely used in both languages.
> >
> > I don't see that as a benefit in C++, because it's illegal
> > within the STL, and encouraging people to do that is a bad
> > idea.
> >
> > [ And BTW I never use it. ]
AllanW@my-dejanews.com wrote:
>
> No, you use x+100 instead.
...
>
> Novice:
> I need to call binary_search to see if the x[] array has a match
> for value y.
...
> ..., so the call looks like this:
> int z = sizeof(x) / sizeof(x[0]);
> binary_search(&x[0], &x[z], y)
...
How about:
binary_search(x, x+z, y);
But FWIW, I do use '&x[0]' a lot and '&x[z]' only occasionally.
I am one of those programmers who prefer '&x[i]' over 'x+i', since
the former is more descriptive of what's going on, at least in my
eyes.
-- David R. Tribble, dtribble@technologist.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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1999/01/04 Raw View
In article <76oqmu$foq$1@nnrp1.dejanews.com>, <fvali@biotrack.com> wrote:
> In C (my reference is the C9x draft) the expression &*E is equivalent
> to E even if E is a null pointer, i.e., neither the operand of *, nor of
> & is evaluated.
> I found no evidence that this expression is well-defined in Standard C++.
> Why is this so? What is the harm in defining this behavior as is done
> for C (C9x atleast, I do not have access to a C89 std).
Because C9X changed the behavior of C89 and C++ didn't.
--
Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1999/01/04 Raw View
fvali@biotrack.com writes:
> In C (my reference is the C9x draft) the expression &*E is equivalent
>to E even if E is a null pointer, i.e., neither the operand of *, nor of
>& is evaluated.
>I found no evidence that this expression is well-defined in Standard C++.
>Thus the following fragment is well defined C code but not C++:
>struct A { };
>struct A* ap1 = 0;
>struct A* ap2 = &*(ap1);
>// assert( ap2 == 0 );
>Why is this so? What is the harm in defining this behavior as is done
>for C (C9x atleast, I do not have access to a C89 std).
Allowing &*p to have meaning when p is null requires a special
case in the semantics and associativity of the operators. Without
the special case, the meaning is &(*p), which is undefined for
a null pointer.
In C, you can add the language wart that the "&" and "*" cancel
each other out, in effect mandating a compiler optimization.
In C++, the situation is not so straightforward. Either or both of
the operators might be overloaded. If so, the functions must
be called unless the compiler can prove they have no side effects.
As a further note, there is no special case in C89, which was
the only C standard in effect when the C++ standard was under
development. For that matter, C89 still is the only C standard
in effect, since C9X is only in the CD1 stage.
--
Steve Clamage, stephen.clamage@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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1999/01/04 Raw View
fvali@biotrack.com wrote:
> In C (my reference is the C9x draft) the expression &*E is equivalent
> to E even if E is a null pointer, i.e., neither the operand of *, nor of
> & is evaluated.
>
> I found no evidence that this expression is well-defined in Standard C++.
It isn't. It could be clearer, with a statement such as
P = 'dereferencing a null pointer is undefined behaviour'.
(And the std says that it says P <g>)
But *p refers to the object p is pointing to, so *(T*)0 cannot
be well defined.
I think the rewrite rule &*E -> E in the C9X draft is silly
and shocking.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Martin von Loewis <loewis@informatik.hu-berlin.de>
Date: 1999/01/04 Raw View
Valentin Bonnard <bonnardv@pratique.fr> writes:
> P = 'dereferencing a null pointer is undefined behaviour'.
>
> (And the std says that it says P <g>)
ROTFL. Is anybody collecting C++ quotes?
Martin
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1999/01/04 Raw View
On 4 Jan 1999 01:58:43 GMT, fvali@biotrack.com <fvali@biotrack.com> wrote:
> In C (my reference is the C9x draft) the expression &*E is equivalent
>to E even if E is a null pointer, i.e., neither the operand of *, nor of
>& is evaluated.
No, "&*E" is not the same as "E". If E is null, then "&*E" should
give a runtime memory access violation as you can't dereference
the null pointer. Also, the implementation may do runtime array
bounds checking. So if E refers to an array of size 0, then "&*E"
could give a runtime error as "*E" or "E[0]" accesses the array
out of bounds. In a similar vein, for an array 'v' of size 'N',
"v+N" is a pointer past the last element in the array, but "&v[N]"
is undefined as it may result in a runtime array bounds error as
v[N] accesses the array out of bounds.
Moreover, if E is an object type, the operators op* and op& may
be overloded. For example, op* may be overloaded to return a
reference to a specific field in a struct rather than a reference
to the whole struct. So "E" refers to the whole struct, wherease
"&*E" refers to the address of a specific field in the struct.
Or perhaps there is no op* at all.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1999/01/05 Raw View
In article <3690FE26.480A@pratique.fr>,
Valentin Bonnard <bonnardv@pratique.fr> wrote:
> I think the rewrite rule &*E -> E in the C9X draft is silly
> and shocking.
It has one beneficial side effect, namely that in the scope of
int x[100];
the expression &x[100] is legal. It's undefined in C89 and C++,
even though it is widely used in both languages.
--
Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1999/01/06 Raw View
Andrew Koenig wrote:
>
> In article <3690FE26.480A@pratique.fr>,
> Valentin Bonnard <bonnardv@pratique.fr> wrote:
>
> > I think the rewrite rule &*E -> E in the C9X draft is silly
> > and shocking.
>
> It has one beneficial side effect, namely that in the scope of
>
> int x[100];
>
> the expression &x[100] is legal. It's undefined in C89 and C++,
> even though it is widely used in both languages.
I don't see that as a benefit in C++, because it's illegal
within the STL, and encouraging people to do that is a bad
idea.
[ And BTW I never use it. ]
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/07 Raw View
In article <369364ED.ADA@pratique.fr>,
Valentin Bonnard <bonnardv@pratique.fr> wrote:
>
> Andrew Koenig wrote:
> >
> > In article <3690FE26.480A@pratique.fr>,
> > Valentin Bonnard <bonnardv@pratique.fr> wrote:
> >
> > > I think the rewrite rule &*E -> E in the C9X draft is silly
> > > and shocking.
> >
> > It has one beneficial side effect, namely that in the scope of
> >
> > int x[100];
> >
> > the expression &x[100] is legal. It's undefined in C89 and C++,
> > even though it is widely used in both languages.
>
> I don't see that as a benefit in C++, because it's illegal
> within the STL, and encouraging people to do that is a bad
> idea.
>
> [ And BTW I never use it. ]
No, you use x+100 instead.
The problem exists for experts and novices alike.
Experts:
When I see &x[y], I have trained myself to think of x+y, because
that's a simpler explanation for what's going on. There is one
exception to that rule, and that's the one case where x+y is
valid but x[y] is not: namely, when y==sizeof(x)/sizeof(x[0]).
But I don't see that unless I look very, very carefully. Gosh,
I can't tell you how many times I've been burned by that. Why,
back in '94 I was debugging one app that... (ramble ramble ramble)
Novice:
I need to call binary_search to see if the x[] array has a match
for value y. Looking at the documentation, I see that the first
parameter is an iterator to the first element to search, and
the second parameter is an iterator to one past the last element
to search. Since x[] is a C-style array, I can use pointers as
the iterators. So I need a pointer to x[0] and a pointer to
just past x[z-1], where z is the number of elements in the array.
I get the address by using the & operator, so the call looks like
this:
int z = sizeof(x) / sizeof(x[0]);
binary_search(&x[0], &x[z], y)
Voice of reason:
No, that's wrong because x[z] isn't defined. Maybe we can avoid
problems by using a macro.
#define PAST_END(x) ((x)+sizeof(x)/sizeof(x[0]))
Expert:
MACROS?!? Are you kidding? Listen, Bub, we don't use Macros anymore
except for conditional compilation. Macros, sheesh!
Novice:
Sure looks like a good idea, but why haven't I seen it in any
of the magazines I read?
Voice of reason:
But this will solve the problem. Just use this instead of x+z or
&x[z], and everything will work fine.
Expert:
What, are you still here? Yeah, maybe it will solve the problem if
I remember to use it ... but if I could always remember to use it,
then I could always remember to do it right in the first place!
Come on, get real.
Novice:
I don't get it. How do I use it? What's it for again? It looks
different than it did before. Are you just making this up?
Voice of reason:
Look, will you just try it? One program, what could it hurt?
Expert:
You go try it first, tell me how it works.
Novice:
I think you changed it again! Isn't it finished yet?
Voice of reason:
Oh, forget it! I'm leaving!
Expert:
Don't let the door hit you on the way out!
Novice:
He sure didn't know anything about programming. Not like you and me!
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/01/07 Raw View
In article <369364ED.ADA@pratique.fr>,
Valentin Bonnard <bonnardv@pratique.fr> wrote:
>
> Andrew Koenig wrote:
> >
> > In article <3690FE26.480A@pratique.fr>,
> > Valentin Bonnard <bonnardv@pratique.fr> wrote:
> >
> > > I think the rewrite rule &*E -> E in the C9X draft is silly
> > > and shocking.
> >
> > It has one beneficial side effect, namely that in the scope of
> >
> > int x[100];
> >
> > the expression &x[100] is legal. It's undefined in C89 and C++,
> > even though it is widely used in both languages.
>
> I don't see that as a benefit in C++, because it's illegal
> within the STL, and encouraging people to do that is a bad
> idea.
The benefit in C++ is that &x[ 100 ] is the end iterator for a C style
array. You can also write x + 100, but for many people (myself
included), &x[ 100 ] seems more natural.
Whether this convenience is worth still another special case (hack) in
the language specification is another question.
--
James Kanze GABI Software, S rl
Conseils en informatique orient objet --
-- Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr mailto: James.Kanze@dresdner-bank.com
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fvali@biotrack.com
Date: 1999/01/04 Raw View
Hi,
In C (my reference is the C9x draft) the expression &*E is equivalent
to E even if E is a null pointer, i.e., neither the operand of *, nor of
& is evaluated.
I found no evidence that this expression is well-defined in Standard C++.
Thus the following fragment is well defined C code but not C++:
struct A { };
struct A* ap1 = 0;
struct A* ap2 = &*(ap1);
// assert( ap2 == 0 );
Why is this so? What is the harm in defining this behavior as is done
for C (C9x atleast, I do not have access to a C89 std).
Thanks,
-fais
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]