Если некоторая функция принимает указатель на char, например:

то имея массив объявленный как

можно вызвать функцию foo так:

либо так:

Причем второй способ встречался чаще. Есть ли разница в этих двух способах вызова функции?

Голосую за второй вариант- можно потом заменить тип array на vector или string без изменения твоего кода

мне тоже стало интересно почему эти варианты идентичны ? я второй понял бы как передача ссылки на первый элемент массива, но вроде как передается весь массив

если смотреть со стороны ф-ции

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

смелое однако заявление  



Это сообщение отредактировал(а) mes - 19.11.2011, 02:42

оператор индекса ведь есть и у вектора и у стринга. или что?

Если Вы имели в виду, что необходимо проверять строку на предмет empty(), то да - изменения потребуются (как, впрочем, и с вектором).
Или, может, Вы имели в виду, что operator[] строки не обязан возвращать указатель на, так сказать, raw-данные строки ?

В общем, хотелось бы комметариев

Это сообщение отредактировал(а) borisbn - 19.11.2011, 09:25

Голосую за первый вариант, потому что второй - напрасное усложнение.

operator[] возвращает ссылку на элемент под этим индексом

IMHO, всё зависит от реализации контейнера, поэтому второй вариант гарантирует портабельность кода, а первый нет.


Это сообщение отредактировал(а) Леопольд - 19.11.2011, 11:28

 

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

я хотел дать возможность самим найти ответ на вопрос.. что впрочем Вы исделали 

а разве существуют реализации std::string/std::vector возвращающие не ссылку на элемент?
  
нет, конечно, в Qt`ешных контейнерах это нормально, там и множество не сортированное. но это ничего. все равно никто(почти) из пользователей этого и не заметил.
почти уверен в том, что и borisbn об этом не знал ;)

Это сообщение отредактировал(а) boostcoder - 19.11.2011, 12:07

да без разницы как сделаешь, лишь бы самому было понятно, но лучше второй вариант, так будет понятней что передаешь указатель массива, а не какую нить переменную (чисто так чтение кода упрощается со вторым вариантом).

существуют (законы по стандарту) реализации std::string в которых расположение элементов не плоское.. (в отличие от vector`а)..
Это мы еще не впомнили про возможное отсутствие признака конца строки..  


речь не о них, а о stl..

Добавлено через 2 минуты и 53 секунды
поэтому конструкция типа  &str[ 0 ]  (для std::string) - это путь к длительному и весьма занятному времяпровождению за дебагом 

Теоретически эти данные могут быть расположены не последовательно в памяти. Мы не знаем какой внутренний механизм у стринга. Чтобы расположить данные последовательно, и завершить их нулем, существует .c_str();

Одна из вещей которая меня всегда удивляет в С++, (как впрочем видимо и в других языках), есть вещи которые работают в реале всегда, но теоретически нарушают некое правило, и тем самым вызвают бурю возражений (одну из этих вы привели).
И есть обратное, когда код прямо не нарушает правило, но в реале, глючит абсолютно везде и абсолютно всегда! (хотя бы тот же самый utf-8). И это почему-то, ни у кого не вызывает бурю эмоций!
  

ну раз Вы говорите...

volatile,у вас вроде VS (или кто нибудь другой у кого она есть)..
  какой sizeof у std::string ? 
 VS желательна старой версии, на новой будет скорей всего будет 4 байта ( из за cow)..

Это сообщение отредактировал(а) mes - 19.11.2011, 12:36

mes, VS2005/Win7x64, Default Project Settings for Console App:
Debug
32 bytes
Release
28 bytes

попробовал в VS2010 - результат тот же

Это сообщение отредактировал(а) semibug - 19.11.2011, 12:53

mes, 
В студии стринг маленькие строки (кажется до 14 байт, точно не помню) хранит внутри себя, без выделения памяти. Поэтому размер не 4 байта, а как сказал 
semibug, 




Это сообщение отредактировал(а) volatile - 19.11.2011, 13:04

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

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

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

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

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

я говорил :

а эт несколько иное значение 

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

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

где-то на винграде это обсуждалось. но я не понимаю где здесь хоть намек на эффективность? вот нужно создать мильен строк размером больше того буфера, и что мы получим? - пустые расходы памяти. ведь 14*1000000 = 14мб  

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


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

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

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



Это сообщение отредактировал(а) mes - 19.11.2011, 15:29

mes, абсолютно согласен.