Some macros and unused date functions

[lekkereten]

In date.c only 4 out of 9 functions are being used.

In the following functions: date_get_year, date_get_month, date_get_hour, date_get_min, date_get_sec, the only one which it is used is date_get_day to later be called by is_day_of_sun, is_day_of_moon, is_day_of_star which will be called on other files.

My suggestion is that the functions that are not in use to be removed.

Otherwise a macro could be made. Something like that:

#define date_get_sub(tm_element) { \
   time_t t; \
   struct tm* lt; \
   t = time(NULL); \
   lt = localtime(&t); \
   return lt->tm_element; \
}

int date_get_year(void) {
   date_get_sub(tm_year + 1900);
}

{...}

Also, it reminded me about Show* functions in showmsg.c.

And with Euphy's script-shortener spirit as inspiration, this could be rewritten with a macro:

#define ShowSub(msg_const) { \
   int ret; \
   va_list ap; \
   va_start(ap, string); \
   ret = _vShowMessage(msg_const, string, ap); \
   va_end(ap); \
   return ret; \
}

int ShowMessage(const char *string, ...) {
   ShowSub(MSG_NONE);
}

int ShowStatus(const char *string, ...) {
   ShowSub(MSG_STATUS);
}

int ShowSQL(const char *string, ...) {
   ShowSub(MSG_SQL);
}

{...}

Now, I don't know if the usage of macros is a good programming practice, it's up to you to decide if this is a good thing that I suggested.

Bonus:

And do you guys think that it would be worth using the restrict keyword, since pointers are everywhere in the code, and I just thought that it could help optimize it.

Example:

int merc_hom_change_name(struct map_session_data *sd, char *restrict name) <-----
{
   int i;
   struct homun_data *hd;
   nullpo_retr(1, sd);

   hd = sd->hd;
   if (!merc_is_hom_active(hd))
       return 1;
   if(hd->homunculus.rename_flag && !battle_config.hom_rename)
       return 1;

   for(i=0;i<NAME_LENGTH && name[i];i++){ <---
       if( !(name[i]&0xe0) || name[i]==0x7f) <---
           return 1;
   }

   return intif_rename_hom(sd, name); <---
}

Thanks.

[Lighta]

Hi what you suggesting is to reduce code redundancy, (al,ost at oneextreme here) well ok but I would prefer do it as subfonction instead macro.

restrict could be a good idea of optimisation evenif that may increase maintanibility time a bit.