I am to convert a C# program into Java. At one point I really don't get what is done, there. I changed the code to clarify the types and give an example.
string myString = "Test";
long l = (long)myString[0];
1) What is the [0] doing with a normal string? Is that even possible? Is it just the substring, in this case "T"?
2) How could you cast a String or character to long, if the String represents a text?
long l = (long)myString[0];
the index of a string gives the char. A char is castable as a long. This will give you the long-value (unicode value) of the character in the first position of the string, i.e., A will be 65.
The cast (long) is not needed in C#, because char has what's called a "implicit cast operator" for long and int. The following statement is just as well correct:
long l = myString[0];
The equivalent of char in C# is char in Java, albeit that implementations are slightly different. In Java, a char can be cast to an int or a long. To get the character, use CharAt().
I think it's converting a char code to long. In Java you would have to:
long l = (long) myString.charAt(0)
A string is an array of characters, so that makes it possible to access given position.
Having said that, myString[0] is accessing the first char, 'T'.
You can then cast a char to a long, converting it to its ASCII position value.
You can use this converter http://www.tangiblesoftwaresolutions.com/index.htm - the trial version is able to convert some amount of lines for free :)
Related
In C#; I understand that numbers are different to signs... As I understand it, a byte conversion to an int is possible because the int type can read all of the byte binary compilation. However, why can't type char be as easily converted to string in the same way? Example:
char c = 'a';
string asdf = c; <== why do I have to use a ToString-method here?
Well, because of the same reason int cannot be converted to int[], these are different types, and C# is a strongly typed programming language.
In fact, char is a numeric type and rules of numeric types conversion also apply to char, so it can be converted to int or long, but cannot be implicitly converted to string or char[], for example.
I have a VBScript which I'm converting to Delphi.
I'm struggling with these 2 lines.
Can someone explain what do they do:
init_lib.Flags(&H7FFF)
init_lib.Environment(1)
Couldn't find any documentation related to the 1st line.
I kept the 2nd line as it is in Delphi but not sure how to convert the 1st line.
What's their equivalent in Delphi (or C#) ?
&H is a VB shorthand for hexadecimal value.
In order to use the value in Delphi you have to use the string without the prefix or to convert the string '7FFF' to a decimal value: you know what type of argument Flags accepts.
The '7FFF' hex string corresponds to the decimal 32767.
The shorthand for hexadecimal values in Delphi is $: $7FFF evaluates to an Integer type that can be assigned to a variable or a constant directly.
Maybe someone in either of the camps can tell me whats going on here:
Python:
temp = int('%d%d' % (temp2, temp3)) / 10.0;
I'm working on parsing temperature data, and found a piece of python that I can't understand. What is going on here? Is python adding together two numbers here and casting them to int, and then divide by 10?
C# might look like:
temp = ((int)(temp2+temp3))/10;
But I am not sure what that % does? Data is jibberish so I don't know what is correct translation for that line in python to C#
In C# it looks like:
var temp = int.Parse(temp2.ToString() + temp3.ToString())/10f;
or:
var temp = Convert.ToInt32(string.Format("{0}{1}", temp2, temp3))/10f;
this is similar: What's the difference between %s and %d in Python string formatting?
name = 'marcog'
number = 42
print '%s %d' % (name, number)
will print marcog 42. Note that name is a string (%s) and number is an integer (%d for decimal).
See
http://docs.python.org/library/stdtypes.html#string-formatting-operations
for details.
So it seems like the "%" is just telling python to put the values on the right into the placeholders on the left.
from the documentation linked in the answer I quoted:
Given format % values (where format is a string or Unicode object), % conversion specifications in format are replaced with zero or more elements of values. The effect is similar to the using sprintf() in the C language. If format is a Unicode object, or if any of the objects being converted using the %s conversion are Unicode objects, the result will also be a Unicode object.
Would probably want to set up a python script and try it out, placing your own values into the variables.
When I try to concatenate two characters using the + operator, the compiler displays the following error message: "Can not implicitly convert type int to string."
My code is:
const string Expr = ('$' + (char)(39));
Why do I get this error? And how do I fix it?
Using the + operator on two chars doesn't concat them. Instead it converts them to int, and adds these ints, resulting in an int.
A simple solution for your problem is using "$", which is a string, instead of '$', which is a char, but that's no constant expression, so in your case it'll fail with a new compiler error.
Or you could skip the integer step completely and just use const string Expr = "$'". Or if you really want to use an integral codepoint, you can convert it to hex and use "$\u0027".
In some similar situations a common workaround is concatenating with the empty string "" first ("" + a + b). Or you could manually call ToString() on one (or both) of the operands. But in your case turning the $-prefix into string is cleaner.
Just use String.Concat:
string.Concat('$', (char)39)
The + operator on strings is internally translated to that method anyway.
Also, you can't use the const keyword with an expression like that. consider using readonly instead.
I'm working with strings, which could contain surrogate unicode characters (non-BMP, 4 bytes per character).
When I use "\Uxxxxxxxxv" format to specify surrogate character in F# - for some characters it gives different result than in the case of C#. For example:
C#:
string s = "\U0001D11E";
bool c = Char.IsSurrogate(s, 0);
Console.WriteLine(String.Format("Length: {0}, is surrogate: {1}", s.Length, c));
Gives: Length: 2, is surrogate: True
F#:
let s = "\U0001D11E"
let c = Char.IsSurrogate(s, 0)
printf "Length: %d, is surrogate: %b" s.Length c
Gives: Length: 2, is surrogate: false
Note: Some surrogate characters works in F# ("\U0010011", "\U00100011"), but some of them doesn't work.
Q: Is this is bug in F#? How can I handle allowed surrogate unicode characters in strings with F# (Does F# has different format, or only the way is to use Char.ConvertFromUtf32 0x1D11E)
Update:
s.ToCharArray() gives for F# [| 0xD800; 0xDF41 |]; for C# { 0xD834, 0xDD1E }
This is a known bug in the F# compiler that shipped with VS2010 (and SP1); the fix appears in the VS11 bits, so if you have the VS11 Beta and use the F# 3.0 compiler, you'll see this behave as expected.
(If the other answers/comments here don't provide you with a suitable workaround in the meantime, let me know.)
That obviously means that F# makes mistake while parsing some string literals. That is proven by the fact character you've mentioned is non-BMP, and in UTF-16 it should be represented as pair of surrogates.
Surrogates are words in range 0xD800-0xDFFF, while neither of chars in produced string fits in that range.
But processing of surrogates doesn't change, as framework (what is under the hood) is the same. So you already have answer in your question - if you need string literals with non-BMP characters in your code, you should just use Char.ConvertFromUtf32 instead of \UXXXXXXXX notation. And all the rest processing will be just the same as always.
It seem to me that this is something connected with different forms of normalization.
Both in C# and in F# s.IsNormalized() returns true
But in C#
s.ToCharArray() gives us {55348, 56606} //0xD834, 0xDD1E
and in F#
s.ToCharArray() gives us {65533, 57422} //0xFFFD, 0xE04E
And as you probably know System.Char.IsSurrogate is implemented in the following way:
public static bool IsSurrogate(char c)
{
return (c >= HIGH_SURROGATE_START && c <= LOW_SURROGATE_END);
}
where
HIGH_SURROGATE_START = 0x00d800;
LOW_SURROGATE_END = 0x00dfff;
So in C# first char (55348) is less than LOW_SURROGATE_END but in F# first char (65533) is not less than LOW_SURROGATE_END.
I hope this helps.