1. почему name() возвращает не std::string?
2. зачем деструктор виртуальный? наследоваться от этого класса всё равно вряд ли кому нибудь надо...

Здравствуйте, Tom, Вы писали:

T> 1. почему name() возвращает не std::string?

Потому что строки, которые он возвращает, вполне могут быть статическими
данными, соответственно, копирование их в std::string — дополнительные
накладные расходы.

Здраствуйте, Tom. Вы писали:

T> 1. почему name() возвращает не std::string?
Наверное, чтобы не зависеть от реализации std::string.
Кстати, примерно с полгода назад в форуме обсуждался тот факт, что name() можно использовать только в отладочных целях, потому что результат, который она возвращает никак не регламентирован.

T> 2. зачем деструктор виртуальный? наследоваться от этого класса всё равно вряд ли кому нибудь надо...
А вдруг потребуется? Например, разработчик компилятора захочет расширить интерфейс класса.

Здравствуйте, Tom, Вы писали:

Tom>1. почему name() возвращает не std::string?
А чем это лучше const* char?

Tom>2. зачем деструктор виртуальный? наследоваться от этого класса всё равно вряд ли кому нибудь надо...
Ну, я бы не стал этого утверждать. Возможности класса type_info не очень велики , поэтому легко представить ситуацию, когда эти возможности кому-то потребуется расширить. Сделать это за счет наследования — один из вариантов, при этом виртуальный деструктор вполне может пригодиться.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Tom, Вы писали:

T>> 1. почему name() возвращает не std::string?

ПК>Потому что строки, которые он возвращает, вполне могут быть статическими
ПК>данными, соответственно, копирование их в std::string — дополнительные
ПК>накладные расходы.

не аргумент
так как тогда вообще зачем std::string
тем более, что копировать/или нет — зависит от реализации STL

Здравствуйте, Tom, Вы писали:

T>>> 1. почему name() возвращает не std::string?

ПК>>Потому что строки, которые он возвращает, вполне могут быть статическими
ПК>>данными, соответственно, копирование их в std::string — дополнительные
ПК>>накладные расходы.

Tom>не аргумент
Tom>так как тогда вообще зачем std::string
Tom>тем более, что копировать/или нет — зависит от реализации STL
ИМХО просто тип-инфо раньше стринга появился, вот и все.

Здравствуйте, Tom, Вы писали:

T> так как тогда вообще зачем std::string

Для замены p = new char[...] ... strcpy ... strlen ... delete [] p ...

T> тем более, что копировать/или нет — зависит от реализации STL

Я не знаю ни одной реализации, в которой можно было бы "привязать"
std::string к статической const char*, избегая копирования.

LVV>ИМХО просто тип-инфо раньше стринга появился, вот и все.

Нет, это не аргумент. Просто себестоимость слишком велика. Сравни:

const char* get_name_1()
{
   return "hello";
}

std::string get_name_2()
{
   return std::string("hello");
}

Здравствуйте, Tom, Вы писали:

Tom>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>Здравствуйте, Tom, Вы писали:

T>>> 1. почему name() возвращает не std::string?

ПК>>Потому что строки, которые он возвращает, вполне могут быть статическими
ПК>>данными, соответственно, копирование их в std::string — дополнительные
ПК>>накладные расходы.

Tom>не аргумент
Tom>так как тогда вообще зачем std::string
Tom>тем более, что копировать/или нет — зависит от реализации STL

Мое ИМХО такое: реализяция type_info это часть CRT, а о стринге такого сказать нельзя. Разве лучшим решением будет в CRT запихать реализацию стрингов или тянуть за собой еще что нибудь.

Здравствуйте, Tom, Вы писали:

T>>> 1. почему name() возвращает не std::string?

ПК>>Потому что строки, которые он возвращает, вполне могут быть статическими
ПК>>данными, соответственно, копирование их в std::string — дополнительные
ПК>>накладные расходы.

Tom>не аргумент
Tom>так как тогда вообще зачем std::string
Tom>тем более, что копировать/или нет — зависит от реализации STL

Ещё потому, что type_info — внутренняя структура С++, её рожает компилятор.
А std::string — это авторская разработка той или иной компании; как захочу, так и сделаю.

Здравствуйте, Кодт, Вы писали:

К> Ещё потому, что type_info — внутренняя структура С++, её рожает
К> компилятор. А std::string — это авторская разработка той или иной
К> компании; как захочу, так и сделаю.

Не совсем так: формально std::string — точно такая же "внутренняя структура".
как и type_info. Стандарт не оговаривает возможности подмены стандартной
библиотеки.

Но твои рассуждения напомнили мне одну вещь: поставка компилятора по выбору
разработчиков может включать не всю стандартную библиотеку (т.к. называемая
hosted implementation), а только ее подмножество (freestanding
implementation). В последнем случае разработчики компилятора сами решают,
что включать, за исключением нескольких заголовков, которые должны быть
обязательно. В частности, <string> в число этих заголовков не входит,
а <typeinfo> — входит (17.4.1.3).

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не совсем так: формально std::string — точно такая же "внутренняя структура".
ПК>как и type_info. Стандарт не оговаривает возможности подмены стандартной
ПК>библиотеки.

ПК>Но твои рассуждения напомнили мне одну вещь: поставка компилятора по выбору
ПК>разработчиков может включать не всю стандартную библиотеку (т.к. называемая
ПК>hosted implementation), а только ее подмножество (freestanding
ПК>implementation). В последнем случае разработчики компилятора сами решают,
ПК>что включать, за исключением нескольких заголовков, которые должны быть
ПК>обязательно. В частности, <string> в число этих заголовков не входит,
ПК>а <typeinfo> — входит (17.4.1.3).

Так здесь нужно определиться — что первично, а что вторично.

<typeinfo> описывает, как выглядит структура type_info.
Если ты поменяешь объявление type_info (например, добавишь новые виртуальные методы, члены-данные) — получишь рассогласование с оригинальным представлением и все прелести неопределённого поведения по нарушению ODR.

А <string> определяет класс. Если поменяешь — не забудь только перекомпилировать все проекты.

По аналогии: семейство хедеров WinAPI (windows.h и все-все-все) является отражением WinAPI.

Здравствуйте, Кодт, Вы писали:

К><typeinfo> описывает, как выглядит структура type_info.
К>Если ты поменяешь объявление type_info (например, добавишь новые виртуальные методы, члены-данные) — получишь рассогласование с оригинальным представлением и все прелести неопределённого поведения по нарушению ODR.

К>А <string> определяет класс. Если поменяешь — не забудь только перекомпилировать все проекты.

Это еще не факт. Класс string — чисто теоретически — может быть встроенным в компилятор.

Здравствуйте, achp, Вы писали:

A>Это еще не факт. Класс string — чисто теоретически — может быть встроенным в компилятор.

А чисто практически такое бывает? Хоть где-нибудь?

Здравствуйте, Кодт, Вы писали:

К>А чисто практически такое бывает? Хоть где-нибудь?

А черт его знает .

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Tom, Вы писали:

T>> так как тогда вообще зачем std::string

ПК>Для замены p = new char[...] ... strcpy ... strlen ... delete [] p ...

T>> тем более, что копировать/или нет — зависит от реализации STL

ПК>Я не знаю ни одной реализации, в которой можно было бы "привязать"
ПК>std::string к статической const char*, избегая копирования.
А это есть правильно разве?

ps: мне кстате возможности у std::string assign() часто не хватает

Здравствуйте, Кодт, Вы писали:

A>> Это еще не факт. Класс string — чисто теоретически — может быть
A>> встроенным в компилятор.

К> А чисто практически такое бывает? Хоть где-нибудь?

Бывает. Например, в интерпретаторе CInt.

Tom wrote:

> так как тогда вообще зачем std::string
А зачем std::exception::what возвращает не std::string? А затем, что может
быть острая нехватка памяти. Не хотелось бы терять сообщение об ошибке
из-за этого. Кроме сообщения об ошибке можно также информацию о типе в
поток ошибок добавить. И тоже не хотелось бы его потерять.
К тому же, всегда можно из char const* сконструировать std::string, причем в
некоторых местах можно даже не заметить, что там char const*.

--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

achp wrote:

> Это еще не факт. Класс string — чисто теоретически — может быть встроенным
> в компилятор.
Я хочу такую вещь. Поможет убрать динамическое выделение памяти в очевидных
случаях, а в неочевидных может иногда предсказать оптимальный размерчик для
reserve.

--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)