Tommi M=C3=A4kitalo wrote:

> "&*vec.begin()" as well as "&vec[0]" is ugly syntax.=20

That's a bit besides the point, isn't it?

> Another solution to my buffer-problem is to add a method
> std::vector::data(), which returns pointer to the buffer, like
> std::basic_string::data(). The difference to std::string would be, that=
 the
> non-const data()-method will return a non-const pointer. That would mak=
e my
> buffer almost obsolete.

You've got it:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464

However this is currently in the Working Paper, while &vec[0] is in the=20
stanard _now_.

~Marc.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thorsten Ottosen"

> In the mean time, check out
> http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/circular_buffer/
> Already accepted into boost and will probably be part of the next release.
>
Accepted but its creator left the project.
I promised to take it over but need to find time.
It won't be part of next release.

/Pavel




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Kuehl wrote:

> Tommi M=C3=A4kitalo wrote:
>> Exactly this automated acquire and release is what I get, including
>> exception-safety.
>=20
> Sure. The buffer functions are not intended to be used without an
> appropriate wrapper. How this wrapper looks exactly, however, depends
> on your needs - and you managed to significantly weaken your case by
> pointing out that you want a buffer which, when resized, does not copy
> its elements. In the few cases where I need a buffer, I don't need
> resizing at all! ... and in all cases where I need resizing of a
> container, I need the elements to be copied. That is, we and I guess
> other interested in temporary buffers disagree of the design principles
> of the buffer.
>=20
>> I need sometimes the system-call poll. This need a pointer to struct
>> pollfd, where I can pass the file-descriptors, I am interested in. I
>> can't use get_temporary_buffer here, because I don't want to deal with
>> less than a specific count of elements. It is perfectly ok to get a
>> alloc_error, when memory is exhausted.
>=20
> Maybe it is time to read the documentation (or, if this is bad, the
> holy standard) instead of insisting that what you need is the ultimate
> and nothing already there might be helpful in achieving your goal. The
> function 'get_temporary_buffer()' will return a pair of null values if
> it can't allocate a buffer, i.e. it signals an allocation error.
>>=20
>> It is a easy to write wrapper, but very usable. I don't think it is a
>> argument, that it is simple to write.
>=20
> No, not that alone. Hands up everybody who has ever used a 'max()' or a
> 'min()' function! Right, nearly everybody. Only those too lazy to put
> their hands up or those sleeping didn't put their hands up. Hands up
> everybody who has every used a temporary buffer. I would expect ten,
> maybe twenty percent of the hands to go up on this one. Utility is
> another important measure. Of course, to those needing a temporary
> buffer it is highly useful but even those disagree on the details. The
> overall percentage of C++ users which would benefit from any particular
> buffer class design is probably below one percent. Worth the effort for
> something which can trivially be built upon existing facilities to
> serve at least all those who need a buffer?
>=20
>> std::copy is simple to write.
>=20
> You think it is? I have done the exercise and I disagree with you. In
> fact, you cannot built a reasonable and portable 'std::copy()' unless
> you use TR1 facilities. "Reasonable", of course, includes that the
> implementation of 'std::copy()' performs well for all kinds of
> sequences and e.g. uses 'memmove()' where appropriate, handles segmente=
d
> sequences, 'move()'s its elements, etc.
>=20
>> And so is std::auto_ptr.
>=20
> Interesting... I thought it is impossible to write a conforming
> implementation in C++. But then, I haven't been following the discussio=
n
> on this oddball to closely.
>=20
>> Or less,
>=20
> This is an interesting one! Here is an exercise: write a portable
> 'less<void*>' without using 'std::less<void*>', of course. However,
> apart from this special case, there is another reason d'etre for this
> class template: it is used as the default in various places in the
> standard C++ library.
>=20
>> min, max.
>=20
> These are pretty trivial and I would expect that these are indeed
> quite frequently used - several orders of magnitude more frequently
> than temporary buffers in general (which, as mentioned above, is used
> one or two orders of magnitude more often than any specific buffer
> design).
>=20
>> The standard should have solutions for common problems.
>=20
> Indeed. ... and I would consider things like sockets, XML parsers,
> and database access facilities to be several orders of magnitudes
> more important than buffer classes! In fact, I would claim that buffer
> classes are a rather uncommon need.
>=20
>> They might be trivial, but I like code, where I can
>> say: Oh - here is a list<> - I know exactly, how the program deal with
>> the data, without looking into the implementation or documentation of
>> some individual solution. And so it would be nice to see: Oh - here th=
e
>> program uses std::basic_buffer<char> - the program handles memory in a
>> exception-safe manner.
>=20
> You like others to do your work. Of course, you also want them to do
> your work the way you would do it not necessarily as they would do it.
> Don't we all? (so that we have more time doing the work we consider to
> be really important)

Ok - I expected you to deny them to be trivial. I know they aren't that
trivial as they look like. I don't think a buffer is less often needed as
many obscure things of the standard, but it's ok. I like the idea of
std::vector<T>::data() mentioned in another thread.

Waht do you think about adding a exceptionsafe wrapper for
get_temporary_buffer() and return_temporary_buffer()? I think most uses c=
an
be handled by a generic wrapper.

Tommi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Schoolderman wrote:

> Tommi M=C3=A4kitalo wrote:
>=20
=2E
>=20
> You've got it:
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464
>=20
> However this is currently in the Working Paper, while &vec[0] is in the
> stanard _now_.
>=20
> ~Marc.
>=20
Yes thank you. I'd vote for #464 for now. std::basic_buffer or something
isn't in the standard either. std::vector<T>::data() would solve the
problems.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I would like to make a proposal for a new class it the standard-library: a
buffer.

The motivation is, that I need often a buffer for collecting something
temporary, e.g. a receive-buffer for network-IO. The systemcall read needs
a pointer to memory, where it should write the received data. I could use a
static array, but to make the buffer configurable at runtime, I need to
deal with heap-memory. I have to allocate memory, which need to be released
somewhere.

A buffer-class allocates, holds and releases the memory, but allowes full
access to it. The buffer could be used also in a std::streambuf as the
actual data-area.

A uage-example is here:

void someFunc(int fd, unsigned bufsize)
{
  std::buffer<char> myBuffer;
  myBuffer.resize(bufsize);  // or std::buffer<> myBuffer(bufsize);
  int n = read(fd, myBuffer.data(), bufsize);
  // do something with the data
}

std::buffer is not copyable or assignable. This makes it as lightweight as
possible.

I have a implemenation of something like it in my own toolbox and find it
very handy.

What do you think about it?


Tommi M  kitalo

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <dnv8qa$2ahs$1@ulysses.news.tiscali.de>,
 Tommi M=C3=A4kitalo <tommi@maekitalo.de> wrote:


> A buffer-class allocates, holds and releases the memory, but allowes fu=
ll
> access to it. The buffer could be used also in a std::streambuf as the
> actual data-area.
>=20
> A uage-example is here:
>=20
> void someFunc(int fd, unsigned bufsize)
> {
>   std::buffer<char> myBuffer;
>   myBuffer.resize(bufsize);  // or std::buffer<> myBuffer(bufsize);
>   int n =3D read(fd, myBuffer.data(), bufsize);
>   // do something with the data
> }

> What do you think about it?

I think I'd rather just use std::vector.  I don't see what this offers=20
that vector doesn't.

--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (773) 961-1620

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nevin@eviloverlord.com wrote:

>>  std::buffer<char> myBuffer;
>>  myBuffer.resize(bufsize);  // or std::buffer<> myBuffer(bufsize);
>>  int n = read(fd, myBuffer.data(), bufsize);
>>  // do something with the data
>>What do you think about it?
> I think I'd rather just use std::vector.  I don't see what this offers
> that vector doesn't.

Perhaps it should be pointed out that a vector<char> also provides
complete access to its internals:

std::vector<char> myBuffer(bufsize);
int n = read(fd, &myBuffer[0], bufsize);
  // do something

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M=E4kitalo wrote:

> A buffer-class allocates, holds and releases the memory, but allowes fu=
ll
> access to it.

Have you looked at the functions 'get_temporary_buffer()' and
'return_temporary_buffer()'? What does your class offer which these
functions don't - except, of course, the automated acquire and
release. I think these two function provide the necessary functionality
including the ability to deal appropriately with situations where no
temporary buffer of the required size is available. A thin and easy to
write wrapper class could do just this and provide your favorite buffer
interface of the day, i.e. it is something not reasonable to put into
a standard.

> The buffer could be used also in a std::streambuf as the=20
> actual data-area.

Stream buffers need to cling to their buffers. It is entirely
appropriate to allocate the buffer e.g. on the heap or embedded into
the buffer.
--=20
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nevin ":-]" Liber wrote:

> In article <dnv8qa$2ahs$1@ulysses.news.tiscali.de>,
.
>
> I think I'd rather just use std::vector.  I don't see what this offers
> that vector doesn't.
>
A difference is also, that a buffer don't need to care about data, when
resized. The buffer throws the old data away and allocates new. There are 2
advantages about this approach: The data don't need to be copied, which
speeds it up and the memory is only needed once. When a vector is copied,
it needs at least temporarily space for the old and for the new data.

A buffer will have a method swap, which eases reallocating and manually
copying data like this:

std::buffer<char> buffer(initial_size);
.
// to extend size and keep the data:
{
  std::buffer<char> tmpBuffer(initial_size + some_amount);  // allocate a
larger buffer
  std::copy(buffer.begin(); buffer.end(), tmpBuffer.begin());  // copy old
data to the new buffer
  buffer.swap(tmpBuffer);  // replace the old buffer with the new one
  // tmpBuffer now holds the old buffer
} // the destructor of tmpBuffer deallocates the old data


Maybe there should be a basic_buffer and typedefs like this:

namespace std
{
template <typename _CharT, typename _Alloc = allocator<_CharT> >
class basic_buffer;

typedef basic_buffer<char> buffer;
typedef basic_buffer<wchar_t> wbuffer;
}

There is no traits, because buffer does not do anything with the
character-type.

The user can as well define e.g. a:

typedef basic_buffer<struct pollfd> pollfd_buffer;

for use in poll(2).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nevin ":-]" Liber wrote:

.
>
> I think I'd rather just use std::vector.  I don't see what this offers
> that vector doesn't.
>
You don't get a writable pointer to data from a std::vector.

Tommi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Kuehl wrote:

> Tommi M=C3=A4kitalo wrote:
>=20
>> A buffer-class allocates, holds and releases the memory, but allowes f=
ull
>> access to it.
>=20
> Have you looked at the functions 'get_temporary_buffer()' and
> 'return_temporary_buffer()'? What does your class offer which these
> functions don't - except, of course, the automated acquire and
> release. I think these two function provide the necessary functionality
> including the ability to deal appropriately with situations where no
> temporary buffer of the required size is available. A thin and easy to
> write wrapper class could do just this and provide your favorite buffer
> interface of the day, i.e. it is something not reasonable to put into
> a standard.
>=20
>> The buffer could be used also in a std::streambuf as the
>> actual data-area.
>=20
> Stream buffers need to cling to their buffers. It is entirely
> appropriate to allocate the buffer e.g. on the heap or embedded into
> the buffer.
Exactly this automated acquire and release is what I get, including
exception-safety.

I need sometimes the system-call poll. This need a pointer to struct poll=
fd,
where I can pass the file-descriptors, I am interested in. I can't use
get_temporary_buffer here, because I don't want to deal with less than a
specific count of elements. It is perfectly ok to get a alloc_error, when
memory is exhausted.

It is a easy to write wrapper, but very usable. I don't think it is a
argument, that it is simple to write. std::copy is simple to write. And s=
o
is std::auto_ptr. Or less, min, max. The standard should have solutions f=
or
common problems. They might be trivial, but I like code, where I can say:
Oh - here is a list<> - I know exactly, how the program deal with the dat=
a,
without looking into the implementation or documentation of some individu=
al
solution. And so it would be nice to see: Oh - here the program uses
std::basic_buffer<char> - the program handles memory in a exception-safe
manner.

Tommi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M=E4kitalo wrote:
> Nevin ":-]" Liber wrote:
>=20
> .
>=20
>>I think I'd rather just use std::vector.  I don't see what this offers
>>that vector doesn't.
>>
>=20
> You don't get a writable pointer to data from a std::vector.

you do:

if( !vec.empty() )
   foo( &*vec.begin(), vec.size() )

the problem with vector is that you then initialize the data twice,=20
quite expensive in many situations.

Some proposals have been made to remedy this:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1870.html#add-se=
t-buffer-t-size-t-to-vector-and-basic-string

-Thorsten

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M   kitalo wrote:
> Hi,
>
> I would like to make a proposal for a new class it the standard-library: a
> buffer.
>
> The motivation is, that I need often a buffer for collecting something
> temporary, e.g. a receive-buffer for network-IO. The systemcall read needs
> a pointer to memory, where it should write the received data. I could use a
> static array, but to make the buffer configurable at runtime, I need to
> deal with heap-memory. I have to allocate memory, which need to be released
> somewhere.
>
> A buffer-class allocates, holds and releases the memory, but allowes full
> access to it. The buffer could be used also in a std::streambuf as the
> actual data-area.
>
> A uage-example is here:
>
> void someFunc(int fd, unsigned bufsize)
> {
>   std::buffer<char> myBuffer;
>   myBuffer.resize(bufsize);  // or std::buffer<> myBuffer(bufsize);
>   int n = read(fd, myBuffer.data(), bufsize);
>   // do something with the data
> }
>
> std::buffer is not copyable or assignable. This makes it as lightweight as
> possible.
>
> I have a implemenation of something like it in my own toolbox and find it
> very handy.
>
> What do you think about it?

I think to make this buffer idea more interesting - and to distinguish
it from a std::vector - it should be a read/write circular buffer. A
circular buffers is fairly tricky to implement - which makes it a very
good candidate for a standard library implementation. In other words,
no one who needs one should have to write their own.

Conceptually, however, a circular buffer is easy to describe. A
"writer" client writes data into the buffer (often data received over
the network) and advances a "write to" pointer to the next location in
the buffer to write subsequent data. More or less concurrently with the
write operations, a reader client "reads" the data in the buffer,
transferring it or otherwise consuming it, and advances a "read from"
pointer to indicate at which point in the buffer reading should resume.
Since the buffer is fixed in size, at some point the writer will have
written enough bytes to reach the end of the buffer. At this point the
writer moves the "write to" pointer to start of the buffer. Assuming
some data has been read, there will be free space available for writing
at the start of the buffer. So the writer can write up to (but not
beyond) the "read from" pointer set by the reader. By the same token,
when the reader has read up to the end of the buffer, it resumes
reading from the start of the buffer up to (but not beyond) the "write
to" pointer.

In essence the reader chases after the writer, and optimally neither
lets the writer "lap" its position (and thus fill the buffer) or catch
up to the writer (thus emptying the buffer) except when there is no
more data to be read.

A circular buffer is efficient since it minimizes copy operations.
Moreover, a circular buffer should not need semaphores or other locking
mechanisms to arbitrate between the reader and the writer - so an
implementation should be quite portable.

Note that a circular buffer could be implemented with a
std::vector<char> providing the storage. In which case all that is
needed is to design and implement the circular buffer interface. Here
is rough sketch of how such an interface might look:

      class circular_buffer
      {
      public:
             circular_buffer( size_t size);

             size_t       readable_buffer_size() const;
             const char * readable_buffer_ptr() const;
             size_t       read( char *outBuffer, size_t len);

             size_t       writable_buffer_size() const;
             char *       writable_buffer_ptr();
             size_t       write( const char *bytes, size_t len);

             bool         empty() const;
             bool         full() const;
             ...

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Greg Herlihy wrote:

> Tommi M=FF=FFkitalo wrote:
>> Hi,
>>
=2E
>=FF
> I think to make this buffer idea more interesting - and to distinguish
> it from a std::vector - it should be a read/write circular buffer. A
> circular buffers is fairly tricky to implement - which makes it a very
> good candidate for a standard library implementation. In other words,
> no one who needs one should have to write their own.
>=FF
=2E
>=FF
> Greg
>=FF
>=FF
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with=
 ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu   =
 ]
> [              --- Please see the FAQ before posting. ---              =
 ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]

This might well be a adapter to std::basic_buffer. I wouldn't mix them, b=
ut
it is still an interesting idea.

Tommi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:

> Tommi M=C3=A4kitalo wrote:
>> Nevin ":-]" Liber wrote:
>>=20
>> .
>>=20
>>>I think I'd rather just use std::vector.  I don't see what this offers
>>>that vector doesn't.
>>>
>>=20
>> You don't get a writable pointer to data from a std::vector.
>=20
> you do:
>=20
> if( !vec.empty() )
>    foo( &*vec.begin(), vec.size() )
>=20
> the problem with vector is that you then initialize the data twice,
> quite expensive in many situations.
>=20
> Some proposals have been made to remedy this:
>=20
>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1870.html#add-se=
t-buffer-t-size-t-to-vector-and-basic-string
>=20
> -Thorsten
>=20
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with=
 ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu   =
 ]
> [              --- Please see the FAQ before posting. ---              =
 ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
Does *vec.begin() return a reference to the first element of the internal
buffer or a dereferenced interator, which just have to behaves like a
reference to the first element, which might well be a reference to the
first element?

"&*vec.begin()" as well as "&vec[0]" is ugly syntax. "vec.begin()" and
"vec[0]" deal with the first element, but not with the whole data. Taking=
 a
pointer and dealing it as a pointer to a array of elements breaks logic. =
It
is not intuitive at all.

Another solution to my buffer-problem is to add a method
std::vector::data(), which returns pointer to the buffer, like
std::basic_string::data(). The difference to std::string would be, that t=
he
non-const data()-method will return a non-const pointer. That would make =
my
buffer almost obsolete.

There is still one issue left: when resizing a vector, the vector will co=
py
the data, even when not currently logically empty. std::buffer (or
std::basic_buffer) does not copy data, but discards old content when
resized.

And I don't like the mentioned proposal at all. std::vector and
std::basic_string have to deal with something, they have not allocated.
That is a bad idea.


Tommi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M=E4kitalo wrote:
> Exactly this automated acquire and release is what I get, including
> exception-safety.

Sure. The buffer functions are not intended to be used without an
appropriate wrapper. How this wrapper looks exactly, however, depends
on your needs - and you managed to significantly weaken your case by
pointing out that you want a buffer which, when resized, does not copy
its elements. In the few cases where I need a buffer, I don't need
resizing at all! ... and in all cases where I need resizing of a
container, I need the elements to be copied. That is, we and I guess
other interested in temporary buffers disagree of the design principles
of the buffer.

> I need sometimes the system-call poll. This need a pointer to struct
> pollfd, where I can pass the file-descriptors, I am interested in. I ca=
n't
> use get_temporary_buffer here, because I don't want to deal with less t=
han
> a specific count of elements. It is perfectly ok to get a alloc_error,
> when memory is exhausted.

Maybe it is time to read the documentation (or, if this is bad, the
holy standard) instead of insisting that what you need is the ultimate
and nothing already there might be helpful in achieving your goal. The
function 'get_temporary_buffer()' will return a pair of null values if
it can't allocate a buffer, i.e. it signals an allocation error.
>=20
> It is a easy to write wrapper, but very usable. I don't think it is a
> argument, that it is simple to write.

No, not that alone. Hands up everybody who has ever used a 'max()' or a
'min()' function! Right, nearly everybody. Only those too lazy to put
their hands up or those sleeping didn't put their hands up. Hands up
everybody who has every used a temporary buffer. I would expect ten,
maybe twenty percent of the hands to go up on this one. Utility is
another important measure. Of course, to those needing a temporary
buffer it is highly useful but even those disagree on the details. The
overall percentage of C++ users which would benefit from any particular
buffer class design is probably below one percent. Worth the effort for
something which can trivially be built upon existing facilities to
serve at least all those who need a buffer?

> std::copy is simple to write.

You think it is? I have done the exercise and I disagree with you. In
fact, you cannot built a reasonable and portable 'std::copy()' unless
you use TR1 facilities. "Reasonable", of course, includes that the
implementation of 'std::copy()' performs well for all kinds of
sequences and e.g. uses 'memmove()' where appropriate, handles segmented
sequences, 'move()'s its elements, etc.

> And so is std::auto_ptr.

Interesting... I thought it is impossible to write a conforming
implementation in C++. But then, I haven't been following the discussion
on this oddball to closely.

> Or less,

This is an interesting one! Here is an exercise: write a portable
'less<void*>' without using 'std::less<void*>', of course. However,
apart from this special case, there is another reason d'etre for this
class template: it is used as the default in various places in the
standard C++ library.

> min, max.

These are pretty trivial and I would expect that these are indeed
quite frequently used - several orders of magnitude more frequently
than temporary buffers in general (which, as mentioned above, is used
one or two orders of magnitude more often than any specific buffer
design).

> The standard should have solutions for common problems.

Indeed. ... and I would consider things like sockets, XML parsers,
and database access facilities to be several orders of magnitudes
more important than buffer classes! In fact, I would claim that buffer
classes are a rather uncommon need.

> They might be trivial, but I like code, where I can=20
> say: Oh - here is a list<> - I know exactly, how the program deal with =
the
> data, without looking into the implementation or documentation of some
> individual solution. And so it would be nice to see: Oh - here the prog=
ram
> uses std::basic_buffer<char> - the program handles memory in a
> exception-safe manner.

You like others to do your work. Of course, you also want them to do
your work the way you would do it not necessarily as they would do it.
Don't we all? (so that we have more time doing the work we consider to
be really important)
--=20
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M=C3=A4kitalo wrote:
> Thorsten Ottosen wrote:
>=20

> Another solution to my buffer-problem is to add a method
> std::vector::data(), which returns pointer to the buffer, like
> std::basic_string::data(). The difference to std::string would be, that=
 the
> non-const data()-method will return a non-const pointer. That would mak=
e my
> buffer almost obsolete.

See

http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-defects.html#464


> There is still one issue left: when resizing a vector, the vector will =
copy
> the data, even when not currently logically empty. std::buffer (or
> std::basic_buffer) does not copy data, but discards old content when
> resized.
>=20
> And I don't like the mentioned proposal at all. std::vector and
> std::basic_string have to deal with something, they have not allocated.
> That is a bad idea.

Well, there could be an additional requirement that the allocator must=20
be compatible with the allocator of the string/vector.

-Thorsten

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tommi M=C3=A4kitalo wrote:
> Greg Herlihy wrote:
>=20
>=20
>>Tommi M=EF=BF=BD=EF=BF=BDkitalo wrote:
>>
>>>Hi,
>>>
>=20
> .
>=20
>>=EF=BF=BD
>>I think to make this buffer idea more interesting - and to distinguish
>>it from a std::vector - it should be a read/write circular buffer. A
>>circular buffers is fairly tricky to implement - which makes it a very
>>good candidate for a standard library implementation. In other words,
>>no one who needs one should have to write their own.

In the mean time, check out

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/ci=
rcular_buffer/

Already accepted into boost and will probably be part of the next release.

-Thorsten

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <do46n1$7kg$1@ulysses.news.tiscali.de>, Tommi M=88=A7kitalo
<tommi@maekitalo.de> wrote:

>=20
> Another solution to my buffer-problem is to add a method
> std::vector::data(), which returns pointer to the buffer, like
> std::basic_string::data(). The difference to std::string would be, that=
 the
> non-const data()-method will return a non-const pointer. That would mak=
e my
> buffer almost obsolete.
>=20
> There is still one issue left: when resizing a vector, the vector will =
copy
> the data, even when not currently logically empty. std::buffer (or
> std::basic_buffer) does not copy data, but discards old content when
> resized.

   You have been shown how to get a T * to the data of vector<T,A>.

   now to resize a vector without copying [just default constructing]

   template <class T,class A>
   void buffer_resize(std::vector<T,A> &vec,typename
std::vector<T,A>::size_type n)
   {
      if(n > vec.size())
      {
         std::vector<T,A>  temp;
         temp.swap(vec);
      }
      vec.resize(n);
   }

   does not copy, but uses T()  if on entry n > vec.size() otherwise it
does nothing but change the size and 'end' of the vector internally.
these are normally very cheap, especially for things used to build an
array for a buffer.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]