> I don’t understand why these extra paddings are present and why one is gone. Even with pragma pack 8, should not it be only one padding?
If you're referring to `__pad2` in the example, that trailing padding is there to ensure that the size of the struct is a multiple of its alignment, which is 8, so that if there's a contiguous span of those structures, each instance after the first one will remained properly aligned.
Without `__pad2`, that struct would be 36-bytes, which would cause every other instance in an array/contiguous-span to be aligned on 4 bytes instead of 8.
In my later school years, when I had semi-regular need for printing things in colour, I took to drilling holes in the inkjet cartridges and refilling them with cheap ink using syringes.
Which worked out to about £5 for the syringes, £5 for 400 ml of CMYK ink, and my dad already had a power drill—which was equivalent to about £104-worth of black ink cartridges, and about £312-worth of colour ink cartridges. (Now it would be about £160 of black and £480 of colour).
It only took 15-to-30-minutes to refill both cartridges, including drilling the holes.
Some printer manufacturers have implemented DRM for ink to prevent this kind of thing.
Unfortunately not, I just tried running the copy included with Windows XP SP1 on Windows 11—it relies on SheRemoveQuotesW which was removed from Shell32 in Windows Vista. (It doesn't seem to be able to use a copy of a Windows-XP-sourced shell32.dll from the working directory, either).
That's because Windows 11 only comes in 64-bit flavors and Program Manager as bundled with XP would be 32-bit. WoW64[1] can't bridge 64- and 32-bit binaries in the context of system components, such as the shell.
Try running that under 32-bit Windows 10, I never tried it myself but I have a feeling it should work.
My mother cleans schools for a living, and she once remarked to me that most of the teaching staff in the grammar schools[1] she cleaned would avoid making conversation with the cleaners, and some would even avoid making eye contact, which was contrary to non-selective schools, where most of the teaching staff would make conversation with the cleaners.
[1] Grammar schools are academically-selective, state-funded schools in the UK and elsewhere—staff and students alike are generally of a higher socioeconomic milieu than in non-selective, state-funded schools.
Not initiating conversation could be down to disinterest, yes.
But I think consistently refusing eye contact does constitute a lack of respect, if the person refusing to return eye contact has no problem returning it to the upper echelons of staff.
And, having attended one of those grammar schools, I know that some of the teachers who refused to return eye contact had no issue with faux friendliness.
PowerShell yet again proves itself to be an enlightened language:
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.} = $True
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.}
True
Jesting aside, I have actually used that syntax before to prefix variable names with '&' and '@' to differentiate between virtual and physical addresses in some code for patching a binary.
Whether there's a performance detriment from borderless-fullscreen vs exclusive-fullscreen depends on how a program presents its frames (and on the OS, of course).
On Windows, under ideal circumstances borderless-fullscreen performs identically to exclusive-fullscreen as Windows will let the program skip the compositor and present its frames more-or-less directly to the display. (Under really ideal circumstances the same applies to bordered non-fullscreen windows.)
If the compositor can't be skipped, borderless-fullscreen can be a bit brutal on performance: on a 4K 160Hz screen I've experienced an additional 40-milliseconds+ of frame-latency purely from borderless-fullscreen being used.
This is something I _really_ like about D.
Unit-tests are built into the language, as is comment-based documentation—put those two together and you get unit-tests as documentation examples built into the language; all it takes is to put a documentation comment (which can be blank) right before a `unittest` block after a declaration.
I took the same "docs are tests and tests are docs" approach with integration testing when I created this library: https://github.com/hitchdev/hitchstory
I realized at some point that a test and a how-to guide can and probably should actually be the same thing - not just for doctests (https://docs.python.org/3/library/doctest.html), but for every kind of test.
It's not only 2x quicker to combine writing a test with writing docs, the test part and the docs part reinforce the quality of each other:
* Tests are more easily understandable when you attach written context - the kind that is used when generating a readable how-to guide.
* How to docs are better if they come attached to a guarantee that they're tested, not out of date and not missing crucial details.
* Integration test driven development where how-to docs are created as a side effect is really nice.
I've been using a Matias Ergo Pro Programmable for the past three-or-so years and it's been excellent; all the wrist pain I had been experiencing after typing ceased once I started using it, and that's held true since.
The switches are tactile but quiet. The keycaps are well-sized with a pleasant texture. It's very weighty, and never moves. It has arrow-keys and Home/End/PgUp/PgDn. The cable that joins the two halves is just a standard 3.5mm TRRS audio cable. The USB cable is detachable.
It does have a few flaws: the Escape key's awkwardly out-of-the-way, the same goes for the Delete key; the fabric used for the palm-rests is sort of difficult to clean; very rarely, a pressed key will get stuck and will repeat after it's been depressed.
I've also tried the Kinesis Freestyle 2... I'm much less of fond it, it might just be the worst keyboard I've used (especially relative to its price).
Its switches are bad, even by the standards of membrane switches—to get keypresses to reliably register I have mash the keys so forcefully that it ends up being louder than the mechanical Ergo Pro. The keycaps are small, with a texture that's unpleasant to the touch. The cable that joins the two halves is proprietary, and the cable that comes out of the box is too short at 9", the 20" cable costs 20% of what the keyboard does and is still too short to fully utilise the split. The USB cable isn't detachable. Something about the way the right half is laid out makes it difficult to get your hand in position to use it. The Escape key's really out-of-the-way, as is the Fn key.
Though, it does have a lot of macro keys.
If you're referring to `__pad2` in the example, that trailing padding is there to ensure that the size of the struct is a multiple of its alignment, which is 8, so that if there's a contiguous span of those structures, each instance after the first one will remained properly aligned. Without `__pad2`, that struct would be 36-bytes, which would cause every other instance in an array/contiguous-span to be aligned on 4 bytes instead of 8.