Re[4]: подскажите еще по string& func() - C/C++

Вот в сях просто:

char* func() {
  char* value;
  ............
  if (...) {
    return value;
  } else {
    return NULL;
  }
}

а как быть в плюсах?

string& func() {
.......
}

В мою тяпничную бошку приходит только кривая идея сделать в классе пустую переменную типа string и передавать ее (типа NULL)... Можно еще свой exception написать, но мне не очень нравится идея прокидывать и ловить их, этот механизм не отличается большой скоростью, имхо...

А, еще можно передавать переменную, а не ссылку на нее, но это тоже не самый быстрый вариант...

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

hal>Вот в сях просто:
hal>

hal>char* func() {
hal>  char* value;
hal>  ............
hal>  if (...) {
hal>    return value;
hal>  } else {
hal>    return NULL;
hal>  }
hal>}
hal>

hal>а как быть в плюсах?
hal>

hal>string& func() {
hal>.......
hal>}
hal>

std::string * func() {
  std::string * value;
  ............
  if (...) {
    return value;
  } else {
    return NULL;
  }
}

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

hal>Вот в сях просто:
hal>

hal>char* func() {
hal>  char* value;
hal>  ............
hal>  if (...) {
hal>    return value;
hal>  } else {
hal>    return NULL;
hal>  }
hal>}
hal>

hal>а как быть в плюсах?

Можно поступить точно так же.

hal>

hal>string& func() {
hal>.......
hal>}
hal>

hal>В мою тяпничную бошку приходит только кривая идея сделать в классе пустую переменную типа string и передавать ее (типа NULL)... Можно еще свой exception написать, но мне не очень нравится идея прокидывать и ловить их, этот механизм не отличается большой скоростью, имхо...

hal>А, еще можно передавать переменную, а не ссылку на нее, но это тоже не самый быстрый вариант...

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

А так?

string* func() {
.......
}

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

А можно и так

bool func(std::string & value)
{
 ............
  if (...) {
    return true;
  } else {
    return false;
  }
}

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

hal> ...

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

В твоём же случае, похоже, некоторая переменная может либо существовать, либо нет,
так что возможно тебя устроит что-то в стиле

string& func() {
    static string value;
    ............
    if (...) {
        return value;
    } else {
        throw( exception() );
    }
}

хотя всё зависит от решаемой задачи...

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

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

Вот:

string& CGIRequest::operator[](string& key) {
    CGIRequestMap::iterator iter;
    iter = m_variables.find(key);
    return iter->second;
}

Т.е. у меня есть map со списком ключей и значений... Мне надо вернуть значение по ключу... А в случае, если ключ не найден, сообщить об этом...
Прошу сильно не пинать, я давно не юзал ни Си, не плюсы... Почему-то решил уж если юзаю плюсы, то буду использовать string и ссылки... Видать мне нужно RTFM про ссылки и указатели и отличия между ними...

Тогда еще вопрос... Будет-ли "красиво" и по стилю делать так:

char* method() {
  char* value;
  ............
  if (...) {
    return value;
  } else {
    return NULL;
  }
}

или все же лучше стринги, ссылки и исключения?

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

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

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

hal>Вот:

hal>

hal>string& CGIRequest::operator[](string& key) {
hal>    CGIRequestMap::iterator iter;
hal>    iter = m_variables.find(key);
hal>    return iter->second;
hal>}
hal>

hal>Т.е. у меня есть map со списком ключей и значений... Мне надо вернуть значение по ключу... А в случае, если ключ не найден, сообщить об этом...
Т.е. получается, что ситуация, когда запрашиваемый ключ отсутствует, вполне естественна. В этом случае, ИМХО, указатели подходят больше. В конкретной ситуации можно посткпить так:

const char* CGIRequest::operator[](const string& key) {
    CGIRequestMap::iterator iter;
    iter = m_variables.find(key);
        if(variables.end() != iter)
       return iter->second.c_str();
        else
           return 0;
}

Таким образом и управление памятью возложено на std::string, и результат поиска просто интерпретируется. Но это конечно, если потом не трудно будет с указателем работать...

hal>Прошу сильно не пинать, я давно не юзал ни Си, не плюсы... Почему-то решил уж если юзаю плюсы, то буду использовать string и ссылки... Видать мне нужно RTFM про ссылки и указатели и отличия между ними...

ИМХО подход "или только это, или только вот это" — не есть хорошо

hal>Тогда еще вопрос... Будет-ли "красиво" и по стилю делать так:
hal>

hal>char* method() {
hal>  char* value;
hal>  ............
hal>  if (...) {
hal>    return value;
hal>  } else {
hal>    return NULL;
hal>  }
hal>}
hal>

hal>или все же лучше стринги, ссылки и исключения?

Однозначно тебе на этот вопрос никто не ответит. Конкретное решение всегда должно приниматься на основании конкретных требований. Просто старайся делать так, чтобы эту твою функцию удобно было использовать. Если, к примеру, каждый ее вызов придется оборачивать в try/catch, то заранее готовся к "комплиментам" со стороны пользователей этой функции

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

B>ИМХО подход "или только это, или только вот это" — не есть хорошо

Тогда я лучше все переделаю под char... Выделять и удалять память под строки не сложно, а "бардака" в стиле не люблю

hal>>или все же лучше стринги, ссылки и исключения?

B>Однозначно тебе на этот вопрос никто не ответит. Конкретное решение всегда должно приниматься на основании конкретных требований. Просто старайся делать так, чтобы эту твою функцию удобно было использовать. Если, к примеру, каждый ее вызов придется оборачивать в try/catch, то заранее готовся к "комплиментам" со стороны пользователей этой функции

Ок, понял... Правда имея большой опыт программирования на Java, меня не напрягало использование исключений... Может оттого что там все красиво реализовано?

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

_>

_>string& func() {
_>    static string value;
_>    ............
_>    if (...) {
_>        return value;
_>    } else {
_>        throw( exception() );
_>    }
_>}
_>

Вот не надо такой стиль подсказывать. А что будет, если этой функцией попытаются воспользоваться два клиента? Когда первый предполагает, что по ссылке ещё то, что вернули ему, а второй уже получил ссылку туда же с новым результатом?

Понятно, что в контексте исходной задачи это неактуально, но всё же.

можн еще юзать std::auto_ptr
выделять в функции память под переменную динамически и засовывать объект в auto_ptr. его же и возвращать через констр. копир.
тогда во внешней ф-ии, когда auto_ptr закончит свою жизнь, он автоматом удалит объект и очистит память.

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

hal>Тогда я лучше все переделаю под char... Выделять и удалять память под строки не сложно, а "бардака" в стиле не люблю

на самом деле я бу рекомендовал кругом придерживаться одного. и ежели это С++, то использовать только string. так и путаницы меньше и придерживатся одного стиля есть хорошо. поэтому я бы рекомендовал:

bool func(string& result)

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

CGIRequestMap::iterator CGIRequest::operator[](const string& key) const {
    return m_variables.find(key);
}

CGIRequestMap::iterator CGIRequest::InvalidItem() const {
    return m_variables.end();
}

...

CGIRequestMap::iterator i=request["some"];
if (i!=request.InvalidItem()) {
    i->second=...;
}

... << RSDN@Home 1.1.3 stable >>

C>Понятно, что в контексте исходной задачи это неактуально, но всё же.

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

hal>Т.е. у меня есть map со списком ключей и значений... Мне надо вернуть значение по ключу... А в случае, если ключ не найден, сообщить об этом...
hal>Прошу сильно не пинать, я давно не юзал ни Си, не плюсы... Почему-то решил уж если юзаю плюсы, то буду использовать string и ссылки... Видать мне нужно RTFM про ссылки и указатели и отличия между ними...

Ссылки можно отдавать только на объекты, чья жизнь длиннее, чем жизнь ссылки. Но это так, к вопросу об RTFM...

Предлагаю несколько вариантов решения; выбери наиболее симпатичный.

// возвращать дефолтное значение
string func(const string& key, // обрати внимание: ключ - по смыслу должен быть rvalue или const lvalue,
            const string& defvalue = string() // дефолтное значение дефолтного значения - пустая строка
           )
{
  the_map_type::const_iterator it = the_map.find(key);
  if(it != the_map.end())
    return it->second;
  else
    return defvalue;
}
int main()
{
  ..... cout<<func("hello","failure"); .....
}

// возвращать ссылку на дефолт
const string& defvalue() // возвращает ссылку на один и тот же объект
{
  static string dv;
  return dv;
}
const string& func(const string& key)
{
  .....
  if(.....) return it->second; else return defvalue();
}
int main()
{
  ..... if(&func("hello") == &defvalue()) cout<<"failed"; .....
}

// возвращать пару ссылка+флаг
pair<const string&, bool> func(const string& key)
{
  static const string dv; // внутренняя константа, служит для создания валидной ссылки
  ....
  if(.....)
    return pair<const string&,bool>(it->second, true);
  else
    return pair<const string&,bool>(dv, false);
  // нельзя пользоваться make_pair, т.к. будут потеряны ссылки
}

// пара значение+флаг
pair<string, bool> func(const string& key)
{
  .....
  if(.....)
    return make_pair(it->second,true);
  else
    return make_pair(string(),false);
}

	От:	hal
	Дата:	28.01.05 12:52
	Оценка:

	От:	Lapulya
	Дата:	28.01.05 13:01
	Оценка:

	От:	Bell
	Дата:	28.01.05 13:01
	Оценка:

	От:	ansi
	Дата:	28.01.05 13:02
	Оценка:

	От:	Lapulya
	Дата:	28.01.05 13:04
	Оценка:

От:	yxiie	www.enkord.com
Дата:	28.01.05 17:55
Оценка:

	От:	tacit_one
	Дата:	31.01.05 17:17
	Оценка:

	От:	Кодт
	Дата:	01.02.05 09:23
	Оценка:	+1