From -4510160543107205886 X-Google-Thread: f78e5,1130823ffefc6ebe X-Google-Thread: fc772,1130823ffefc6ebe X-Google-Attributes: gidf78e5,gidfc772,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed-east.nntpserver.com!nntpserver.com!newsfeed1.sea.pnap.net!newsfeed2.sea.pnap.net!newsfeed.pnap.net!brmea-news-1.sun.com!news1nwk.sfbay.sun.com!taumet!clamage From: llewelly Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: Re: Unions up in arms! Date: Wed, 15 Sep 2004 20:19:20 +0000 (UTC) Organization: The Illusory Sorting Algorithm Lines: 53 Sender: cppmods@netlab.cs.rpi.edu Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: <86zn3sp3bk.fsf@Zorthluthik.local.bar> References: <9215d7ac.0409081832.4ab088d6@posting.google.com> <9215d7ac.0409111529.ab7cefa@posting.google.com> NNTP-Posting-Host: taumet.sfbay.sun.com Content-Type: TEXT/PLAIN X-Trace: news1nwk.SFbay.Sun.COM 1095279560 13735 129.146.79.208 (15 Sep 2004 20:19:20 GMT) X-Complaints-To: usenet@news1nwk.sfbay.sun.com NNTP-Posting-Date: Wed, 15 Sep 2004 20:19:20 +0000 (UTC) X-Original-NNTP-posting-date: Wed, 15 Sep 2004 19:22:46 +0000 (UTC) Delivered-to: std-c++@ucar.edu X-Original-Date: Tue, 14 Sep 2004 22:24:15 -0600 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAQUiXT0HMCo9UcraBAQFh/QIAmY998yS7R3xDsgFZoqyyLnjDzjfWhTxy IoAgLcYaSh5F6LEOkteSwQqVWYPI0LhmD1n5cu2fsPQsIgShd0dMOw== =+XG5 X-Approved-For-Group: kuehl@inf.uni-konstanz.de comp.lang.c++.moderated X-NNTP-posting-host: netlab.cs.rpi.edu Original-recipient: rfc822;stephen.clamage@sun.com Originator: clamage@taumet Xref: g2news1.google.com comp.std.c++:2641 comp.lang.c++.moderated:8285 glenlow@pixelglow.com (Glen Low) writes: > > Aren't you making a fairly big assumption? > > What if sizeof(int) != sizeof(float)? > > Let's assume that it is so. > > > >And finally, what does "including, recursively, a member of a > > >subaggregate or contained union" mean? > > Well, interpretation A was that: > > an object of type int can be accessed by a lvalue of type union { int > i; float f }; and also an lvalue of type union { union { int i; float > f}; float g; }; > > But that doesn't make sense, since if the lvalue is constrained to be > of struct type instead, you could possibly access an undefined value > e.g. the float value. > > Interpretation B is that > > an object of type int can be accessed by a lvalue of type union { int > i; float f; }.i or union {int i; float f; }.f etc. > > This hinges on the phrase "through an lvalue", since the actual lvalue > is no longer of union (or struct) type. I see a lot of gcc users > advocating this, e.g. Mark Mitchell of Codesourcery who contributed > the type-based alias analysis code to gcc. [snip] I think if asked him whether or not it was conforming, he would tell you 'no'. Wherever I've seen him 'advocating' that construct, it is to replace an older form of non-standard type punning which gcc no longer supports, with a different form of non-standard type punning which gcc still supports; it was always clear from context that such constructs were not conforming. IOWs, when compiled with gcc, it will do what experienced gcc users expect, but it is not conforming. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] [ 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 ]