It's anyways bad practice to initialie a char array with a string literal.
The author of that comment never really justifies it, and I find the statement puzzling.
In C (and you've tagged this as C), that's pretty much the only way to initialize an array of char
with a string value (initialization is different from assignment). You can write either
char string[] = "october";
or
char string[8] = "october";
or
char string[MAX_MONTH_LENGTH] = "october";
In the first case, the size of the array is taken from the size of the initializer. String literals are stored as arrays of char
with a terminating 0 byte, so the size of the array is 8 ('o', 'c', 't', 'o', 'b', 'e', 'r', 0). In the second two cases, the size of the array is specified as part of the declaration (8 and MAX_MONTH_LENGTH
, whatever that happens to be).
What you cannot do is write something like
char string[];
string = "october";
or
char string[8];
string = "october";
etc. In the first case, the declaration of string
is incomplete because no array size has been specified and there's no initializer to take the size from. In both cases, the =
won't work because a) an array expression such as string
may not be the target of an assignment and b) the =
operator isn't defined to copy the contents of one array to another anyway.
By that same token, you can't write
char string[] = foo;
where foo
is another array of char
. This form of initialization will only work with string literals.
EDIT
I should amend this to say that you can also initialize arrays to hold a string with an array-style initializer, like
char string[] = {'o', 'c', 't', 'o', 'b', 'e', 'r', 0};
or
char string[] = {111, 99, 116, 111, 98, 101, 114, 0}; // assumes ASCII
but it's easier on the eyes to use string literals.
EDIT2
In order to assign the contents of an array outside of a declaration, you would need to use either strcpy/strncpy
(for 0-terminated strings) or memcpy
(for any other type of array):
if (sizeof string > strlen("october"))
strcpy(string, "october");
or
strncpy(string, "october", sizeof string); // only copies as many characters as will
// fit in the target buffer; 0 terminator
// may not be copied, but the buffer is
// uselessly completely zeroed if the
// string is shorter!
Most event loops will suspend if there are no events ready, which means the operating system will not give the task any execution time until an event happens.
Say the event is a key being pressed. You might ask if there's a loop somewhere in the operating system checking for keypresses. The answer is no. Keys being pressed generate an interrupt, which is handled asynchronously by the hardware. Likewise for timers, mouse movements, a packet arriving, etc.
In fact, for most operating systems, polling for events is the abstraction. The hardware and OS handle events asynchronously and put them in a queue that can be polled by applications. You only really see true polling at the hardware level in embedded systems, and even there not always.
Best Answer
It's not a bad practice... it all depends on what the function is doing, and whether the code in the function needs to be within a loop, or whether it can be refactored outside of a loop.
A function is just a set of instructions, so you could, theoretically, take any function's instructions and put them directly inside the loop, and you have essentially the same thing. If that set of instructions is to add two plus two, you don't have much to worry about. If that set of instructions is to open a database table of 10 million rows, find a row, write the values to disk, close the connection and repeat, then you've got something to think about.
Often times, regardless of how long it actually takes, it might just plain be required even if it's not performant. Other times, you could really put some dumb stuff in a loop.
Let's take the "open a database table of 10 million rows and write each row's values to a file" example.
Bad loop:
In the above, a table instance (and all of the associated overhead) is done necessarily for each iteration.
Better loop:
or, perhaps even better (as it could be internally optimized by the language compiler):
So, you can see a few ways that we could manage code within a loop versus setting it up outside of the loop.
That's really the only thing worth considering, at least on a day to day basis.