string looses contents.

[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?
tia
--
http://www.kolumbus.fi/bob.smith

[Alf P. Steinbach]

* 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?

[Morten V Pedersen]

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.st r();

cout << resultString;

return 0;

}

--

// Morten - www.mortenvp.dk

[Bob Smith]

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::Qx RSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::ad d( 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::da ta()const{
return Buf;
}
QxRSSBuffer::~Q xRSSBuffer(){
delete [] Buf;
}
int QxRSSBuffer::si ze()const{
return Used;
}

</code>
( improvements welcome )
--
http://www.kolumbus.fi/bob.smith

[Ron Natalie]

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.

[Alf P. Steinbach]

* Bob Smith:

#include <qxrssbuffer. h>
#include <g++/cstring>
QxRSSBuffer::Qx RSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::ad d( 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?

[Ron Natalie]

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.

[Bob Smith]

Alf P. Steinbach wrote:

* Bob Smith:

#include <qxrssbuffer. h>
#include <g++/cstring>
QxRSSBuffer::Qx RSSBuffer( int size, int increment )
:Size( size ), Used ( 0 ), Increment( increment )
{
Buf = new char[ Size ];
memset( Buf, 0, Size );
}
void QxRSSBuffer::ad d( 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

[Bob Smith]

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::ostringstr eam 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::ostringstr eam + std::string.

Your expert advice is highly appreciated.
--
http://www.kolumbus.fi/bob.smith