The short version
It truncates by default.
The medium version
The standard is basically spaghetti on this, but it eventually boils down to saying that it's the equivalent of saying fopen(const char*, "w")
(27.9.1.4 [filebuf.members]), which then points us towards the ISO C 7.9 standard.
Checking that out provides us with §7.19.5.3, "The fopen function", which specifies the behavior when "w" is passed:
w truncate to zero length or create text file for writing
The long version
If you'd like to follow the spaghetti trail yourself, start with 27.9.1.11 [ofstream.cons], which describes the constructor's behavior as
Effects: Constructs an object of class basic_ofstream<charT,traits>
, initializing the base class with
basic_ostream(&sb
) and initializing sb
with basic_filebuf<charT,traits>())
(27.7.3.2, 27.9.1.2),
then calls rdbuf()->open(s, mode|ios_base::out)
. If that function returns a null pointer, calls
setstate(failbit)
.
Where rdbuf()
returns basic_filebuf<charT,traits>*
(27.9.1.13 [ofstream])
Which leads us to 27.9.1.1 [filebuf], or more specifically, 27.9.1.4 [filebuf.members] , which describes the open
function:
basic_filebuf<charT,traits>* open(const char* s, ios_base::openmode mode);
as
Effects: If is_open() != false
, returns a null pointer. Otherwise, initializes the filebuf as required.
It then opens a file, if possible, whose name is the NTBS s
(as if by calling std::fopen(s,modstr)
).
The NTBS modstr
is determined from mode & ~ios_base::ate
as indicated in Table 132. If mode is
not some combination of flags shown in the table then the open fails.
NTBS: Null-terminated byte-string
Table 132 describes equivalence rules between C++ ios_base::openmode
and C-style stdio strings:
Table 132 — File open modes
|
| 'ios_base' flag combination | 'stdio' equivalent |
| binary | in | out | trunc | app | |
| | | + | | | "w" |
| etc... |
Which leads us to a footnote on the same page that states:
...the function signatures fopen(const char*, const char*)
and fseek(FILE*, long,
int)
are declared, in <cstdio>
(27.9.2).
Which sends us, predictably, to 27.9.2 [c.files], which provides the nearly useless Table 134, but then references the C standard:
See also: ISO C 7.9, Amendment 1 4.6.2.
Which I talk about in the main portion of this answer.