- A question about if constexpr - 1 Update
- issues with std::variant - 1 Update
- What does the "L" mean - 20 Updates
- "Microsoft Exploring Rust as the Solution for Safe Software" - 2 Updates
- popup with timeout question - 1 Update
| boltar@nowhere.co.uk: Dec 04 04:49PM On Tue, 3 Dec 2019 18:03:41 +0000 >no >> one else gives a rats arse. >You just contradicted yourself, dear. No, its my accurate opinion that no one else gives a damn. |
| wtholliday@gmail.com: Dec 04 08:37AM -0800 I'm using std::variant in my code for one very important type (`Node`). This variant has 68 different types in it. There are two issues: 1. Compile times are extremely slow (~30s per file), due to variant visitation. I'm an indie developer and I don't want to have to buy a new computer (might only be a factor of two faster anyway). 2. If I hire a contractor to help, they might be baffled by the c++ fancyness, such as: Node setExposedPosition(Node node, Vec2 p) { std::visit(overloaded { [p](auto& n, decltype(n.exposedPosition)* = nullptr) { n.exposedPosition = p; }, [](auto&...) { } }, node); return node; } (This kind of stuff is all over the place, because it eliminates a LOT of redundant code) Now that's pretty cool pattern matching, but let's face it, this would be much more understandable: Node setExposedPosition(Node node, Vec2 p) { if(hasField(node, EXPOSED_POSITION_BIT)) { node.exposedPosition = p; } return node; } I've found that if I simply make Node a struct with every possible data member from all the variant types, it only increases the size of Node by a factor of two, which is totally fine. (I could use std::optional for each member, but that would increase the size, and potentially be more dynamic than I need) Does that sound like the approach you would take? thanks! |
| T <T@invalid.invalid>: Dec 03 11:38PM -0800 Hi All MB_ICONEXCLAMATION 0x00000030L What does the "L" at the end mean? Many thanks, -T |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 04 08:43AM +0100 Am 04.12.2019 um 08:38 schrieb T: > MB_ICONEXCLAMATION > 0x00000030L > What does the "L" at the end mean? It means that the integral literal is a long. |
| T <T@invalid.invalid>: Dec 04 12:05AM -0800 On 2019-12-03 23:43, Bonita Montero wrote: >> 0x00000030L >> What does the "L" at the end mean? > It means that the integral literal is a long. 64 bit integer? |
| Geoff <geoff@invalid.invalid>: Dec 04 12:32AM -0800 >>> What does the "L" at the end mean? >> It means that the integral literal is a long. >64 bit integer? No. It has 8 hexadecimal digits and they are 4 bits each. 8 x 4 = 32 last I checked. |
| T <T@invalid.invalid>: Dec 04 12:33AM -0800 On 2019-12-04 00:32, Geoff wrote: >> 64 bit integer? > No. It has 8 hexadecimal digits and they are 4 bits each. > 8 x 4 = 32 last I checked. Cool. Thank you! |
| T <T@invalid.invalid>: Dec 04 12:34AM -0800 On 2019-12-03 23:43, Bonita Montero wrote: >> 0x00000030L >> What does the "L" at the end mean? > It means that the integral literal is a long. Thank you! |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Dec 04 09:39AM +0100 Op 04.dec..2019 om 09:05 schreef T: >>> What does the "L" at the end mean? >> It means that the integral literal is a long. > 64 bit integer? It means "long". The size of long depends on your platform. |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 04 10:40AM +0200 On 4.12.2019 10:05, T wrote: >>> What does the "L" at the end mean? >> It means that the integral literal is a long. > 64 bit integer? Depends on the platform/implementation. In this case the constant is from Windows headers, and in Windows/MSVC a long is 32-bit even in 64-bit Windows. This is basically so because long happened to be 32-bit in 16-bit DOS 35 years ago, and MS used it a lot instead of 16-bit int (which was indeed unusable for many purposes). As a result, now they cannot change 'long' to 64-bit because they have abused it so much. |
| T <T@invalid.invalid>: Dec 04 12:51AM -0800 On 2019-12-04 00:39, Fred. Zwarts wrote: >>> It means that the integral literal is a long. >> 64 bit integer? > It means "long". The size of long depends on your platform. Thank you! |
| T <T@invalid.invalid>: Dec 04 12:56AM -0800 On 2019-12-04 00:40, Paavo Helde wrote: > years ago, and MS used it a lot instead of 16-bit int (which was indeed > unusable for many purposes). As a result, now they cannot change 'long' > to 64-bit because they have abused it so much. Great explanation. Thank you! In Perl6 , we have: int8 (int8_t in C) int16 (int16_t in C) int32 (int32_t in C) int64 (int64_t in C) $ p6 'my int64 $x=0xF; say $x;' 15 $ p6 'my int64 $x=0xFFFFFFFFFFFFFFF; say $x;' 1152921504606846975 $ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;' Cannot unbox 64 bit wide bigint into native integer in block <unit> at -e line 1 |
| Bo Persson <bo@bo-persson.se>: Dec 04 10:08AM +0100 On 2019-12-04 at 09:56, T wrote: > $ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;' > Cannot unbox 64 bit wide bigint into native integer > in block <unit> at -e line 1 Some languages historically also target more exotic hardware, so in C (and C++) int and long are allowed be 36 bits instead of 16 and 32 https://stackoverflow.com/a/6972551 Bo Persson |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 04 11:11AM +0200 On 4.12.2019 10:32, Geoff wrote: >> 64 bit integer? > No. It has 8 hexadecimal digits and they are 4 bits each. > 8 x 4 = 32 last I checked. Does not follow. 0x30L is not 8 bits even though it has 2 hex digits only. The reason why MB_ICONEXCLAMATION is written with 8 hex digits is because MS programmers *thought* long is always 32 bits. |
| Geoff <geoff@invalid.invalid>: Dec 04 01:14AM -0800 On Wed, 04 Dec 2019 11:11:20 +0200, Paavo Helde >Does not follow. 0x30L is not 8 bits even though it has 2 hex digits only. >The reason why MB_ICONEXCLAMATION is written with 8 hex digits is >because MS programmers *thought* long is always 32 bits. I agree. They were signaling to themselves to expect 32 bits. Serves me right for being a smart ass about it. :) |
| T <T@invalid.invalid>: Dec 04 01:20AM -0800 On 2019-12-04 01:08, Bo Persson wrote: > (and C++) int and long are allowed be 36 bits instead of 16 and 32 > https://stackoverflow.com/a/6972551 > Bo Persson 36 bit? My brain hurts |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 04 01:47PM +0100 >>> What does the "L" at the end mean? >> It means that the integral literal is a long. > 64 bit integer? Forget it, these suffixes are mostly useless as the compiler can determine the type from the value. |
| Thiago Adams <thiago.adams@gmail.com>: Dec 04 04:57AM -0800 On Wednesday, December 4, 2019 at 9:47:55 AM UTC-3, Bonita Montero wrote: > > 64 bit integer? > Forget it, these suffixes are mostly useless as the compiler can > determine the type from the value. In C we have macros to expand to the corresponding size. For instance UINT64_C(0x123) might expand to the integer constant 0x123ULL. |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Dec 04 02:41PM +0100 Op 04.dec..2019 om 13:47 schreef Bonita Montero: >> 64 bit integer? > Forget it, these suffixes are mostly useless as the compiler can > determine the type from the value. The suffixes can be very important, in particular if the macros are later used in operations. Take as an example a platform where int is 16 bits and long is 32 bits. #define V1 0X7EEE #define V2 0X7EEEL #define R1 (2 * V1) #define R2 (2 * V2) Then the result of R1 is undefined because of an integer overflow, whereas R2 is defined. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 04 08:55AM -0500 Op 04.dec..2019 om 13:47 schreef Bonita Montero: >> 64 bit integer? > Forget it, these suffixes are mostly useless as the compiler can > determine the type from the value. The whole point of the suffixes is cope with the possibility (which occurs pretty frequently) that the type that is determined by the value differs from the one you want the constant to have. A cast can be more specific, but a suffix is more convenient, when it's sufficient to do what you want. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 04 03:06PM +0100 > #define R2 (2 * V2) > Then the result of R1 is undefined because of an integer overflow, > whereas R2 is defined. I wrote "mostly useless" and not "useless every time". |
| Keith Thompson <kst-u@mib.org>: Dec 04 08:28AM -0800 > MB_ICONEXCLAMATION > 0x00000030L > What does the "L" at the end mean? The type of a hexadecimal integer literal with an "L" suffix is of the first of long int unsigned long int long long int unsigned long long int in which its value will fit (C++11 2.14.2 [lex.icon]). Since long int is guaranteed to be at least 32 bits, 0x00000030L is of type long int. The leading 0s are presumably intended to imply a 32-bit quantity, which is probably the case for the system for which the code is intended, but it's not guaranteed. (64-bit Linux-based systems usually have 64-bit long; on such systems 0x00000030L is 64 bits. It's *always* of type long int under any conforming implementations.) Leading zeros are ignored. 0x00000000000000000000000000000030L is equivalent to 0x00000030L. A conforming implementation could make long int any size 32 bits or wider. The size in bits is a multiple of CHAR_BIT, which is at least 8. An implementation could have 33-bit long int; on such a system characters would have to be either 11 or 33 bits. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 03 05:05PM -0800 On 12/2/2019 9:03 PM, Cholo Lennon wrote: > I've already seen this several times... a company needs to have the > control of the tool (Microsoft/VisualBasic/VisualJ/C#/TypeScript/F#, > Sun/Java, Google/Go/Dart, JetBrains/Kotlin, etc) Microsoft/Q# https://en.wikipedia.org/wiki/Q_Sharp ;^) |
| Stuart Redmann <DerTopper@web.de>: Dec 04 02:32PM +0100 > P.S. People often talk as if C# was invented by itself, as a standalone > language. In fact, C# is just one member of the .NET/CLR family. I think > of VB.NET as the primary .NET language. I suppose C# comes next after VB. Note that MS also made the integration of unmanaged C++ code into the managed DotNet world very simple, something that is much harder to achieve with Java (co-workers of mine constantly struggle with this, whereas I enjoy the easy C++/CLI coding :-) IMHO, this makes C# more than just a Java clone. I have done three large projects (> 100kLOC) with C++/C#, and I enjoyed it very much. Regards, Stuart PS: I was lying a little bit. When my managed C++ libraries wouldn't load because boost::thread uses TLS somewhere inside, I spent an awful great amount of time figuring this out :-/ |
| Geoff <geoff@invalid.invalid>: Dec 04 01:19AM -0800 >> box. >That explains it. Thank you! >I am spoiled by Linux's send-notify. Keeping in mind that this is off topic for this group. Here's a simple About box in C that might help. This will work if your timed box has only one button and closes on receipt of a WM_COMMAND and doesn't have to handle any other buttons. BOOL CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_INITDIALOG: SetTimer(hDlg, 1, 5000, NULL); return (TRUE); break; case WM_TIMER: SendMessage(hDlg, WM_COMMAND, NULL, NULL); return(TRUE); break; case WM_COMMAND: KillTimer(hDlg, 1); EndDialog(hDlg, TRUE); return (TRUE); break; } return (FALSE); } |
| 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