The Big Programming Thread - Page 338
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Ilikestarcraft
Korea (South)17731 Posts
| ||
|
Deleted User 101379
4849 Posts
| ||
|
spinesheath
Germany8679 Posts
On August 10 2013 01:08 Ilikestarcraft wrote: Have a quick question In this code while (*s++ = *t++); I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition? As a sidenote: Don't write code like that. It's not readable and prone to mistakes. This works in C/C++ because everything can and will be implicitly casted to bool. 0 => false, everything else => true. I doubt C++ would still support this if it wasn't for compatability (with C) reasons. NULL is defined as #define NULL 0and personally I don't like using NULL anyways, 0 does the job and doesn't have to worry about #define shenanigans. It wouldn't work in languages with stricter typing, where you typically don't have this implicit cast to bool. | ||
|
gedatsu
1286 Posts
On August 10 2013 01:08 Ilikestarcraft wrote: Have a quick question In this code while (*s++ = *t++); I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition? A statement like "a = b" will set the variable a to b, and then return the (new) value of a. The while test interprets 0 as false, and anything else as true. So when you reach the terminating '\0' of t, it will set *s to '\0', and then return '\0'=0 to the while statement which interprets it as false and stops. The code is susceptible to a buffer overflow attack, you shouldn't use it. | ||
|
doubleupgradeobbies!
Australia1187 Posts
On August 10 2013 01:08 Ilikestarcraft wrote: Have a quick question In this code while (*s++ = *t++); I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition? Just aside from what others have said, it's often important to know what the return value of functions/operators are, because c will use them as implicit bool values. As spine said, try not to program like this, it's difficult to read and forces people to memorize alot of return values especially when you start putting functions in there. Some of them are common/intuitive and arn't a big problem, but it's a slippery slope for putting more obscure functions into your while/if statements and it becomes a pain to read for even experienced programmers. That said, it is important to know that return values can be used in that fashion, because people do this all the time, it's even pretty common in textbooks. So that at least you will know to look up return values when you see something like that. Basically don't do it yourself, but be prepared to deal with having to read it :D | ||
|
nunez
Norway4003 Posts
On August 10 2013 01:50 spinesheath wrote: As a sidenote: Don't write code like that. It's not readable and prone to mistakes. This works in C/C++ because everything can and will be implicitly casted to bool. 0 => false, everything else => true. I doubt C++ would still support this if it wasn't for compatability (with C) reasons. NULL is defined as #define NULL 0and personally I don't like using NULL anyways, 0 does the job and doesn't have to worry about #define shenanigans. It wouldn't work in languages with stricter typing, where you typically don't have this implicit cast to bool. we have nullptr now! :> | ||
|
spinesheath
Germany8679 Posts
Yeah, I just didn't actually code any C++ lately so I haven't gotten a chance to use it and forgot to mention it. It's a lot better than the previous solution as it has much better type safety. NULL should be considered obsolete imo (even if the definition is changed to nullptr, though I wonder how many compilers would actually do that since it might break existing hackish code). | ||
|
Kambing
United States1176 Posts
On August 10 2013 03:22 spinesheath wrote: Yeah, I just didn't actually code any C++ lately so I haven't gotten a chance to use it and forgot to mention it. It's a lot better than the previous solution as it has much better type safety. NULL should be considered obsolete imo (even if the definition is changed to nullptr, though I wonder how many compilers would actually do that since it might break existing hackish code). The standard defines conversions from nullptr to NULL (and other pre-C++11 null types), so there's no concern of breaking existing code. | ||
|
Rannasha
Netherlands2398 Posts
On August 09 2013 03:34 Millitron wrote: Thanks. I got it to work, though I couldn't do your idea for the for-loops. That only colored the corners of every, it did not draw the edges. I don't mind the minor efficiency cost. I doubt the images will ever be much bigger than 2000x2000, and they're not used in anything time-critical. Ah yes, you're right. I didn't think it through long enough. What would work is something like: for (int i = 10; i < 2000; i+= 10) | ||
|
bangsholt
Denmark138 Posts
![]() Unless the run time is a problem, you should not optimize. If you do optimize, run a profiler and figure out where you should optimize. You are almost always wrong in your guesses with where to optimize. Clearness of code is as important if not more important than speed, as it's hard to achieve better speed if you do not know what is going on. | ||
|
Shield
Bulgaria4824 Posts
On August 11 2013 03:20 bangsholt wrote: But why would you do that You'll just take the runtime from "not very long" to "a bit less than not very long", and now it is not obvious why you are skipping it ![]() Unless the run time is a problem, you should not optimize. If you do optimize, run a profiler and figure out where you should optimize. You are almost always wrong in your guesses with where to optimize. Clearness of code is as important if not more important than speed, as it's hard to achieve better speed if you do not know what is going on. Any "a bit less than not very long" is better than "not very long". If something isn't clear, you always have /* comments */, right? I don't really agree with your thinking. After all, one of Software Engineering's goals is efficiency, in particular not to waste system resources. | ||
|
Blisse
Canada3710 Posts
In this case, it's decently intuitive, so I don't think bangsholt's point stands (I would say the loops are still a bit unclear in their intent (for example using x and y instead of i and j, etc)), but the idea is okay. In an ideal world, when you optimize, you shouldn't be writing little hacky its to get X marginally faster. Instead, you should be focusing on why your original code wasn't as fast as it could've been before. (Some exceptions may apply). Small hackish behavior should feel very dirty because the premise is that all software problems can be resolved to much smaller, simpler problems, so when you use little "tricks" to gain an edge, it means the solution to your original problem wasn't optimal, and you could've found a more elegant solution that doesn't require this quirky, unclear optimization. | ||
|
waxypants
United States479 Posts
On August 10 2013 01:08 Ilikestarcraft wrote: Have a quick question In this code while (*s++ = *t++); I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition? Question was eventually addressed adequately I think, but there seems to be a lot of misunderstanding about NULL. NULL is meant for pointers. NULL actually has nothing to do with this problem. The conditional takes the value of "*s" after it has been assigned and will evaluate to false if it was 0 and true otherwise. At the end of the string is the null character ('\0', 0x00, etc). This is not the same as NULL, which is the null pointer. So, after "*s" is set to the null character, the while statement evaluates to false and then breaks out. As a side note, in C NULL can be defined as
which makes its intention more clear. Setting a pointer to 0 rather than NULL sucks because then you lose the ability to look at the assignment statement and immediately tell if you are dealing with a pointer or an integer type. | ||
|
CecilSunkure
United States2829 Posts
On August 11 2013 06:03 waxypants wrote:
which makes its intention more clear. Setting a pointer to 0 rather than NULL sucks because then you lose the ability to look at the assignment statement and immediately tell if you are dealing with a pointer or an integer type. It doesn't matter so much, as both (void *)0 and 0 are the same bit configuration underneath. The only difference between the two is compiler semantics. | ||
|
waxypants
United States479 Posts
On August 11 2013 06:06 CecilSunkure wrote: It doesn't matter so much, as both (void *)0 and 0 are the same bit configuration underneath. The only difference between the two is compiler semantics. I'm a bit confused as I don't even see how your point relates to my point, or even how even the rest of your statement implies "It doesn't matter so much". Additionally, they are not even necessarily the same "bit configuration underneath" (edit: As assigned to pointers, they are, but not in general). | ||
|
Shenghi
167 Posts
On August 11 2013 04:38 darkness wrote: Any "a bit less than not very long" is better than "not very long". If something isn't clear, you always have /* comments */, right? I don't really agree with your thinking. After all, one of Software Engineering's goals is efficiency, in particular not to waste system resources. If something isn't clear, you ought to rewrite it so that it is clear rather than using comments to explain the unclear code. Furthermore, "a bit less long" is really only better than "not very long" if we're talking about orders of magnitude. The minor optimization discussed here is turning an algorithm from O(N^2) to O(N^2), losing a bunch of readability in the process. So you're really giving up something important and hardly gain anything in return. | ||
|
Deleted User 101379
4849 Posts
On August 11 2013 06:38 Shenghi wrote: The minor optimization discussed here is turning an algorithm from O(N^2) to O(N^2), losing a bunch of readability in the process. The O(N^2) is a notation of complexity, not performance. for (i = 0; i < 1000;++i) for (i = 0; i < 100; ++i) Both are O(1) but the second is still preferrable whenever possible. Just because they are both O(1) doesn't mean that one can't be better than the other. The code being discussed makes the execution 10 times faster, so that is not a minor optimization. Depending on the context it can be a huge difference for a really, really, really tiny loss of readability. | ||
|
CecilSunkure
United States2829 Posts
On August 11 2013 07:35 Morfildur wrote: The O(N^2) is a notation of complexity, not performance. for (i = 0; i < 1000;++i) for (i = 0; i < 100; ++i) Both are O(1) but the second is still preferrable whenever possible. Just because they are both O(1) doesn't mean that one can't be better than the other. The code being discussed makes the execution 10 times faster, so that is not a minor optimization. Depending on the context it can be a huge difference for a really, really, really tiny loss of readability. That's O(N) ![]() N is 1000, then 100. | ||
|
Deleted User 101379
4849 Posts
Depends. The 1000 is a constant, it never changes. Constant execution time is O(1). If the 1000 was passed in via a variable, it would be O(N), i.e. scales linarly. The 100 is not related to the 1000 before, so it's in itself O(1) as well. In the case of void foo(int x) it would be O(N) Then again, that is just my interpretation. Might be that comp sci people disagree with it. I never cared much about the theory of that stuff since it has no connection to real programming anyways. | ||
|
Shield
Bulgaria4824 Posts
How is this not O(N^2)? As far as I remember, nested loop is O(N^2) or O(N^3) if you have 3 loops inside each other. I'm 99% sure this is the case, but regardless if I'm right, I still need to refresh my Big O notation knowledge. | ||
| ||

