Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+181
int maxOf5(int a, int b, int c, int d, int e) {
int arr[5];
arr[0] = a;
arr[1] = b;
arr[2] = c;
arr[3] = d;
arr[4] = e;
bubbleSort(&arr, 5);
return arr[0];
}no comments...
Запостил: 
wh_,
22 Декабря 2010
Follow us!
разлогиниться забыл, лол
А что, логарифм уже не считается? Его можно тратить как угодно?
я только что 15 минут потратил, чтобы выяснить, надо ли заменять ReallocMem на пару FreeMem/GetMem, любого байтоёба уделаю :-Р
и да, откуда уэб обезьяне знать про асимптотику
хотя "порядок" звучало подозрительно
&arr возвращает адрес arr. Этот тип похож на int**, только он ещё содержит явное число элементов int*[5].
Вопрос в том... Что же принимает bubbleSort?
От меня этот момент как-то ускользает...
В стандарте есть два типа массивов array of N type T и array of unknown bound type T, последний точно определяется указателем, а вот первый неким указателем с длиной. И так получается, что адрес указателя не конвертируется в адрес указателя с диной. Хотя сами указатели на массивы приводятся легко к указателю.
То есть, неявно передать адрес указателя с длиной, значит вызвать ошибку преобразования типов. Так оно кажется.
Я попробовал сообразить... И просто не нашёл такого прототипа bubbleSort, который не вызвал бы ошибку типа при передаче &arr.
Это просто передача int*
Про передачу по ссылке я фигню сказал, иначе было бы написано sort(arr без амперсанда.
Если бы "бубле" имело простой прототип bubbleSort(int[],int), то вызов выглядел бы так: bubbleSort(arr,int);
Вот я и не понимаю... Что за "бубле-то" должно быть, чтобы ему &arr отдавать...
Я склоняюсь к тому, что для массива, который объявлен с явным числом элементов оператор получения адреса указателя -- бессмыслица.
void bubbleSort(void* a, ptrdiff_t b);
Не?
Передача указателя на массив уже разрешена без каста.
Я, конечно, не знаю, как это может восприниматься разными компиляторами, но не должно... Теоретически &arr и arr -- это разные вещи. То есть в bubbleSort(int*,int) не получится без явного каста подпихнуть &arr. Конечно, вы всегда можете сделать аналогично операции с void*: reinterpret_cast<int*>(&arr), но это уже говорит о пробеле на этапе проектирования, который привёл к "шву" на этапе конструирования.
Я продолжаю придерживаться позиции, что смысла в &arr просто нет никакого, нужно было передавать arr.
int* - это тип такой, "указатель на инт".
&i - это указательнь на конкретную переменную.
> Теоретически &arr и arr -- это разные вещи.
Это-то причём?
Похоже ты знаешь С ещё хуже, чем я.
В выражении int arr[5]; arr -- не int, а что-то другое, что приводится неявно (по стандарту) к int*. Потому &arr -- это уже адрес адреса переменной типа int. Что-то похожее на int** (но не оно). Положить int** в int* нельзя. При этом и &arr положить в int** тоже нельзя.
Да.
> Что-то похожее на int** (но не оно).
Не оно, да. Это int*.
ЛОЛ.
Вам не кажется, что если прямая операция адресации выполнена два раза, то обратная операция разименования тоже должна быть выполнена дважды?
Ну... На худой конец, что ли, попробуйте скомпилировать у себя код вида:
int arr[1] = {0};
int * intPtr = &arr;
Я уж и на знаю, что ещё сделать, чтобы вы увидели разницу.
Где тебе тут привиделся адрес адреса?
Я вижу только адрес массива. Массив - это не указатель. Это область памяти, в которой лежат несколько переменных подряд. А в функцию передаётся указатель на эту область памяти.
Короче, заканчивай ПХП защищать, плохо влияет.
Массив действительно не является указателем, это бесспорно. Но что такое переменная arr? Так вот, переменная arr -- это "что-то", что в программе представляет собой абстракцию массива. Однако, согласно стандарту, эта абстракция приводится в указатель на первый элемент при операциях над ней. Так вот положено в C++.
Что есть &? & -- это оператор, который будучи применён к переменной возвращает адрес этой переменной в памяти.
Что же будет, если мы напишем &arr?
arr неявно превратится в указатель на первый элемент массива, после чего от этого указателя будет взят адрес. То есть, это уже (в общем случае) не адрес первого элемента, а адрес указателя, который содержит адрес первого элемента.
Адрес адреса...
Вы взяли адрес arr и положили его в первый элемент массива адресов.
В строке два левое выражение имеет тип int*[1], как и правое &arr, а вовсе не int*, ага.
А я код писал, где была попытка положить &arr в int*, как предлагал TarasB.
"passing pointers by reference is so C++"
Смотря где.
Тоесть я при передаче любого указателя должен использовать ptrdiff_t ?
на мелких N bubble sort более эффективен чем quick sort.
это наверное самая читабельная реализация какую только и можно придумать.
народ и не улавливает что "&arr" и "arr" имеют тот же самый эффект и тот же самый тип. в оригинальном С "&arr" было ошибкой (метка/имя массива уже есть по определению указатель; ассемблерщики должны улавить откуда ноги у синтаксиса растут). но народ просто постоянно на это спотыкался, почему и разрешили в языке "&arr" и оно аналогично "arr" и есть указатель на массив/первый элемент массива.
ЗЫ та же самая фигня и про указатели на функции: имя функции есть указатель, и &func_name просто синоним введенный для читабельности.
И специально попытался крутануть код в MSVC++, известен он свой "нестандартностью", результат тот же был: ошибка кастинга типа.
Это новшество 2011го стандарта будет?
void sort(int *arr, int size) {}
void func() {}
int _tmain(int argc, _TCHAR* argv[]) {
int arr[5] = {0};
cout << typeid(arr).name() << endl; // int [5]
cout << typeid(&arr).name() << endl; // int (*)[5]
cout << typeid(func).name() << endl; // void __cdecl (void)
cout << typeid(&func).name() << endl; // void (__cdecl*)(void)
sort(arr, 5); // correct
sort(&arr, 5); // ill-formed
return 0;
}