- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 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
long GetMicroseconds();
CTvoid cLog::GetTime (char * acLocal, time_t tTime)
{
struct tm ltLocalTime;
struct tm * ptLocalTime;
tTime = time (NULL);
ptLocalTime = localtime_r (&tTime, <LocalTime);
sprintf(acLocal,"%04d%02d%02d %02d%02d%02d-%06ld",
ptLocalTime->tm_year+1900,
ptLocalTime->tm_mon+1,
ptLocalTime->tm_mday,
ptLocalTime->tm_hour,
ptLocalTime->tm_min,
ptLocalTime->tm_sec,
GetMicroseconds());
}
long GetMicroseconds()
{
struct timeval timeVal;
if (0 == gettimeofday( &timeVal, NULL ))
return timeVal.tv_usec;
return -1;
}
cLog::__Write(...)
{
/* ... */
tTime = time(NULL);
GetTime (acDataTime, tTime);
/* ... */
}
R&D дали задание добавить микросекунды ко всем таймстемпам в логах.
сказано - сделано.
ну ведь никто не говорил что таймстемпы должны быть еще и консистентными.
ЗЫ ну и time() надо вызвать раза два-три - для надёжности.
clock_gettime() нету ?
... хм. это хорошая идея для еще одного говнокода. там какие-то чудаки все тандартные типы пере-typedef-или. типа "typedef int CTint;" и т.д. и т.п. для, цитирую, портабельности.
> clock_gettime() нету ?
блин, если бы у нас тут кто маны читать умел.
и если бы доблесное IT еще apropos и $MANPATH постоянно не гробило на серваках постоянно.
Такое много где делают, напр. в gtk (gchar, gint, gshort, glong, gfloat, gdouble и т. п.)
Вы в курсе, что int не гарантируется быть 32-битным? Так что про портабельность тут вполне резонно. Сделано на всякий пожарный.
Или может быть такой случай, что 32-битных полатформ int должен быть 32-битным, а для 64-битных 0- 64-битный. int везде одинаковый, long под юниксами 64 бита, а под виндовс - 32 бита, зато 64 бита является long long и т.д. Как тут не затайпдефить.
Так что тайпдефанье тут имеет смысл. Может быть сейчас оно сделано так: "typedef int CTint". Но когда что-то поменяется, не нужно будет везде выискивать и вставлять другой тип. Достаточно просто передефайнить CTint - и всё.
Другой разговор что зачастую такие студенчкеские поделки никому не нужны и запускаются с одной системы...
Мля. Детский сад. Не тормози. Именно с такой логикой народ и пишет такое говно.
stdint.h & inttypes.h существует уже ХЕЗ как давно. во первых.
во вторых. C библиотека (и даже POSIX) определена используя стандартные С типы. это и есть то как задается портабельность. если функции нужен параметром int, значит нужен int, long - значит long. а не какое-то самопальное говно. вне зависимости от платформы.
Я вчера опять с аиксом воевал. Ставишь _POSIX_SOURCE, в одном месте ругается. Ставишь _ALL_SOURCE, в другом... Так и не заломал:(
Может, зашлю на говнокод даже. fcntl.h без _POSIX_SOURCE не компилируется. Если не предусмотрено его использование без этого дефайна, так бы и сказали в самом начале. Чего-то я в этой жизни не понимаю, видать.
$ gcc -D_ALL_SOURCE aaa.c
In file included from /usr/include/fcntl.h:188,
from aaa.c:1:
/usr/include/unistd.h:924: error: parse error before '[' token
/usr/include/unistd.h:925: error: parse error before 'rid_t'
$ more aaa.c
$ cat aaa.c
#include <fcntl.h>
$
Потому что этот rid_t только под _POSIX_SOURCE.
Какого хрена оно не подразумевается ALL_SOURCE-ом, не знаю.
А потом вообще начинается ахтунг:
$ gcc -D_ALL_SOURCE -D_POSIX_SOURCE aaa.c
In file included from /usr/include/fcntl.h:188,
from aaa.c:1:
/usr/include/unistd.h:924: error: parse error before '[' token
/usr/include/unistd.h:925: error: parse error before 'rid_t'
$ gcc aaa.c
In file included from /usr/include/fcntl.h:188,
from aaa.c:1:
/usr/include/unistd.h:924: error: parse error before '[' token
/usr/include/unistd.h:925: error: parse error before 'rid_t'
$ gcc -D_POSIX_SOURCE aaa.c
<тут он скомпилялся>
$
протестировать сам сейчас не могу бо IT месяц назад сняло с сети наш единственный AIX 6.1 сервак (отдали другому отделу бо мы официально в данный момент времени на Соларис/Линукс пересаживаемся).
Разобраться можно, но лень. Проще оказалось сделать оттуда дырку домой и собрать тут.
Ну и правильно, что пересаживаетесь. Эти проприетарные динозавры свое отжили.
но эти проприетарные системы как были так и останутся сидеть в разных нишах. нормальной поддержки (скажем 10-летний контракт) на дешевые гетерогенные платформы никто не дает. и именно такие контракты и держат на плаву всех этих динозавров.
были конечно пара клинических случаев (типа С++ компилятор (с) ~1995 плюс доморощеная встраиваемая платформа) но это все мелочи по сравнению с ордами кривых непортабельных извращений народ якобы специально делает для портабельности.
прочиталось как const void
много думал