basic_ifstream( );
explicit basic_ifstream(
const char *_Filename,
ios_base::openmode _Mode = ios_base::in,
int _Prot = (int)ios_base::_Openprot
);
_Prot - The default file opening protection.
Полная версия: PIL Image.fromstring
ну а vs2008 ест.
msdn. basic_ifstream
msdn. _fsopen
короче, это расширение компилятора, которое не имеет отношения к C++
msdn. _fsopen
shflag
Type of sharing allowed.
_SH_COMPAT
Sets Compatibility mode for 16-bit applications.
_SH_DENYNO
Permits read and write access.
_SH_DENYRD
Denies read access to the file.
_SH_DENYRW
Denies read and write access to the file.
_SH_DENYWR
Denies write access to the file.
короче, это расширение компилятора, которое не имеет отношения к C++
py.user.next
fstream - уже поток ввода
Я имел ввиду две вещи:
1 запятую
2 http://www.rsdn.ru/forum/cpp/2278257.1.aspx :
“В конструкторах и методах open() присутствует второй параметр, определяющий режим открытия потока. Открытие файлового потока для чтения/записи не зависит от типа объекта, объявляемого в программе — этот тип определяет только режим открытия по умолчанию при отсутствии второго аргумента. Это означает, что поток типа istream вполне можно открывать и для записи тоже, а поток ofstream — для чтения. Однако операции, разрешенные для объявленного объекта, определяются классом потока данных.”
Если вы просто передаете вторым аргументом std::ios::binary то неявно сбрасываете флаг std::ios::in и получаете поток который и не in и не out. Поведение в этом случае будет определяться реализацией потрохов используемого компилятора. Поэтому всегда считал что в этом случае лучше применять в c++ питоновский подход. Явное задание флагов лучше неявного.
doza_andopen-std. C++. n3242
Если вы просто передаете вторым аргументом std::ios::binary то неявно сбрасываете флаг std::ios::in и получаете поток который и не in и не out.
Такой вот он, “Python для экспертов”…