Re: memstream discussion (was Re: strstream reinstatement)
werasm ha scritto:
// this function is called by some legacy framework,
// it's expected to fill the given buffer with something
void legacy_callback(char* buf, size_t buflen)
{
omemstream formatter(buf, buflen);
/* use formatter to fill the buffer and check overflow */
}
This case IMO is so vastly different from the other, that it justifies
having a unique/different ostream entity to handle it. Why provide a
(do-it-all) interface. That is the problem with the current ostrstream.
What makes this example so different from the other one? I don't
understand. I'm not trying to do-it-all with one component. They really
looks like the same problem to me.
I think we need a new entity that wraps around an array reference and
performs operations on the referenced array... array_ostream? I'll have
a look at what boost offers in terms of this.
I'm still not convinced that having a separate wrapper is a good thing
and also that is necessary.
About Boost, if we had the iostream library then we would need no
memstreams, because they'd be already there. Have a look at classes
basic_array_source and basic_array_sink. Boost.iostream is certainly a
superior solution to this and many other problems. It simply hasn't been
formally proposed (yet), otherwise I would not have submitted my proposal.
template <unsigned N, bool AddNull = true>
class memstream
{
public: //...
enum {SzToAdd = AddNull ? 1 : 0};
enum{ Sz = N+SzToAdd };
memstream( char (&rarray)[Sz] )
: rarray_( rarray )
{
rarray_[Sz-1] = '\0';
}
char (&rarray_)[Sz];
};
If he specifies the input buffer size as erroneous, then compilation
error. See why specifying size becomes safe/handy.
Hmmm... What I don't understand is why bother the programmer to remember
the size of the array and punish him if he gets it wrong? Why don't we
just use a template to select automatically the correct size for him? In
*addition* to the constructor:
memstream(char* s, size_t n);
we could have
template <int N>
explicit memstream(char (&s)[N]);
which automatically selects the right size. The programmer can't go
wrong and his life would be easier.
2) Alternatively, you could zero-initialize the buffer on the class
constructor, but then we would fail the goal to be as lightweight as
possible, performing an operation that the user might not want to pay.
Only necessary to set that last character to NULL, no great penalty.
You don't seem to be joking, so it must be me that is missing
something... How could a NUL in the last position be enough? What if I
don't fill the buffer entirely? Suppose I use the memstream as in *your*
example:
char a[100];
memstream<100, true> s(a); // a[99] is now '\0'
s << "X"; // just fill the first char of the buffer
legacy_function(a); // ops!
you are passing to legacy_function a buffer with a 'X', 98 rubbish chars
and a '\0'. Yes, we won't have UB, but legacy_function will get
rubbish... I don't think that's tolerable. You can't even be sure about
the length of the string, because there may or may not be other NULs in
the rubbish.
So, you see, #1 is a no-no, #2 and #3 introduce a non-negligible cost
and potential confusion in certain situations.
#2 IMO is negligible. Null terminating the last position...
If it worked...
Moreover I disagree with you that the ends is so easy to
forget. That would explain my resistance to have null-
termination as the default behaviour.
Adding ends is inconsistent with how output streams are used in
general, and for this reason easy to forget (or not know in the first
place). Forcing NULL termination at least prevents (or lessens the
chance of) UB, which is my objective.
Here we are in the realm of opinions. I don't find the usage of
std::ends inconsistent in general, just very uncommon. Compare it with
std::endl which is used when writing to a file to force a flush.
However, #3 looks
very promising as it would be optional and I am indeed inclined to
consider it as soon as I find a way to properly handle the overflow. I
have to thank you for making me think about it.
Pleasure, 3 lookes promising for me too and is more consistent with how
other output streams are used.
If you speak of inconsistency, then #3 is indeed a departure from the
standard stream classes because it would be the first case where a
stream class writes something in the buffer that is not a direct result
of the application data.
Anyway, the basic controversy here is if (output) memstreams should be a
facility to build null-terminated strings or not. My proposal stems from
the assumption that "The proposed templates also don't try
to provide any view of the underlying buffer as a string" and is
consistent with that. I understand that this assumption is perhaps too
draconian and may limit the usefulness of the component, but it helps to
keep the interface simple and efficient. If the committee decides that
this makes my memstreams not useful enough or, worse, too error-prone,
then I'm ready to relax the assumption and study other options. But,
please don't say that I want to do-it-all if the component you have in
mind stems from opposite assumptions than mine.
Regards,
Ganesh
---
[ 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.comeaucomputing.com/csc/faq.html ]