|
Hughlander posted:It's just a hack Id expect a TA to find clever. By treating the bool as an int with true being nonzero and false being zero if any return is false you are multiplying by zero and now the bool will always be false for the rest of the operations. But why not just set result to the return from the function? That seems an overly-complicated way of going about things.
|
#
?
Jan 12, 2014 21:32
|
|
|
|
| # ? Jun 8, 2024 21:12 |
|
|
Its called bad programming.
|
|
#
?
Jan 12, 2014 21:54
|
|
|
hooah posted:But why not just set result to the return from the function? That seems an overly-complicated way of going about things. Not to suggest it's a good idea still, you'd probably get the exact same performance, or even better, doing something less opaque and without causing warnings, like bool x=doingstuff(); result=(result&&x); And none of this is relevant to the actual code as given which is doing *= on declaration, so it's using an undefined value as the first argument. Hopefully that was shorthand to tell us that result was a bool, rather than the actual code?
|
|
#
?
Jan 12, 2014 22:32
|
|
|
roomforthetuna posted:And none of this is relevant to the actual code as given which is doing *= on declaration, so it's using an undefined value as the first argument. Hopefully that was shorthand to tell us that result was a bool, rather than the actual code? Yes, I was including the type in that line, although result was declared earlier.
|
|
#
?
Jan 12, 2014 22:52
|
|
|
roomforthetuna posted:Not to suggest it's a good idea still, you'd probably get the exact same performance, or even better, doing something less opaque and without causing warnings, like Or just code:
|
|
#
?
Jan 12, 2014 23:23
|
|
|
FamDav posted:Second, aliasing rules work on types, not memory locations. Edited the example to fix it.
|
|
#
?
Jan 12, 2014 23:41
|
|
|
Again,Some dude, possibly the same one posted:C99 6.5 7: An aggregate type does not change things.
|
|
#
?
Jan 13, 2014 00:03
|
|
|
Right, A and B::a fit that rule, but my concern is that A[] and B don't. i.e. I don't think this wouldn't work:code:OneEightHundred fucked around with this message at 01:39 on Jan 13, 2014 |
|
#
?
Jan 13, 2014 01:33
|
|
|
Subscript syntax — and pointer arithmetic in general — doesn't say anything for aliasing purposes about the base having array type. And anyway, there's a rule that, for the purposes of pointer arithmetic, a singleton object is interchangeable with an array of length 1. However, you're technically correct anyway that the l-values can't alias, but it's not because of the type-aliasing rules; it's because a pointer to a hypothetical element before an array is not a valid pointer into the array, and pointer arithmetic is undefined on an invalid pointer. I don't know of any compiler that does that analysis, though, and it would be problematic in practice because of offsetof tricks.
|
|
#
?
Jan 13, 2014 18:45
|
|
|
I figured out in my home project that the CSV file I'm trying to read in, at the size of roughly 32MB, takes 60 seconds to load. I profiled it in VTune and found out I was heavily I/O bound. It was something like only 5-10% of the run time could be pegged to actual CPU cycles. So sure, I'm reading a file off the disk, but half a meg per second on my desktop doesn't really explain that. I'm kind of saddened by the lack of some standard CSV loader, or at least a cross-platform one, but I guess that fits within the culture. The core of what I first wrote uses an ifstream for the file in question, and calls std::getline() to read off each line. I was assuming a good first in-place optimization would be to replace this with slurping the file and working off it in memory. I guess there are a lot of caveats to that. I ultimately got the contents into a preallocated char* and get a stream handle off that, after a few attempts that were just acting like middlemen and were causing the file stream to still arbitrarily seek. I also hear ifstream has a buffer anyways, and then I read that none of the standard streams do any buffering by defaults. Now I have no clue. At this point I wonder what I can do to try to minimize that I/O overhead. I assume if I get it into memory I shouldn't have any more file I/O overhead; I haven't confirmed that in a new profile yet. I also kind of wonder about streams in VS2010. Should I drop back to the C library? Should I jump forward into Boost?
|
|
#
?
Jan 15, 2014 20:19
|
|
|
Profilers often have some ability to trace syscalls and I/O requests so you can figure out if e.g. you're doing a ton of small reads behind the scenes.
|
|
#
?
Jan 15, 2014 22:00
|
|
|
Try the suggestion in this question: http://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python
|
|
#
?
Jan 15, 2014 22:12
|
|
|
I'm having trouble overloading a function. One is void foo(vector<int> &v) and the other is void foo(vector<int> &v, int a, int b) and MSVC is complaining that when I call foo(v, 0, static_cast<int>(v.size() - 1)) "the function does not take 3 arguments".
|
|
#
?
Jan 16, 2014 01:51
|
|
|
hooah posted:I'm having trouble overloading a function. One is void foo(vector<int> &v) and the other is void foo(vector<int> &v, int a, int b) and MSVC is complaining that when I call foo(v, 0, static_cast<int>(v.size() - 1)) "the function does not take 3 arguments". I just tried this out with VS2012 and it worked fine for me. Are you sure both the functions are in the same scope? If it was just an argument mismatch you should get an error message mentioning overloaded functions, but since you're not I think you're running into something like this.
|
|
#
?
Jan 16, 2014 02:11
|
|
|
DaVideo posted:I just tried this out with VS2012 and it worked fine for me. Are you sure both the functions are in the same scope? If it was just an argument mismatch you should get an error message mentioning overloaded functions, but since you're not I think you're running into something like this. I think I missed the scope part of the equation. I'll just rename one of them.
|
|
#
?
Jan 16, 2014 02:14
|
|
|
Rocko Bonaparte posted:I figured out in my home project that the CSV file I'm trying to read in, at the size of roughly 32MB, takes 60 seconds to load. I profiled it in VTune and found out I was heavily I/O bound. It was something like only 5-10% of the run time could be pegged to actual CPU cycles. So sure, I'm reading a file off the disk, but half a meg per second on my desktop doesn't really explain that. I'm kind of saddened by the lack of some standard CSV loader, or at least a cross-platform one, but I guess that fits within the culture. The last time I did something like that, I made my own caching wrapper around read() (that read a MB at the time), and pulled a char at the time out of that. It felt very much like reinventing the wheel, but it worked nicely.
|
|
#
?
Jan 16, 2014 10:45
|
|
|
While hacking together a quicksort algorithm from the book, I came across this bit of code. Here, i starts at the left element in the array, and j starts at one before the last element.code:code:hooah fucked around with this message at 22:48 on Jan 16, 2014 |
|
#
?
Jan 16, 2014 22:26
|
|
|
First, your indentation is horrible. It doesn't match the code structure in any sensible way. Second, try first rewriting the code to not use pre-increment tricks and empty loop bodies and conditions. It might make it clearer what it is doing: C++ code:E: You can also do away with the more_to_sort flag without having to resort to empty loop conditions and a break. In fact it's quite explicit what the real condition for the loop to end is. See if you can spot it. nielsm fucked around with this message at 22:48 on Jan 16, 2014 |
|
#
?
Jan 16, 2014 22:44
|
|
|
Ah, I think I see. The difference has to do with the while loop bodies being empty, yes? Also, sorry about the indentation; I copied the code from Visual Studio, and Chrome made enormous tabs that I didn't completely fix. I shall do that now.
|
|
#
?
Jan 16, 2014 22:47
|
|
|
So I'm not sure if this is the right thread to ask this, but here's some background. I'm trying to use a C library for graphs called igraph. I downloaded the source of the newest stable version, and compiled it properly on my system without errors (as far as I know). The problem is that although I can compile code that uses the library successfully, the functionality of the library appears to be broken. Below is the simple test code I'm using: pre:#include <igraph.h>
int main(int argc, char* argv[])
{
igraph_t g;
igraph_empty(&g, 0, 1);
printf("vcount: %d\n", igraph_vcount(&g));
printf("ecount: %d\n", igraph_ecount(&g));
if (igraph_vcount(&g) != 0) {
return 1;
}
if (igraph_ecount(&g) != 0) {
return 2;
}
igraph_destroy(&g);
return 0;
}pre:vcount: 1335272576 ecount: 0 vcount: -1973136176 ecount: 0 vcount: -1321827856 ecount: 0 vcount: -556353632 ecount: 0 vcount: 1584473680 ecount: 0 Here's how I'm compiling it in gcc: pre:gcc -g -ansi -Wall -Iinclude/igraph -Llib -ligraph main.c -o main My question is, am I missing something stupid? Some GCC flag that I'm missing or one I'm using that could be messing things up? Some issue with 64-bit Fedora running in a VM that I'm unaware of? I just want to know what the next step would be to troubleshoot this further other than posting on the mailing list I guess. I don't really want to do anything more with this library until I fix this problem.
|
|
#
?
Jan 25, 2014 02:01
|
|
|
It looks like you're getting an uninitialised variable somewhere. Try checking the value of g.n (since that's all igraph_vcount() does) immediately before and after calling igraph_empty() and see if the value changes.
|
|
#
?
Jan 25, 2014 02:59
|
|
|
i don't know if anyone here can help me, but i've been spinnin my wheels on this for a good few hours now. what i'm trying to implement: http://www.roguebasin.com/index.php...ngeon_Generator what i've got: http://pastebin.com/Nh9t76G8 i'm trying to build a 2d array of objects, whose type has a member describing a rectangle (with endpoint and dimensions) so far the "container" objects seem to work just fine. they print as expected. as for the "rooms" within each object in the array, only the first element (top left, 0,0) ever prints. i have no idea why and it's driving me nuts. any help would be greatly appreciated.
|
|
#
?
Jan 25, 2014 08:02
|
|
|
First question: My C++ prof told us that memory you allocate with new and then forget to delete creates a memory leak, but when your program terminates, all memory allocated to the program (including what you forgot to de-allocate) gets returned. My software design prof says the memory doesn't get returned until you reboot your computer. Is this OS-dependent, or is one of them wrong? Second: Is there a way to create say 10 variables of the same type and name them something like thing1 through thing10 without copying the same line 10 times? I'm guessing probably not.
|
|
#
?
Jan 25, 2014 14:49
|
|
|
hooah posted:First question: My C++ prof told us that memory you allocate with new and then forget to delete creates a memory leak, but when your program terminates, all memory allocated to the program (including what you forgot to de-allocate) gets returned. My software design prof says the memory doesn't get returned until you reboot your computer. Is this OS-dependent, or is one of them wrong? hooah posted:Second: Is there a way to create say 10 variables of the same type and name them something like thing1 through thing10 without copying the same line 10 times? I'm guessing probably not. Bonfire Lit fucked around with this message at 15:07 on Jan 25, 2014 |
|
#
?
Jan 25, 2014 15:03
|
|
|
This is how you learn that some professors will say things that are literally wrong and probably don't care to learn otherwise.
|
|
#
?
Jan 25, 2014 15:10
|
|
|
hooah posted:First question: My C++ prof told us that memory you allocate with new and then forget to delete creates a memory leak, but when your program terminates, all memory allocated to the program (including what you forgot to de-allocate) gets returned. My software design prof says the memory doesn't get returned until you reboot your computer. Is this OS-dependent, or is one of them wrong? It's free to be used once the process dies. If you ask the OS for the right to use some memory, it's going to keep track of which processes can see that memory, and once there are no processes using a particular piece of memory, it will know that memory can be used for something else. It's not OS-dependent if you're talking about operating systems where "rebooting" your computer is an actual thing. You could theoretically make an OS and standard library where it was true, of course, but if your hardware supports the notion of memory protection that would be extremely silly. hooah posted:Second: Is there a way to create say 10 variables of the same type and name them something like thing1 through thing10 without copying the same line 10 times? I'm guessing probably not. Make an array of size 10. code:
|
|
#
?
Jan 25, 2014 15:10
|
|
|
hooah posted:My software design prof says the memory doesn't get returned until you reboot your computer. Is this OS-dependent, or is one of them wrong?
|
|
#
?
Jan 25, 2014 17:29
|
|
|
roomforthetuna posted:I think Windows 3.1 was the last time this was true of a major user-level OS. But while he's wrong, he's kind of right from the perspective of software design - you should be designing code as if that's true, not just leaking everywhere 'til your program shuts down. It's more than "should", it's "must", because new and delete do more than allocate and deallocate memory. They also call constructors and destructors. So if you don't call delete on an object because its memory will get freed when your program exits, and that object is, say, buffering things before writing them to disk, then it won't be able to flush its buffers as it most likely normally would in its destructor, and you've just lost some data.
|
|
#
?
Jan 25, 2014 18:53
|
|
|
Ephphatha posted:It looks like you're getting an uninitialised variable somewhere. Try checking the value of g.n (since that's all igraph_vcount() does) immediately before and after calling igraph_empty() and see if the value changes. Thanks for such a fast reply, sorry I couldn't respond sooner. Here's what I get from that: pre:g.n before igraph_empty: 0 g.n after igraph_empty: 0 vcount: -579552 ecount: 0 DarkJC fucked around with this message at 20:26 on Jan 25, 2014 |
|
#
?
Jan 25, 2014 20:05
|
|
|
Here's the relevant definition:code:code:
|
|
#
?
Jan 25, 2014 21:35
|
|
|
Now a coworker wants to put using std::string; and using std::vector; and using boost::variant; and some others in a common utils.hpp header file. What's the best way to shut this movement down?
|
|
#
?
Jan 25, 2014 22:02
|
|
|
roomforthetuna posted:I think Windows 3.1 was the last time this was true of a major user-level OS. But while he's wrong, he's kind of right from the perspective of software design - you should be designing code as if that's true, not just leaking everywhere 'til your program shuts down.
|
|
#
?
Jan 25, 2014 22:58
|
|
|
shrughes posted:Now a coworker wants to put using std::string; and using std::vector; and using boost::variant; and some others in a common utils.hpp header file. What's the best way to shut this movement down? Brain them.
|
|
#
?
Jan 25, 2014 23:38
|
|
|
Sure, but the design of "never free mmeory" can bite you later. Trying to reuse the parser or lexer in a static analyzer tool or the codegen in a JIT will bite you in the rear end if it never frees memory. gcc has some atrocious use-after-free errors if you try to actually use it to compile more than one compilation unit at a time. Take a guess why David Malcolm's JIT branch hasn't updated for a while.
|
|
#
?
Jan 25, 2014 23:39
|
|
|
Otto Skorzeny posted:Brain them. I think I've managed to derail it into a compromise of telling them to do it inside non-global namespaces.
|
|
#
?
Jan 25, 2014 23:46
|
|
|
Suspicious Dish posted:gcc has some atrocious use-after-free errors if you try to actually use it to compile more than one compilation unit at a time. Take a guess why David Malcolm's JIT branch hasn't updated for a while. Is this related to their hodgepodge of memory management schemes (last I remember, they have a mix of gc, refcounting, obstacks and bespoke implementations of malloc/free; wonder if that's still the case?)
|
|
#
?
Jan 25, 2014 23:58
|
|
|
Suspicious Dish posted:Sure, but the design of "never free mmeory" can bite you later. Trying to reuse the parser or lexer in a static analyzer tool or the codegen in a JIT will bite you in the rear end if it never frees memory.
|
|
#
?
Jan 26, 2014 00:17
|
|
|
shrughes posted:I think I've managed to derail it into a compromise of telling them to do it inside non-global namespaces. I think that's fine. We do this in some places -- in our code we use C++11 and boost, and often there are similar-but-different libraries (thread-related stuff, smart pointers, time, etc.). To make it easy to change what what we use at a later point and to prevent us from having to qualify the types/templates in certain namespaces, we bring them in via using-declarations in headers.
|
|
#
?
Jan 26, 2014 00:43
|
|
|
shrughes posted:Now a coworker wants to put using std::string; and using std::vector; and using boost::variant; and some others in a common utils.hpp header file. What's the best way to shut this movement down? We are not allowed to use "using" full stop!
|
|
#
?
Jan 26, 2014 05:08
|
|
|
|
| # ? Jun 8, 2024 21:12 |
|
|
That's definitely an overreaction. Locally scoped using statements can significantly improve readability in some cases, and they're sometimes the only way to get the correct semantics (e.g. for swap).
|
|
#
?
Jan 26, 2014 05:21
|
|