Этот дополнительный ответ в ответ на комментарий OP к моему более раннему ответу. Защитник спрашивает:
"Я имею некоторые вопросы в запасе. Если бы это ожидает массив интервала типа, и я отправил дважды, почему это изменило бы результат в 360 градусах. Я все еще не получил ответ на это".
будет легче проиллюстрировать это со столкновением типа между short int
и int
, но та же идея относится int
по сравнению с double
.
Смотрят на этот код:
#include <stdlib.h>
#include <stdio.h>
void functionA(short int[], int size);
int main(void) {
printf("sizeof short int : %lu\n", sizeof(short int));
printf("sizeof int : %lu\n", sizeof(int));
printf("\n\n");
printf("==== sending short int to functionA() ====\n");
short int shortdata[4] = {10, 20, 50, 100};
functionA(shortdata, 4);
printf("==== sending int to functionA() ====\n");
int intdata[4] = {10, 20, 50, 100};
functionA(intdata, 4);
}
void functionA(short int arr[], int size) {
int i;
char* ptr;
for (i = 0; i < size; ++i) {
ptr = &arr[i];
printf("bytes of 'arr[%d]' : %x %x\n", i, *ptr, *(ptr+1));
printf("value of 'arr[%d]' : %d\n", i, arr[i]);
printf("\n");
}
}
, который производит этот вывод:
sizeof short int : 2
sizeof int : 4
==== sending short int to functionA() ====
bytes of 'arr[0]' : a 0
value of 'arr[0]' : 10
bytes of 'arr[1]' : 14 0
value of 'arr[1]' : 20
bytes of 'arr[2]' : 32 0
value of 'arr[2]' : 50
bytes of 'arr[3]' : 64 0
value of 'arr[3]' : 100
==== sending int to functionA() ====
bytes of 'arr[0]' : a 0
value of 'arr[0]' : 10
bytes of 'arr[1]' : 0 0
value of 'arr[1]' : 0
bytes of 'arr[2]' : 14 0
value of 'arr[2]' : 20
bytes of 'arr[3]' : 0 0
value of 'arr[3]' : 0
первые две строки вывода показывают, что на моей машине, short int
берет 2 байта памяти, и int
берет 4 байта.
functionA()
ожидает short int
массив, и когда я отправляю его short int[]
, мы видим ожидаемый вывод. Байты, которые составляют первый элемент массива, 0x0a 0x00
, который в десятичном числе равняется "10"; байты, которые составляют второй элемент массива, 0x14 0x00
, который в десятичном числе равняется "20"; и так далее.
, Но когда я отправляю functionA()
int[]
, я отправляю 4 байта за элемент, поэтому когда это выполняет итерации через массив, это не видит элементы правильно. Это делает хорошо с первым элементом, но только потому, что это - небольшое число; когда это ищет второй элемент, это на самом деле смотрит на последние два байта первого элемента, таким образом, это видит 0x00 0x00
, или "0"; когда это ищет третий элемент, это смотрит на первые два байта второго элемента и видит 0x14 0x00
, или "20"; и так далее.
Другой способ показать случается так, что байты [1 120] являются этим:
0a 00 14 00 32 00 64 00
и байты [1 121] это:
0a 00 00 00 14 00 00 00 32 00 00 00 64 00 00 00
, поскольку functionA()
ожидает short int[]
, это рассматривает intdata
тот путь - два байта за элемент - и видит как его элементы:
arr[0] : 0a 00
arr[1] : 00 00
arr[2] : 14 00
arr[3] : 00 00
Это - подобная история с Вашим кодом. Ваш getAverage()
ожидает int[]
, поэтому когда Вы отправляете его double[]
, это не видит байты путем, Вы предназначаете.
(Столкновение между [1 128] и double
является еще более решительным, чем между [1 130] и int
; это вызвано тем, что в дополнение к тому, чтобы быть различными размерами (на большинстве современных машин, int
4 байта и double
, 8 байтов), числа с плавающей запятой хранятся как экспонента и мантисса - таким образом, значения байта имеют совершенно другое значение.)
я надеюсь, что это объяснение помогает, и я поощряю Вас экспериментировать с кодом выше и читать о внутренностях памяти C, поскольку это принадлежит выделению и обработке переменных. Как новый программист C, Вы вникнете в к основным принципам, которые помогут Вам столько, сколько Вы продолжаете программировать в C.
У меня была такая же проблема с веб-приложением, которое я разрабатываю. В итоге я отключил автоматическую сборку и начал сборку один раз в день (Project-> Build автоматически), так что я все еще получаю преимущества завершения кода из библиотек, ускоряя программу на старых компьютерах.
Я столкнулся с этим вопросом, ища тот же ответ. Я перечислю шаги, которые я сделал здесь, и, надеюсь, это поможет кому-то в будущем.
Я использую Eclipse 4.1 и делаю следующее, чтобы исключить проверку для определенных файлов xml. Я уверен, что если вы настроите различные валидаторы, это будет работать и для других файлов.
Перейдите в «Настройки» -> «Проверка» Найдите валидатор, который вы хотите изменить, и выберите настройки (не у всех валидаторов есть настройки, надеюсь, у вас есть).
В настройках вы можете добавить группу исключения, где вы можете добавить правило, чтобы указать, чтобы исключить валидатор для определенных расширения, имя папки или файла, характер проекта, фасет или тип содержимого.
У меня есть Eclipse для разработчиков PHP, и я столкнулся с той же проблемой.
В дополнение к превосходным ответам, приведенным выше, у меня есть еще одно предложение.
Моя первая рекомендация - не использовать Aptana, если только вам не нужны эти валидаторы (поскольку их практически невозможно отключить, исходя из моего опыта).
Кроме того, перейдите в Файл -> Свойства -> Строители, снимите флажки «Проверка» и «Конструктор сценариев» и «Валидатор JavaScript».
Пока что он помог значительно ускорить некоторые операции.
Я также рекомендую отключить «Автоматическую сборку». Поскольку вы используете PHP, шансы, что он вам действительно понадобится для создания чего-либо, если вы не хотите проверки, невелики.
В главном меню перейдите в «Проект» и снимите флажок «Создавать автоматически».
Я обнаружил, что в свойствах проекта есть категория Строители. В списке строителей у меня был JavaScript Builder. Я отменил выбор этого конструктора, и все мои неприятные проблемы с проверкой JavaScript исчезли.
это сработало для меня: Свойства > Строители и сняв соответствующий флажок. https://bugs.eclipse.org/bugs/show_bug.cgi?id=317833
кажется ошибкой в некоторых версиях eclipse.