- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
static char months [] = "JanFebMarAprMayJunJulAugSepOctNovDecGlk";
static char dows [] = "SunMonTueWedThuFriSatEar";
int dd [] =
{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
void gen_http_date (char date_buffer[29], int time) {
int day, mon, year, hour, min, sec, xd, i, dow;
if (time < 0) time = 0;
sec = time % 60;
time /= 60;
min = time % 60;
time /= 60;
hour = time % 24;
time /= 24;
dow = (time + 4) % 7;
xd = time % (365 * 3 + 366);
time /= (365 * 3 + 366);
year = time * 4 + 1970;
if (xd >= 365) {
year++;
xd -= 365;
if (xd >= 365) {
year++;
xd -= 365;
if (xd >= 366) {
year++;
xd -= 366;
}
}
}
if (year & 3) {
dd[1] = 28;
} else {
dd[1] = 29;
}
for (i = 0; i < 12; i++) {
if (xd < dd[i]) {
break;
}
xd -= dd[i];
}
day = xd + 1;
mon = i;
assert (day >= 1 && day <= 31 && mon >=0 && mon <= 11 &&
year >= 1970 && year <= 2039);
sprintf (date_buffer, "%.3s, %.2d %.3s %d %.2d:%.2d:%.2d GM",
dows + dow * 3, day, months + mon * 3, year,
hour, min, sec);
date_buffer[28] = 'T';
}
Делать имена месяцев и дни недели одной сишной строкой, чтобы потом выводить оттуда по три символа через sprintf, считая оффсет умножением на 3 т.к. имена месяцев и дней недели влазят в три символа
https://github.com/vk-com/kphp-kdb/blob/ce1ac4fbde2d3b546936ad07d6a748958f6d2198/net/net-http-server.c#L664
http://roem.ru/2013/07/20/kphp76561/
>ВКонтактовские "олимпиадники"-чемпионы ACM разработали крайне интересную высоконагруженным сайтам технологию.
Хреновые какие-то олимпиадники попались, раз неосилили http://ideone.com/IfvBgi
Follow us!
assert (day >= 1 && day <= 31 && mon >=0 && mon <= 11 &&
year >= 1970 && year <= 2039);
Про 1970 очевидно, начало юникс-времени и вселенной. А что у нас с 2039 годом?
> Самая поздняя дата, которая может быть представлена таким форматом в стандарте POSIX — это 03:14:07, вторник, 19 января 2038 года по Всемирному времени (UTC).
https://ru.wikipedia.org/wiki/Проблема_2038_года
Проверка, впрочем, в таком случае становится хоть и логичной, но некорректной.
Спасибо.
http://ideone.com/GAJ1j1
Пойду стандарт полистаю
Именно поэтому все размерности, кроме самой первой, должны быть константами...
https://github.com/vk-com/kphp-kdb/blob/ce1ac4fbde2d3b546936ad07d6a748958f6d2198/net/net-http-server.c#L735
dd[1] = 28;
} else {
dd[1] = 29;
}
а что, 2100 - високосный?
а, ну да, он же не в диапазоне, значит можно хуй забить
АЦМ-логика, да
И байтоёбства преступно мало.
Может тут можно было ускорить поиск:
Тогда нужно ещё и силу трения отменить вдобавок и всю термодинамику.
Тут же именно само соотношение между периодом обращения вокруг солнца и вокруг своей оси забагованное.
(Вики гласит, что полная энергия взрыва царь-бомбы оценивается в 2,4·10^17Дж).
http://lib.rus.ec/i/23/299223/p47.png
А так у нас всего 14 разных календарей.
http://ru.wikipedia.org/wiki/Французский_республиканский_календарь
256, кстати был бы 16 прериаля.
Ещё в плюсах — фиксированный день недели. Больше одного календаря не понадобится, да и тот не нужен, если можешь считать в уме на уровне 5 класса.
Ну как вариант - двоичный поиск в сложенном заранее массиве. Или даже захардкоженный поиск в духе:Или может быть даже лукап из массива в 365 ячеек... Х.з., что из этого будет быстрее...
P.S. Но на самом деле, дат в таком формате в выхлопе сервера не так уж много, и всё это байтоёбство мало что даст в плане общей производительности...
> двоичный поиск в сложенном заранее массиве
Думал про оба. Таблица - неплохо, но относительно большая.
Двоичный поиск для малых таблиц зачастую медленее, потому что тупой цикл выполняется быстрее за счёт его тупости и последовательного обращения к памяти.
Как насчёт компромисного варианта: перебирать с шагом 2, а если превысили, то выбирать из 2-х предыдущих.
Мне кажется, что все-таки таблица на 366 ячеек будет самым эффективным решением - нет переходов, максимум один cache miss на выборку.
Да, в расчетах то 7 и 12, но в массивах с именами то 8 и 13...
'1','2','3' - очень напрягает кучу кавычек набирать
потому частенько делаю '1,2,3'.split(',')
http://ideone.com/tTFkXf
http://ideone.com/uUFA4K
Никогда не понимал этого - выбор языка из-за какого-то малозначимого сахарка.
В любом популярном и не очень яву можно сделать себе функцию:
qw("1 2 3")
Да. Кодеры всего мира которых НЕ пишут на руби сейчас неистово негодуют, и выбрасывают свои языки, попутно переучиваясь на ruby потому что не могут записать массив через пробелы.
Проблемы подобного рода исключительно в голове у программиста. А ведь изначально Elvenfighter зеленым написал...
qw("1 2 3")
только она не отработает при компиляции
Засунь ее результат в глобальную статическую переменную. Всем пофиг на эти несколько наносекунд при старте. Да и один хрен в пёрле и руби эта самая "компиляция" происходит примерно в тот же момент (или они уже научились сохранять байткод аля питон?).
:/
Баш:
В Лиспе #(a b c) будет массивом строк.
В J все данные - массивы, интерпретация будет зависеть от читателя.
В большинстве языков не так уж и просто - нужно писать никому не нужные запятые.
в лиспе хардкодные литералы строк вроде не особо нужны, там символы есть, имхо они более подходят по философию языка.
(c) Walter Bright
Не проще ли сделать возвращаемый буфер на один байт больше?
Байтоёбы, чо. Экономят на спичках в многомегабайтном бинарнике.