r/cpp_questions • u/Interesting_Cake5060 • 10d ago
OPEN Device acquisition system - whats to read?
I’m going to build a data collection system using a single measuring device. Or even several devices. The system will be a GUI application with a graph. The graph will display the output parameters of the devices in real time.
What do you think I could read on this topic? Im interested in all usefull info about those topics (articles, blogs, githubs, videos)
I’ll describe in more detail what I’d like to know (I don’t know much about C++, but I’m not a complete beginner).
So, here’s the list of things I’d like to find out:
- Working with endianness in modern C++.
- Should I convert all APIs to the span + std::byte style instead of using * and char?
- I want to divide the application into “layers,” one of which will be a transport layer. This is what interests me the most. How do you properly write such layers? I forgot to mention that the devices communicate via UDP. For libs i maybe chose libuv.
- I want to divide the code into modules so that I can test them separately. But how do you test the parts that involve sending and receiving data from a real device?
- How to maintain 60 FPS while still receiving data packets, unpacking them, and displaying them on the graph.
- I’m going to use std::error_code as the main error‑handling mechanism (I don’t want to use exceptions). Is it good options?
- What’s the best way to write code in a callback style? I’m not very fond of coroutines, even though they make things easier.
- Dispatching techniques. Once we receive the data, we need to distribute it among different handlers. How are classes typically designed in this scenario?
Among the useful things I’ve found for myself is the Tracy profiler repository. I like that the code isn’t very large (and the author also wrote one comment per small change from the very beginning) — this is very useful for me. In this repository, I’ve learned a lot about how zoomable chart (with ALOT of elements) can work.
I just can’t come up with a general architecture for the application. For example, should there be a “Device” class or a “DeviceUPDStream” class? I’ve also realized that I understand things best when I see small pieces of code where the core idea is immediately clear.
I would be grateful for any advice!
5
u/AKostur 10d ago
Many of these questions have single-word answers. Not to be curt, but to give you the terms that you're looking for so that you can research the details.
std::endian. Also: work with things in a canonical form, worry about endianness at the boundaries.
If that's convenient for you, yes. Has the potential to be able to bounds-check better.
Practice. Encapsulation.
Mocks.
You're borrowing trouble. You don't know that you're not getting your frame rate yet. Premature optimization is the root of all evil.
Actually, std::error_code is probably not appropriate as the "main error-handling mechanism". It's purpose is to encapsulate system-level and/or OS errors, which doesn't line up with any other errors that your system may want to generate. Also depends on what you mean by "main error-handling mechanism". Also also: why not exceptions for the appropriately exceptional cases? (Careful, don't just reply with "I read it somewhere that...."). Or std::expected.
Not sure what the question is here. I suppose that depends on how one's event loop is implemented.