Что подразумевает C++ класс с private конструктором и парным auto_ptr?

Question

[MikhailEdoshin]

Подскажите, пожалуйста — у меня имеется некое C/C++ API. Си-часть у него не совсем Си, потому что, хоть оно и объявлено extern "C", но внутри у него идет C++ код (например, используются ссылки, классы, пространства имен и т. п.; то есть единственное, что там «Си», это сохраненные имена функций). Си-плюс-плюс-часть у него представлена несколькими классами, но классы «пустые» — весь их код находится тут же в заголовочных файлах в виде inline-функций, которые, в свою очередь, вызывают методы из псевдо-Си части.

Я, соответственно, пустую часть игнорирую и работают с псевдо-Си частью. Кроме того, я работаю из обычного C — я просто передекларировал функции сам, заменяя ссылки на указатели, объявил неполные типы, где нужно и так далее. Все работает замечательно.

Но есть нюанс. Что я не совсем понимаю, так это то, что имел в виду автор исходного API. Например:

1. Функция возвращает константную ссылку, т. е.

const foo::Bar& myfunc(); 

В своем C-адаптере я переопределяю ее так:

const foo_Bar_t* myfunc();

Правильно ли я понимаю, что я не могу хранить этот указатель после возврата из функции?

2. Класс с private-конструктором и сопутствующий auto_ptr. Выглядит это так:

namespace foo {
    class Baz
    {
        private: 
            Baz();
            Baz( const Baz& source);
    };
    class BazAutoPtr: public std:auto_ptr<Baz>
    {
        public:
            inline BazAutoPtr();
    };
} 

BazAutoPtr() являет собою следующее:

inline BazAutoPtr::BazAutoPtr() {
    this->operator=(*static cast<Baz>(&std::auto_ptr<element_type>(Baz_Constructor())));
}

Здесь Baz_Constructor — это функция из псевдо-Си части, которая, собственно, создает новый Baz и возвращает указатель:

foo::Baz* Baz_Constructor();

Как я все это понимаю, объекты foo::Baz напрямую создавать нельзя, только через auto_ptr. Код в BazAutoPtr() вызывает реальный конструктор и подменяет там только что созданный пустой объект. Я также представляю смысл auto_ptr — выделить объект в куче и автоматом его удалить при выходе из функции. Что я не понимаю, так это что имел в виду автор API, сооружая вот эту конструкцию? Имел ли он в виду, что я вообще не должен хранить экземпляры foo::Baz или же что-то другое?

(Чисто технически я их храню пока без видимых последствий; но кто его знает.)

Answer 1

[Monnoroch]

Мне кажется, с таким подходом вы все равно словите полсотни разных UB, так что в любом случае не советую так делать, а советую писать обертки. А автор кода очень странный. Мало того, что auto_ptr уже давно deprecated, так еще и наследоваться от него — это явно стремно. Резюмируя, тут автор что угодно мог подразумевать, от синтаксического сахара, до каких-то правил использования, и мне кажется, кроме как спросить его, нет способа понять.

Comments

[MikhailEdoshin]

Мне на выходе все равно Си нужен — у меня Питон к этому подключен — так что если я напишу какие-то обертки, мне все равно придется как-то типы в Си переводить и решать ровно ту же проблему — зачем тут константная ссылка и auto_ptr. Да, наверное, пойду авторам писать. (Тут еще беда в том, что продукт коммерческий и писать не совсем ясно, кому, не поддержке же индийской и не менеджерам, но вроде где-то у меня было что-то более прямое.)

[Лолшто]

Для питона на С++ есть boost.python. Недавно о нем статья на хабре была, кстати.

[nicolausYes]

auto_ptr уже давно deprecated

auto_ptr deprecated только с версии C++11, так что не так уж давно. Многие компиляторы еще не поддерживают новый стандарт (например, на работе приходится писать в VS2010).

А унаследоваться от auto_ptr, согласен, как минимум странно.

[MikhailEdoshin]

boost.python, наверное, хорош если у меня есть мой C++ код, про который я все знаю, и которым сам командую, а тут у меня прослойка между чужим приложением и питоном, тут, боюсь, не выйдет. (Ну и я уже написал все и оно, в общем, работает без сучка и без задоринки, во всяком случае в моих тестах — я больше перестраховываюсь, люблю я поперестраховываться :)

Да, основное приложение там на сегодняшний день скомпилировано в MS VS v9 (2008), а API в этом виде идет еще с 2004 года, какие уж там были компиляторы и стандарты, не знаю. А я, признаться, думал, это какая-то стандартная идиома — класс, который нельзя создать, и auto_ptr к нему — теперь знаю, что это самобытное творчество :)

Answer 2

[Лолшто]

const foo::Bar& myfunc(); 

В своем C-адаптере я переопределяю ее так:

const foo_Bar_t* myfunc();

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

Правильно ли я понимаю, что я не могу хранить этот указатель после возврата из функции?

Все зависит от того, что делает функция:

const int g = 1;
struct S
{
	const int & foo() const
	{
		return v;
	}
	const int & bar() const
	{
		return g;
	}
	int v = 0;
};

const int & foobar()
{
	S s;
	//return s.foo(); // oops
	return s.bar(); //ok
}

int main(int argc, char const *argv[])
{
	return foobar();
}

Дальше у вас идет некорректный код:
Как должен работать static_cast от std::auto_ptr<Baz>* в Baz?
Я предполагаю, что у вас там на самом деле написано:

this->operator=(*static_cast<BazAutoPtr*>(&std::auto_ptr<element_type>(Baz_Constructor())));

Что в общем тоже неопределенное поведение, потому что
— error: taking address of temporary
— static_cast объекта к типу, объектом которого он на самом деле не является.

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

inline BazAutoPtr():std::auto_ptr<Baz>(Baz_Constructor()){}

В общем, самый дельный совет тут — завязывать с кодом, в котором такое написно.

Comments

[Door]

Ошибся

[MikhailEdoshin]

Ну там по-любому не на глобальную переменную ссылка возвращается. По контексту там происходит вычисление выражения, вроде как в Excel, и по ходу вызывается моя функция (я пишу плагин), с передачей в нее некоторых параметров, и в принципе, технически имеет полный смысл передавать только ссылки, не копии, и кроме того, нет никакой гарантии, что переданный параметр будет существовать после вызова, потому что он мог быть только что собран перед вызовом и будет немедленно удален после. Я сопоставил это с чтением всяких мануалей — да вот хоть на SO было: «the rule of thumb is never rely on a const-reference existing beyond the lifetime of the function that receives it as a parameter» — и пришел к выводу, что да, авторы, похоже, имели в виду все-таки именно это. Хотя там довольно кривое API, но все-таки, какая-то логика должна быть. Что я и делаю — я такие объекты помечаю для себя как «хрупкие» и работаю с ними не так, как с собственными.

А сейчас вот стал перечитывать код, который создает мои собственные объекты, и задумался. Технически там объект мой — я получаю нормальный указатель на него, могу его редактировать и отвечаю за его удаление. Но вот этот auto_ptr меня смутил. (Да, и этот хитромудрый конструкт — это reset(), я просто переписал не ту версию, в Win32 у них почему-то такой вот костыль.)

(Насчет указателей — по стандарту да, но в моем случае, ссылки работают как родные, а другие платформы там вряд ли появятся. Код уж какой есть — хорошо бы более вменяемый, но неоткуда взять :) С другой стороны, where there's muck, there's brass, криво, конечно, но отчасти на этом я и рассчитываю заработать — я поверх этого ужаса-ужаса ставлю нормальное API для Python).

[Door]

если не на глобальную и если это не ссылка на объект, которые живёт больше, чем вызов ф-и, и если это не ссылка, на объект выделенный в куче (т.е., что-то типо *(new foo_Bar_t)), тогда всё плохо.
Может это ф-я класса, которая возвращает константную ссылку на внутренний элемент? что-то этого:

struct MyStruct
{
	int val;
	
	MyStruct()
		: val(0)
	{
	}

	const int& get() const
	{
		return val;
	}
};

{
MyStruct obj;
const int& val = obj.get();
// using val
}

тогда всё нормально.

[Лолшто]

he rule of thumb is never rely on a const-reference existing beyond the lifetime of the function that receives it as a parameter

относится к другому случаю: не сохранять ссылки на параметры функции:

struct S
{
S(const int& v):v(v){} //this is bad
const int& v;
}

int main()
{
S s(6); //because this can happen
std::cout << s.v;
}

[MikhailEdoshin]

Тут проблема в том, что функция получает литерал? Я понимал это так: вот есть у меня функция, согласно API она будет вызвана с константными ссылками (int foo(Bar& bar, Baz& baz)) — все это как бы намекает, что bar и baz хранит не стоит, если только из контекста или документации не следует обратное. В любом случае, я их и не храню, если нужно, делаю копию, так что это не так важно. Меня больше фокус с auto_ptr волновал, я думал, это какая-то идиома :)

[Лолшто]

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

Причем, все это относится только к константным ссылкам. Если дано int foo(int& bar), то нельзя будет написать foo(3), или foo(sin(5)).

Answer 3

[Door]

Думаю, в первом случае, лучше всего будет вернуть просто foo_Bar_t (зависит от того, что внутри foo_Bar_t).
А второе — бредятина полная: нельзя наследоваться от std:auto_ptr… В std:auto_ptr не переопределён оператор взятия адреса (operator&) и приведение типа std:auto_ptr<Baz>* в Baz — не должно скомпилироваться. И если уже писать такой бред, то, наверное, лучше сделать так:

inline BazAutoPtr::BazAutoPtr()
{
    reset(Baz_Constructor());
}

Comments

[Door]

И оператор присваивания в Baz уже тогда сделайте закрытым — наверное, и присваивать нельзя экземпляры этого класса.

[MikhailEdoshin]

Точно; там, собственно, так и есть в той версии, что для gcc; а я не заметив, переписал Win32 вариант. Под Windows, во всяком случае, эта конструкция работает. А для gcc там действительно reset; я еще, помню, долго вкуривал, что это за reset такой.

Внутри foo_Bar_t ничего, это неполный тип, я объявляю его просто как typedef struct foo_Bar foo_Bar_t и дальше работаю исключительно с указателями. (У них там в псевдо-Си вообще void* всякий раз, когда по смыслу нужен экземпляр (this), но я наклепал все-таки разных типов для удобства.)

[Лолшто]

Для того, чтобы вернуть foo_Bar_t по значению, она должна быть определена (defined) в С коде, и соответственно должна быть POD.

[Door]

да, конечно, должна быть определена в С коде (что, думаю, так и есть).
А что мешает в С++ мне вернуть не POD тип по значению? А в С — все структуры POD ведь.

[Лолшто]

Определена, а не объявлена. А согласно принципу одного определения, структура должна быть определена одинаково и в С и в С++ коде. То есть только POD.
Пример, почему это важно: в С++ у класса может быть задан конструктор копирования, а в С коде — нет. Поэтому вернуть по значению объект такого класса С коду нельзя.

[Door]

Я не пойму:

А согласно принципу одного определения, структура должна быть определена одинаково и в С и в С++ коде

Вы противоречете сами себе — согласно принципу одного определения — тип должен быть определён только один раз, как ни странно.
Что значит «структура должна быть определена одинаково и в С и в С++ коде»? Это как?

[Лолшто]

Door, возможно, я не совсем корректно выразился. Согласно приниципу одного определения класс должен быть определен только одним способом. Если класс определен как

class S
{
public:
std::string text;
};

То он должен быть определен так всюду. И такой класс, очевидно, нельзя передать в С код.