Re: [Stlport-devel] [Stlport-cvs] SF.net SVN: stlport:[3611] trunk/STLport

[Ulrich E. <eck...@sa...>]

Guys,

I've been reading a bit the provided links and here's my opinion on the 
matter:

1. Openmode 'app' alone is not part of the valid openmodes of the current C++ 
standard. Further, that standard says explicitly that if the mode is not one 
of the supported modes, opening fails. This is a requirement, and there is 
simply no way around it.

2. Concerning the draft for the next standard, I'm all for it to already 
prepare STLport for the upcoming changes. However, that should be either in a 
separate feature branch or separated by a preprocessor macro which defaults 
to deactivated. I'm against basing STLport on an unreleased standard draft.

3. Concerning bug report #2001222, I'm not sure if it actually is a bug. It 
seems the standard indeed says that the write position is set to the end of 
the file before every write operation. From that doesn't follow that its 
write position must already be at the end after opening it. I find this 
wording bad, either it should require that it is positioned or explicitly 
allow it to now be positioned at the end. However, it doesn't change that 
there are _no requirements_ on the write position after opening the file!

I guess the expectations of the bug reporter were simply wrong and the use 
of 'ate' as suggested would have rather fixed his code. I'm looking forward 
to more responses on that issue from clc++m where Francois posted a similar 
question.

4. Concerning revision #3608, I actually don't like it for one simple reason: 
it does two changes at once. One change is to seek to the end after opening 
with 'app' or 'ate' instead of only after opening with 'ate'. This alone 
would have made STLport behave like the bug reporter expected. The other 
change is to allow 'app', 'in|app' and 'in|out|app' as additional opening 
modes, according to the draft standard.

5. I'm wondering, do we actually have a test that assures that 'app' behaves 
as expected?

  ofstream out("test.txt", ios_base::app);
  out << "01234";
  out.seekp(0);
  out << "56789";
  out << endl;

This must yield a file containing a single line "0123456789\n", i.e. it must 
ignore the intermediate out.seekp(0).

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

**************************************************************************************