я глядя на этот код

представлял себе std::string  

ну и что это меняет ? уж не то, что не хватает ..c_str() ? надеюсь все таки, что сомнения вызвало что то другое,  ибо нигде не говорится, что упомянутая реализация класса объекта sock принимает что то иное, нежели string  

Добавлено через 7 минут и 46 секунд

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

Не тема, а сплошной творческий онанизм.
Звыняйте - не здержался   

это почему это? название парметров дела не меняет, дело в передаче параметров а не их последущей обработке. Главное что внутри функции они используются раздельно и все. Остальное не важно.

Само название дела не меняет,  но смысл несенный параметром для конкретной функции меняет.  


Это далеко не главное. Каждый параметр является самостоятельной сущностью и от того насколько правильно Вы ее определите будет зависть логичность архитектуры вашей функции. Некоторое время назад поднимался вопрос, что лучше передавать : много одиночных параметров или одну структуру ?
Я придерживаюсь мнения, ответ лежит по середине, т.е
1  я не согласен с упаковкой в структуру, ради упаковки
2. я не согласен с расскрытой передачей, т.е когда один смысловой параметр представлен набором одиночных.
т.е. Кесарю - кесарево.

От вашего вопроса отличается только тем, что у Вас структура является представлена строкой. Поэтому смотрите в суть параметра и будет Вам ответ . 


P.S. Все вышенаписанное ИМХО.

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

первый вариант
парсинг не сложный, если строка не хаотична, а имеет определенную структуру, к примеру
"<key1>=<value1>;<key2>=<value2>"

парсинг мб и не сложный... вона в sendmail тоже не сложный парсинг, а багов было и есть тонны... 
где парсинг - там всегда гемморой. Упаковать в общем в структуру и передавать ссылку на ее - мой выбор.
Во вторых будет делаться давжды работа в первом варианте (часто) : сначала склейка, потом парсинг. зачем?

При прочих равных - вариант №2.

не согласен, спорить не буду



в таком случае мы сделаем функцию зависимой от конкретных параметров
т. е, к примеру есть стек функций L1->L2->L3->...->Ln
L1 генерирует набор параметров, которые последовательно должны быть обработаны L2, L3, ..., Ln
что лучше
делать толстую структуру со всеми возможными параметрами или передавать строку, из которой каждая функция выберет нужные параметры?
кроме того, а если каждый  следующий уровень динамически генерирует параметры для следующего уровня?
тогда L1 должна невольно знать об их существовании, а это лишняя связанность

Добавлено через 2 минуты и 9 секунд

унификация представления

согласен, парсер не такая деталь которую стоит бояться. Другой вопрос что статическая проверка , гораздо безопаснее, чем простое динамическое использование данных,
но иногда бывает необходимым использование динамических структур. Если такой подход преобладает, то Cpp/С ИМХО неправильно выбран как целевой язы




В чистом виде оба варианта плохи.


Это сообщение отредактировал(а) mes - 6.12.2008, 16:44

если уж заговорили о структурах: если у нас параметры вида 

то, по моему, идеальный вариант параметров ф-ии это vector<pair<string,string>>. И никакие парсинги и структуры даром не нужны...

тогда уж лучше std::map<std::string, std::string>   

а сохранение в файл ? a передача данных между инстанциями ?    все зависит от требований задачи )

Это сообщение отредактировал(а) mes - 6.12.2008, 18:11

не, вдруг сортировка лишнее?


и что не так?