> 2x memory looks like a naive implementation of just allocating an std::string from heap for each line. Due to heap fragmentation and various overhead it would quickly blow up.
Looks more line Qt's internal UTF-16 encoding in this case.
Keyboard-wedge is only one of a dozen ways a barcode scanner can send data. Most also have legacy serial interfaces for use with old POS systems, so you have scantags that enable and disable those, and configure the baud rate, start bits, stop bits, parity bits, flow control (like a dozen different types), minimum idle time between subsequent codes, etc. And some of the old stuff isn't exactly ASCII, like there are systems that operate in MSI/Plessey mode which is all sorts of martian. It has its own whole config tree. I don't even remember how Nixdorf mode works, I never had to deal with it.
And even within USB, sometimes you emulate a HID keyboard and send scancodes, sometimes you enumerate as an actual USB HID barcode scanner (that's a dedicated device class), sometimes you emulate a USB CDC serial device and inherit all the serial config from above minus the baud rate. Oh, and sometimes you can configure the USB polling interval for performance.
Do you start with a special key/character to signal that a barcode is coming, or just begin vomiting digits into wherever the cursor happens to be? Pad shorter codes with leading zeroes? Do you send CR or LF at the end, perhaps both? Or some other key/character like tab?
Oh and keep in mind that some barcodes can do alpha characters too. Which keyboard layout are you emulating, because the whole world isn't US-English? Convert to upper or lower case? Filter characters? Send a different start-character to indicate that an alpha code is coming?
And then you've got the symbology selection. There are hundreds of different types of barcodes, and they're used for different things. Have you ever scanned a box and the scanner picked up a barcode from the shipping label rather than the UPC? That's because whoever set up the POS didn't disable the other symbologies. They should have. So there are config variables for all that. Even just the UPC/EAN/JAN family has a dozen subvariants, and some POS systems want a prefix to indicate which variant is coming down the wire.
Then there's scan tuning. How many times does the laser/imager need to read the code before it considers it good? Crank this up to increase confidence, crank it down to favor speed. How much "dead time" should the reader take after scanning one code before it can scan another code? How much should it have before it can scan the SAME code again? Picture the way a clerk whips products across the scan window and try to tune it so you can easily scan multiples of an identical product, without scanning the very same item twice if it remains within the window too long.
Newer scanners also have tunables for recognizing barcodes displayed on LCDs since customers now sometimes present coupons on their phone screens. That's its own whole can of worms and largely newer than my time in the industry so I don't know the specifics, but again it's a performance tradeoff depending on the situation.
There's also minimum and maximum distance and apparent line width, which can help in certain handheld situations (think of the handheld style used at convenience store counters) where it otherwise might pick up distant products on the counter by mistake. But sometimes you might want to be able to scan things from a few feet away, so that's configurable.
Then you've got UX variables. Beep after a good read? Configure pitch, duration, and volume. Different beep/tone for error? All of the above again. Turn the feedback LED(s) green/red for those statuses? Or does green mean "ready for scan", like at self-checkouts? Scanner always active, or only when activated by button push (handheld) or proximity sensor (pedestal) or scale (checklane)? Or active only when DTR line high (serial)? Timeout after activation if no valid read? There's so much more, this only scratches the surface.
Finally, all these config variables can be stored, recalled, defaulted, protected, and unprotected.
In the Challenger case, the bad information has been deliberately hidden within the structure. They could just as well have pulled it up in the structure.
It's like saying variable font sizes are inherently bad because due to them, contracts can have small print sections.
That would be nice, then I wouldn't have to use non-standard stuff.
I made my own easy-to-incorporate-into-any-project library - https://github.com/lelanthran/libds - just copy the ds_*.h and ds_*.c into a project and you're good to go.
I'm not saying it will work for you, but it works for me.
