How to convert memory address (like 0xc20803a000) to string? Golang - memory

I think question is quite self-explained. I want to know how can I convert memory address like this 0xc20803a000 to string type. Is it possible?

You can use fmt.Sprintf(), with %p (base 16 notation, with leading 0x)
myString := fmt.Sprintf("%p", yourPointer)
fmt.Sprintf() returns a string.
You can see several examples (of printing a memory pointer) in:
"How do I print the pointer value of a Go object? What does the pointer value mean?".
"Go by Example: String Formatting".
Replace in those examples Printf by Sprintf, and you have a string for you to use.

Related

Why do I get EXC_BAD_ACCESS when using %1$s for String(format:)

I have a localized string that looks like this:
String(format: "unable_to_reach".localized(), name) //name is a string. I have also tried just "x"
The key/value pair in the localize file looks like this:
"unable_to_reach" = "Unable to reach %1$s";
Now, sometimes this works, othertimes it crashes with the EXC_BAD_ACCESS error. Why is this? isn't %1$s supposed to be used for string values?
The format specifier %1$s is %s with a positional specifier of $1 inserted into it. %s is the format specifier for a null-terminated C string. If you instead pass it a Swift String, bad things will happen. Don't do that. (It will likely cause a buffer overflow if the Swift string does not contain any null bytes.)
You want %# (or %$1#, to preserve the positional specifier.)
See the document on string format specifiers for more information.
Edit:
BTW, you should think about using Swift string interpolation instead:
let unableToReach = "unable_to_reach".localized()
let final = "\(unableToReach) \(name)"
That is more "Swifty".
Note that if you want to use localized placeholders to allow for different word ordering in different languages, you really still need to use String(format:) and the %# (or %1# positional syntax) version.

Converting type string to long

I am trying to convert the type of string to long in the following code:
PaymentReceived = String.Format(new CultureInfo("en-IN", true), "{0:n}", t.PaymentReceived),
Here t.PaymentReceived is of type long, and the PaymentReceived is of type string but I want it to be of type long.
I am using this to convert the PaymentReceived value into comma separated value.
I am trying to do as of my knowledge like
PaymentReceived = Convert.ToInt64( String.Format(new CultureInfo("en-IN", true), "{0:n}", t.PaymentReceived))
But the error is Additional information: Input string was not in a correct format.
So please help me with another solution, thank you.
The formatter n, adds additional non-numeric characters. For en-IN culture, that means a number like 1000 ends up as 1,000.00.
The Convert.ToInt64 method requires that the string be 100% numeric, including no period, which might be fine for Convert.ToDecimal, but a long is not a float. Therefore, emphatically, your string is not formatted correctly, and the error is both obvious and correct. I'm not sure what your ultimate goal here is, but it makes no sense to convert a long to a formatted string and then immediately convert it back to a long, anyways.
Assuming you have only the string and you need to format it as a long, then you need to ensure that it's formatted as a long should be. That requires:
Split on the decimal point and take just the left side:
str = str.Split(new[] { '.' })[0];
Replace any commas with empty strings:
str = str.Replace(",", "");
That assumes you know the format will something like 1,000.00. Otherwise, you may want to use a regex to replace all non-numeric characters with an empty string, instead. However, you still need to split on the decimal. Otherwise, if you just removed all non-numeric characters from something like 1,000.00, then you'd end up with 100000, a number 100 times larger than the actual string number. Also, this is all dependent on the culture. Some cultures use , as the decimal separator and . and delimiter in large numbers. If you need to handle various cultures, you'll need to adjust accordingly.

NSSet full of NSStrings. When I print the set to the console, the results are unexpected

Here's what happens:
Internal database stuff: one class has a string property on it, that stores a phone number. This number is set using the code
CFBridgingRelease(ABMultiValueCopyValueAtIndex(ABRecordCopyValue(record, kABPersonPhoneProperty), 0));
My function: finds all objects of this type, and stores phone numbers of each object in an NSMutableSet.
Debug: I print the description of the set to the console.
Results:
Some of the set's objects look as expected (the majority actually): "+64 27 0124 975"
Some are missing quotation marks: 027 7824 565
Some have weird unicode symbols: "021\U00a0026\U00a017788"
My question:
Why the difference - what does it mean, and do I need to fix anything?
NSLog with %# – as I assume you are using – has some intelligence in how it presents NSStrings as it calls the description method. If the string has anything other than alphanumerics, such as the '+' or '\' above, it will use quotes. The string with unicode characters simply has its characters encoded as shown, and they are automatically converted into this lossless format. You should be able to convert it to something prettier for the console if you really need to with something like this:
NSLog(#"%#", [NSString stringWithCString:[myString.description cStringUsingEncoding:NSASCIIStringEncoding] encoding:NSNonLossyASCIIStringEncoding]);

which one of these is an example of coercion

I have been pondering a multiple choice question on coercion. One of the 4 examples a,b,c or d is an example of coercion. I narrowed it down to A or B. But I am having a problem choosing between the two. Cane someone please explain why one is coercion and one isn't.
A)
string s="tomat";
char c='o';
s=s+c;
I thought A could be correct because we have two different types, character and string, being added. Meaning that c is promoted to string, hence coercion.
B)
double x=1.0;
double y=2.0;
int i=(int)(x+y);
I also thought B was the correct answer because the double (x+y) is being turned into a int to be placed in i. But I thought this could be wrong because its being done actively through use of (int) rather than passively such as "int i = x + y"
I'll list the other two options, even though I believe that neither one is the correct answer
C)
char A=0x20;
A = A << 1 | 0x01;
cout << A << endl;
D)
double x=1.0;
double y=x+1;
return 0;
I'm not just looking for an answer, but an explanation. I have read tons of things on coercion and A and B both look like the right answer. So why is one correct and the other not.
I actually think it's B. Even though there's the explicit (int), it's still type coercion (just not automatic type coercion). You're converting a floating point value (probably stored as an IEEE floating point value) to an integer value (probably stored in two's complement).
Whereas A is simply concatenating a character to a string, where a string is just a null terminated array of characters. There's no data type conversion going on there, just a bit of memory manipulation.
I could be wrong though.
EDIT: I would have to agree with Parris. Given that this is a C++ string and not a C array of characters (my mistake), the chracter in A is probably being coerced to a string.
I don't think type casting is equivalent to type coercion, which is why A would probably be the right answer.
B takes a double and casts it to an int, which is more like a conversion than a coercion. In A you aren't converting anything you're being implicit. You are telling the runtime/compiler/whatever "these 2 things are similar can you figure out how to concatenate them?"
C isn't a conversion or coercion its just bit shifting. Although the cout might be coercion... I am not sure if there is coercion to a string there to write to the console.
D might contain a coercion since 1 is an int and you are adding it to a double. However, you can do floating point math with integers having a decimal is just more explicit.
I think A is the most straight forward example of coercion. Although C's cout statement seems suspicious as well.

Entering Text From Delphi To Word

I'm using Delphi XE2 and use the following code to enter the letter Y into a bookmark in a Word (2010) template.
Doc.Bookmarks.Item('NS').Range.InsertAfter('Y');
Except in the document, instead of the letter Y, the number 89 appears.
Is the fault likely to be from my code or in the Word document? Any direction gratefully received.
Your literal 'Y' is a character literal rather than a string string literal. The ASCII code for Y is 89.
So, you are passing a Char rather than a string. When Word needs to get a string representation of that integer it simply converts the integer 89 to its textual representation, the string '89'.
To get around the problem you can do this:
var
Text: string;
....
Text := 'Y';
Doc.Bookmarks.Item('NS').Range.InsertAfter(Text);
The idea is that we ensure that we pass a string to InsertAfter() rather than a character. Remember that InsertAfter() receives a variant parameter and so you do need to be careful about the type of the payload stored in the variant.

Resources