Re: VS 2005/C++/x64

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 4 Dec 2007 17:17:34 -0600

Message-ID:

<eVxXcusNIHA.1204@TK2MSFTNGP03.phx.gbl>

"Mark" <mmodrall@nospam.nospam> wrote in message
news:A00DCB81-B997-408F-9F4A-7B690E3961BE@microsoft.com...

Hi Ben...

I'll do that, thanks.

I don't know if this should be on another thread or not, but I thought I'd
ask - is there any way to tell if a variable is signed or unsigned with a
compile-time operator?

I'm having to 64-bit proof piles of our old code + 3rd party stuff, and
I'm
trying to come up with some macros to help identify/work around variable
size
boundaries.

I've come up with these macros that work okay, but the ISSIGNED() macro is
a
little kludgy and requires a type name rather than an instance to work
because of the cast.

// either type or instance macros
#define SINTMAX ( s ) (0x7FFFFFFFFFFFFFFF >> ((sizeof(long long) - sizeof
(
s )) * 8 )
#define UINTMAX ( s ) (0xFFFFFFFFFFFFFFFF >> ((sizeof(long long) - sizeof
(
s )) * 8 )

// type-only macros
#define ISSIGNED ( s ) ( ( s ) (UINTMAX ( s )) != (UINTMAX ( s )))
#define INTMAX ( s ) (ISSIGNED ( s ) ? SINTMAX ( s ) : UINTMAX ( s ))
#define INTMIN ( s ) (ISSIGNED ( s ) ? -(SINTMAX ( s ))-1 : 0)

The easy test for signed variables is: (((T)-1) < 0) where T is a integral
type

So immediately your ISSIGNED becomes a lot less hackish...

Using Norbert's template idea:

template<bool B>
struct compilerbool
{
enum { value = B };
compilerbool(int) {}
};
template<typename T>
compilerbool<(((T)-1) < 0)> is_signed(T) { return 0; }

Being enum-based, it is computed at compile-time, but it is not considered
to be a compile-time constant so you can't for example use it as an array
bound. The original expression will work though... if you have the type
name.
(please excuse the C++/CLI test case which is what I had handy)

int main(array<System::String ^> ^args)
{
int one = 1;
unsigned two = 2;
Console::WriteLine(is_signed(one).value);
Console::WriteLine(is_signed(two).value);
return 0;
}

Thanks
Mark

"Ben Voigt [C++ MVP]" wrote:

"Mark" <mmodrall@nospam.nospam> wrote in message
news:DB0E41EA-5D24-4ECD-BDC0-DF5F0BE16DD3@microsoft.com...

Thanks, Ben...

I am confused by one thing. When I go to Configuration Manager and
choose
<New> under Active solution platform: there are a number of standard
names
in
the list, x64 being one of them.

There's a drop-down under that saying Copy settings from:.

When I add an x64 platform without copying any settings from, I don't
appear
to get any of the standard pre-processor defines (_WIN64, etc).

Is there a way of adding the architecture to the solution that does get
all
the standard defines set up?

I think this is one of the outstanding complaints about the configuration
manager. My best advice is to create a new project for the desired
platform
and see what build options the new project wizard gives you.

Thanks
Mark

"Ben Voigt [C++ MVP]" wrote:

"Mark" <mmodrall@nospam.nospam> wrote in message
news:4DB18024-9CC0-4EB1-B66D-629692BC3018@microsoft.com...

Hi...

We're taking a pile of our old C++ and C# projects over to an x64
environment and we're running into some oddities. I've found some
article
referencing some of the pitfalls but also some things that just
aren't
lining
up.

We've added the x64 platform configuration to the solution and
that's
what
we're trying to build with.

1) our C++ projects are using pre-compiled headers, but if we build
32-bit
first then x64 we don't get a full list of compatibility problems.
Uncheck
pre-compiled headers and it explodes. Are pre-compiled headers just
not
supposed to be used for cross-platform builds?

Pre-compiled headers, like any compiler product, need to be stored in
a
separate intermediate directory for each target configuration. Just
like
dumping a mixture of debug and release object files in the same
directory
is
a recipe for disaster, so is pointing the 32-bit and 64-bit compilers
to
the
same .pch.

2) I found articles saying int and long are still 16 and 32-bits
respectively even with an x64 bit while size_t, time_t and others
supposedly
become 64-bit (major source of compiler warnings) *but*
2a) when I mouse over a size_t declaration in my code in VS, it says
"typedef unsigned int size_t;" Shouldn't that be unsigned __int64?
Of
course you can't find which include file's typedef is being used
easily.
Is
the intellisense just wrong?

int and long are 32-bits, size_t is 64-bits, and Intellisense is wrong
fairly frequently

2b) when I went searching the VC++ includes for size_t declarations
I
found
that time.h has
#if !defined (_WIN32)
#error ERROR: Only Win32 target supported
#endif
but then lower down has
#ifndef _SIZE_T_DEFINED
#ifdef _WIN64
typedef unsigned __int64 size_t;
#else
typedef _W64 unsigned int size_t;
#endif
#define _SIZE_T_DEFINED
#endif
and *still* lower down has
#ifndef _SIZE_T_DEFINED
typedef unsigned int size_t;
#define _SIZE_T_DEFINED
#endif

Especially since time.h includes crtdefs.h at the top, it doesn't
look
like
the size_t defs in time.h are active, but it does look a bit messed
up.
There are also 64-bit definitions for time_t in the file but the
stuff
at
the
top makes it look like it would blow up.

For 64-bit builds, you define both _WIN32 and _WIN64.

Any tips?

Hope this clears up the confusion.

Thanks
Mark