The ring buffer is the tool of champions. But confining yourself to C++98 is just masochism. Just because we're embedded doesn't mean we can't have nice things.
Right, I'm using the most recent C++ standard via GCC on STM32 parts now.
Show HN: Embedded Ring Buffer C++98
11–20 of 41 posts
Re: Show HN: Embedded Ring Buffer C++98
#12Don't use "NULL" in C++[1]. [1] https://cpp4arduino.com/2018/10/26/why-cpp-programmers-dont-...
From the article:
> Are there any drawbacks to using nullptr instead of NULL? No, unless you target old compilers that don’t support C++11, which is very unlikely.
and OP is specifically targeting c++98.
Re: Show HN: Embedded Ring Buffer C++98
#13> memset(data, 0, LENGTH); >// ... > T data[LENGTH]; I'm not sure how important it is in practice, but I'm pretty sure you don't zero out the whole array for sizeof(T) > 1. Anyhow, memsetting to 0 a complex type is... not something I'd recommend in most cases.
Ouch, yeah. They need std::fill(). This is the kind of thing that makes you lose faith in a C++ library. (Also, what's with the volatile private variables?!)
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time.
I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile.
To write, you put the value in the array, and then advance the write position. To read, you copy a value out, and then advance the read position. Volatile ensures that if a read is interrupted by a write or vice versa, the entire operation is still atomic. Without volatile, the compiler has more freedom to reorder memory access.
Re: Show HN: Embedded Ring Buffer C++98
#14Earlier quoted context omitted.
Ouch, yeah. They need std::fill(). This is the kind of thing that makes you lose faith in a C++ library. (Also, what's with the volatile private variables?!)
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time. I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile. To write, you put the value in the array, and then advance the write position. To read, you copy a va…
Oh I see. Didn't realize they're assuming 1 reader/1 writer. Thanks!
Re: Show HN: Embedded Ring Buffer C++98
#15Earlier quoted context omitted.
Ouch, yeah. They need std::fill(). This is the kind of thing that makes you lose faith in a C++ library. (Also, what's with the volatile private variables?!)
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time. I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile. To write, you put the value in the array, and then advance the write position. To read, you copy a va…
Unfortunately the compiler can still reorder nonvolatile operations across volatile ones, so unless the buffer is also volatile, it is not as useful as one would expect.
Re: Show HN: Embedded Ring Buffer C++98
#16Earlier quoted context omitted.
Ouch, yeah. They need std::fill(). This is the kind of thing that makes you lose faith in a C++ library. (Also, what's with the volatile private variables?!)
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time. I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile. To write, you put the value in the array, and then advance the write position. To read, you copy a va…
Assuming pre-C++20 semantics, which were anyway compiler specific.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...
Re: Show HN: Embedded Ring Buffer C++98
#17Earlier quoted context omitted.
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time. I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile. To write, you put the value in the array, and then advance the write position. To read, you copy a va…
Assuming pre-C++20 semantics, which were anyway compiler specific. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...
Do you know which of these proposed changes is actually happening? I don't think all of them are, right?
Re: Show HN: Embedded Ring Buffer C++98
#18Earlier quoted context omitted.
The use of volatile is typical here. It allows the ring buffer to be used from interrupts, as long as you have one reader and one writer at a time. I haven't checked the code for correctness, but in a typical ring buffer implementation intended to be used in interrupts, you would make the read and write pos volatile. To write, you put the value in the array, and then advance the write position. To read, you copy a va…
Assuming pre-C++20 semantics, which were anyway compiler specific. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...
With one exception, the relevant details aren't really compiler-specific, and C++20 keeps the relevant parts... if you perform two operations on volatile values, the operations can't be reordered, because the spec says so.
> Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
Not the best, clearest, most useful part of the C++ spec but the core concept is there... if you perform operation A on a volatile object, then perform operation B on a volatile object, the emitted code must perform A before B. To my knowledge, this part of the C++ standard hasn't even changed wording in C++20, and isn't deprecated either.
The compiler-specific parts are things like:
1. Is this a compiler fence? (If no, the buffer in a ring buffer must also be volatile.)
2. Is this a memory fence?
3. Is there some platform-specific way in which operations on volatile objects are different?
The part you do need to know is if the operation will tear.
Re: Show HN: Embedded Ring Buffer C++98
#19Don't use "NULL" in C++[1]. [1] https://cpp4arduino.com/2018/10/26/why-cpp-programmers-dont-...
What else then? In c++11 you would of course use nullptr_t, but the OP code is pre-c++11.
GCC used to use a magic builtin in pre C++11 to implement NULL, but IIRC they removed it as non-conforming.
Re: Show HN: Embedded Ring Buffer C++98
#20Earlier quoted context omitted.
Assuming pre-C++20 semantics, which were anyway compiler specific. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...
With one exception, the relevant details aren't really compiler-specific, and C++20 keeps the relevant parts... if you perform two operations on volatile values, the operations can't be reordered, because the spec says so. > Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine. Not the best, clearest, most useful part of the C++ spec but the core concept is there...…
[deleted]