Double vs double

[Guest]

Is there a difference between:
private Double[,] B = new double[2, 2];
and
private double[,] E = new double[2, 2];

The editor shows the Double in aqua and double in blue leading me to think
so. But the screen tip indicates they are equivalent.

 

[Nicholas Paldino [.NET/C# MVP]]

mr peanut,

No, there isn't. double (lower case) is nothing more than a C# alias
for System.Double, which is the type included in MSCORLIB. They are the
same thing.

 

[Rene]

But are they the same across all platforms?

For example, if I was to declare a variable as an "int" on a 32 bit OS the
size of it will be 32 bits, but if I was to use the "int" keyword on a 64
bit OS, will it reference a 32 bit integer or a 64 bit integer?

Just curious, thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

It will be a 32 bit integer. The type is consistent across platforms.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

But are they the same across all platforms?

For example, if I was to declare a variable as an "int" on a 32 bit OS the
size of it will be 32 bits, but if I was to use the "int" keyword on a 64
bit OS, will it reference a 32 bit integer or a 64 bit integer?

It will still be 32 bit on a 64 bit platform.

The only type that changes size is IntPtr.

Arne

 

[Rene]

Thanks Guys,

OK, I guess the one thing that may not be the same is that different
programming languages may map the same keyword to a different CLR type.

For example, perhaps Cobol.Net (or whatever) could map the keyword "int" to
System.Int64 rather than to System.Int32.

I realize that this observation is beyond the scope of the posters question
but I just wanted to point it out, I remember reading somewhere someone
suggesting to use the CLR type names rather than the aliases for a couple of
reasons and I think one of the was what I mentioned above.

In other words, using the CLR type names is supposed to be better for
clarity (even for people coming form different programming languages)
although I believe Microsoft like us to use the aliases better.

Cheers.

It will be a 32 bit integer. The type is consistent across platforms.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

But are they the same across all platforms?

For example, if I was to declare a variable as an "int" on a 32 bit OS
the size of it will be 32 bits, but if I was to use the "int" keyword on
a 64 bit OS, will it reference a 32 bit integer or a 64 bit integer?

Just curious, thanks.

 

[Ian Semmel]

C# actually defines what an int is (32-bit signed integer).

C++ and C don't, and it is up to the particular compiler implementation
to define them.

-----Original Message-----
From: Rene [mailto:[email protected]]
Posted At: Monday, 10 September 2007 5:06 AM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Double vs double
Subject: Re: Double vs double

Thanks Guys,

OK, I guess the one thing that may not be the same is that different
programming languages may map the same keyword to a different CLR type.

For example, perhaps Cobol.Net (or whatever) could map the keyword
"int" to
System.Int64 rather than to System.Int32.

I realize that this observation is beyond the scope of the posters
question
but I just wanted to point it out, I remember reading somewhere someone
suggesting to use the CLR type names rather than the aliases for a
couple of
reasons and I think one of the was what I mentioned above.

In other words, using the CLR type names is supposed to be better for
clarity (even for people coming form different programming languages)
although I believe Microsoft like us to use the aliases better.

Cheers.


"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in
message news:[email protected]...

It will be a 32 bit integer. The type is consistent across platforms.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

But are they the same across all platforms?

For example, if I was to declare a variable as an "int" on a 32 bit OS
the size of it will be 32 bits, but if I was to use the "int" keyword on
a 64 bit OS, will it reference a 32 bit integer or a 64 bit integer?

Just curious, thanks.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

OK, I guess the one thing that may not be the same is that different
programming languages may map the same keyword to a different CLR type.

For example, perhaps Cobol.Net (or whatever) could map the keyword "int" to
System.Int64 rather than to System.Int32.

I realize that this observation is beyond the scope of the posters question
but I just wanted to point it out, I remember reading somewhere someone
suggesting to use the CLR type names rather than the aliases for a couple of
reasons and I think one of the was what I mentioned above.

In other words, using the CLR type names is supposed to be better for
clarity (even for people coming form different programming languages)
although I believe Microsoft like us to use the aliases better.

Different programming languages has completely different data types.

Cobol has data types like:

01 NUMBER-1 PIC 9(6) PACKED-DECIMAL.
01 NUMBER-2 PIC 9(6) PACKED-DECIMAL.
01 RESULT PIC 9(6) DISPLAY.
01 V PIC 9(4)V99 DISPLAY.
01 VV PIC ZZZ9.99 DISPLAY.
01 POS PIC S9(4) DISPLAY VALUE 12.
01 NEG PIC S9(4) DISPLAY VALUE -12.
01 S PIC X(10).
01 S2 PIC XX.

I think they will have bigger problems than int versus int32.

Arne

 

[Jon Skeet [C# MVP]]

OK, I guess the one thing that may not be the same is that different
programming languages may map the same keyword to a different CLR type.

For example, perhaps Cobol.Net (or whatever) could map the keyword "int" to
System.Int64 rather than to System.Int32.

I realize that this observation is beyond the scope of the posters question
but I just wanted to point it out, I remember reading somewhere someone
suggesting to use the CLR type names rather than the aliases for a couple of
reasons and I think one of the was what I mentioned above.

That's a good reason to use CLR names in method names - ReadInt32,
ReadInt64 etc. It's not a good reason to

In other words, using the CLR type names is supposed to be better for
clarity (even for people coming form different programming languages)
although I believe Microsoft like us to use the aliases better.

People who are reading/writing C# should learn C# - trying to make code
readable for non-C# programmers seems like a non-starter to me,
especially as it's likely to make the code *less* readable for C#
coders (who in most cases are likely to be the bulk of the readership).