- Std::any vs std::optional - 13 Updates
- My Parallel Compression Library was just updated to version 4.32 - 1 Update
- Amine Moulay Ramdane - 1 Update
- Let's call the <=> operator "trike" because of the math term - 1 Update
- Read again, i correct a typo - 2 Updates
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 13 12:56AM +0100 On Sat, 12 May 2018 01:44:43 GMT > std::any is variant, and std::optional would better be replaced by future > addition of tagged unions as in Rust eg ADT's in functional languages. > They started with decomposition of tuples, next are tagged unions ;) C++ already has discriminated unions (aka sum types). It's called std::variant. |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 06:03AM >> They started with decomposition of tuples, next are tagged unions ;) > C++ already has discriminated unions (aka sum types). It's called > std::variant. It's not built in into the language so you need std::optional,std::any ... ;) Anyway, what is difference between std::any and std::variant? -- press any key to continue or any other to quit... |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 13 10:36AM +0100 On Sun, 13 May 2018 06:03:24 GMT > On 2018-05-12, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > > On Sat, 12 May 2018 01:44:43 GMT > > Melzzzzz <Melzzzzz@zzzzz.com> wrote: [snip] > It's not built in into the language so you need std::optional,std::any > ... ;) > Anyway, what is difference between std::any and std::variant? std::variant, std::optional and std::any are all provided in the standard library for C++17, so I am not clear what you mean that std::variant is 'not built in into the language so you need std::optional, std::any ...'. std::variant is a perfectly normal sum type or discriminated union. There is nothing much more to be said about it, except that pattern matching on it is possible using function overloading with std::visit but is inconvenient. std::optional is a normal Maybe or Option type. std::any is somewhat odd. It seems to be a means of introducing dynamic typing to C++ of the python/javascript/lisp kind, and as such I can see it could have its uses: in particular, it does enable you to have heterogenous C++ containers. It has a type operator which returns a std::type_info object describing its contents, and an any_cast access operator which throws an exception if the typeid of the contained object is not the type requested by the cast; so to that extent it is a safer version of void* with type introspection. I don't use any of these because I write code which depends on C++11/14 but not C++17. From C++11 it is not that difficult to construct discriminated (tagged) unions yourself, and I have my own home-grown option class. Chris |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 12:03PM > but not C++17. From C++11 it is not that difficult to construct > discriminated (tagged) unions yourself, and I have my own home-grown > option class. Problem with tagged unions, that are not built into language, is in optimisation: tag cannot be optimized out as in Haskell or Rust. -- press any key to continue or any other to quit... |
| Sam <sam@email-scan.com>: May 13 08:52AM -0400 Melzzzzz writes: > Problem with tagged unions, that are not built into language, is in > optimisation: tag cannot be optimized out as in Haskell or Rust. Do not underestimate a modern C++ compiler's ability to optimize away various things. |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 01:57PM >> optimisation: tag cannot be optimized out as in Haskell or Rust. > Do not underestimate a modern C++ compiler's ability to optimize away > various things. Struct member cannot be optimised out. -- press any key to continue or any other to quit... |
| David Brown <david.brown@hesbynett.no>: May 13 05:11PM +0200 On 13/05/18 15:57, Melzzzzz wrote: >> Do not underestimate a modern C++ compiler's ability to optimize away >> various things. > Struct member cannot be optimised out. Do not underestimate a modern C++ compiler's ability to optimize away various things. Sometimes the compiler /can/ optimise away struct members. Perhaps not in as many situations as for some languages and tools, but compilers can do a lot if they have the information available. |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 03:23PM > Sometimes the compiler /can/ optimise away struct members. Perhaps not > in as many situations as for some languages and tools, but compilers can > do a lot if they have the information available. Sometime is not same as sizeof (somestruct) == 8 instead of 16 or 12... -- press any key to continue or any other to quit... |
| David Brown <david.brown@hesbynett.no>: May 13 05:58PM +0200 On 13/05/18 17:23, Melzzzzz wrote: >> in as many situations as for some languages and tools, but compilers can >> do a lot if they have the information available. > Sometime is not same as sizeof (somestruct) == 8 instead of 16 or 12... True. But languages with built-in tagged unions also need a field to store the type if they can't optimise it away. There is little difference. |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 05:55PM >> Sometime is not same as sizeof (somestruct) == 8 instead of 16 or 12... > True. But languages with built-in tagged unions also need a field to > store the type if they can't optimise it away. There is little difference. Another case for introducing tagged unions in language: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf -- press any key to continue or any other to quit... |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 13 03:27PM -0400 On 05/13/2018 11:23 AM, Melzzzzz wrote: > On 2018-05-13, David Brown <david.brown@hesbynett.no> wrote: >> On 13/05/18 15:57, Melzzzzz wrote: ... >> in as many situations as for some languages and tools, but compilers can >> do a lot if they have the information available. > Sometime is not same as sizeof (somestruct) == 8 instead of 16 or 12... A compiler is free to remove a struct member if it can do so without preventing the observable behavior of your program from matching one of the permitted behaviors allowed by the standard for your program. I wouldn't dare assume that I could list all of the things that need to be true in order for that to be feasible, but one of them is, for example, that the observable behavior of your program shouldn't depend upon the result of applying sizeof to the struct type. |
| woodbrian77@gmail.com: May 13 02:43PM -0700 On Sunday, May 13, 2018 at 2:27:17 PM UTC-5, James Kuyper wrote: > true in order for that to be feasible, but one of them is, for example, > that the observable behavior of your program shouldn't depend upon the > result of applying sizeof to the struct type. Is there a way to get a compiler to tell you that it's removing a class member? I'd like to know about it so I can either remove the member myself or disable the optimization. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 13 10:46PM +0100 On Sun, 13 May 2018 12:03:14 GMT Melzzzzz <Melzzzzz@zzzzz.com> wrote: [snip] > Problem with tagged unions, that are not built into language, is in > optimisation: tag cannot be optimized out as in Haskell or Rust. OK, I see your point. However, pattern matching on a variant is in most cases a runtime operation. Some form of type identification or tagging is therefore required even in the case of the languages which have sum types built in. Since most functional languages allocate their non-immediate objects on a garbage collected heap, this may (and usually does) involve allocating objects on 8 byte boundaries and using the redundant lower bits of the address for type information ("pointer tagging"). However, there is nothing to stop C++ implementations doing the same. If they do not, it is probably for good efficiency reasons, trading an extra 4 bytes for more speed (say, in enabling allocation of local objects on the stack). |
| Sky89 <Sky89@sky68.com>: May 13 08:42PM -0400 Hello, My Parallel Compression Library was just updated to version 4.32 I have posted here because it works with C++Builder.. Now when you instantiate an object, it is now thread-safe to compress and decompress using my efficient Threadpool that is NUMA efficient, and my Parallel Compression Library is NUMA efficient on Windows, because it parallelizes the read and write of memory on the NUMA nodes, so it is very powerful, and my Parallel archiver is also NUMA efficient like that, the other Parallel libraries are not NUMA efficient like my Parallel Compression Library and my Parallel archiver. I think i will enhance more my Parallel Compression Library to support encryption and i will sell it to Embarcadero software company that sells C++Builder and Delphi, because my Parallel Compression Library works with C++Builder and Delphi and FreePascal, and it works on Linux and Windows and i can easily port it to other operating systems. You can download my Parallel Compression Library from: https://sites.google.com/site/aminer68/parallel-compression-library Thank you, Amine Moulay Ramdane. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 11:20AM +0200 Am 04.05.2018 um 04:10 schrieb Real Troll: > Can somebody arrange to send him the meds because it looks like he has > run out of them and his country can't afford to import from the > developed countries. I agree. He seems to be manic and has to be put on appropriate medication. |
| legalize+jeeves@mail.xmission.com (Richard): May 13 03:03AM [Please do not mail me a copy of your followup] Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code >But neither am I going to jump on anything new that gets standardized >as part of C++, when I already have a mechanism that I know, and >that's already standardized on the platforms I care about. For most library features, they've evolved from features already implemented as libraries and having had widespread use. Many C++11 (and later) library editions were migrations from boost, such as shared_ptr, thread, and filesystem. This is one of the things that disturbs me about the 2D graphics effort; they are creating a proposal from something without having widespread use of it in the proposed form. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 13 12:46AM +0100 On 13/05/2018 02:48, Sky89 wrote: > Hello... > Read again, i correct a typo Why do you repeatedly do this? Why do you re-post because you want to "correct a typo" when nobody cares? Nobody else "corrects" typos in Usenet posts in this way because it just adds noise you demented fuckwit. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne 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." |
| Dan Purgert <dan@djph.net>: May 13 12:09AM Mr Flibble wrote: > Why do you repeatedly do this? Why do you re-post because you want to > "correct a typo" when nobody cares? Nobody else "corrects" typos in Usenet > posts in this way because it just adds noise you demented fuckwit. Well, at least my suspicions have been confirmed about him ... -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment