Я уже жаловался, что в Ubuntu-14.04 в Qt таймер неточно отрабатывает
заданный интервал, вместо 4000ms проходит 4063.
Сегодня обнаружилась ещё более странная вещь уже в консоли в программе на C.
Это маленькая тестовая программа, там сначала создаётся udp-сокет, для него
запускается recvfrom и ждёт обращения, а когда оно приходит, то с помощью
sendto отсылает его обратно. Затем там в цикле передаётся некий массив, но
это несущественно. Оказалось, что, если после выполнения sendto вставить
вызов gettimeofday, всё равно, перед циклом или внутри, то sendto ничего
не пересылает и заканчивется с ошибкой 22 и возвращает -1.
Т.е. только присутствие в тексте программы gettimeofday приводит
к неработоспособности. В Astra Linux, основанной на Debian Wheezy,
и то и другое работает правильно.
[quote="Peter"]Приведу попозже, но там именно то, что я описал: помещение gettimeofday() после sendto()
каким-то образом на неё влияет.
вангую, что вы как-то не правильно делаете, и добились UB.[/quote]
Однако в Astra Linux (Debian Wheezy), эта программа работает. Вот её код с отступами:
Если gettimeofday() поместить, например, перед 2-м while(), то sendto() возвращает -1 и заканчивается с ошибкой 22.
То же самое в варианте программы без цикла после sendto(), вернее, когда в цикле всё время передаётся один и тот же файл.
jpg_udp_nnn - это файлы, состоящие из udp-пакетов для очередного jpg, но это не важно, важно, что gettimeofday()
влияет на предидущий вызов sendto().
ошибка 22 - это EINVAL. Ищите у себя: либо что-то неправильно вызываете, либо нагадили в память (переполнился какой-нибудь буфер)
Я в вашем "кирпиче" ничего не нашёл, но особо внимательно и не проверял.
досвидания. Увидимся в следующей жизни, когда вы научитесь писать.[/quote]
Это игра ума. Ещё раньше я замечал, что для struct sockaddr_in sizeof() часто возвращает
0 или -1, уже не помню. И зачем я буду себя ограничивать в коде?
досвидания. Увидимся в следующей жизни, когда вы научитесь писать.[/quote]
Это игра ума. Ещё раньше я замечал, что для struct sockaddr_in sizeof() часто возвращает
0 или -1, уже не помню. И зачем я буду себя ограничивать в коде?
Пётр.[/quote] да ладно! sizeof() действительно вычисляется не при компиляции, а при исполнении, но вернуть ерунду он никак не может. Во всяком случае переспрашивать его бесполезно. Кстати, объекты длины 0 вполне допустимы.
Но речь здесь о другом: этот кусок действительно странный, но он законный, так что обсуждать эту часть есть смысл только после того, как всё заработает.
[quote=Peter][quote=drBatty]досвидания. Увидимся в следующей жизни, когда вы научитесь писать.
Это игра ума. Ещё раньше я замечал, что для struct sockaddr_in sizeof() часто возвращает
0 или -1, уже не помню. И зачем я буду себя ограничивать в коде?
Пётр.[/quote] да ладно! sizeof() действительно вычисляется не при компиляции, а при исполнении, но вернуть ерунду он никак не может. Во всяком случае переспрашивать его бесполезно. Кстати, объекты длины 0 вполне допустимы.
Но речь здесь о другом: этот кусок действительно странный, но он законный, так что обсуждать эту часть есть смысл только после того, как всё заработает.[/quote]
Замечал опять же в Ubuntu в этой программе. Однако этот кусок работает и в Ubuntu
и в Debian, поскольку выход из него происходит.
Пётр.
drBatty написал:
[quote="Peter"]И зачем я буду себя ограничивать в коде?
не, не нужно. Наоборот. Вам сюда[/quote]
Я там не вникал, но cin и cout с перенаправлением я никогда не использую,
употребляю только fprintf.
Обычно я стараюсь оптимизировать время выполнения.
преждевременная оптимизация — всегда зло(не я сказал).
И ваш "код" это доказывает на все 146%. Он не просто медленно работает, а часто вообще не работает.
И не нужно валить с больной головы на здоровую, Ubuntu тут совсем не причём.
PS:
"Peter" написал:
Обычно я стараюсь оптимизировать время выполнения.
очевидно, вы даже не знаете, что это такое, "время выполнения". Доказательство
text
llen:len = sizeof(struct sockaddr_in);
if (len == 0)
goto llen;
лично мне это УГ даже неловко в {code} оборачивать.
"s.xbatob" написал:
sizeof() действительно вычисляется не при компиляции, а при исполнении
в C/C++ таки при компиляции. Это константа в рантайме. У вас опечатка что-ли?
Я же сказал, что это игра ума. Тем более я не знал, почему sizeof() возвращала 0, вот и хотел это проверить - будет 0 или нет.
И это не настоящая программа для работы, она была написана для проверки одного предположения.
во первых, sizeof ничего не возвращает, это константа. Но в отличиеот других констант, её значение не известно программисту во время написания кода.
Вот пример использования этой константы:
text
int* val = malloc(sizeof(int));
в коде никаких sizeof НЕ будет, а будет просто malloc(8), если у вас int имеет размер в 8 байт. Важно понимать, что sizeof возвращает размер в char'ах, а это не байты.
Во вторых, если у вас sizeof "возвращает" ноль, то вы явно что-то делаете не так. Зачем вам объект, которого нет?
В третьих, ваша "программа" не нужна(никому). Т.к. это write-only макароны.
Хорошо, я не задумывался, является ли sizeof() исполнимым оператором. До сих пор с ним не былотрудностей.
зачем вы задумывались об оптимизации того, чего не понимаете?
goto, кстати, практически НЕ оптимизируется, а вот цикл while компилятор с радостью выкинет (потому, можно написать не нужный цикл, если вам так понятнее и "читаемие", но вот ненужное goto нельзя писать ни в коем разе).
Вот смотрите:
text
int factorial(int x)
{
return x<=1? 1: x*factorial(x-1);
}
вы наверное скажите, что это "плохой код", да? Неоптимизированный, да? Работать будет медленно?
ВНЕЗАПНО: второй код — это и есть первый, только после обработки gcc,
Спрашивается, а зачем нужно было обмазываться goto, если компилятор сам умеет ими обмазываться?
