Which is more efficient for the compiler and the best practice for checking whether a string is blank?
Checking whether the length of the string == 0
Checking whether the string is empty (strVar == "")
Also, does the answer depend on language?
Yes, it depends on language, since string storage differs between languages.
Pascal-type strings: Length = 0.
C-style strings: [0] == 0.
.NET: .IsNullOrEmpty.
Etc.
In languages that use C-style (null-terminated) strings, comparing to "" will be faster. That's an O(1) operation, while taking the length of a C-style string is O(n).
In languages that store length as part of the string object (C#, Java, ...) checking the length is also O(1). In this case, directly checking the length is faster, because it avoids the overhead of constructing the new empty string.
In languages that use C-style (null-terminated) strings, comparing to "" will be faster
Actually, it may be better to check if the first char in the string is '\0':
char *mystring;
/* do something with the string */
if ((mystring != NULL) && (mystring[0] == '\0')) {
/* the string is empty */
}
In Perl there's a third option, that the string is undefined. This is a bit different from a NULL pointer in C, if only because you don't get a segmentation fault for accessing an undefined string.
In .Net:
string.IsNullOrEmpty( nystr );
strings can be null, so .Length sometimes throws a NullReferenceException
For C strings,
if (s[0] == 0)
will be faster than either
if (strlen(s) == 0)
or
if (strcmp(s, "") == 0)
because you will avoid the overhead of a function call.
String.IsNullOrEmpty() only works on .net 2.0 and above, for .net 1/1.1, I tend to use:
if (inputString == null || inputString == String.Empty)
{
// String is null or empty, do something clever here. Or just expload.
}
I use String.Empty as opposed to "" because "" will create an object, whereas String.Empty wont - I know its something small and trivial, but id still rather not create objects when I dont need them! (Source)
Assuming your question is .NET:
If you want to validate your string against nullity as well use IsNullOrEmpty, if you know already that your string is not null, for example when checking TextBox.Text etc., do not use IsNullOrEmpty, and then comes in your question.
So for my opinion String.Length is less perfomance than string comparison.
I event tested it (I also tested with C#, same result):
Module Module1
Sub Main()
Dim myString = ""
Dim a, b, c, d As Long
Console.WriteLine("Way 1...")
a = Now.Ticks
For index = 0 To 10000000
Dim isEmpty = myString = ""
Next
b = Now.Ticks
Console.WriteLine("Way 2...")
c = Now.Ticks
For index = 0 To 10000000
Dim isEmpty = myString.Length = 0
Next
d = Now.Ticks
Dim way1 = b - a, way2 = d - c
Console.WriteLine("way 1 took {0} ticks", way1)
Console.WriteLine("way 2 took {0} ticks", way2)
Console.WriteLine("way 1 took {0} ticks more than way 2", way1 - way2)
Console.Read()
End Sub
End Module
Result:
Way 1...
Way 2...
way 1 took 624001 ticks
way 2 took 468001 ticks
way 1 took 156000 ticks more than way 2
Which means comparison takes way more than string length check.
After I read this thread, I conducted a little experiment, which yielded two distinct, and interesting, findings.
Consider the following.
strInstallString "1" string
The above is copied from the locals window of the Visual Studio debugger. The same value is used in all three of the following examples.
if ( strInstallString == "" ) === if ( strInstallString == string.Empty )
Following is the code displayed in the disassembly window of the Visual Studio 2013 debugger for these two fundamentally identical cases.
if ( strInstallString == "" )
003126FB mov edx,dword ptr ds:[31B2184h]
00312701 mov ecx,dword ptr [ebp-50h]
00312704 call 59DEC0B0 ; On return, EAX = 0x00000000.
00312709 mov dword ptr [ebp-9Ch],eax
0031270F cmp dword ptr [ebp-9Ch],0
00312716 sete al
00312719 movzx eax,al
0031271C mov dword ptr [ebp-64h],eax
0031271F cmp dword ptr [ebp-64h],0
00312723 jne 00312750
if ( strInstallString == string.Empty )
00452443 mov edx,dword ptr ds:[3282184h]
00452449 mov ecx,dword ptr [ebp-50h]
0045244C call 59DEC0B0 ; On return, EAX = 0x00000000.
00452451 mov dword ptr [ebp-9Ch],eax
00452457 cmp dword ptr [ebp-9Ch],0
0045245E sete al
00452461 movzx eax,al
00452464 mov dword ptr [ebp-64h],eax
00452467 cmp dword ptr [ebp-64h],0
0045246B jne 00452498
if ( strInstallString == string.Empty ) Isn't Significantly Different
if ( strInstallString.Length == 0 )
003E284B mov ecx,dword ptr [ebp-50h]
003E284E cmp dword ptr [ecx],ecx
003E2850 call 5ACBC87E ; On return, EAX = 0x00000001.
003E2855 mov dword ptr [ebp-9Ch],eax
003E285B cmp dword ptr [ebp-9Ch],0
003E2862 setne al
003E2865 movzx eax,al
003E2868 mov dword ptr [ebp-64h],eax
003E286B cmp dword ptr [ebp-64h],0
003E286F jne 003E289C
From the above machine code listings, generated by the NGEN module of the .NET Framework, version 4.5, I draw the following conclusions.
Testing for equality against the empty string literal and the static string.Empty property on the System.string class are, for all practical purposes, identical. The only difference between the two code snippets is the source of the first move instruction, and both are offsets relative to ds, implying that both refer to baked-in constants.
Testing for equality against the empty string, as either a literal or the string.Empty property, sets up a two-argument function call, which indicates inequality by returning zero. I base this conclusion on other tests that I performed a couple of months ago, in which I followed some of my own code across the managed/unmanaged divide and back. In all cases, any call that required two or more arguments put the first argument in register ECX, and and the second in register EDX. I don't recall how subsequent arguments were passed. Nevertheless, the call setup looked more like __fastcall than __stdcall. Likewise, the expected return values always showed up in register EAX, which is almost universal.
Testing the length of the string sets up a one-argument function call, which returns 1 (in register EAX), which happens to be the length of the string being tested.
Given that the immediately visible machine code is almost identical, the only reason that I can imagine that would account for the better performance of the string equality over the sting length reported by Shinny is that the two-argument function that performs the comparison is significantly better optimized than the one-argument function that reads the length off the string instance.
Conclusion
As a matter of principle, I avoid comparing against the empty string as a literal, because the empty string literal can appear ambiguous in source code. To that end, my .NET helper classes have long defined the empty string as a constant. Though I use string.Empty for direct, inline comparisons, the constant earns its keep for defining other constants whose value is the empty string, because a constant cannot be assigned string.Empty as its value.
This exercise settles, once and for all, any concern I might have about the cost, if any, of comparing against either string.Empty or the constant defined by my helper classes.
However, it also raises a puzzling question to replace it; why is comparing against string.Empty more efficient than testing the length of the string? Or is the test used by Shinny invalidated because by the way the loop is implemented? (I find that hard to believe, but, then again, I've been fooled before, as I'm sure you have, too!)
I have long assumed that system.string objects were counted strings, fundamentally similar to the long established Basic String (BSTR) that we have long known from COM.
In Java 1.6, the String class has a new method [isEmpty] 1
There is also the Jakarta commons library, which has the [isBlank] 2 method. Blank is defined as a string that contains only whitespace.
Actually, IMO the best way to determine is the IsNullOrEmpty() method of the string class.
http://msdn.microsoft.com/en-us/library/system.string.isnullorempty.
Update: I assumed .Net, in other languages, this might be different.
In this case, directly checking the length is faster, because it avoids the overhead of constructing the new empty string.
#DerekPark: That's not always true. "" is a string literal so, in Java, it will almost certainly already be interned.
#Nathan
Actually, it may be better to check if the first char in the string is '\0':
I almost mentioned that, but ended up leaving it out, since calling strcmp() with the empty string and directly checking the first character in the string are both O(1). You basically just pay for an extra function call, which is pretty cheap. If you really need the absolute best speed, though, definitely go with a direct first-char-to-0 comparison.
Honestly, I always use strlen() == 0, because I have never written a program where this was actually a measurable performance issue, and I think that's the most readable way to express the check.
Again, without knowing the language, it's impossible to tell.
However, I recommend that you choose the technique that makes the most sense to the maintenance programmer that follows and will have to maintain your work.
I'd recommend writing a function that explicitly does what you want, such as
#define IS_EMPTY(s) ((s)[0]==0)
or comparable. Now there's no doubt at is you're checking.
If strings in a language have an internal length property, checking the length is faster because it is an integer comparison of the property value with zero. However, when strings have no such property, the length must be determined the moment you want to test for it, and this is very fast for a string that actually has length zero, but can take a very long time if the string is huge, which you cannot know in advance, because if you knew it had size zero, why do you need to check that at all?
If a strings don't store their lengths internally, comparing against an empty string is usually faster, as even if that means that the two strings will be compared character by character, this loop terminates after the very first iteration for sure, so the time is linear (O(1)) and does not depend on string length. However, even if strings do have an internal length property, comparing them to an empty string may be as fast as checking that property as in that case most implementations will do just that: They first compare lengths and if not the same, they skip comparing characters entirely as if not even the lengths match, the strings cannot be equal to begin with. Yet if the lengths do match, they usually check for the special case 0 and again skip the character comparison loop.
And if a language does offer an explicit way to check if a string is empty, always use that, since no matter which way is faster, that is the way this check is using internally. E.g. to check for an empty string in a shell script, you could use
[ "$var" = "" ]
which would be string comparison. Or you could use
[ ${#var} -eq 0 ]
which uses string length comparison. Yet the most efficient way is in fact
[ -z "$var" ]
as the -z operation only exists for exactly this purpose.
C is special in that regard, as the string internals are exposed (strings are not encapsulated objects in C) and while C strings don't have a length property and their length must be determined each time needed, it is very easy to check if a C string is empty by just checking if it's first character is NUL, as NUL is always the last character in a C string, so nothing can beat:
char * string = ...;
if (!*string) { /* empty */ }
(note that in C *string is the same as string[0], !x is the same as x == 0, and 0 is the same '\0', so you could have written string[0] == '\0' but for the compiler that's exactly the same as what I've written above)
Related
in nim if you set a charachter in the middle of a string to '\0' the len function doesn't update. Is this something we should just not do ever ? Is slicing the recommended way ?
Generally you should not think of Nim strings as null terminated. Even though they are, but that's just an implementation detail to allow seamless C interop.
Also Nim strings are encoding agnostic meaning that a '\0' can be a valid byte within a string. The convention is utf8 though.
To change the length of the string use setLen proc.
var s = "123456"
s.setLen(3)
assert(s == "123")
I am trying to create a program at LC3 assembly that counts the length of a string in the following way:
All data is already stored somewhere in memory.
There is a variable in which the address of the first element of the string is stored. (I apologize in advance for my lack of assembly knowledge in case this thing is not called "variable".)
The output (length of the string) must be stored at R0.
I made an attempt, but the results are disappointing. Here is my code:
.ORIG X3000
AND R0,R0,#0 ;R0 has the output(lenght)
LEA R1,ZERO ;R1 always has an adress of an element of the string
LOOP LDR R2,R1,#0 ;R2 has the contex of that adress
BRZ FINISH ;if R2=0,then we have found end of string
ADD R0,R0,#1 ;if not,increase the lenght by 1.
ADD R1,R1,#1 ;increase the adress by one
BRznp LOOP
FINISH
HALT
ZERO .FILL x5000 ;i chose a random rocation.I don't even know how to store a string in memory to run this program.
.END ;do i need any ASCII-decimal transformation or something similar?
Actually, I guess that my program is a piece of garbage.This is the new version of my program.I suppose that X0000 is end of string.I am a total beginner at LC3 assembly. How can I count that length?
To define a string you can use the .STRINGZ directive, which also places the terminating zero after it. You should use BRNZP because the assembler apparently doesn't like BRZNP. Other than that, your code works fine.
The following questions are based on the use of XOR :
Given a string say of integers. The task at hand is to remove the
given character from string. I tried using XOR to solve it. eg
char str[] = "123456" . Remove 4. XOR the given character with
the entire string. That character vanishes.
XOR = (1^2^3^4^5^6) ^ 4
However I am left with the XOR of the remaining characters.
XOR = (1^2^3^5^6)
Is there any method I could get the individual characters back?
I need to find and remove elements that have duplicates (including the elements themselves)
eg. A = {1,9,8,2,2} then output should be {1,9,8} after removal
However this will fail since 1^9 = 8. Hence (1^9)^8^2^2 gives empty array. Is there any alternative using XOR itself?
int num=4;
for(i=0;i<strlen(str);i++)
{
if(((str[i]-'0')^num) == 0)
remove_number(i);
}
I am trying to store a string in memory, access that string and change the lower case letters to upper case and visa versa. What I do not understand is how to reference the address of the string and ascii value at that address. I believe I can figure the logic out, just having problems with data and address manipulation. How do I differentiate the two? NOTE: This is a homework coding assignment.
Hint. Flip the "32" bit with a xor value,0x20 to toggle case.
On the Z80 assembler it would be something like
SRC: DB 'Press A Key To Continue', 0; Our source string
DST: DB 'Press A Key To Continue', 0; Where we will put our string. make sure its big enough so we don't over write our program.
;load MSG+0 to working regist
;flip the 32 bit
;move the working register to DST + 0
;load MSG+1 and repeat
Accessing the string is different depending on if it's in the flash or RAM (I think that strings may be copied into RAM on boot, but I'm not positive). Given that this is a homework problem, though, you probably have direct access to the string in RAM. As #EnabrenTane points out you can just flip bit 5 of the char byte to change the case (read the excellent Wikipedia ASCII page to learn more about ASCII byte codes). So, if you needed to do this in C:
char the_string[6] = "foobar" // assuming string is created like this
int l = 6 * sizeof(char); // the length of the string
for(int i=0; i<l; i++) {
char* c = the_string + i; // grab char[i] of the string
*char = *char ^ 0x20; // flip the case
}
(I haven't tried compiling this so there may be errors)
For strings created like the one above the value stored in the_string is actually a pointer to the address of the first character. To find a specific character within that string you just add to the address. To manipulate the string you need to dereference your char* pointer and - in this example - store the value back into the same spot, overwriting the original value.
Ok, i've always kind of known that computers treat strings as a series of numbers under the covers, but i never really looked at the details of how it works. What sort of magic is going on in the average compiler/processor when we do, for instance, the following?
string myString = "foo";
myString += "bar";
print(myString) //replace with printing function of your choice
The answer is completely dependent on the language in question. But C is usually a good language to kind of see how things happen behind the scenes.
In C:
In C strings are array of char with a 0 at the end:
char str[1024];
strcpy(str, "hello ");
strcpy(str, "world!");
Behind the scenes str[0] == 'h' (which has an int value), str[1] == 'e', ...
str[11] == '!', str[12] == '\0';
A char is simply a number which can contain one of 256 values. Each character has a numeric value.
In C++:
strings are supported in the same way as C but you also have a string type which is part of STL.
string literals are part of static storage and cannot be changed directly unless you want undefined behavior.
It's implementation dependent how the string type actually works behind the scenes, but the string objects themselves are mutable.
In C#:
strings are immutable. Which means you can't directly change a string once it's created. When you do += what happen is a new string gets created and your string now references that new string.
The implementation varies between language and compiler of course, but typically for C it's something like the following. Note that strings are essentially syntactical sugar for char arrays (char[]) in C.
1.
string myString = "foo";
Allocate 3 bytes of memory for the array and set the value of the 1st byte to 'f' (its ASCII code rather), the 2nd byte to 'o', the 2rd byte to 'o'.
2.
foo += "bar";
Read existing string (char array) from memory pointed to by foo.
Allocate 6 bytes of memory, fill the first 3 bytes with the read contents of foo, and the next 3 bytes with b, a, and r.
3.
print(foo)
Read the string foo now points to from memory, and print it to the screen.
This is a pretty rough overview, but hopefully should give you the general idea.
Side note: In some languages/compuilers, char != byte - for example, C#, where strings are stored in Unicode format by default, and notably the length of the string is also stored in memory. C++ typically uses null-terminated strings, which solves the problem in another way, though it means determining its length is O(n) rather than O(1).
Its very language dependent. However, in most cases strings are immutable, so doing that is going to allocate a new string and release the old one's memory.
I'm assuming a typo in your sample and that there is only one variable called either foo or myString, not two variables?
I'd say that it'll depend a lot on what compiler you're using. In .Net strings are immutable so when you add "bar" you're not actually adding it but rather creating a new string containing "foobar" and telling it to put that in your variable.
In other languages it will work differently.