у меня возник небольой спор, выберите, то, что вы бы использовали в своем проекте. Комментарии приветсвуются.
Заранее спасибо.

vinter, ответ "создам структуру(класс)" не принимается?

с помощью класса можно будет передавать оба варианта (в конструкторах) и в том же конструкторе можно будет проверить "правильность" данных
+ это может очистить код и ускорить работу проги (так как часто проверки на "правильность" данных дублируются в каждой из функций)

имхо, очень сильно зависит от формализованности и законченности списка параметров. Если список параметров четко оговорен и типизирован - тогда предпочту параметры раскидать. Если же преполагается плавающий механизм списка параметров (а особенно, если etc подразумевает неоконченный и неизвестный на момент разработки хвост) - тогда лучше строкой...
Создавать класс ради сиюминутной единичной задачи - не всегда оправдано.   Хотя как вариант...

ama_kid, я и не говорю, что всегда нужно делать так
точнее я имел в виду, что так нужно делать только в случае достаточно больших прог

но в вопросе о "сиюминутности" ничего не говорится, потому я предложил еще 1 вариант.

нет 

Если нет объективных причин, то предпочту второй вариант. Т.к. лень парсить строку 

выбрал второй вариант, однако в таком виде : 
foo ("192.168.0.2:3456", "i  ***","etc") ;

каждая строка представляет собой определенную структуру, предназначенную для хранения данных для определенной задачи.
т.е конечный вид функции условно такой

имхо парсить строку меж этих задач (Connect  и SendIdentify) , да и так же применять один и тот же вид "протокола" хранения данных для каждой задачи на мой взгляд нецелесообразно.


Это сообщение отредактировал(а) mes - 5.12.2008, 19:07

просто лень разбирать строку

я бы создал класс ip::tcp::endpoint, для хоста, и класс auth::user для имени-пароля и передавал бы их, это технологичней  

народ вы на названия переменных не заморачивайтесь, это просто пример 

ну ты меня понял, текстовая строка это текстовая строка, тем более если она получена откуда-то извне. она должна пройти какую-то валидацию, потом должна быть проанализирована, а потом на ее основе должны быть созданы объекты, с которыми работает программа. 
Но если ф-я о которой идет речь это ф-я, которая и должна создать эти объекты, то лучше передавать одну строку, так-как это эффективней(меньше фрагментация памяти, меньше разных участков памяти должно быть загружено в кэш), плюс, одно строку можно целиком обработать регулярным выражением  

ну с точки зреняи эффективности первый вариант в любом случае проигрывает:
1. В С++ нет регулярных, а значит надо писать свой парсер, или юзать boost(который тоже не Святым Духом питается).
2. Парсинг это затраты, и эти затраты куда больше, чем затраты на фрагментацию(сомневаюсь, что она будет иметь место), к тому же я думаю лежать то они как раз убдут так же как и цельная строка, не вижу причин компилятору поступить по другому.

ну если нужно получить в результате не строку, а скажем число, то парсить все-равно будет нужно


строки в памяти размещает не компилятор а менеджер памяти, представь что у тебя over 9000 таких строковых параметров, думаешь фрагментации не будет?
хотя на самом деле это не важно в 99.9% случаев, нужно руководствоваться логикой работы программы, в одном месте более правильным может быть 1-й вариант в другом 2-й

разве в данном случе все не будет просто лежать последовательно в стеке?


ага

как повезет
стандарт не гарантирует, что строки

будут лежать последовательно

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

представлял себе 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

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


и что не так?

про хранение :  загрузить данные в ассоциативный контейнер без парсера проблематично   .
про передачу: то что реализация вектора (и других стл контейнеров) компиляторно зависимая и передавать их как параметры другой инстанции (из под другого компилятора) чревато сбоем.


А заодно лишаемся статического контроля типов   

P.S. у любого способа есть свои недостатки и преимущества, и нужно просто стараться найти оптимальное решение.   

моя твоя не понимать, у нас есть данные. Отдельно каждая строка, зачем нам парсер?


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

не ошибаешься
точнее не вектор, а буфер, на который он показывает


ошибаешься

в стандарте, к примеру, не указано, что должно идкт первым - указатель на буфер в куче или размер буфера


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

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

ну это все решаемо, просто пишем буфер вектора в другой инстанс. С такой стороны получется действительно строка  будет проще(при условии, что там парсинг простой).

Сплошным куском должен лежать не объект-вектор, а данные которые он хранит.   
Также стандартизированы основной набор методов, однако способ реализации не оговаривается.

как Вы думаете, что получится если описания векторов в двух программах (которые обмениваются данными в виде объектов типа вектор)  будут незначительно отличаться ?
например так : 

 

Добавлено @ 19:23

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

и подходить к делу осознанно   


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

mes, согласен 
P.S и давай на ты, не привычно в интернете и на Вы...

А про вариант сделать функцию перегруженной, предоставив более одного способа передачи данных, чего-то никто не вспомнил  

я за вариант


передавать строку - это точно геморой.  В дополнение к тому что ее распарсить нужно, нужно так же проверить все ли параметры в ней были. Эта фактически изменит сигнатуру функции foo - т.е. уже может вернуть ошибку (не удалось распарсить), и там где функцию вызывали эту ошибку уже надо как-то обрабатывать (по хорошему конечно, имбо кодеры конечно никаких проверок не делают .

Это сообщение отредактировал(а) Torsten - 8.12.2008, 19:21