[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.