почему первый вариант считается правильным и даже предпочтительным, а не например более правильный и более осмысленный (нет неявного преобразования char* в string) с моей точки зрения второй вариант?:
vector<string> v;
v.push_back(string("str"));
из той же оперы что и первый вариант:
string foo()
{
return"str";
}
существуют ли контейнеры отличные от std::string которые могут работать только со вторым вариантом или оба этих варианта это просто синонимы?
Re: неявное преобразование char* в string - это плохо?
От:
Аноним
Дата:
02.05.06 10:32
Оценка:
Двойной вызов конструктора ?
Re: неявное преобразование char* в string - это плохо?
"greenloki" <53992@users.rsdn.ru> wrote in message news:1876206@news.rsdn.ru... > допустим первый вариант: >
> vector<string> v;
> v.push_back("str");
>
> > почему первый вариант считается правильным и даже предпочтительным, а не например более правильный и более осмысленный (нет неявного преобразования char* в string) с моей точки зрения второй вариант?: >
> > существуют ли контейнеры отличные от std::string которые могут работать только со вторым вариантом или оба этих варианта это просто синонимы?
Неявные преобразования обычно запрещают для повышения безопасности там, где они чреваты какми-либо неприятностями. Например, запрещено неявное конструирование boost::shared_ptr по голому указателю, т.к. можно случайно сконструировать указатель на объект, который не был создан с пом. оператора new и незаметиь этого. Конструирование std::string по const char* является частой и естественной операцией, совершенно безопасной, и нет оснований запрещать неявное конструирование.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[2]: неявное преобразование char* в string - это плохо?
Здравствуйте, <Аноним>, Вы писали:
А>Двойной вызов конструктора ?
В обоих случаях может создаваться временный объект, но (5.2.2/4)
During the initialization of a parameter, an implementation may avoid the construction of extra temporaries by combining the conversions on the associated argument and/or the construction of temporaries with the initialization of the parameter
Ни на одном моем компиляторе мне не удалось добиться конструирования лишнего объекта как при передачи по значению, так и по ссылке.
ИМХО если конструктор не объявлен как explicit, то использование неявных преобразований предполагалось автором класса, так что в этом нет ничего "неправильного".
Re[3]: неявное преобразование char* в string - это плохо?
Здравствуйте, MuTPu4, Вы писали:
А>>Двойной вызов конструктора ? MTP>В обоих случаях может создаваться временный объект, но (5.2.2/4) MTP>
MTP>During the initialization of a parameter, an implementation may avoid the construction of extra temporaries by combining the conversions on the associated argument and/or the construction of temporaries with the initialization of the parameter
MTP>Ни на одном моем компиляторе мне не удалось добиться конструирования лишнего объекта как при передачи по значению, так и по ссылке.
На 6-7 визуале генерируемый код для обоих случаев одинаков и везде в push_back передается временнный объект string(раз конструктор) + в push_back-е — конструктор копирования! итого 2 (или я вас неправильно понял?)
Re[4]: неявное преобразование char* в string - это плохо?
Здравствуйте, IvnAR, Вы писали:
IAR>На 6-7 визуале генерируемый код для обоих случаев одинаков и везде в push_back передается временнный объект string(раз конструктор) + в push_back-е — конструктор копирования! итого 2 (или я вас неправильно понял?)
Из визуалов я использую версию 7.1. На простом тесте (передача параметра в свою функцию) все лишние временные объекты были элиминированы, т.е. параметр функции был непосредственно проинициализирован.
Для исходного примера с вектором не совсем ясно как интепретировать результаты. Реализация имеет право копировать переданный объект столько раз, сколько посчитает нужным. Например, в случае VC 7.1 в коде push_back содержаться еще косвенные вызовы. В любом случае, явное и неявное преобразования дали у меня одинаковый результат — создано 3 объекта, так что разницы, опять же, никакой.
Re[2]: неявное преобразование char* в string - это плохо?
" Аноним " <0@users.rsdn.ru> wrote in message news:1876244@news.rsdn.ru... > Двойной вызов конструктора ?
По количеству конструкторов эти два примера совершенно эквивалентны. Разница только лишь в том, что в первом случае конструктор вызывается неявно а во втором — явно.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[5]: неявное преобразование char* в string - это плохо?
Здравствуйте, MuTPu4, Вы писали:
MTP>Здравствуйте, IvnAR, Вы писали:
IAR>>На 6-7 визуале генерируемый код для обоих случаев одинаков и везде в push_back передается временнный объект string(раз конструктор) + в push_back-е — конструктор копирования! итого 2 (или я вас неправильно понял?) MTP>Из визуалов я использую версию 7.1. На простом тесте (передача параметра в свою функцию) все лишние временные объекты были элиминированы, т.е. параметр функции был непосредственно проинициализирован. MTP>Для исходного примера с вектором не совсем ясно как интепретировать результаты. Реализация имеет право копировать переданный объект столько раз, сколько посчитает нужным. Например, в случае VC 7.1 в коде push_back содержаться еще косвенные вызовы. В любом случае, явное и неявное преобразования дали у меня одинаковый результат — создано 3 объекта, так что разницы, опять же, никакой.
Да разницы нет; а что за 3-й объект — у меня 2(я их уже перечислял)(Правда StlPort)
Re: неявное преобразование char* в string - это плохо?
В ходе поддержки _разных_ приложений _несколько_ раз сталкивался с тем, что возвращали false так —
std::string GetFileName()
{
char some_buf[100];
if (SomeOsAPIFunction(some_buf, 100))
return some_buf;
else
[b]return false; <------------------- !!!!!!!!!!
}
[/b]
Правильно работающая программа — просто частный случай Undefined Behavior
Re: неявное преобразование char* в string - это плохо?
Hello _Winnie,
_> Здравствуйте, greenloki, Вы писали:
_> В ходе поддержки _разных_ приложений _несколько_ раз сталкивался с _> тем, что возвращали инициализировали std::string нулём или false, _> например так -
_>
Здравствуйте, khap, Вы писали:
K>А как сделать такой же функционал с std::string GetFileName() ?
K>Возвращать пустую строку неверно, т.к. это может быть вполне корректным значением.
bool GetFileName(std::string& s);
K>Бросать exception?
Как нравится
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Re[3]: неявное преобразование char* в string - это плохо?
Здравствуйте, khap, Вы писали:
K>А как сделать такой же функционал с std::string GetFileName() ?
K>Возвращать пустую строку неверно, т.к. это может быть вполне корректным значением.
_W>В ходе поддержки _разных_ приложений _несколько_ раз сталкивался с тем, что возвращали инициализировали std::string нулём или false, например так —
почему компилятор не отлавливает такие гадости?
Re[3]: неявное преобразование char* в string - это плохо?
MTP>ИМХО если конструктор не объявлен как explicit, то использование неявных преобразований предполагалось автором класса, так что в этом нет ничего "неправильного".
хорошо, то что код на выходе будет одинаковый это понятно, а читаемость? стиль кода? в c++ столько подразумеваемых действий, что лишних совсем не хочется плодить, ладно я, но если код без явного вызова конструктора увидит адепт другого языка у него уши в трубочку могут свернутся
Re[3]: неявное преобразование char* в string - это плохо?
Здравствуйте, greenloki, Вы писали:
_W>>В ходе поддержки _разных_ приложений _несколько_ раз сталкивался с тем, что возвращали инициализировали std::string нулём или false, например так — G>почему компилятор не отлавливает такие гадости?
Именно за неявного преобразвания false в (char*)NULL
Правильно работающая программа — просто частный случай Undefined Behavior
, хотя и некорректно решенная.
