1

Keen to use stringstream on an STM32 for handling data that gets sent over various UART connections to radio modules (wifi, BLE, Zigbee, etc). I am running FreeRTOS, if that matters. Very concerned about the dynamic memory allocation in the STL lib causing unhandled overflows (I have to have "-fno-exceptions"). I can handle buffer overruns myself in a simple writer method, so that isn't an issue, but I want to be certain that the stringstream never tries to increase it's memory beyond a pre-set limit.

Currently I just use char* buffers, but, I want to find a better solution.

I want to be able to do something like this.

#include <sstream>      // std::stringstream

class Wifi
{
public:
    std::stringstream* ss;

    Wifi()
    {
        ss.set_max_size(1024); // 1kB
    }
};

TIA

Eliahu Aaron
  • 4,103
  • 5
  • 27
  • 37
GreenaGiant
  • 73
  • 9
  • Maybe [this](https://stackoverflow.com/a/22025719/10927863) answer can help – Eliahu Aaron Jul 30 '19 at 13:36
  • Yes smashing. That means I can use the reserve() method. Much appreciated. Feel free to put as an answer so I can give you the proper credit. Cheers – GreenaGiant Jul 30 '19 at 16:16
  • 1
    Turns out that doesn't work in that you don't have access to the underlying string so you can't use the capacity() method, nor the shrink_to_fit() method. :-( – GreenaGiant Jul 30 '19 at 18:51
  • 1
    Basic stringstreams have an allocator template argument. You could try making an allocator that never allocates beyond a boundary, but if I read the [requirements](https://en.cppreference.com/w/cpp/named_req/Allocator) correctly, it relies on exceptions to communicate errors. – PaulR Aug 05 '19 at 08:28
  • 1
    I also wanted a better, more modern solution. I've been developing for embedded devices for ...a while and always avoided heavy string and streams. Recently came across Stroustrup's "convert an integer to a string" advice: www.stroustrup.com/bs_faq2.html#int-to-string so I tried just adding `std::stringstream ss;` line into the code and linker told me `region 'FLASH' overflowed by 77328 bytes` (with STM32CubeIDE defaults) ... code size went from 69kB to 203kB... on a 128kB flash controller... NO thanks! Nice Zero-overhead principle guys. Good luck to you. I will keep avoiding sstream header. – Steven Spark Apr 26 '23 at 19:44
  • The zero overhead principle is incredibly misleading because it is correct for the language but many libraries are incredibly heavy on flash memory. Maybe modules might help but I'm not holding my breath for a "from X import y" type python solution, so you only get what you need – GreenaGiant Apr 27 '23 at 21:28

0 Answers0