From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!newsprint.newsread.com!newsfeed.stueberl.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!tsicnews.teliasonera.com!news.otenet.gr!news.grnet.gr!newsfd02.forthnet.gr!not-for-mail From: Ioannis Vranos Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Tue, 29 Mar 2005 00:24:59 +0300 Organization: FORTHnet S.A., Atthidon 4, GR-17671 Kalithea, Greece, Tel: +30 2109559000, Fax: +30 2109559333, url: http://www.forthnet.gr Message-ID: <1112045099.679682@athnrd02> References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net> <1112022773.497341@athnrd02> <1112026376.920221@athnrd02> <1112034544.645999@athnrd02> <1112039976.169686@athnrd02> NNTP-Posting-Host: athnrd02.forthnet.gr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: athprx02.forthnet.gr 1112045099 15325 193.92.150.73 (28 Mar 2005 21:24:59 GMT) X-Complaints-To: abuse@forthnet.gr NNTP-Posting-Date: Mon, 28 Mar 2005 21:24:59 +0000 (UTC) User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en In-Reply-To: Cache-Post-Path: newsfd02!unknown@ppp27-adsl-132.ath.forthnet.gr Xref: g2news1.google.com comp.lang.ada:10096 comp.lang.c++:47686 comp.realtime:1796 comp.software-eng:5433 Date: 2005-03-29T00:24:59+03:00 List-Id: REH wrote: > No, it is not about whether memcpy() is a necessary function. You purposely > over simplified what I did. I don't want to appear rude, but your whole > statement about moving a double byte-by-byte to avoid alignment issues is > just nonsense. My point was that we can create objects in a low level way like that. > You didn't take portability into account when you wrote the > snippets of code using placement new, and now you wish to backpedal. I considered them to be portable (apart from the non-explicit call of destructors mistake). > You > really are not going to convince me that you intended write all your classes > to copy all the bytes of variables with alignment needs greater than one, > instead of just fixing the alignment. > > Do you really expect my to believe > you would write: > > struct foo { > foo(double d) : m_dbl(d) {} > double get() const > { > double tmp; > memcpy(&tmp, &m_dbl, sizeof(tmp)); > return tmp; > } > > private: > double m_dbl; > } > > char buf[sizeof(foo)]; > > foo* pf = new(buf) foo(); > double d = pf->get(); > > > instead of: > > struct foo { > foo(double d) : m_dbl(d) {} > double get() const {return m_dbl;} > > private: > double m_dbl; > } > > union data_type { > double align; > char buf[sizeof(foo)]; > } data; > > foo* pf = new(data.buf) foo(); > double d = pf->get(); Yes the first one is also always guaranteed to work. In summary, the standard guarantees that you can read *any* POD type as a sequence of chars/unsigned chars and copy them to a new char/unsigned char array and you will have an exact, working copy of the original *POD* type. For non-POD types, you can only read them as sequences of unsigned chars only, but if you copy them it is *not* guaranteed that you will have either exact or working copies of the original. No alignment is mentioned about this anywhere. Now this means, that strictly speaking my code with the class having the defined constructor and destructor is not portable since is a non-POD type, and thus should not had used it in clc++, since strict theoretical portability is important in here. However the following code *is* portable: #include #include class SomeClass { public: double d; int i; float f; long l; }; int main() { using namespace std; unsigned char array[sizeof(SomeClass)]; SomeClass obj= {1, 2, 3, 4}; memcpy(array, &obj, sizeof(obj)); SomeClass *p= reinterpret_cast(array); cout<d<<" "<i<<" "<f<<" "<l<<"\n"; } C:\c>temp 1 2 3 4 C:\c> So since this is *guaranteed* to be portable, why this isn't? #include #include class SomeClass { public: double d; int i; float f; long l; }; int main() { using namespace std; unsigned char array[sizeof(SomeClass)]; SomeClass obj= {1, 2, 3, 4}; SomeClass *p= new(array)SomeClass(obj); cout<d<<" "<i<<" "<f<<" "<l<<"\n"; } C:\c>temp 1 2 3 4 C:\c> -- Ioannis Vranos http://www23.brinkster.com/noicys