Re: Do Microsoft?s Copilot+ PCs Require Linux?

rbowman wrote this copyrighted missive and expects royalties:

On Tue, 28 May 2024 14:36:37 -0400, Joel wrote:
>

I would use the features of CPP that are not OOP, but otherwise, regular
C is all one needs, aside from minor things only assembly can do
(largely OS core/device drivers).

I once tried, as an experiment, writing an audio player using straight
C and unions to do "inheritance".

Once was enough.

Sometimes C is enough, though. Or sometimes one is forced to use a C-only
library or wrap C++ code in 'extern "C"' interfaces.

Other than Esri stuff my C++ looks a lot like C but then so does
Stroustrup's in the edition I have. Esri's ArcObjects is COM based so they
make extensive use of smart pointers. It took me a while to get used to

COM... bleh.

IFeaturePtr pFeature;
IGeometryPtr pGeometry;
ICurvePtr pCurve;
....
pFeature->get_Shape(&pGeometry);
pCurve = pGeometry
>
The first one makes sense. There is a bunch of variant and BSTR mumbo-
jumbo that goes with COM but pFeature->get_Value(someField) works like you
would thing but there is no pFeature->get_Curve), only the magical
assignment instead of even pGeometry->get_Curve(&pCurve);
>
The docs weren't that great so it was often 'okay, I've got this, not how
the hell do I get that?'
>
The other problem with C++ for me was the awkward way it was hatched that
let Microsoft fill in the blanks so you have things like String and
string.

Yeah, Qt jumped into the breech with things like QString. I make sure that
the public interfaces use C++ standard types, and convert to stuff like QString
internally only where necessary... I have a little function named qt() for that.
It's only in the GUI, so the performance hit is insignificant.

--
Q: What's a light-year?
A: One-third less calories than a regular year.