C programming style question

[Michael Sherwin]

the point is that uint64_t from <stdint.h> is a standard-defined way to request an exactly 64 bit unsigned int while __int64 is an implementation-defined token. It's not a huge difference though.

So I should be able to use uint64_t and still typedef to u64. I'll give it a try.

EDIT: No such file as stdint.h or inttypes.h

[kbhearn]

the point is that uint64_t from <stdint.h> is a standard-defined way to request an exactly 64 bit unsigned int while __int64 is an implementation-defined token. It's not a huge difference though.

So I should be able to use uint64_t and still typedef to u64. I'll give it a try.

absolutely, if you'd prefer to write u64, that would be the portable way to go about it :)

as a side note, the clue on all these things that aren't portable: anything that starts with a double underscore is implementation-defined.

[Michael Sherwin]

the point is that uint64_t from <stdint.h> is a standard-defined way to request an exactly 64 bit unsigned int while __int64 is an implementation-defined token. It's not a huge difference though.

So I should be able to use uint64_t and still typedef to u64. I'll give it a try.

absolutely, if you'd prefer to write u64, that would be the portable way to go about it

as a side note, the clue on all these things that aren't portable: anything that starts with a double underscore is implementation-defined.

Since my compiler does not come with stdint.h or inttypes.h I will just include that in the #ifdef _MSC_VER block.

[Michael Sherwin]

Okay this is what I have so far. And it seems to work correctly. However I'm still open to suggestions.

Code: Select all

#ifdef _MSC_VER
#define CDECL __cdecl
typedef unsigned __int32 s32;
typedef   signed __int64 u64;
#else
#include <stdint.h>
#include <inttypes.h>
#define sint32_t s32;
#define uint64_t u64;
#define CDECL
#endif

#define EXIT_SUCCESS 1

u64 dirNW&#91;64&#93;;
u64 dirNN&#91;64&#93;;
u64 dirNE&#91;64&#93;;
u64 dirEE&#91;64&#93;;
u64 dirSE&#91;64&#93;;
u64 dirSS&#91;64&#93;;
u64 dirSW&#91;64&#93;;
u64 dirWW&#91;64&#93;;

void InitData&#40;void&#41;;
s32 CDECL main&#40;void&#41;;

void InitData&#40;) &#123;
  s32 i,j,k,sq64,sq0x88; 
  u64 *dirXX&#91;8&#93; = &#123;dirNW,dirNN,dirNE,dirEE,dirSE,dirSS,dirSW,dirWW&#125;;
  s32 board0x88Off&#91;8&#93; = &#123;15,16,17,1,-15,16,17,-1&#125;;
  s32 board64Off&#91;8&#93; = &#123;7,8,9,1,-7,-8,-9&#125;;
  for&#40;i = 0, k = -1; i <= 0x80; i++) &#123;
    if&#40;&#40;i & 0x88 ? false &#58; true&#41;) &#123; 
      k++;
      for&#40;j = 0; j < 8; j++) &#123;
        dirXX&#91;j&#93;&#91;k&#93; = 0;
        sq64 = k;
        sq0x88 = i + board0x88Off&#91;j&#93;;
        while&#40;&#40;sq0x88 & 0x88 ? false &#58; true&#41;) &#123;
          sq64 = sq64 + board64Off&#91;j&#93;;
          dirXX&#91;j&#93;&#91;k&#93; ^= &#40;u64&#41;1 << sq64;
          sq0x88 = sq0x88 + board0x88Off&#91;j&#93;;
        &#125;
      &#125;
    &#125;
  &#125;
&#125;

s32 CDECL main&#40;)&#123;
  InitData&#40;);
  return&#40;EXIT_SUCCESS&#41;;
&#125;

[kbhearn]

the point is that uint64_t from <stdint.h> is a standard-defined way to request an exactly 64 bit unsigned int while __int64 is an implementation-defined token. It's not a huge difference though.

So I should be able to use uint64_t and still typedef to u64. I'll give it a try.

absolutely, if you'd prefer to write u64, that would be the portable way to go about it :)

as a side note, the clue on all these things that aren't portable: anything that starts with a double underscore is implementation-defined.

Since my compiler does not come with stdint.h or inttypes.h I will just include that in the #ifdef _MSC_VER block.

dare i ask how old your compiler is? it's true microsoft didn't support it for a long while as it was part of C99 and microsoft didn't care about that but a few years back they finally implemented some of the core parts in VS2012 (probably at least in part because C++11 required certain C99 features to exist - the stdint.h header being one of those).

[mar]

Hmm, I wonder why you need to specify __cdecl at all, not sure if it still holds for VS2015 (if would be very surprised if it wouldn't),
but __cdecl is the default calling convention (unless you mess with your project settings manually)

I also wonder why not simply int main() as you'll most likely never return anything outside -32k..32k range anyway.

[Dann Corbit]

I like it better.
But this is a naughty no-no:
#define EXIT_SUCCESS 1

The macro EXIT_SUCCESS is included in header file
#include <stdlib.h>
and needs to be defined by the implementation.

Believe it or not, your implementation behaves badly on {for instance} OpenVMS and normally EXIT_SUCCESS will be zero for most systems.

[Dann Corbit]

Hmm, I wonder why you need to specify __cdecl at all, not sure if it still holds for VS2015 (if would be very surprised if it wouldn't),
but __cdecl is the default calling convention (unless you mess with your project settings manually)

I also wonder why not simply int main() as you'll most likely never return anything outside -32k..32k range anyway.

I did not try it lately, but (for instance) if you did a fastcall compile (forces things to registers for returns) you would get an error message about main() with Visual Studio.
https://msdn.microsoft.com/en-us/library/6xa169sk.aspx

[Dann Corbit]

From the cited link, it looks like they fixed the problem with main():

"Using the /Gr compiler option causes each function in the module to compile as __fastcall unless the function is declared by using a conflicting attribute, or the name of the function is main."

[mar]

I did not try it lately, but (for instance) if you did a fastcall compile (forces things to registers for returns) you would get an error message about main() with Visual Studio.
https://msdn.microsoft.com/en-us/library/6xa169sk.aspx

Elementary types are always returned in registers. I think fastcall simply passes function args in registers if possible (but this is done automatically for x64).
For performance critical paths tiny functions will be inlined anyway so I don't see what you really gain from using fastcall (except for adding extra ifdef/define CDECL)?
If it's not inlined (i.e. complicated) then you don't have enough registers anyway [x86] and most likely some of those args will be stored on stack anyway because you'll need to reuse registers to optimize inner loops etc.
So I would strongly discourage anyone from messing with default calling convention, it won't magically make your program run faster.