This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: basic_filebuf supporting non-modal I/O without seekpos


On 09/18/2010 10:52 PM, Theodore Papadopoulo wrote:
> But a small test program seems to show that this is not strictly
> necessary....
>
> #include <stdio.h>
>
> int main() {
> char string[20];
> FILE* fp = fopen("toto","a+");
> fgets(string,10,fp);
> fputs("This is a test",fp);
> return 0;
> }
This is interesting. It is perfectly possible that, as a matter of
quality of implementation some libcs (you tested glibc, I suspect) can
do that without an fseek in the middle. Certainly, however, as you
correctly noticed, the C Standard (I have C99 at hand) *permits* the
above to work, doesn't require it, it all depends on the implementation,
and portable code certainly had better having an fseek in the middle. I
suspect that, at least people coming from C, are used to that, and
that's why find the current behavior of our implementation completely
rather reasonable, after all.

That said, I'm certainly for allowing reads after writes and viceversa
optionally without a seek in the middle, I only want to make *real* sure
the change is doable in C++ without affecting performance for the basic
scheme of reads, seek, writes, seek, reads, etc, which definitely is the
most important pattern (and rationale for the C specifications), because
I have seen with my eyes the code (both streambuf and filebuf) we had
before 2003 and it was just ugly.

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]