Конструкторы ofstream и стандарт C++11 и компилятор gcc необходимо разобраться

@kravam · Регистрация: 04.06.2008

Студворк — интернет-сервис помощи студентам

Друзья! Условимся, что компилятор g++ поддерживает этот стандарт, ибо ошибок, говорящих об обратном не замечено вроде.

C++
1
2
3
4
5
6
7
8
//main.cpp
#include <fstream>
using namespace std;
int main()
{
   ofstream of("f.txt");
   ofstream of_(of);
}

команда g++.exe main.cpp и простыня ошибок

C:\mingw32\bin>g++.exe main.cpp
In file included from C:/mingw32/i686-w64-mingw32/include/c++/ios:42:0,
from C:/mingw32/i686-w64-mingw32/include/c++/istream:38,
from C:/mingw32/i686-w64-mingw32/include/c++/fstream:38,
from main.cpp:2:
C:/mingw32/i686-w64-mingw32/include/c++/bits/ios_base.h: In copy constructor 'std::basic_ios<char>::
basic_ios(const std::basic_ios<char>&)':
C:/mingw32/i686-w64-mingw32/include/c++/bits/ios_base.h:786:5: error: 'std::ios_base::ios_base(const
std::ios_base&)' is private
ios_base(const ios_base&);
^
In file included from C:/mingw32/i686-w64-mingw32/include/c++/ios:44:0,
from C:/mingw32/i686-w64-mingw32/include/c++/istream:38,
from C:/mingw32/i686-w64-mingw32/include/c++/fstream:38,
from main.cpp:2:
C:/mingw32/i686-w64-mingw32/include/c++/bits/basic_ios.h:66:11: error: within this context
class basic_ios : public ios_base
^
In file included from main.cpp:2:0:
C:/mingw32/i686-w64-mingw32/include/c++/fstream: In copy constructor 'std::basic_ofstream<char>::bas
ic_ofstream(const std::basic_ofstream<char>&)':
C:/mingw32/i686-w64-mingw32/include/c++/fstream:602:11: note: synthesized method 'std::basic_ios<cha
r>::basic_ios(const std::basic_ios<char>&)' first required here
class basic_ofstream : public basic_ostream<_CharT,_Traits>
^
In file included from C:/mingw32/i686-w64-mingw32/include/c++/ios:43:0,
from C:/mingw32/i686-w64-mingw32/include/c++/istream:38,
from C:/mingw32/i686-w64-mingw32/include/c++/fstream:38,
from main.cpp:2:
C:/mingw32/i686-w64-mingw32/include/c++/streambuf: In copy constructor 'std::basic_filebuf<char>::ba
sic_filebuf(const std::basic_filebuf<char>&)':
C:/mingw32/i686-w64-mingw32/include/c++/streambuf:802:7: error: 'std::basic_streambuf<_CharT, _Trait
s>::basic_streambuf(const std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char; _Traits = std
::char_traits<char>]' is private
basic_streambuf(const basic_streambuf& __sb)
^
In file included from main.cpp:2:0:
C:/mingw32/i686-w64-mingw32/include/c++/fstream:72:11: error: within this context
class basic_filebuf : public basic_streambuf<_CharT, _Traits>
^
C:/mingw32/i686-w64-mingw32/include/c++/fstream: In copy constructor 'std::basic_ofstream<char>::bas
ic_ofstream(const std::basic_ofstream<char>&)':
C:/mingw32/i686-w64-mingw32/include/c++/fstream:602:11: note: synthesized method 'std::basic_filebuf
<char>::basic_filebuf(const std::basic_filebuf<char>&)' first required here
class basic_ofstream : public basic_ostream<_CharT,_Traits>
^
main.cpp: In function 'int main()':
main.cpp:8:19: note: synthesized method 'std::basic_ofstream<char>::basic_ofstre am(const std::basic_
ofstream<char>&)' first required here
ofstream of_(of);
^

C:\mingw32\bin>

ЧЯДНТ? Здесь увидел синтаксис C++11. Спасибо, кто откликнется.

@0x10 · 26.09.2014, 13:48

Сообщение от kravam

Реально не могу взять в толк. Разработчики включили нечто (конструктор) в новый стандарт. Потом переиграли, этот же конструктор удалили и известили нас об этом? Чё-то здесь не то...

По порядку.
1. Копировать поток нельзя по очевидным причинам. Следовательно, нужен механизм, запрещающий пользователю использовать операции копирования - конструктор копирования и оператор присваивания.
2. Для того, чтобы добиться этого в предыдущем стандарте, приходилось конструктор копирования и оператор присваивания помещать в приватную часть, закрывая тем самым от пользователя. Закрытые части классов не документируются для конечного пользователя.
3. Пункт 2 - это хак, поскольку невозможно запретить использования этих методов внутри самого класса. Разве что можно было поместить в приватную часть объявления, не снабжая их определениями. Но см выше - это хак.
4. В новом стандарте появился более семантичный способ удаления методов - и он уже включается в документацию, поскольку является такой же полноценной спецификацией интерфейса как для пользователей, так и для разработчиков библиотеки.

@kravam · 26.09.2014, 13:49 **[ТС]**

Сообщение от aLarman

просто появился синтексис позволяющий этот конструктор явно удалить, вот они и написали про него, никто его в этот класс не включал!

Зачем они про него написали?

Я сейчас пишу программу, у меня там куча всяких временных переменных, функций, есть отдельный экзешник для тестирования. Но по окончании работ я удалю из исходников все отладочные надписи, все временные переменные и вспомогательные функции, чтобы не спотыкаться об них, они черновик. Всё, что не работает- всё удалю. Если всё это оставлять, даже в закомменченном виде, как потом работать с исходниками? Ужас! А тут нам говорят- оказывается, в процессе работы над классом ofstream был у нас такой конструктор, но потом мы его удалили. Мне, как пользователю класса зачем знать, что когда-то у разработчиков был какой-то инструмент (конструктор), которым я в потенциале мог бы пользоваться, но которым я пользоваться не буду потому, что его забраковали? Незачем. Поэтому тут что-то не то.

Tulosba · 26.09.2014, 14:15

Сообщение от kravam

классом ofstream был у нас такой конструктор, но потом мы его удалили.

Всё не так. Зачем из сообщения к сообщению повторять одну и ту же неправильно понятую информацию?

Некоторые функции, в частности копирующий конструктор создаются для класса по умолчанию, даже если они не объявлены явно. Версия по умолчанию просто осуществляет почленное копирование полей. Но если такое поведение не соответствует семантике класса, то возможны варианты: либо пишут свой копирующий конструктор (если объект разрешается копировать) или объявляют его как deleted (раньше, до С++11, это делалось помещением объявления копирующего конструктора в private секцию, без определения оного), если копирование не предполагается.

Можно бы и в Стандарт заглянуть по теме deleted функций (8.4.3 Deleted definitions)

@DrOffset · 26.09.2014, 17:03

Сообщение от kravam

Ужас! А тут нам говорят- оказывается, в процессе работы над классом ofstream был у нас такой конструктор, но потом мы его удалили. Мне, как пользователю класса зачем знать, что когда-то у разработчиков был какой-то инструмент (конструктор), которым я в потенциале мог бы пользоваться, но которым я пользоваться не буду потому, что его забраковали? Незачем. Поэтому тут что-то не то.

Выше уже все объяснили. Я просто добавлю.
Понимаешь ли какая вещь, языки развиваются не только в направлении возможности что-то сделать, но и в направлении улучшить самодокументируемость кода.
Знаком с понятием контракт?
Например в С++ есть const. Этот const на самом деле не нужен для решения задачи. Мы можем просто помнить какие объекты для нас константы, а какие нет. Правда ведь?
Но помнить это утомительно. Тем более, если кто-то другой будет смотреть наш код, то он, естественно, никогда не узнает какие объекты мы задумали const, а какие нет.
Гораздо проще переложить это на компилятор, пусть он следит, что константно, а что нет. И другой программист никогда не ошибется, компилятор ему не позволит - напомнит. Иными словами const - это способ описания контракта.
Теперь к текущей теме. В соответствии с архитектурой потоков их копировать не имеет смысла. Поток - всегда уникален. Однако в С++ конструктор копирования автоматически генерируется. Мы можем просто написать в документации, что поток копировать нельзя. Но язык позволит это сделать, позволит совершить логическую ошибку - нарушить контракт. И ее обязательно кто-то совершит, т.к. (почти) никто не читает документацию. Это проблема. В С++03 не было языкового средства установить контракт отсутствия копирования (т.е. не было синтаксиса позволяющего указать, что объект класса копировать нельзя, так же как мы можем установить, что объект класса нельзя изменить посредством const). Поэтому для этих целей использовался хак, который описал 0x10 выше (перечитай его пост пожалуйста). В С++11 появилось языковое средство это сделать, без хака. Это средство позволяет пометить функцию класса невозможной к использованию (удалить). Семантически же поведение потоков в С++11 не изменилось, как нельзя их было копировать в С++03, так нельзя их копировать и в С++11, изменилось только средство позволяющее предостеречь пользователя класса от нарушения контракта.

@kravam · 26.09.2014, 19:23 **[ТС]**

Но ведь эти дядьки сами собирают компилятор, почему они делают так, чтобы

1) конструктор копирования всегда вызывался (даже если он вызывается объектом типа ofstream), а потом сами аккуратно так, как им кажется, делают так, чтобы
2) этот конструктор не вызывался, (объявляют его delete).

А почему они сразу-то не делают, чтобы он вызывался не во всех случаях? Это же не так, что им дали компилятор собранный, а они бедолаги думают, как бы сделать, чтобы конструктор копирования не вызывался (чтобы поток был один) нет, они его сами и собирают с нуля. Почему ж так-то?

@0x10 · 26.09.2014, 19:29

Сообщение от kravam

конструктор копирования всегда вызывался (даже если он вызывается объектом типа ofstream)

Эм... Что?

@DrOffset · 26.09.2014, 19:30

Сообщение от kravam

А почему они сразу-то не делают, чтобы он вызывался не во всех случаях? Это же не так, что им дали компилятор собранный, а они бедолаги думают, как бы сделать, чтобы конструктор копирования не вызывался (чтобы поток был один) нет, они его сами и собирают с нуля. Почему ж так-то?

При чем тут вообще компилятор? Стандартная библиотека - это такой же код, совершенно обычный. И играет он по тем же правилам, что и любой другой код. А правила описаны в стандарте ISO\IEC на язык С++.

@0x10 · 26.09.2014, 19:31

Сообщение от kravam

А почему они сразу-то не делают, чтобы он вызывался не во всех случаях?

Некоторые методы генерируются компилятором. В частности - КК. Логика такая: "Если объект может быть создан, то он может быть и скопирован". Особые случаи должны быть реализованы программистом.

@kravam · 26.09.2014, 19:32 **[ТС]**

Я говорю, компилятор всегда добавляет конструктор копирования. Так почему он добавляет конструктор копирования в класс ofstream? Ну кто-то же этот компилятор делал! Почему так сделали-то? Ну ладно при царе горохе, согласен. Но щас-то все всё осмыслили и всё равно его так собирают.

@0x10 · 26.09.2014, 19:34

Сообщение от kravam

Так почему он добавляет конструктор копирования в класс ofstream?

Пардон, это предложение обрабатывать класс с именем ofstream как особый случай? Если так - даже не знаю как прокомментировать такое решение.

@DrOffset · 26.09.2014, 19:45

Сообщение от kravam

Я говорю, компилятор всегда добавляет конструктор копирования. Так почему он добавляет конструктор копирования в класс ofstream? Ну кто-то же этот компилятор делал! Почему так сделали-то? Ну ладно при царе горохе, согласен. Но щас-то все всё осмыслили и всё равно его так собирают.

Ты не читаешь, что я написал? Код в стандартной библиотеки ничем не отличается от другого кода, который данный компилятор собирает. Стандартная библиотека это не часть ядра языка. Ее можно заменить на другую совершенно свободно или вообще исключить из состава компилятора, если того требует задача.

Добавлено через 3 минуты

Сообщение от kravam

Но щас-то все всё осмыслили и всё равно его так собирают.

Вообще, если ты пишешь возражения подобные этому, то ты либо не понял вот этот пост, либо проигнорировал его. Если не понял, то так и скажи, я объясню еще раз. Если проигнорировал, то, пардон, сказать мне больше нечего.

@kravam · 26.09.2014, 20:02 **[ТС]**

Сообщение от DrOffset

Код в стандартной библиотеки ничем не отличается от другого кода, который данный компилятор собирает. Стандартная библиотека это не часть ядра языка. Ее можно заменить на другую совершенно свободно или вообще исключить из состава компилятора, если того требует задача.

да? Ну тогда на пальцах. Библиотека pthread и wx немножко конфликтуют друг с другом у меня на компе. Они скачаны из разных мест и собраны разными разработчиками. Парням из pthread плевать на парней из wx, поэтому все конфликты должен разрешать я.

Но компилятор сделан так, что
a) КК вызывается всегда
б) После чего на него повешена мулька в виде delete о которую все- ах, простите, не все, а такие как я- спотыкаются, и после повешения этой мульки КК перестаёт вызываться.
в) И это сделал ОДИН И ТОТ ЖЕ человек, или одна команда разработчиков.

++++++++++++++++++++++++++++++++++++++++ +++++++++++

Если бы я качнул ofstream или как там она называется (std) отдельно он g++, может и вопроса бы такого нет возникло! Действительно, Петя сделал чтобы g++ ВСЕГДА вызывал KK, а Вася, который разрабатывал std сделал так, чтобы этого не было с помощью delete. Всё логично. Мне щас если самому понадобится использовать delete при создании некоторых классов, я и сам буду это делать.

Но если бы я кропал компилятор, я бы сразу сделал, чтобы при создании этих классов КК не вызывался. Безо всяких delete. Это же правильно? Правильно. Но так не было сделано для класса ofstream. Не может же это быть простым недосмотром.

(Пример: у меня в ту же библиотеку wx ЖЁСТКО зашит макрос UNICODE И никак его не отменить. Вот то есть никак. Вот то есть изначально компилятор сделан ТАК. То есть они как хотят так и делают.)

@0x10 · 26.09.2014, 20:05

Сообщение от kravam

a) КК вызывается всегда

Только если он есть и вызван в коде.

Добавлено через 1 минуту

Сообщение от kravam

Но если бы я кропал компилятор, я бы сразу сделал, чтобы при создании этих классов КК не вызывался. Безо всяких delete. Это же правильно? Правильно. Но так не было сделано для класса ofstream. Не может же это быть простым недосмотром.

Как отличить класс ofstream от остальных, чтобы применить для него специальное правило? Он не встроен в компилятор. Вообще я начинаю повторять то, что уже сказал DrOffset,

@DrOffset · 26.09.2014, 20:14

Сообщение от kravam

Это же правильно? Правильно.

Нет, не правильно. Это не правильно для С++, т.к. в этом случае пришлось бы делать стандартную библиотеку частью ядра языка, а это противоречит духу и философии С++.

Сообщение от kravam

Не может же это быть простым недосмотром.

Это не недосмотр, а парадигма. Выносим в библиотеки функциональность, а язык предоставляет только базовые возможности. А коль скоро библиотека отдельно, а язык отдельно, то и исключений никаких быть не может. Особенно таких жутких, как предложенное.

Добавлено через 2 минуты

Сообщение от kravam

Пример: у меня в ту же библиотеку wx ЖЁСТКО зашит макрос UNICODE И никак его не отменить. Вот то есть никак. Вот то есть изначально компилятор сделан ТАК. То есть они как хотят так и делают.)

Причем тут компилятор, опять же? Макрос зашит при компиляции (конфигурации) библиотеки wx. Я же тебе про это писал. Если очень необходимо его отменить, то нужно перекомпилировать библиотеку wx (между прочим этим же компилятором) без флага UNICODE (и об этом я тоже писал). Это все область ответственности конкретной библиотеки, а не компилятора.

@kravam · 26.09.2014, 20:21 **[ТС]**

Сообщение от 0x10

Только если он есть и вызван в коде.

Ну я имел ввиду он всегда добавляется компилятором по умолчанию.

Сообщение от 0x10

Он не встроен в компилятор.

Ну может быть не встроен, я не знаю, может нет таких способов определить. А может есть. Ладно, не буду настаивать, невежество своё показывать не буду. Я и так устал уже. А ещё куча вопросов нерешённых. Поехали разбираться с delete:

/////////////////////////////////////////////////////////

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
class x
{
 public:
 x () {}
 x (const x&)=delete;
};
 
 
int main()
{
 x x_0;
 x x_1(x_0);
}

C:\mingw32\bin>g++.exe main.cpp
main.cpp:9:15: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++
11
x (const x&)=delete;
^
main.cpp: In function 'int main()':
main.cpp:16:11: error: use of deleted function 'x::x(const x&)'
x x_1(x_0);
^
main.cpp:9:2: note: declared here
x (const x&)=delete;
^

C:\mingw32\bin>

Я, грешник, частенько игнорирую предупреждения, но не в этот раз. Перевёл как: функции по умолчанию и удалённые доступны только с параметром -std=c++11 or -std=gnu++11

Так это всё-таки они доступны (пусть даже ТОЛЬКО с этим опциями)? Проверить не могу, 4.9.1 эти опции игнорирует...

@0x10 · 26.09.2014, 20:23

Сообщение от kravam

Так это всё-таки они доступны (пусть даже ТОЛЬКО с этим опциями)?

Возможность удаления функций доступна с опцией -std=c++11

Добавлено через 35 секунд

Сообщение от kravam

Ну может быть не встроен, я не знаю, может нет таких способов определить.

Открыть заголовочный файл и убедиться, что это обычный библиотечный код.

@kravam · 26.09.2014, 20:27 **[ТС]**

ПРошу прощения, зарапортовался я, всё нормально в этой части.

C++
1
2
3
4
5
6
7
8
9
10
C:\mingw32\bin>g++.exe main.cpp -std=c++11
main.cpp: In function 'int main()':
main.cpp:12:11: error: use of deleted function 'x::x(const x&)'
  x x_1(x_0);
           ^
main.cpp:5:2: note: declared here
  x (const x&)=delete;
  ^
 
C:\mingw32\bin>

ругается, как и ДОЛЖЕН ругаться.

Добавлено через 3 минуты

Сообщение от 0x10

Открыть заголовочный файл и убедиться, что это обычный библиотечный код.

В заголовочном я вряд ли увижу код!

@0x10 · 26.09.2014, 20:31

Сообщение от kravam

В заголовочном я вряд ли увижу код!

Да ладно? https://gcc.gnu.org/onlinedocs... ource.html

@kravam · 26.09.2014, 20:41 **[ТС]**

Ты хочешь сказать, всё это хозяйство всякий раз перекомпилируется? Я думал всё уже скомпилено, линковщик линкует только и всё.

@0x10 · 26.09.2014, 20:44

Сообщение от kravam

Ты хочешь сказать, всё это хозяйство всякий раз перекомпилируется?

STL вся на шаблонах, а шаблоны нельзя скомпилировать и уложить в объектный файл, поскольку в точке инстанцирования нужно полное определение.

Новые блоги и статьи Все статьи Все блоги /
Установка нескольких штампов электронной подписи в строго определенных местах файла docx ВладимирСамохин 19.07.2026 (В!) Работа с Электронной подписью - это неотъемлемая часть современного документооборота. Но что делать, если нужно поставить несколько штампов электронной подписи в строго определенных местах. . .	сукцессия 35. Научная статья о проделанной работе anaschu 19.07.2026 Написал в формате латекс и пдф	Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ начало и оглавление - Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование. . .	сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .
32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .	сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .	Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,705
	26.09.2014, 19:23 [ТС]
	Но ведь эти дядьки сами собирают компилятор, почему они делают так, чтобы 1) конструктор копирования всегда вызывался (даже если он вызывается объектом типа ofstream), а потом сами аккуратно так, как им кажется, делают так, чтобы 2) этот конструктор не вызывался, (объявляют его delete). А почему они сразу-то не делают, чтобы он вызывался не во всех случаях? Это же не так, что им дали компилятор собранный, а они бедолаги думают, как бы сделать, чтобы конструктор копирования не вызывался (чтобы поток был один) нет, они его сами и собирают с нуля. Почему ж так-то? 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,705
	26.09.2014, 19:32 [ТС]
	Я говорю, компилятор всегда добавляет конструктор копирования. Так почему он добавляет конструктор копирования в класс ofstream? Ну кто-то же этот компилятор делал! Почему так сделали-то? Ну ладно при царе горохе, согласен. Но щас-то все всё осмыслили и всё равно его так собирают. 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,705
	26.09.2014, 20:41 [ТС]
	Ты хочешь сказать, всё это хозяйство всякий раз перекомпилируется? Я думал всё уже скомпилено, линковщик линкует только и всё. 0