[solved] compiler not "seeing" file in new path

[mzimmers]

Hi, all -

I need to do some work with 64-bit integers in a Qt application. I tried including the cstdint file, but according to the editor, it can't find it. In terminal, I added a path to the file in my PATH variable, quit and re-started Creator, with the same results.

I also noticed that the Creator text editor suggests a data type int64_t when I type in "int." Is there some built-in 64-bit support that I don't know about? Am I barking up the wrong tree with the cstdint file?

Any suggestions on how best to handle this are appreciated.

[JohanSolo]

I think you can simply use the long (unsigned) int, which should in principle use 8 bytes (i.e. 64 bits). If your compiler does the job correctly you don't even need to add fancy #include, this is regular C++.

At least this works with gcc 4.3.2 on 64bits SLC5.

Edit : if you're using a 32 bits OS I'm afraid this won't work.

[tobias.hunger]

... and there are qint8/16/32/64 as well as quint8/16/32/64 defined, too.

[mzimmers]

The long signed int shows as 4 bytes. I can't use unsigned, or if I did, it would be more trouble than it's worth.

[JohanSolo]

Just for curiosity, what OS and compiler are you using?

[mzimmers]

Running Mac OS and GNU compiler (relatively recent version).

I do need something that will port over to Windows, so I want the least-involved solution possible.

[mzimmers]

Tobias: that's a good point, and I may go that route.

Of course, the presenting issue of why Creator isn't following the path in my shell $PATH variable is still a mystery...

[koahnig]

The definition for 64 bit int is "long long" or "long long int" on 32 bit OS.

@#ifdef UNIX32
/**

• \typedef long long Int64
• \brief Defines an alias representing int 64.
  /
  typedef long long Int64;
  /*
• \typedef unsigned long long Uint64
• \brief Defines an alias representing uint 64.
  /
  typedef unsigned long long Uint64;
  #endif
  #if defined(UNIX64)
  /*
• \typedef long Int64
• \brief Defines an alias representing int 64.
  /
  typedef long Int64;
  /*
• \typedef unsigned long Uint64
• \brief Defines an alias representing uint 64.
  /
  typedef unsigned long Uint64;
  #endif
  #ifdef WIN32
  /*
• \typedef long long Int64
• \brief Defines an alias representing int 64.
  /
  typedef long long Int64;
  /*
• \typedef unsigned long long Uint64
• \brief Defines an alias representing uint 64.
  */
  typedef unsigned long long Uint64;
  #endif
  @

I guess on a Mac it should work similar, but I do not have the experience.

[goetz]

mzimmer, regarding your include problem, try:

@
#include <tr1/cstdint>
@

This works for me (on a Mac). cstdint is used in conjunction with boost/C++ TR1 standard, and is not in the standard include path, but in a tr1 subdirectory.

If you want to be portable, I would go with the Qt defined qintXXX types.

[mzimmers]

Thanks, Volker.

Am I wrong in believing that Creator picks up the environment variables from my shell?

[goetz]

If you just change the PATH variable in the shell (terminal), then you must start creator via open:

@
open /Applications/Qt\ Creator.app
@

If you start it via the Finder or with Spotlight search, it will not see this change.

[mzimmers]

Oh.

Oops.

Does Creator maintain its own PATH variable?

BTW: the tr1/ worked...thanks.

[goetz]

No, that's a matter of OS X/Finder/launchd and works this way for every application which is started this way.

If you change the PATH in a terminal, it is only valid in this very terminal/shell and the processes started from that shell. It's even not visible in other terminal windows or even tabs.

But you can always add your own extensions to the environment in Creator in the build and run settings.

[mzimmers]

OK, thanks, Volker.