Hi,

I'm using Microsoft .NET 2003, and I have the LNK2020 error when
building my program.

I have this in my code:

unsigned __int64 VarArray[256] = {0};

When I build the program, I get the error "error LNK2020: unresolved
token (0A000108) VarArray". Same error when declaring it as
"uint64_t", even though other variables (non-arrays) that are also
declared as "unsigned __int64" and "uint64_t" gave no error.

There is no error if I declare VarArray as "unsigned int" instead.

Eventually, I'm performing bitwise operations on VarArray.

What is wrong here?

Thank you.

Regards,
Rayne

On Oct 19, 6:01=A0am, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
wrote:
> Hi,
>
> I'm using Microsoft .NET 2003, and I have the LNK2020 error when
> building my program.
>
> I have this in my code:
>
> unsigned __int64 VarArray[256] =3D {0};
>
> When I build the program, I get the error "error LNK2020: unresolved
> token (0A000108) VarArray". Same error when declaring it as
> "uint64_t", even though other variables (non-arrays) that are also
> declared as "unsigned __int64" and "uint64_t" gave no error.
>
> There is no error if I declare VarArray as "unsigned int" instead.
>
> Eventually, I'm performing bitwise operations on VarArray.
>
> What is wrong here?
>
> Thank you.
>
> Regards,
> Rayne

Are the errors in other files than the one that includes the variable
definition?  Perhaps you need an "extern" declaration of the global
variable in a header/in those other files?

lancer6238@yahoo.com wrote:
> Hi,
>
> I'm using Microsoft .NET 2003, and I have the LNK2020 error when
> building my program.
>
> I have this in my code:
>
> unsigned __int64 VarArray[256] = {0};
>
[...]

Hi,
a little research on google makes me think that you are mixing managed
and unmanaged code. Such "mixed mode application" won't be linked
against the "microsoft standard library". Read this thread, maybe it can
help you:

       http://www.pcreview.co.uk/forums/thread-1433392.php

-- 
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare   --  Galileo  Galilei  --   You can only help him
a scoprirla dentro di s�.                        discover it in himself.

Vincenzo Mercuri

Vincenzo Mercuri wrote:
> [...] Such "mixed mode application" won't be linked
> against the "microsoft standard library". Read this thread, maybe it can
> help you:
>
> http://www.pcreview.co.uk/forums/thread-1433392.php

or rather...check whether __int64 is a managed extension or not.

-- 
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare   --  Galileo  Galilei  --   You can only help him
a scoprirla dentro di s�.                        discover it in himself.

Vincenzo Mercuri

On 10/19/2010 6:01 AM, lancer6238@yahoo.com wrote:
> Hi,
>
> I'm using Microsoft .NET 2003, and I have the LNK2020 error when
> building my program.
>
> I have this in my code:
>
> unsigned __int64 VarArray[256] = {0};
>
> When I build the program, I get the error "error LNK2020: unresolved
> token (0A000108) VarArray". Same error when declaring it as
> "uint64_t", even though other variables (non-arrays) that are also
> declared as "unsigned __int64" and "uint64_t" gave no error.
>
> There is no error if I declare VarArray as "unsigned int" instead.
>
> Eventually, I'm performing bitwise operations on VarArray.
>
> What is wrong here?

This is a Microsoft-specific error, related to "managed types".

     http://msdn.microsoft.com/en-us/library/b57tw91b(v=VS.71).aspx

     http://msdn.microsoft.com/en-us/library/b57tw91b(VS.80).aspx

     =====
     unresolved token 'token'

     Similar to an undefined external error, except that the reference
     is via metadata. In metadata, all functions and data must be defined.
     =====

If you need more information, you'll need to ask in a Microsoft-specific 
newsgroup.

-- 
Kenneth Brody

"lancer6238@yahoo.com" <lancer6238@yahoo.com> writes:
> Hi,
>
> I'm using Microsoft .NET 2003, and I have the LNK2020 error when
> building my program.
>
> I have this in my code:
>
> unsigned __int64 VarArray[256] = {0};
[snip]

I'm not familiar with Microsoft extensions, but I'd be a bit surprised
if "unsigned __int64" were the right way to refer to a 64-bit unsigned
type.  If __int64 is a typedef rather than a macro, that should be a
syntax error.  (If it's a macro, it makes me wonder why the heck they
didn't make it at typedef.)

A bit of Googling indicates that there's something called __uint64.
I suggest using that rather than "unsigned __int64".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
[...]
> [...] I'd be a bit surprised
> if "unsigned __int64" were the right way to refer to a 64-bit unsigned
> type.  If __int64 is a typedef rather than a macro, that should be a
> syntax error.  (If it's a macro, it makes me wonder why the heck they
> didn't make it at typedef.)
>
> A bit of Googling indicates that there's something called __uint64.
> I suggest using that rather than "unsigned __int64".

Actually there exists something called Uint64 that is a "managed type",
but, according to the MSDN documentation, its C++/CLI equivalent is just
"unsigned __int64" or "unsigned long long":

http://msdn.microsoft.com/en-us/library/s3f49ktz(v=VS.80).aspx

http://msdn.microsoft.com/en-us/library/2e6a4at9(v=VS.71).aspx

I don't know if __uint64 exists actually, but "unsigned __int64" is
surely the right (Microsoft's) way to refer to it.

I think we should be surprised :-)

-- 
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare   --  Galileo  Galilei  --   You can only help him
a scoprirla dentro di s�.                        discover it in himself.

Vincenzo Mercuri

Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> writes:
> Keith Thompson wrote:
> [...]
>> [...] I'd be a bit surprised
>> if "unsigned __int64" were the right way to refer to a 64-bit unsigned
>> type.  If __int64 is a typedef rather than a macro, that should be a
>> syntax error.  (If it's a macro, it makes me wonder why the heck they
>> didn't make it at typedef.)
>>
>> A bit of Googling indicates that there's something called __uint64.
>> I suggest using that rather than "unsigned __int64".
>
> Actually there exists something called Uint64 that is a "managed type",
> but, according to the MSDN documentation, its C++/CLI equivalent is just
> "unsigned __int64" or "unsigned long long":
>
> http://msdn.microsoft.com/en-us/library/s3f49ktz(v=VS.80).aspx
>
> http://msdn.microsoft.com/en-us/library/2e6a4at9(v=VS.71).aspx
>
> I don't know if __uint64 exists actually, but "unsigned __int64" is
> surely the right (Microsoft's) way to refer to it.
>
> I think we should be surprised :-)

I'm both surprised and dismayed.

According to the first of those web pages, int and long are both
32 bits (4 bytes).

No doubt __int32 is a macro that expands to "int", so "long __int32" is
a 32-bit type and "long long __int32" is a 64-bit type.  Unless of
course __int32 expands to "long", so "long __int32" is a 64-bit type
and "long long __int32" is a syntax error.

Ugh.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> Vincenzo Mercuri<vincenzo.mercuri@yahoo.it>  writes:
[...]
>> I think we should be surprised :-)
>
> I'm both surprised and dismayed.
[...]
> No doubt __int32 is a macro that expands to "int", so "long __int32" is
> a 32-bit type and "long long __int32" is a 64-bit type.  Unless of
> course __int32 expands to "long", so "long __int32" is a 64-bit type
> and "long long __int32" is a syntax error.
>
> Ugh.

Uhm, I think that the "KISS" rule won't work at Microsoft.

-- 
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare   --  Galileo  Galilei  --   You can only help him
a scoprirla dentro di s�.                        discover it in himself.

Vincenzo Mercuri

* Vincenzo Mercuri <vincenzo.mercuri@gmail.com>:
> Uhm, I think that the "KISS" rule won't work at Microsoft.

If you ever read/wrote native win32 API code, you already know that. My
last 'wtf' moment was when I tried to modify an existing MSI file
through the windows installer api. I was indeed forced to prepare and
execute SQL queries to accomplish this.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@palmen-it.de>
 web:   http://palmen-it.de/  |             http://palmen-it.de/pub.txt
 my open source projects:     |   Fingerprint: ED9B 62D0 BE39 32F9 2488
 http://palmen-it.de/?pg=pro  +                5D0C 8177 9D80 5ECF F683

Felix Palmen wrote:
> * Vincenzo Mercuri<vincenzo.mercuri@gmail.com>:
>> Uhm, I think that the "KISS" rule won't work at Microsoft.
>
> If you ever read/wrote native win32 API code, you already know that. My
> last 'wtf' moment was when I tried to modify an existing MSI file
> through the windows installer api. I was indeed forced to prepare and
> execute SQL queries to accomplish this.

Yes, I did some, I still have the books by Petzold and Richter.
I think that sometimes Microsoft makes an attempt on programmers'
health, with MFC in the past, with C++/CLI now and for the future.
However, win32 APIs are actually the least harm on Windows front...

-- 
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare   --  Galileo  Galilei  --   You can only help him
a scoprirla dentro di s�.                        discover it in himself.

Vincenzo Mercuri

On 10/19/2010 8:42 PM, Keith Thompson wrote:
[... Microsoft C ...]
> No doubt __int32 is a macro that expands to "int",

"No doubt"?  You're that certain?

Sorry, but Microsoft's C compiler has __int32 as a built-in type, along with 
8, 16, 64, and 128-bit types.

http://msdn.microsoft.com/en-us/library/cc953fe1.aspx

> so "long __int32" is
> a 32-bit type and "long long __int32" is a 64-bit type.  Unless of
> course __int32 expands to "long", so "long __int32" is a 64-bit type
> and "long long __int32" is a syntax error.
>
> Ugh.

Well, "__int32" doesn't "expand" at all.

Now, if other implementations define such types, they may define them 
differently.

-- 
Kenneth Brody

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 10/19/2010 8:42 PM, Keith Thompson wrote:
> [... Microsoft C ...]
>> No doubt __int32 is a macro that expands to "int",
>
> "No doubt"?  You're that certain?
>
> Sorry, but Microsoft's C compiler has __int32 as a built-in type, along with 
> 8, 16, 64, and 128-bit types.
>
> http://msdn.microsoft.com/en-us/library/cc953fe1.aspx

Poor choice of words on my part.  I was speculating.  Apparently __int8,
__int16, __int32, and __int64 are implementation-defined keywords.

>> so "long __int32" is
>> a 32-bit type and "long long __int32" is a 64-bit type.  Unless of
>> course __int32 expands to "long", so "long __int32" is a 64-bit type
>> and "long long __int32" is a syntax error.
>>
>> Ugh.
>
> Well, "__int32" doesn't "expand" at all.

So I would speculate that "long __int32" or "long long __int32" would be
a syntax error.

BTW, that web page has a number of errors and omissions.  There's no
mention of either "unsigned __int32" or "__uint32".  It mentions
something called "longlong", described only as "Larger than an unsigned
long" (and discusses "long long" on the next line).  It claims that

    Objects of type int can be declared as signed int  or unsigned
    int. Signed int is a synonym for int.

but in fact something declared as unsigned int is not an object of type
int.

I hope their implementation is more coherent than their documentation.

> Now, if other implementations define such types, they may define them 
> differently.

Certainly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/20/2010 2:48 PM, Keith Thompson wrote:
> Kenneth Brody<kenbrody@spamcop.net>  writes:
[...]
>> http://msdn.microsoft.com/en-us/library/cc953fe1.aspx
>
> Poor choice of words on my part.  I was speculating.  Apparently __int8,
> __int16, __int32, and __int64 are implementation-defined keywords.
[...]
> So I would speculate that "long __int32" or "long long __int32" would be
> a syntax error.

Well, interestingly(?), "long __int32" works, whereas the others do not. 
More telling is the wording of the error:

"long __int8 foo;" generates:

     error C2632: 'long' followed by 'char' is illegal

"long __int16 foo;" generates:

     error C2632: 'long' followed by 'short' is illegal

"long __int32 foo;" generates:

     (no warning or error)

"long __int64 foo;" generates:

     error C2632: 'long' followed by '__int64' is illegal

Note that telling the compiler to display the preprocessor output still 
shows "__int8", "__int16", "__int32", and "__int64".

Even more "interesting" is that if you use a "long long" modifier, the error 
says "'__int64' followed by ... is illegal".

So, "long long __int8 foo;" generates the confusing error message:

     error C2632: '__int64' followed by 'char' is illegal

> BTW, that web page has a number of errors and omissions.  There's no
[...]
> I hope their implementation is more coherent than their documentation.
[...]

-- 
Kenneth Brody