From -9056609846559087915 X-Google-Thread: 7894ca11fe,191c67e7ffa6c8e7 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.glorb.com!news.alt.net From: Joshua Maurice Newsgroups: comp.std.c++ Subject: Re: reinterpret_cast(&some_int) Date: Sat, 23 Oct 2010 13:03:53 CST Organization: http://groups.google.com Lines: 100 Sender: std-c++-request@ruralroute.cs.rpi.edu Approved: austern@google.com Message-ID: <6b8c006a-1ebe-447c-82c3-6374486343a3@p37g2000pra.googlegroups.com> References: <402768.38178.qm@web110410.mail.gq1.yahoo.com> <1bb08f2a-854d-4d6c-b686-42a84dd8c2c2@t13g2000yqm.googlegroups.com> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Hash: SCt|d6006069480605e907c4a9f5bcf5c22162890e0c|beef97890bb30624b194b8a407432175 X-Countries: United States X-SMTP-From: accepted assassin.cs.rpi.edu [128.113.126.17] (assassin.cs.rpi.edu) {United States} DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cs.rpi.edu; h=date :to:sender:message-id:from:subject:references:content-type; s= default; i=128.113.126.17@cs.rpi.edu; t=1287857032; x= 1288461832; l=4447; bh=tljnmN408+WK1QBXvZE4CGbwwe0=; b=PoCY0KkYa 88TjpVpVql+E64JiaLpUPwo3Kp2JJvXJLE7S0aYWV2lBNZifnsUb6Wx8ktv9KYD0 r9W3pu/iBRMsUfhH9sUdF5fHp8IRJ6CJTD6F4kr+qgulAdgn7/9Ga/b21OmRV1uX Zq8ROyK1yyFkvsprdd8d75WXwyuf/ouG04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cs.rpi.edu; h=date:to:sender :message-id:from:subject:references:content-type; q=dns; s= default; b=reFMQaZ3bxYAIyb0tl5KQxbL43NrO/C24cML37EDb6ihDQJBGb6ew ej0sIh6ZIdeD+Z4/u3bJ5GhZlwC4x89ZbcHzC1weBN0Ro2TmUfbct/pH9gXBLG8k SzxaWNs/VhbhtW73Jz7v1sqSzD6MJe+JcL82+4moYapdqpQHPpM1Mw= X-Spam-Report: Spam Report from cliffclavin.cs.rpi.edu (SA:3.2.5): -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 3.4 HEADER_SPAM Bulk email fingerprint (header-based) found -0.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 SARE_HEAD_HDR_APPROV Message headers used which identify spam 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Info: 0.9, local; ALL_TRUSTED,AWL,BAYES_00,HEADER_SPAM,SARE_HEAD_HDR_APPROV X-Spam-Scanned-By: cliffclavin.cs.rpi.edu using SpamAssassin 3.2.5 X-Virus-Scanned-By: cliffclavin.cs.rpi.edu X-Original-Date: Sat, 23 Oct 2010 09:40:07 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu X-Scanned-By: MIMEDefang 2.67 on 128.113.126.25 Xref: g2news1.google.com comp.std.c++:3054 On Oct 20, 3:14 pm, James Kanze wrote: > On Oct 13, 6:52 pm, Trigve Siver wrote: > > > On 12. Okt, 02:06 h., James Kanze wrote: > > > It is and it isn't. About all you can say is that you're more > > > or less guaranted to pass the address of the int into > > > input.read. Since this function expects the address of a char > > > buffer, and will write it as such, just about anything can > > > happen after that. > > Is there ANY portable way to read binary data of PODs from file? > > Unless you know the format of the data in the file, there's no > way to read it, portable or not. If you know the format, you > read the bytes, and assemble them as the format requires. > > > Only method I can think of is using "char *" buffer and then > > "std::memcpy()" to target of POD type (3.9/2). > > Which will be about the same as using reinterpret_cast. You > will get just about anything. > > > > > And what about reinterpret_cast(&some_pod)? > > > The same. > > Then what is 5.2.10/7("...When a prvalue v of type pointer to > > T1 is converted to the type pointer to cv T2, the result is > > static_cast(static_cast(v)) if both T1 and > > T2 are standard-layout types (3.9) and the alignment > > requirements of T2 are no stricter than those of T1....") > > good for? > > System level programming, where you have to type pun. Nothing > portable, but you might use casts along those lines if you > wanted to extract the exponent field from a floating point, for > example. > > > Could someone give some practical example where the sentence > > above could be applied and give some defined behaviour but > > without the sentence above it wouldn't, please? > > The sentence you quote simply guarantees that the pointer > conversions won't result in undefined behavior. It doesn't say > much about what happens when using the pointers, but the overall > intent is certainly that they will be well behaved for things > that are reasonable on the given architecture, and will do what > someone familiar with the architecture would expect. Thus, to > get the exponent from a double on an Intel architecture, one > might do something like: > int exp = (*reinterpret_cast(&d) >> 4) & 0x07FF; > exp -= 1023; > It's not portable, of course; where the actual exponent bits > are, and how the exponent is represented, depends on the > architecture. > > Any use of reinterpret_cast with regards to I/O, on the other > hand, is almost certainly an error, and in no case portable. > (On the other hand... You don't always need to be 100% portable, > and in some cases, a reinterpret_cast can be a reasonable > compromize to allow reading everything as uint32_t or uint64_t, > and using reinterpret_cast on that. The code for reading > floating point this way is an order of magnitude simpler than > any fully portable solution -- just be aware that it will only > work on Windows and the mainstream Unixes, but not on > mainframes or a number of other machines.) Yay! Is comp.std.c++ back up yet? 6th try. James, I'm not sure if you're purposefully dodging the question, or if you genuinely do not understand the question. Yes, I am happy that we are all better off knowing that dodgy serialization schemes are dodgy, but that wasn't his question. Here, let me phrase the question like this. Ignoring memory allocation issues, stack size issues, and other QoI issues, and I guaranteed that the following program will return 42 on a conforming implementation (modulo typos)? If so, where is the chapter and verse saying that I can read from and write to POD types through a char or unsigned char lvalue obtained with a reinterpret_cast? Would the following program work with "static_cast(static_cast(" instead of "reinterpret_cast("? #include using namespace std; int main() { int const x = 42; stringstream ss; ss.write(reinterpret_cast(&x), sizeof(x)); int y; ss.read(reinterpret_cast(&y), sizeof(y)); return y; } -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]