Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70942 > unrolled thread

Union type punning in C++

Started byMr Flibble <flibbleREMOVETHISBIT@i42.co.uk>
First post2020-01-01 19:24 +0000
Last post2020-01-13 16:29 -0800
Articles 20 on this page of 135 — 18 participants

Back to article view | Back to comp.lang.c++

Contents

  Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-01 19:24 +0000
    Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 09:36 +0000
    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 03:34 -0800
      Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 12:49 +0100
        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 04:52 -0800
          Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 17:22 +0000
            Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 10:26 -0800
              Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-02 21:54 +0000
                Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:49 +0000
                  Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 17:11 +0100
                  Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-03 17:55 +0000
              Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 09:55 +0000
                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 11:20 +0100
                Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 02:21 -0800
                  Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:55 +0000
                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 16:04 +0100
                      Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:45 -0800
                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:26 +0100
                          Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 16:55 -0800
                            Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 01:02 +0000
                              Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 17:06 -0800
                    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:34 -0800
                      Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 16:12 +0000
                        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 08:49 -0800
                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 19:28 +0100
                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:54 +0000
                            Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:25 +0100
                              Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:28 +0000
                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:41 +0100
                                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:52 +0000
                                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:08 +0100
                                      Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:34 +0100
                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:43 +0100
                                        Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:20 +0000
                                          Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
                                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:25 +0000
                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
                                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:27 +0000
                                            Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:36 +0100
                                              Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:41 +0000
                                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:49 +0100
                                                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:01 +0000
                                                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:02 +0100
                                                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:19 +0000
                                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:38 +0100
                              Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-04 12:45 +0100
                                Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 12:00 +0000
                                  Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 13:03 +0100
                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 14:22 +0100
                        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:46 -0800
                      Re: Union type punning in C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:32 -0800
                        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 10:43 -0800
                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:55 +0000
              Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 09:40 -0800
                Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-08 13:23 -0800
                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:41 -0800
                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:52 -0800
                    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-09 12:59 -0800
                      Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-09 13:32 -0800
                      Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 12:28 +0000
                        Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 14:02 +0100
                          Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 16:21 +0000
                            Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 19:18 +0100
                              Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-10 15:41 -0800
                                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 12:01 +0100
                                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 07:05 -0800
                                    Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 23:53 +0100
                                      Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-12 01:41 +0000
                                        Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 19:00 -0800
                                          Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-13 17:32 +0000
                              Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:53 +0000
                                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 13:20 +0100
                                  Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 12:33 +0000
                                    Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 14:28 +0100
                            Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 10:48 +0000
                        Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 11:05 +0000
                          Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:55 +0000
            Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 21:12 +0100
              Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:46 +0000
                Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-03 20:01 +0100
            Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-02 23:23 +0100
    Re: Union type punning in C++ peter koch <peter.koch.larsen@gmail.com> - 2020-01-02 12:39 -0800
    Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 15:39 -0800
      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 16:58 -0800
        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 17:55 -0800
          Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 00:40 -0800
            Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:04 +0000
              Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 15:24 +0100
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:34 -0800
                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 22:59 +0000
                    Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:11 +0000
                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:21 +0000
                        Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:26 +0000
                          Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-04 16:51 -0800
                      Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 18:47 -0800
                        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 19:07 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 06:47 -0800
                Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:57 +0000
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:38 -0800
                    Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 17:06 +0000
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 11:05 -0800
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:38 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 22:37 -0800
        Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:10 -0800
          Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-11 10:23 -0800
            Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 09:01 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 11:03 -0800
                Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 12:48 -0800
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 14:15 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 21:47 -0500
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 23:44 -0800
                        Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 08:26 -0500
                Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:30 -0800
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 09:11 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 21:52 -0500
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 23:15 -0800
                    Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:03 -0800
      Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:28 -0800
        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-11 20:40 -0800
          Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 20:16 -0500
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-12 17:28 -0800
              Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 21:53 -0500
                Re: Union type punning in C++ Manfred <noname@add.invalid> - 2020-01-13 18:50 +0100
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:21 -0800
              Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:57 -0800
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:27 -0800
                  Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:05 -0800
                    Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 20:58 -0800
                      Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 03:47 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 01:22 -0800
                Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 08:04 -0500
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 09:38 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 11:01 -0800
          Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:37 -0800
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:29 -0800

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#70942 — Union type punning in C++

FromMr Flibble <flibbleREMOVETHISBIT@i42.co.uk>
Date2020-01-01 19:24 +0000
SubjectUnion type punning in C++
Message-ID<kl6PF.88068$CSS.31003@fx01.dcg>
Undefined behaviour aside is C++ union type punning an acceptable hack or not, given that it is legal in C?
If it works on all the compilers I care about does it really matter that it is *currently* classed as undefined behaviour?
I would say that everyone has "secretly" fucking done it some time or other so the C++ Standards Committee should get there act together and legalize it like it has been in C.
Can anyone provide a straight answer to this?

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[toc] | [next] | [standalone]

#70955

Fromboltar@nowhere.org
Date2020-01-02 09:36 +0000
Message-ID<qukdjl$1lgb$1@gioia.aioe.org>
In reply to#70942
On Wed, 1 Jan 2020 19:24:26 +0000
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
>Undefined behaviour aside is C++ union type punning an acceptable hack or not,
>given that it is legal in C?

Using a union or otherwise, type punning in a necessity when doing low level
programming. If C++ is ever to be used in this scenario then it has to be 
Supported.

[toc] | [prev] | [next] | [standalone]

#70967

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-02 03:34 -0800
Message-ID<48ade352-879d-4c02-849b-82dad161c3d6@googlegroups.com>
In reply to#70942
On Wednesday, 1 January 2020 21:24:19 UTC+2, Mr Flibble  wrote:
> Undefined behaviour aside is C++ union type punning an acceptable hack or not, given that it is legal in C?
> If it works on all the compilers I care about does it really matter that it is *currently* classed as undefined behaviour?
> I would say that everyone has "secretly" fucking done it some time or other so the C++ Standards Committee should get there act together and legalize it like it has been in C.
> Can anyone provide a straight answer to this?

To me it seems to be unneeded feature.

1) Experiments of mine and others have shown that usage of memcpy
instead of other ways of type punning tends to generate better or
same codes. It is hard to find examples where other methods are
really beneficial. Can the "defacto" gang provide any? No? I thought
so.
2) Compiler writers say that type punning with union breaks some
aliasing optimizations so they have to pessimize just for a case. 
I haven't studied all details of such claims but as they are very highly
skilled people I trust them.
3) Whole pile of different methods is unneeded for doing low level
bit hacks. By Principle of Least Astonishment it is advisable to do
those hacks always using same idioms even when there are multiple
different ways available.

So whatever way the committees of C and C++ decide I will continue
to use memcpy myself for type punning and I will continue to suggest
that as rule in coding standards of projects where I participate. 
 
That old blog says basically same thing as me:
<https://blog.regehr.org/archives/959>

[toc] | [prev] | [next] | [standalone]

#70969

FromBo Persson <bo@bo-persson.se>
Date2020-01-02 12:49 +0100
Message-ID<h763m9FgujeU1@mid.individual.net>
In reply to#70967
On 2020-01-02 at 12:34, Öö Tiib wrote:
> On Wednesday, 1 January 2020 21:24:19 UTC+2, Mr Flibble  wrote:
>> Undefined behaviour aside is C++ union type punning an acceptable hack or not, given that it is legal in C?
>> If it works on all the compilers I care about does it really matter that it is *currently* classed as undefined behaviour?
>> I would say that everyone has "secretly" fucking done it some time or other so the C++ Standards Committee should get there act together and legalize it like it has been in C.
>> Can anyone provide a straight answer to this?
> 
> To me it seems to be unneeded feature.
> 
> 1) Experiments of mine and others have shown that usage of memcpy
> instead of other ways of type punning tends to generate better or
> same codes. It is hard to find examples where other methods are
> really beneficial. Can the "defacto" gang provide any? No? I thought
> so.
> 2) Compiler writers say that type punning with union breaks some
> aliasing optimizations so they have to pessimize just for a case.
> I haven't studied all details of such claims but as they are very highly
> skilled people I trust them.
> 3) Whole pile of different methods is unneeded for doing low level
> bit hacks. By Principle of Least Astonishment it is advisable to do
> those hacks always using same idioms even when there are multiple
> different ways available.
> 
> So whatever way the committees of C and C++ decide I will continue
> to use memcpy myself for type punning and I will continue to suggest
> that as rule in coding standards of projects where I participate.
>   
> That old blog says basically same thing as me:
> <https://blog.regehr.org/archives/959>
> 

The C++ committee seems unwilling to change the union rules and so 
instead adds a bit_cast function to package the memcpy usage with a 
slightly better name:

template< class To, class From >
constexpr To bit_cast(const From& from) noexcept;

https://en.cppreference.com/w/cpp/numeric/bit_cast


     Bo Persson

[toc] | [prev] | [next] | [standalone]

#70970

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-02 04:52 -0800
Message-ID<4535b294-e129-4308-861d-3618089ba264@googlegroups.com>
In reply to#70969
On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
> 
> The C++ committee seems unwilling to change the union rules and so 
> instead adds a bit_cast function to package the memcpy usage with a 
> slightly better name:
> 
> template< class To, class From >
> constexpr To bit_cast(const From& from) noexcept;
> 
> https://en.cppreference.com/w/cpp/numeric/bit_cast

Thanks, I didn't somehow even notice that. So we can throw away
our own type punning wrappers around memcpy in C++20.

[toc] | [prev] | [next] | [standalone]

#70974

Fromboltar@nowhere.org
Date2020-01-02 17:22 +0000
Message-ID<qul8sv$1op2$1@gioia.aioe.org>
In reply to#70970
On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
>> 
>> The C++ committee seems unwilling to change the union rules and so 
>> instead adds a bit_cast function to package the memcpy usage with a 
>> slightly better name:
>> 
>> template< class To, class From >
>> constexpr To bit_cast(const From& from) noexcept;
>> 
>> https://en.cppreference.com/w/cpp/numeric/bit_cast
>
>Thanks, I didn't somehow even notice that. So we can throw away
>our own type punning wrappers around memcpy in C++20.

You realise using a union (or a cast) in theory uses very few CPU cycles to do 
type punning, whereas memcpy has the overhead of a function call + loop. Its
an extremely inefficient way to do it if you don't need the new type to be in
a seperate variable.

[toc] | [prev] | [next] | [standalone]

#70977

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-02 10:26 -0800
Message-ID<73933783-456b-4e90-a5b2-1bc3bd2ae82e@googlegroups.com>
In reply to#70974
On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
> >> 
> >> The C++ committee seems unwilling to change the union rules and so 
> >> instead adds a bit_cast function to package the memcpy usage with a 
> >> slightly better name:
> >> 
> >> template< class To, class From >
> >> constexpr To bit_cast(const From& from) noexcept;
> >> 
> >> https://en.cppreference.com/w/cpp/numeric/bit_cast
> >
> >Thanks, I didn't somehow even notice that. So we can throw away
> >our own type punning wrappers around memcpy in C++20.
> 
> You realise using a union (or a cast) in theory uses very few CPU cycles to do 
> type punning, whereas memcpy has the overhead of a function call + loop. Its
> an extremely inefficient way to do it if you don't need the new type to be in
> a seperate variable.

That is the typical behavior of gibberish team. In one post it is
"de facto" in other "in theory". I wrote:

Experiments of mine and others have shown that usage of memcpy
instead of other ways of type punning tends to generate better or
same codes. It is hard to find examples where other methods are
really beneficial. Can the "defacto" gang provide any? No? I thought
so. 

So drop your rubbish and show assemblers of realistic usages
on real compilers where your "theories" hold.

[toc] | [prev] | [next] | [standalone]

#70982

FromChris Vine <chris@cvine--nospam--.freeserve.co.uk>
Date2020-01-02 21:54 +0000
Message-ID<20200102215405.c7bb68a54ce7899edf7ab1e7@cvine--nospam--.freeserve.co.uk>
In reply to#70977
On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
Öö Tiib <ootiib@hot.ee> wrote:
> On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
> > On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
> > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> > >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
> > >> 
> > >> The C++ committee seems unwilling to change the union rules and so 
> > >> instead adds a bit_cast function to package the memcpy usage with a 
> > >> slightly better name:
> > >> 
> > >> template< class To, class From >
> > >> constexpr To bit_cast(const From& from) noexcept;
> > >> 
> > >> https://en.cppreference.com/w/cpp/numeric/bit_cast
> > >
> > >Thanks, I didn't somehow even notice that. So we can throw away
> > >our own type punning wrappers around memcpy in C++20.
> > 
> > You realise using a union (or a cast) in theory uses very few CPU cycles to do 
> > type punning, whereas memcpy has the overhead of a function call + loop. Its
> > an extremely inefficient way to do it if you don't need the new type to be in
> > a seperate variable.
> 
> That is the typical behavior of gibberish team. In one post it is
> "de facto" in other "in theory". I wrote:
> 
> Experiments of mine and others have shown that usage of memcpy
> instead of other ways of type punning tends to generate better or
> same codes. It is hard to find examples where other methods are
> really beneficial. Can the "defacto" gang provide any? No? I thought
> so. 
> 
> So drop your rubbish and show assemblers of realistic usages
> on real compilers where your "theories" hold.

More to the point, in gcc/clang memcpy is a built-in, and in VS an
"intrinsic", and in most usages does not involve a function call at all
(unless our poster does something like pass it as a function pointer),
as your experiments show.  In C++ it is the recommended alternative to
punning with a union.  However, I think you are wasting your time
arguing with this guy: from his repetitive posts, he is either dim or a
dick, possibly both.

[toc] | [prev] | [next] | [standalone]

#71017

Fromboltar@nowhere.org
Date2020-01-03 14:49 +0000
Message-ID<qunk98$gor$1@gioia.aioe.org>
In reply to#70982
On Thu, 2 Jan 2020 21:54:05 +0000
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>More to the point, in gcc/clang memcpy is a built-in, and in VS an

Built-in doesn't mean loop free and no stack push/pops. It just means the 
compiler doesn't have to link in code from a library but can generate it on
the spot.

>arguing with this guy: from his repetitive posts, he is either dim or a
>dick, possibly both.

Ad Hominem seems to be a common theme from you assclowns when you can't 
actually argue your point.

[toc] | [prev] | [next] | [standalone]

#71030

FromDavid Brown <david.brown@hesbynett.no>
Date2020-01-03 17:11 +0100
Message-ID<qunp4c$cmd$1@dont-email.me>
In reply to#71017
On 03/01/2020 15:49, boltar@nowhere.org wrote:
> On Thu, 2 Jan 2020 21:54:05 +0000
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> More to the point, in gcc/clang memcpy is a built-in, and in VS an
> 
> Built-in doesn't mean loop free and no stack push/pops. It just means the 
> compiler doesn't have to link in code from a library but can generate it on
> the spot.

If your objects are big enough that they need to go on the stack instead
of registers, then yes - you will get stack usage.  And if they are big
enough for a loop to make sense, you will get a loop.  But if they are
small enough, as they often are, they will stay entirely in registers -
whether you use unions or memcpy.

Perhaps you think that because memcpy takes addresses as parameters, it
means the data has to be in ram?  If so, then you are wrong.

Of course, you'd know this if you had bothered to try any examples -
such as the code I posted.

I recommend you go to <https://godbolt.org>.  It is an online compiler,
with lots of different compilers (different versions of gcc, clang,
msvc, icc, etc.).  Put in some code with memcpy of local variables,
compile with optimisation (gcc -O2 or msvc /O2 for example), and /learn/
something.

> 
>> arguing with this guy: from his repetitive posts, he is either dim or a
>> dick, possibly both.
> 
> Ad Hominem seems to be a common theme from you assclowns when you can't 
> actually argue your point.
>

[toc] | [prev] | [next] | [standalone]

#71038

FromChris Vine <chris@cvine--nospam--.freeserve.co.uk>
Date2020-01-03 17:55 +0000
Message-ID<20200103175552.b1164b931d2dce5028a52ff7@cvine--nospam--.freeserve.co.uk>
In reply to#71017
On Fri, 3 Jan 2020 14:49:12 +0000 (UTC)
boltar@nowhere.org wrote:
> On Thu, 2 Jan 2020 21:54:05 +0000
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >More to the point, in gcc/clang memcpy is a built-in, and in VS an
> 
> Built-in doesn't mean loop free and no stack push/pops. It just means the 
> compiler doesn't have to link in code from a library but can generate it on
> the spot.

You said "memcpy has the overhead of a function call".  When used in
place of type punning it doesn't, all the code is inline, no new stack
frame is created and no call instruction is issued.  You said "Its an
extremely inefficient way to do it if you don't need the new type to be
in a seperate variable". You are completely wrong and clueless.

> >arguing with this guy: from his repetitive posts, he is either dim or a
> >dick, possibly both.
> 
> Ad Hominem seems to be a common theme from you assclowns when you can't 
> actually argue your point.

"Ad Hominem seems to be a common theme from you assclowns when you
can't actually argue your point":  a classic of its kind from you.  To
see you complain about ad hominem remarks is excellent given that:

(i) as I have previously pointed to you, almost all of your posts are
wrong.

(ii) numerous people who know far more about it than you have
explained repeatedly where and why you are wrong - the problem is not
that your correspondents don't argue the point (they do) but that you
seem unable to learn anything at all; and

(iii) in consequence, your first reflex to any post in response to one
of yours which points out your errors is to issue an insult.

[toc] | [prev] | [next] | [standalone]

#71006

Fromboltar@nowhere.org
Date2020-01-03 09:55 +0000
Message-ID<qun328$14a$1@gioia.aioe.org>
In reply to#70977
On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
>> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
>> >> 
>> >> The C++ committee seems unwilling to change the union rules and so 
>> >> instead adds a bit_cast function to package the memcpy usage with a 
>> >> slightly better name:
>> >> 
>> >> template< class To, class From >
>> >> constexpr To bit_cast(const From& from) noexcept;
>> >> 
>> >> https://en.cppreference.com/w/cpp/numeric/bit_cast
>> >
>> >Thanks, I didn't somehow even notice that. So we can throw away
>> >our own type punning wrappers around memcpy in C++20.
>> 
>> You realise using a union (or a cast) in theory uses very few CPU cycles to
>do 
>> type punning, whereas memcpy has the overhead of a function call + loop. Its
>> an extremely inefficient way to do it if you don't need the new type to be in
>
>> a seperate variable.
>
>That is the typical behavior of gibberish team. In one post it is
>"de facto" in other "in theory". I wrote:
>
>Experiments of mine and others have shown that usage of memcpy

Lets see your test code then.

[toc] | [prev] | [next] | [standalone]

#71007

FromDavid Brown <david.brown@hesbynett.no>
Date2020-01-03 11:20 +0100
Message-ID<qun4h9$kb4$1@dont-email.me>
In reply to#71006
On 03/01/2020 10:55, boltar@nowhere.org wrote:
> On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
>>> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
>>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>>> On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
>>>>>
>>>>> The C++ committee seems unwilling to change the union rules and so 
>>>>> instead adds a bit_cast function to package the memcpy usage with a 
>>>>> slightly better name:
>>>>>
>>>>> template< class To, class From >
>>>>> constexpr To bit_cast(const From& from) noexcept;
>>>>>
>>>>> https://en.cppreference.com/w/cpp/numeric/bit_cast
>>>>
>>>> Thanks, I didn't somehow even notice that. So we can throw away
>>>> our own type punning wrappers around memcpy in C++20.
>>>
>>> You realise using a union (or a cast) in theory uses very few CPU cycles to
>> do 
>>> type punning, whereas memcpy has the overhead of a function call + loop. Its
>>> an extremely inefficient way to do it if you don't need the new type to be in
>>
>>> a seperate variable.
>>
>> That is the typical behavior of gibberish team. In one post it is
>> "de facto" in other "in theory". I wrote:
>>
>> Experiments of mine and others have shown that usage of memcpy
> 
> Lets see your test code then.
> 

You could look at the code I posted for an example of identical union
and memcpy generated code.

[toc] | [prev] | [next] | [standalone]

#71008

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-03 02:21 -0800
Message-ID<dd6814cc-7b64-463b-8a86-949c78273546@googlegroups.com>
In reply to#71006
On Friday, 3 January 2020 11:55:29 UTC+2, bol...@nowhere.org  wrote:
> On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
> >> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
> >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >> >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
> >> >> 
> >> >> The C++ committee seems unwilling to change the union rules and so 
> >> >> instead adds a bit_cast function to package the memcpy usage with a 
> >> >> slightly better name:
> >> >> 
> >> >> template< class To, class From >
> >> >> constexpr To bit_cast(const From& from) noexcept;
> >> >> 
> >> >> https://en.cppreference.com/w/cpp/numeric/bit_cast
> >> >
> >> >Thanks, I didn't somehow even notice that. So we can throw away
> >> >our own type punning wrappers around memcpy in C++20.
> >> 
> >> You realise using a union (or a cast) in theory uses very few CPU cycles to
> >do 
> >> type punning, whereas memcpy has the overhead of a function call + loop. Its
> >> an extremely inefficient way to do it if you don't need the new type to be in
> >
> >> a seperate variable.
> >
> >That is the typical behavior of gibberish team. In one post it is
> >"de facto" in other "in theory". I wrote:
> >
> >Experiments of mine and others have shown that usage of memcpy
> 
> Lets see your test code then.

You first. You demonstrated lack of knowledge with the "overhead of a
function call + loop" so now please have balls to stand behind your
words of nonsense or to admit your miserable ignorance and obtain
that clue bat Mr Flibble keeps suggesting. More nonsense does not work
anymore. Besides Bo Persson and David Brown posted some and so it 
is likely waste of effort to dig out and add tests of mine as well.

[toc] | [prev] | [next] | [standalone]

#71019

Fromboltar@nowhere.org
Date2020-01-03 14:55 +0000
Message-ID<qunkkf$i7m$1@gioia.aioe.org>
In reply to#71008
On Fri, 3 Jan 2020 02:21:28 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 3 January 2020 11:55:29 UTC+2, bol...@nowhere.org  wrote:
>> On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> >On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
>> >> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
>> >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> >> >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
>> >> >> 
>> >> >> The C++ committee seems unwilling to change the union rules and so 
>> >> >> instead adds a bit_cast function to package the memcpy usage with a 
>> >> >> slightly better name:
>> >> >> 
>> >> >> template< class To, class From >
>> >> >> constexpr To bit_cast(const From& from) noexcept;
>> >> >> 
>> >> >> https://en.cppreference.com/w/cpp/numeric/bit_cast
>> >> >
>> >> >Thanks, I didn't somehow even notice that. So we can throw away
>> >> >our own type punning wrappers around memcpy in C++20.
>> >> 
>> >> You realise using a union (or a cast) in theory uses very few CPU cycles
>to
>> >do 
>> >> type punning, whereas memcpy has the overhead of a function call + loop.
>Its
>> >> an extremely inefficient way to do it if you don't need the new type to
>be in
>> >
>> >> a seperate variable.
>> >
>> >That is the typical behavior of gibberish team. In one post it is
>> >"de facto" in other "in theory". I wrote:
>> >
>> >Experiments of mine and others have shown that usage of memcpy
>> 
>> Lets see your test code then.
>
>You first. You demonstrated lack of knowledge with the "overhead of a

You made the claim so either back it up or fuck off back under your bridge.

[toc] | [prev] | [next] | [standalone]

#71022

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-03 16:04 +0100
Message-ID<qunl5b$lsi$1@news.albasani.net>
In reply to#71019
>> You first. You demonstrated lack of knowledge with the "overhead of a

> You made the claim so either back it up or fuck off back under your bridge.

I just did

#include <cstring>
#include <cstdint>

uint64_t native( double d )
{
#if defined(UNION)
	union
	{
		double   du;
		uint64_t dx;
	};
	du = d;
	return dx;
#else
	uint64_t n;
	memcpy( &n, &d, sizeof(n) );
	return n;
#endif
}

With gcc and without UNION:

_Z6natived:
	movq	%xmm0, %rax
	ret

with UNION:

_Z6natived:
	movq	%xmm0, %rax
	ret

With MSVC and without UNION:

?native@@YA_KN@Z PROC
	movsd	QWORD PTR [rsp+8], xmm0
	mov	rax, QWORD PTR d$[rsp]
	ret	0
?native@@YA_KN@Z ENDP


With UNION:

?native@@YA_KN@Z PROC
	movsd	QWORD PTR $S1$[rsp], xmm0
	mov	rax, QWORD PTR $S1$[rsp]
	ret	0
?native@@YA_KN@Z ENDP

[toc] | [prev] | [next] | [standalone]

#71054

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2020-01-03 14:45 -0800
Message-ID<quog6r$fpn$1@gioia.aioe.org>
In reply to#71022
On 1/3/2020 7:04 AM, Bonita Montero wrote:
>>> You first. You demonstrated lack of knowledge with the "overhead of a
> 
>> You made the claim so either back it up or fuck off back under your 
>> bridge.
> 
> I just did
> 
> #include <cstring>
> #include <cstdint>
> 
> uint64_t native( double d )
> {
> #if defined(UNION)
>      union
>      {
>          double   du;
>          uint64_t dx;
>      };
>      du = d;
>      return dx;
[...]

It seems like a static_assert to ensure that a double is the same size 
as a unit64_t is in order? Or native just knows what its doing, and is 
not meant to be portable?

[toc] | [prev] | [next] | [standalone]

#71065

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 01:26 +0100
Message-ID<quom3p$70t$2@news.albasani.net>
In reply to#71054
>>> You made the claim so either back it up or fuck off back under your 
>>> bridge.
>>
>> I just did
>>
>> #include <cstring>
>> #include <cstdint>
>>
>> uint64_t native( double d )
>> {
>> #if defined(UNION)
>>      union
>>      {
>>          double   du;
>>          uint64_t dx;
>>      };
>>      du = d;
>>      return dx;
> [...]

> It seems like a static_assert to ensure that a double is the same size 
> as a unit64_t is in order? ...

LOL, in that _experimental_code_ just to prove
that memcpy() is translated into efficient moves?

[toc] | [prev] | [next] | [standalone]

#71071

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2020-01-03 16:55 -0800
Message-ID<quonpj$1g5u$1@gioia.aioe.org>
In reply to#71065
On 1/3/2020 4:26 PM, Bonita Montero wrote:
>>>> You made the claim so either back it up or fuck off back under your 
>>>> bridge.
>>>
>>> I just did
>>>
>>> #include <cstring>
>>> #include <cstdint>
>>>
>>> uint64_t native( double d )
>>> {
>>> #if defined(UNION)
>>>      union
>>>      {
>>>          double   du;
>>>          uint64_t dx;
>>>      };
>>>      du = d;
>>>      return dx;
>> [...]
> 
>> It seems like a static_assert to ensure that a double is the same size 
>> as a unit64_t is in order? ...
> 
> LOL, in that _experimental_code_ just to prove
> that memcpy() is translated into efficient moves?

Color me pendant... ;^)

[toc] | [prev] | [next] | [standalone]

#71072

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 01:02 +0000
Message-ID<ruRPF.352157$af.128685@fx09.am4>
In reply to#71071
On 2020-01-04, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/3/2020 4:26 PM, Bonita Montero wrote:
>>>>> You made the claim so either back it up or fuck off back under your 
>>>>> bridge.
>>>>
>>>> I just did
>>>>
>>>> #include <cstring>
>>>> #include <cstdint>
>>>>
>>>> uint64_t native( double d )
>>>> {
>>>> #if defined(UNION)
>>>>      union
>>>>      {
>>>>          double   du;
>>>>          uint64_t dx;
>>>>      };
>>>>      du = d;
>>>>      return dx;
>>> [...]
>> 
>>> It seems like a static_assert to ensure that a double is the same size 
>>> as a unit64_t is in order? ...
>> 
>> LOL, in that _experimental_code_ just to prove
>> that memcpy() is translated into efficient moves?
>
> Color me pendant... ;^)
Not once I saw examples when compiler (gcc) returned garbage
in different scenarios. That code screams 'volatile' ;)

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web