интересно, почему std::string не имеет автоматического приведения к const char*
и нужно каждый раз писать c_str() ?
перевожу тут один старый код, использовавший MFC, на кроссплатформенные рельсы, там CString имела автоматическое преобразование.
Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

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

XC>Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

Страуструп — Язык программирования С++, 3-е издание, глава/параграф 20.3.7.

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

XC>интересно, почему std::string не имеет автоматического приведения к const char*
XC>и нужно каждый раз писать c_str() ?
XC>перевожу тут один старый код, использовавший MFC, на кроссплатформенные рельсы, там CString имела автоматическое преобразование.
XC>Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

const char* f(const std::string& a, const std::string& b)
{
  return a+b;
}

You will always get what you always got
  If you always do  what you always did

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

J>

J>const char* f(const std::string& a, const std::string& b)
J>{
J>  return a+b;
J>}
J>

Обжёгшись на молоке, на воду дует? Таких примеров можно придумать и про то, что и так есть.

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

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

J>>

J>>const char* f(const std::string& a, const std::string& b)
J>>{
J>>  return a+b;
J>>}
J>>

TB>Обжёгшись на молоке, на воду дует? Таких примеров можно придумать и про то, что и так есть.

OK.

auto plus = [](const auto&& a, const auto&& b) {return a+b;}
std::string a,b;
const char* oops = plus(a,b);

You will always get what you always got
  If you always do  what you always did

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

J>OK.
J>

J>auto plus = [](const auto&& a, const auto&& b) {return a+b;}
J>std::string a,b;
J>const char* oops = plus(a,b);
J>

а зачем так сложно?

const char * oops;
{
  std::string a;
  oops = a;
}
//oops

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

XC>интересно, почему std::string не имеет автоматического приведения к const char*
XC>и нужно каждый раз писать c_str() ?
XC>перевожу тут один старый код, использовавший MFC, на кроссплатформенные рельсы, там CString имела автоматическое преобразование.
XC>Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

В общем случае null-терминантность — реверанс в сторону сишных интерфейсов. Давно пора стандартизовать string_ref.
Сишные строки — временное неудобство, в каком то из стандартов можно будет его просто выкинуть.

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

S>Сишные строки — временное неудобство, в каком то из стандартов можно будет его просто выкинуть.

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

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

S>Давно пора стандартизовать string_ref.

Правильно ли я понимаю, что он позволят передавать любую подстроку, не копируя её, и не портя саму исходную строку?
Тогда нужная штука, но на низком уровне всё, к сожалению, на убогом const char* сделано и от этого не уйти.

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

S>Сишные строки — временное неудобство, в каком то из стандартов можно будет его просто выкинуть.
Обратная совместимость принципиальная позиция комитета.

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

XC>перевожу тут один старый код, использовавший MFC, на кроссплатформенные рельсы, там CString имела автоматическое преобразование.
XC>Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

Думаю, всё прозаичней — в MFC c CString просто ошиблись. Вероятно, преследовали сомнительную цель минимизировать изменения в коде при изменении типа переменной XXXXSTR на CString.

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

XC>интересно, почему std::string не имеет автоматического приведения к const char*
XC>и нужно каждый раз писать c_str() ?

По-моему, отсутствие автоматического приведения это мелочи (добавить .c_str()), гораздо хуже, что std::string мало что умеет. К примеру, сравнить с qstring. Из-за слабости методов std::string часто надо делать приведение к char*.

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

XC>интересно, почему std::string не имеет автоматического приведения к const char*
XC>и нужно каждый раз писать c_str() ?
XC>перевожу тут один старый код, использовавший MFC, на кроссплатформенные рельсы, там CString имела автоматическое преобразование.
XC>Наверняка это преобразование не просто так не сделали, а имели в виду какую-то глубокую мысль. Какую?

Потому что std::string не гарантирует завершающий нуль. То есть c_str() вполне может осуществлять копирование.
Чтобы не нарываться на такой нежданчик, сделали это преобразование explicit.

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

XC>интересно, почему std::string не имеет автоматического приведения к const char*

Ахах, сегодня на граблю напоролся. Грубо говоря, код был примерно такой:

std::string str;
const char* ch;
const char* ref = condition ? str : ch;

Только тут был не стринг, а другой класс, у него было неявное приведение к конст чару и обратно. Ну и я предположил, что компилятор поймёт код так:

std::string str;
const char* ch;
const char* ref = condition ? (const char*)(str) : ch;

но компилятор понял код иначе, в итоге ch приводилось к временному стрингу, который грохался сразу после выполнения этой строчки, в рефе хранился мусор

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

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

TB>Правильно ли я понимаю, что он позволят передавать любую подстроку, не копируя её, и не портя саму исходную строку?
TB>Тогда нужная штука, но на низком уровне всё, к сожалению, на убогом const char* сделано и от этого не уйти.
Это всего лишь пара указатель + размер.

Использую большой зоопарк самописных строк — фиксированной длины, с хранением размера, без хранения размера и т.п. Чтобы как то их друг с другом подружить string_ref отлично подходит — implicit конструктор + оператор приведения к string_ref + append(string_ref) и они друг в друга копируемы и конкатенируемы. Все константные методы типа find, rfind и т.п. просто пробрасываются в те же методы string_ref. Потихоньку перевожу все функции, принимавшие const char* на string_ref и простой поиск по c_str выдает все тухлые места c паразитным вычислением длины, остаётся разве что fopen. Нарисовал ещё всякие strtoi, strtod, istream-подобный парсер поверх string_ref, опять таки zero-copy. Вот например какие-нибудь SAX парсеры xml/json — в них часто вообще не нужно копировать названия-значения атрибутов — просто высовываешь наружу в виде string_ref и ассоциируешь по словарному индексу схемы из тех же string_ref.
И вот думаю, — если c_str мне нужен только для fopen, не сделать ли нуль терминантность опцией? Даже для сишных строк фиксированной длины без её хранения (просто обертка над char[N]) ноль в конце не обязателен — strnlen достаточно для приведения к string_ref.

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

S>>Сишные строки — временное неудобство, в каком то из стандартов можно будет его просто выкинуть.
S>Обратная совместимость принципиальная позиция комитета.

Можно было бы перевести STL на стратегии. Обеспечить обратную совместимость и позволить использовать стандартные конструкции вместо велосипедов.

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

K>Здравствуйте, x-code, Вы писали:

XC>>интересно, почему std::string не имеет автоматического приведения к const char*
XC>>и нужно каждый раз писать c_str() ?

K>По-моему, отсутствие автоматического приведения это мелочи (добавить .c_str()), гораздо хуже, что std::string мало что умеет. К примеру, сравнить с qstring. Из-за слабости методов std::string часто надо делать приведение к char*.

А какие методы нужно добавить стрингу, чтобы пореже приводить к char*?