By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,925 Members | 1,129 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,925 IT Pros & Developers. It's quick & easy.

string looses contents.

P: n/a
I am downloading over http port 80 some contents froma site, but the
contents is not properly stored after using ostringstream for temporary
storage, and later ostringstream::str() for passing it over to a string.
This doesn't work. It misses data and teh result is not the same as when
using char buffer[bufsize], which gives correct download. Could anyone
point out why the ostringstream + string way doesn't work, while the char
buffer[buffsize] does?
tia
--
http://www.kolumbus.fi/bob.smith
Jul 23 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
* Bob Smith:
I am downloading over http port 80 some contents froma site, but the
contents is not properly stored after using ostringstream for temporary
storage, and later ostringstream::str() for passing it over to a string.
This doesn't work. It misses data and teh result is not the same as when
using char buffer[bufsize], which gives correct download. Could anyone
point out why the ostringstream + string way doesn't work, while the char
buffer[buffsize] does?


It can be related to a bug-ridden download code that has exquisite timing
requirements.

However, it's most likely only related to incorrect usage of
'ostringstream'.

Since I suspect that your code intermingles the aspects of platform-specific
downloading and C++ buffering I won't ask you to post the code you have.

Instead, implement the following class:

class Buffer
{
private:
// whatever
public:
Buffer();
void add( char const s[] );
std::string result() const;
};

with e.g. the following driver program:

int main()
{
Buffer buf;

buf.add( "Hello, " );
buf.add( "world" );
std::cout << buf.result() << std::endl;
buf.add( "!" );
std::cout << buf.result() << std::endl;
}

which should give the result

Hello, world
Hello, world!

and post your code here.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #2

P: n/a
Bob Smith wrote:
I am downloading over http port 80 some contents froma site, but the
contents is not properly stored after using ostringstream for temporary
storage, and later ostringstream::str() for passing it over to a string.
This doesn't work. It misses data and teh result is not the same as when
using char buffer[bufsize], which gives correct download. Could anyone
point out why the ostringstream + string way doesn't work, while the char
buffer[buffsize] does?
tia


Hi Bob,
Without seeing your actual code it's difficult, but you can try the
following example. Hope it helps.

#include <iostream>
#include <string>
#include <sstream>
using namespace std;

int main()
{
ostringstream outputStream;

string resultString;

outputStream << "Text1 ";

outputStream << "Text2 ";

resultString = outputStream.str();

cout << resultString;

return 0;

}

--

// Morten - www.mortenvp.dk
Jul 23 '05 #3

P: n/a
Alf P. Steinbach wrote:
* Bob Smith:
I am downloading over http port 80 some contents froma site, but the
contents is not properly stored after using ostringstream for temporary
storage, and later ostringstream::str() for passing it over to a string.
This doesn't work. It misses data and teh result is not the same as when
using char buffer[bufsize], which gives correct download. Could anyone
point out why the ostringstream + string way doesn't work, while the char
buffer[buffsize] does?


It can be related to a bug-ridden download code that has exquisite timing
requirements.

However, it's most likely only related to incorrect usage of
'ostringstream'.

Since I suspect that your code intermingles the aspects of
platform-specific downloading and C++ buffering I won't ask you to post
the code you have.

Instead, implement the following class:

class Buffer
{
private:
// whatever
public:
Buffer();
void add( char const s[] );
std::string result() const;
};

with e.g. the following driver program:

int main()
{
Buffer buf;

buf.add( "Hello, " );
buf.add( "world" );
std::cout << buf.result() << std::endl;
buf.add( "!" );
std::cout << buf.result() << std::endl;
}

which should give the result

Hello, world
Hello, world!

and post your code here.

Thank's alf for the prompt reply. Tested your approach and it works very
well. I made a buf of chars which expands as more data comes available.
Thank you.
<code>

#ifndef _QXRSSBUFFER_H
#define _QXRSSBUFFER_H
class QxRSSBuffer{
public:
QxRSSBuffer( int size, int increment = 512 );
void add( const char * p, int len );
const char * data()const;
~QxRSSBuffer();
int size()const;
private:
char * Buf;
int Size;
int Used;
int Increment;
};
#endif

#include <qxrssbuffer.h>
#include <g++/cstring>
QxRSSBuffer::QxRSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::add( const char * p, int len )
{
if ( ( Used + len ) < Size ) {
memcpy( (void*)&Buf[Used], (void*)p, len );
Used += len;
return;
}
char * buf = new char[ Size + Increment ];
memcpy( buf, Buf, Used );
delete [] Buf;
Buf = buf;
Size += Increment;
add( p, len );
}
const char * QxRSSBuffer::data()const{
return Buf;
}
QxRSSBuffer::~QxRSSBuffer(){
delete [] Buf;
}
int QxRSSBuffer::size()const{
return Used;
}

</code>
( improvements welcome )
--
http://www.kolumbus.fi/bob.smith
Jul 23 '05 #4

P: n/a
Bob Smith wrote:
Thank's alf for the prompt reply. Tested your approach and it works very
well. I made a buf of chars which expands as more data comes available.
Thank you.
Why? You like latent bugs and reinventing the wheel? Why not use
std::string or vector?
class QxRSSBuffer{
public:
QxRSSBuffer( int size, int increment = 512 );
void add( const char * p, int len );
const char * data()const;
~QxRSSBuffer();
int size()const;
Your class manages internal memory allocations but lacks a copy
constructor or copy assignment operator (or anyway to specifically
avoid their use). Hence you are asking for trouble.

memcpy( (void*)&Buf[Used], (void*)p, len );
What's with the unnecessary casts above?
char * buf = new char[ Size + Increment ];
memcpy( buf, Buf, Used );
delete [] Buf;
Buf = buf;
Size += Increment;
add( p, len );

Not very efficient if the new size is much larger than the increment.
Jul 23 '05 #5

P: n/a
* Bob Smith:

#include <qxrssbuffer.h>
#include <g++/cstring>
QxRSSBuffer::QxRSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::add( const char * p, int len )
{
if ( ( Used + len ) < Size ) {
memcpy( (void*)&Buf[Used], (void*)p, len );
Used += len;
return;
}
char * buf = new char[ Size + Increment ];
memcpy( buf, Buf, Used );
delete [] Buf;
Buf = buf;
Size += Increment;
add( p, len );
}

There are three main problems with this, that I can see right away.

First, the code assumes that 'len' is always less than 'Increment';
an 'assert' to that effect could help you avoid trouble (buffer overrun),
and a ditto comment in the header file, but better, make no such assumption.

Second, for a small 'Increment' relative to the total final size the
copying involved makes for O(n^2) behavior. The usual way to avoid that
is to double the buffer length each time it's exceeded, which makes for O(n)
time total, and constant amortized time per character. And that's what
e.g. std::vector does, so you can use std::vector as your internal buffer
implementation instead of the low-level and unsafe pointer handling.

Third, of interest if this class is going to be reused, it doesn't define
or declare a copy constructor nor an assignment operator. If you're not
going to support copying of buffers then simply declare a copy constructor
and an assignment operator, as 'private:', and don't define them. As it is,
if an object is copied you have a bug.

Finally, but not really a technical problem per se in the code above, just a
way to avoid potential problems, I recommend using the C++ standard
library's copy operations instead of unsafe memcpy.

( improvements welcome )


See above. ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #6

P: n/a
Alf P. Steinbach wrote:
First, the code assumes that 'len' is always less than 'Increment';
an 'assert' to that effect could help you avoid trouble (buffer overrun),
and a ditto comment in the header file, but better, make no such assumption.


No it doesn't, it just recursively calls add to increment the string
until the buffer is big enough. Not the greatest idea in the world,
but in this case it works.
Jul 23 '05 #7

P: n/a
Alf P. Steinbach wrote:
* Bob Smith:

#include <qxrssbuffer.h>
#include <g++/cstring>
QxRSSBuffer::QxRSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::add( const char * p, int len )
{
if ( ( Used + len ) < Size ) {
memcpy( (void*)&Buf[Used], (void*)p, len );
Used += len;
return;
}
char * buf = new char[ Size + Increment ];
memcpy( buf, Buf, Used );
delete [] Buf;
Buf = buf;
Size += Increment;
add( p, len );
}

There are three main problems with this, that I can see right away.

First, the code assumes that 'len' is always less than 'Increment';
an 'assert' to that effect could help you avoid trouble (buffer overrun),
and a ditto comment in the header file, but better, make no such
assumption.

Second, for a small 'Increment' relative to the total final size the
copying involved makes for O(n^2) behavior. The usual way to avoid that
is to double the buffer length each time it's exceeded, which makes for
O(n)
time total, and constant amortized time per character. And that's what
e.g. std::vector does, so you can use std::vector as your internal buffer
implementation instead of the low-level and unsafe pointer handling.


hmm, ahaa, ...

Third, of interest if this class is going to be reused, it doesn't define
or declare a copy constructor nor an assignment operator. If you're not
going to support copying of buffers then simply declare a copy constructor
and an assignment operator, as 'private:', and don't define them. As it
is, if an object is copied you have a bug.
implemented.

Finally, but not really a technical problem per se in the code above, just
a way to avoid potential problems, I recommend using the C++ standard
library's copy operations instead of unsafe memcpy.

( improvements welcome )


See above. ;-)

Many thank's Alf, your input is highly appreciated.

:-)

--
http://www.kolumbus.fi/bob.smith
Jul 23 '05 #8

P: n/a
Ron Natalie wrote:
Bob Smith wrote:
Thank's alf for the prompt reply. Tested your approach and it works very
well. I made a buf of chars which expands as more data comes available.
Thank you.
Why? You like latent bugs and reinventing the wheel? Why not use
std::string or vector?


I tried using std::ostringstream in concert with std::string to take down
the contents, but the results were not what they should have been. This
could be due to a bug in the stl at my machine, don't know.
class QxRSSBuffer{
public:
QxRSSBuffer( int size, int increment = 512 );
void add( const char * p, int len );
const char * data()const;
~QxRSSBuffer();
int size()const;
Your class manages internal memory allocations but lacks a copy
constructor or copy assignment operator (or anyway to specifically
avoid their use). Hence you are asking for trouble.


implemented.

memcpy( (void*)&Buf[Used], (void*)p, len );


What's with the unnecessary casts above?

removed.
char * buf = new char[ Size + Increment ];
memcpy( buf, Buf, Used );
delete [] Buf;
> Buf = buf;
> Size += Increment;
> add( p, len );
>

Not very efficient if the new size is much larger than the increment.


true, but the increment can be set during object creation.
Can you suggest a better approach for this problem?

to summarize: I download over a socket some contents from a website over
http port 80( in this case an image ) which is of unknown size at the this
objects/class' creation time, and need a buffer for holding the image data.
This works well with the approach I outlined here in this thread, but
failed to operate properly with std::ostringstream + std::string.

Your expert advice is highly appreciated.
--
http://www.kolumbus.fi/bob.smith
Jul 23 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.