Maximum size supported for strstream array

As Sara has alluded, strstream is a deprecated feature in C++, you should be using stringstream.
http://www.cplusplus.com/reference/iostream/stringstream/

Apart from the fact you will find most compilers have no (or limited) support for strstream, it is also a fundamentally flawed class (it has many buffer ownership issues that can lead to hard to diagnose and fix issues)

Just to add to above,  I have found some compilers have long standing bugs in the implementation for strstream, and they have no plans to fix it, because the class is deprecated.

So if you use it, you're using a class that is deprecated, functionally flawed, and most likely has bugs in the implementation.

Sara demonstrated a needed attention to the detail that I included in my original post, which other responders did not. I specifically asked not to vector off into a discussion about stringstream. Those reading and replying to this thread should consider that there are special applications out there besides general desktop applications and these special cases are not even dealing with heap memory, but instead perhaps POSIX shared memory mappings or memory on devices such as IP modules installed in IP carrier cards that have memory mapped into the virtual memory space.  Only strstream is usable in such cases for mapping that memory to a stream device. I don't believe it is correct to state that compilers don't support strstream because it is deprecated. I would like to have specific cased provided in response if you believe otherwise. Stringstream is not a direct replacement for strstream functionality. Stringstream addresses only addresses a specific case of mapping strings to streams. It is unfortunate that such a narrow thinking was applied when the decision to deprecate strstream occurred. It should have been fixed and stringstream added as special case for strings.

Excellent attention to detail on Sara's part. Note that the other responders did just what I asked them not to, vector off on a stringstream discussion. For follow-on readers, it is important to understand why strstream is valuable for special cases where the memory being accessed as a stream is not a simple character array in memory. Special cases such as shared memory and mapped peripheral devices should not be forgotten. Too bad that was not consedered when they decided to deprecate strstream.

you told you don't want to run into a discussion using stringstream, so i will make it short. i used the strstream in a few projects (about 10 years ago) and moved to stringstream for all of them later. i don't remember how much efforts it has made but it must have been near to nothing or otherwise i would remember.

Sara

i value the argument that strstream buffer could be mapped to existing memory while that is not possible or more difficult for stringstream, though i never actually experienced such a necessity (and am not really convinced that there is no way to do it with stringstream). i wouldn't use a deprecated class cause a non-supported class will arise problems sooner or later, latest at the moment where other people have to bother with that.

Sara

Sara,
perhaps we should launch a parallel discussion where someone can identify a solution where they used stringstream as a replacement for strstream for hardware that was mapped into the virtual memory space. The key factor that I understand eliminates the use of stringstream is that the user has no control of the where actual storage of the string object exists. For embedded systems programming on special test equipment, the memory that is mapped is often located on some peripheral card and is mapped into viritual memory space of the application. stringstream does not provide a convenient (if at all) means to enable you to forcee the location of the string objects data storage to be some specific place in the virtual memory space. stringstream is desinged for use where the heap is the source of memory mapping of the string object's data storage. That detail negates its use for other virutal memory mapping scenarios.

i am not very experienced in implementing and using customized allocators, but you probably will know that std::string is a typedef of std::basic_string<char, char_traits<char>, allocator<char> > and the last template argument would allow you to provide a customized allocation for a std::string if that really is the main bottleneck. for that you should know that copying 1 mb of data in memory is a matter of milliseconds or less and in times of memory sizes of multiple gigabytes rarely an issue.

what is the main purpose of using a string stream class for the task. do you want to convert data mainly? or is it for serializing data from a device?

if any of the both, you hardly will need the total buffer as input for a stream but also should be able to firstly identify "substrings" of the buffer which then in most cases could be transferred to the final destination not using a stream operation but using a faster method, for example a simple copy.

Sara

>> Only strstream is usable in such cases for mapping that memory to a stream device
I beg to differ. Are you aware of what an allocator is?

>> Stringstream addresses only addresses a specific case of mapping strings to streams.
Not true. The default allocator on stringstream provides stream sematics for memory represented by stringbuff that, by default, just happens to allocate memory from the heap and represent it as a std::string. The std::string class is a data container (hence, it has a data accessor) that just also happens to have string semantics.

>> It is unfortunate that such a narrow thinking was applied when the decision to deprecate strstream occurred. It should have been fixed...
The problem is that fundemental design of strstream was flawed... it could not be fixed.

Sara: serization of the data using streaming semantics/syntax is the purpose. The 1 Meg of RAM in the peripheral device will operate as a ring buffer. One application will stream data into the memory, another applications will stream the data out. The source would map the RAM as ostream and the processing application would us istream access to extract the information. The insertion and extraction operator routines will need to be smart enough to handle the wrap around of the ring buffer. I concur that a solution could utilize a smaller "substrings", but that would up the complexity of the software. The strstream solution is a simple mapping that works well.

"...This is an important divergence from stringstream ..."

Look for this phrase in the text in the following link:
Difference between strstream and stringstream

There is nothing stopping you providing your own allocator or re-engineering the stringbuf to use a static buffer.

// This is quick and dirty and is just meant as an example of what you could do.

#include <sstream>   
#include <string>   
#include <iostream>

using namespace std;

char buffer[1024];
size_t const buffer_size = sizeof(buffer);

struct my_stringbuf : stringbuf // sub-class a stringstream buffer
{
   streambuf* setbuf ( char* s, streamsize n)
   {
      s_ = s;
      n_ = n;
      pos_ = 0;
      return this;
   }

   typedef char_traits<char> traits;
   typedef traits::int_type int_type;

   int_type overflow ( int_type c = traits::eof() )
   {
      if(c != traits::eof() && pos_ < n_)
         *(s_ + pos_++) = (traits::char_type) c;
      return c;
   }

   char* s_;
   streamsize n_;
   size_t pos_;
};

int main()
{
   my_stringbuf mybuf;
   mybuf.setbuf(buffer, buffer_size);
   iostream io(&mybuf);

   io << "foo\n";
   cout << buffer;
}

Select allOpen in new window