longs in managed C++

Is a long in managed c++ a 64-bit number like in C#
If so how can I distinguish between that and one that's in some unmanaged code, and therefore that is 32-bit
Call it an int

Yves
Tue May 11 11:16:40 CDT 2004


In C++ long is mapped to Int32 while in C# it is mapped to Int64.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/html/vcManagedExtensionsSpec_5_1.asp



--
Yves Tourchot

(ROT13 & rem spam filter to reply)
qriargfby_erzfcnz@flzcngvpb.pn



"songie D" <anonymous@discussions.microsoft.com> wrote in message
news:E18A4946-85D2-4CA0-9BC7-B2C23E3E859D@microsoft.com...
> Is a long in managed c++ a 64-bit number like in C#?
> If so how can I distinguish between that and one that's in some unmanaged
code, and therefore that is 32-bit?
> Call it an int?
>

Ronald
Tue May 11 17:24:14 CDT 2004

No, it is 32 bits.

Ronald Laeremans
Visual C++ team

"songie D" <anonymous@discussions.microsoft.com> wrote in message
news:E18A4946-85D2-4CA0-9BC7-B2C23E3E859D@microsoft.com...
> Is a long in managed c++ a 64-bit number like in C#?
> If so how can I distinguish between that and one that's in some unmanaged
> code, and therefore that is 32-bit?
> Call it an int?
>

Tomas
Tue May 11 21:44:38 CDT 2004

Songie,
> Is a long in managed c++ a 64-bit number like in C#?
> If so how can I distinguish between that and one that's in some unmanaged
code, and therefore that is 32-bit?
> Call it an int?

What Ronald said. Notice you can use __int64 (both in managed and unmanaged
code) to handle 64-bit numbers (or System::Int64 for just managed code)

--
Tomas Restrepo
tomasr@mvps.org

songie
Wed May 12 14:38:13 CDT 2004

OK, being from MSFT maybe you'll know the answer to this.
What is the reason that a long in C# is 64-bits, while a long in
MC++ is 32-bits. Is it perhaps because it is predicted that C# is
the language of the future, while MC++ is there only to provide
IJW for those that feel the need to use it (for whatever reason),
and that we'll all be moving on to 64-bit processors soon anyway
so it makes sense to use a 64-bit variable?

"Ronald Laeremans [MSFT]" <ronaldl@online.microsoft.com> wrote in message
news:uO8Tya6NEHA.3672@TK2MSFTNGP11.phx.gbl...
> No, it is 32 bits.
>
> Ronald Laeremans
> Visual C++ team
>
> "songie D" <anonymous@discussions.microsoft.com> wrote in message
> news:E18A4946-85D2-4CA0-9BC7-B2C23E3E859D@microsoft.com...
> > Is a long in managed c++ a 64-bit number like in C#?
> > If so how can I distinguish between that and one that's in some
unmanaged
> > code, and therefore that is 32-bit?
> > Call it an int?
> >
>
>

Doug
Wed May 12 15:45:16 CDT 2004

songie D wrote:

>OK, being from MSFT maybe you'll know the answer to this.
>What is the reason that a long in C# is 64-bits, while a long in
>MC++ is 32-bits. Is it perhaps because it is predicted that C# is
>the language of the future, while MC++ is there only to provide
>IJW for those that feel the need to use it (for whatever reason),
>and that we'll all be moving on to 64-bit processors soon anyway
>so it makes sense to use a 64-bit variable?

I wouldn't presume to answer for Ronald, but my understanding is that
consideration of Win32/Win64 and other compatibility issues dictated int and
long remain 32 bits for the C++ compiler. It would be bad for Managed C++ to
define a larger size, because then you would throw IJW out the window. C#,
being a brand new language, had none of these concerns, but note that its
int type remains 32 bits, which is enough for most purposes. As in C++, your
primary integer data type in C# is int.

As for the future of C++ on .NET, not only is C++ not being back-burnered,
it's going to be much, much better in the next release. See this MSDN
article for more:

Write Faster Code with the Modern Language Features of Visual C++ 2005
http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/default.aspx

In some ways, such as the new support for deterministic finalization, it
will become superior to C#, and even viewed solely as a pure .NET language,
VC++ 2005 is looking very attractive.

--
Doug Harrison
Microsoft MVP - Visual C++

Ronald
Wed May 12 16:02:46 CDT 2004

And you can also use the somewhat more portable "long long".

Ronald

"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:e8%237as8NEHA.3012@tk2msftngp13.phx.gbl...
> Songie,
>> Is a long in managed c++ a 64-bit number like in C#?
>> If so how can I distinguish between that and one that's in some unmanaged
> code, and therefore that is 32-bit?
>> Call it an int?
>
> What Ronald said. Notice you can use __int64 (both in managed and
> unmanaged
> code) to handle 64-bit numbers (or System::Int64 for just managed code)
>
> --
> Tomas Restrepo
> tomasr@mvps.org
>
>

Tomas
Wed May 12 18:49:47 CDT 2004

Hi Ronald,

> And you can also use the somewhat more portable "long long".

Ahh true! I had forgotten it is now supported! :)

thanks!
--
Tomas Restrepo
tomasr@mvps.org

Simon
Thu May 13 19:04:02 CDT 2004


"songie D" <anonymous@discussions.microsoft.com> wrote in message
news:E2646F30-A571-45D7-B358-6352DC75C310@microsoft.com...
> I wouldn't presume to answer for Ronald, but my understanding is that
> consideration of Win32/Win64 and other compatibility issues dictated
int and
> long remain 32 bits for the C++ compiler. It would be bad for Managed
C++ to
> define a larger size, because then you would throw IJW out the
window.
>
> I can't personally understand why you'd need it, so that doesn't mean
anything to me.

Changing long to be 64 bits on 32-bit MSVC++ right now would break too much
existing code. For example, a long and a void* are often assumed to have the
same number of bits. While on a 64-bit platform it is likely that this will
again be true, on a 32-bit platform to make long longer than a void* would
be bad news.

> In some ways, such as the new support for deterministic finalization,
it
> will become superior to C#, and even viewed solely as a pure .NET
language,
> VC++ 2005 is looking very attractive.
>
> what's that when it's at home.

I assume "deterministic finalization" is a synonym for "deterministic
destruction" since in the .NET world, IIRC, Finalize() is analagous to a
destructor. (It's been a couple of years since I did .NET).

It is at home in situations where you want to be sure your object has really
gone away, and is not sitting on some garbage heap, consuming resources. It
is particularly important when using the Resource Acquisition Is
Initialisation (RAII) pattern. If the constructor locks [a file, some memory
etc] and the destructor unlocks, you really want to be sure your destructor
is called as early as possible.

songie
Tue May 18 16:11:38 CDT 2004

> Changing long to be 64 bits on 32-bit MSVC++ right now would break too
much
> existing code. For example, a long and a void* are often assumed to have
the
> same number of bits. While on a 64-bit platform it is likely that this
will
> again be true, on a 32-bit platform to make long longer than a void* would
> be bad news.

So ????!!!!???

Is this actually relevant in ANY sense to the previous post, which was about
what is the actual point of compiling raw unadulterated C++ code as MSIL
and what's such a great benefit in being able to do so?

And whoever said that 'int' is the primary data type in C++ is barking up
the wrong tree, because it's a long. You know for a fact a long is going to
be 32 bit, an int will be 16-bit if compiled on a 16-bit machine/compiler.

>
> It is at home in situations where you want to be sure your object has
really
> gone away, and is not sitting on some garbage heap, consuming resources.
It
> is particularly important when using the Resource Acquisition Is
> Initialisation (RAII) pattern. If the constructor locks [a file, some
memory
> etc] and the destructor unlocks, you really want to be sure your
destructor
> is called as early as possible.

In C# you tend to call a "Close()" method in addition to letting the garbage
collector
do whatever it has to.

>
>