|
Are you sure optimizations are off? That kind of output is exactly what I'd expect if there's even a bit of dead code elimination, or constant propagation. Then the debugger can sometimes show "statements" being executed that don't exist in the compiled program (and so of course they have no effect.) Try looking at the assembly?
|
# ? Jul 21, 2013 00:07 |
|
|
# ? Jun 8, 2024 11:56 |
|
I tried compiling both programs with intel's c++ compiler, and the debugger now indicates the correct values. So I guess the visual c++ debugger generates incorrect debugging information, while intel's generates correct information?
|
# ? Jul 21, 2013 00:08 |
|
crazypenguin posted:Are you sure optimizations are off? That kind of output is exactly what I'd expect if there's even a bit of dead code elimination, or constant propagation. Then the debugger can sometimes show "statements" being executed that don't exist in the compiled program (and so of course they have no effect.) I'm sure they're off. I'll probably take a look at whats actually being generated eventually, but I think I'm just gonna use intel's compiler for the time being. I'm sorta pressed for time and I've spent a bit too long messing around with this goofy problem already, haha.
|
# ? Jul 21, 2013 00:16 |
|
A better idea would be to not reuse variable names like that, even if you can. Based on this comment "I looked back up through the program", I'm guessing that your function is probably too long to begin with. You should really aim for functions no longer than 25-50 lines or so, and that do one thing and one thing only.
|
# ? Jul 21, 2013 00:44 |
|
Sure, you could say that, but MSVC's compiler/debugger is also absolutely loving broken.
|
# ? Jul 21, 2013 01:26 |
|
Developers, developers, developers. Little does Balmer know Microsoft only targets programmers, programmers, programmers, and developers are out of luck.
|
# ? Jul 21, 2013 01:37 |
|
Suspicious Dish posted:Sure, you could say that, but MSVC's compiler/debugger is also absolutely loving broken.
|
# ? Jul 21, 2013 01:39 |
|
Don't reuse the variable name i because your debugger is broken? I think you wanted the coding horrors thread. Aside, I kind of think number of branches or loops is a much better heuristic for "is this function too big" than number of lines. seiken fucked around with this message at 01:45 on Jul 21, 2013 |
# ? Jul 21, 2013 01:42 |
|
seiken posted:Don't reuse the variable name i because your debugger is broken? I think you wanted the coding horrors thread. That sounds like a practical approach to me. The tools are lovely, but everything else is shittier, so let's make our lives easier by working around the tool. Subscribing to some ideology about purity because it's clearly the debugger's fault and not yours and you'll just wait for MSVC2020 to fix the bug is something that flat out ignores reality. Just change the variable name. It doesn't hurt much.
|
# ? Jul 21, 2013 01:53 |
|
I mean, I was mostly asking about what was going on with the compiler (or debugger). It goes without saying that changing the variable name avoids the issue.
|
# ? Jul 21, 2013 01:59 |
|
Hopefully the debugger can at least manage non-overlapping same named variables?code:
Edit: not that it wouldn't be nice if they fixed the debugger to conform to spec too, of course.
|
# ? Jul 21, 2013 03:08 |
|
Suspicious Dish posted:That sounds like a practical approach to me. The tools are lovely, but everything else is shittier, so let's make our lives easier by working around the tool. Sorry, I didn't necessarily mean you shouldn't rename the variable to avoid the problem. Just that the fact that doing so seems like a reasonable solution is appropriate for the coding horrors thread. vvv because the debugger should loving work that's why, it's crazy you have to do weird workarounds seiken fucked around with this message at 23:17 on Jul 21, 2013 |
# ? Jul 21, 2013 13:23 |
|
Seems as reasonable a solution as any. Why?
|
# ? Jul 21, 2013 19:09 |
|
Dog Jones posted:I tried compiling both programs with intel's c++ compiler, and the debugger now indicates the correct values. So I guess the visual c++ debugger generates incorrect debugging information, while intel's generates correct information? That, or ICC does different register allocation such that both i values get put in the same register. (This is assuming that the PE/COFF debugging information for a function/BB is along the lines of 'variable i is stored in register eax'.)
|
# ? Jul 21, 2013 19:23 |
|
roomforthetuna posted:Hopefully the debugger can at least manage non-overlapping same named variables? Looks like it gives you the correct one when you're inside a loop, at least. Outside of loops, you apparently get the variable from the last executed loop in the current scope. And in the locals tab, you'll have an entry for each loop counter variable even though they're out of scope. So, yeah, it seems like it just wasn't fixed to handle the standard scoping rules when the rest of Visual C++ was. Kinda surprised this hasn't bit me in the rear end before, really.
|
# ? Jul 22, 2013 14:45 |
|
Do you guys think it would be kosher to use uintptr_t on a coding test even though it is not guaranteed to be defined by the standard library? For reference: http://www.cplusplus.com/reference/cstdint/
|
# ? Jul 31, 2013 11:59 |
|
Dog Jones posted:Do you guys think it would be kosher to use uintptr_t on a coding test even though it is not guaranteed to be defined by the standard library? Yes, if you really feel nervous you could even #error if UINTPTR_MAX isn't defined.
|
# ? Jul 31, 2013 14:56 |
|
Can someone help me out with the kind of things I could look for that might cause the problem I'm seeing? I am using zopflipng from https://code.google.com/p/zopfli/ For a particular file I have I'm getting a core due to an assert failure but only with certain build flags on certain architectures. I have it compiled for RedHat 4, GCC 3.4.6 20060404 (Red Hat 3.4.6-11), and for RedHat 6, GCC 4.4.6 20120305 (Red Hat 4.4.6-4). On either platform when I compile it 32-bit with no optimization flags, it cores on an assert in deflate.c:272. When I compile it 32 bit w/ -O2 it works fine on both platforms. 64bit works on both platforms, -O2 or no. I would suspect a memory error but Valgrind reports no memory errors. code:
|
# ? Jul 31, 2013 21:29 |
|
It appears that lodepng, used by zopflipng, is stomping on my stack during a call to realloc. So that's nice.
|
# ? Jul 31, 2013 23:22 |
|
Dog Jones posted:Do you guys think it would be kosher to use uintptr_t on a coding test even though it is not guaranteed to be defined by the standard library? I can understand int8_t is not supported on platforms with native 8-bit types, I presume intptr_t doesn't work with suitably perverse pointers. Apparently AS/400 has 16-byte pointers and fit that niche. MrMoo fucked around with this message at 02:12 on Aug 1, 2013 |
# ? Aug 1, 2013 02:05 |
|
Hughlander posted:Yes, if you really feel nervous you could even #error if UINTPTR_MAX isn't defined. Alright, thanks pal.
|
# ? Aug 1, 2013 11:55 |
|
I'm trying to do some OpenGL tutorials from http://www.arcsynthesis.org/gltut/. I've compiled the GLSDK I need, but when try to build the framework from the first tutorial, I get the following error:code:
Any ideas? EDIT: Also, the tutorial itself gives me these errors: code:
Boz0r fucked around with this message at 15:43 on Aug 1, 2013 |
# ? Aug 1, 2013 15:41 |
Post your code. It's complaining about a specific function call having an invalid parameter. So post that function call. And what that parameter is defined as.
|
|
# ? Aug 1, 2013 15:45 |
|
I've just downloaded the code, I haven't even changed anything yet.code:
EDIT: I've tried moving over to Linux, but now I get a different set of errors: code:
Boz0r fucked around with this message at 14:12 on Aug 2, 2013 |
# ? Aug 1, 2013 16:04 |
|
C++ code:
code:
|
# ? Aug 2, 2013 21:25 |
|
HappyHippo posted:
You don't have to use dynamic memory allocation, you can just create an instance of the child on the stack and then make an abstractClass reference to it. If your compiler supports r-value references, the easiest way would be to simply do: code:
|
# ? Aug 2, 2013 21:35 |
|
That Turkey Story posted:
This is making me but I can't figure out why.
|
# ? Aug 2, 2013 23:11 |
GrumpyDoctor posted:This is making me but I can't figure out why. Looks like the object is getting stack-allocated as a temporary, then ... what happens? Does "blah" actually have the storage for the object, or is it just kind-of in limbo? Why would you even ever want to do that thing, having a local non-pointer non-reference variable of with formal type of an abstract class but actual type of a concrete subclass? I can't think of any cases where having the variable be of the concrete class would not work.
|
|
# ? Aug 2, 2013 23:43 |
|
nielsm posted:Why would you even ever want to do that thing, having a local non-pointer non-reference variable of with formal type of an abstract class but actual type of a concrete subclass? I can't think of any cases where having the variable be of the concrete class would not work. code:
|
# ? Aug 3, 2013 00:18 |
|
Why does this not compile:C++ code:
pre:foo.cpp|23 col 40 error| incompatible operand types ('ConcreteClassA *' and 'ConcreteClassB *') C++ code:
|
# ? Aug 3, 2013 01:34 |
|
nielsm posted:Looks like the object is getting stack-allocated as a temporary, then ... what happens? Does "blah" actually have the storage for the object, or is it just kind-of in limbo? roomforthetuna posted:(I don't understand why it was && rather than & in Turkey's version, nor do I know if there's a way to do this on the stack, but it's an example of where you would want the variable itself to be non-concrete!) That is on the stack. C++ has a rule that the life of a temporary is extended to match the life of the reference, unless that reference is a non-static datamember. This was true in C++98, as well, but since a temporary cannot be directly used to initialize a reference to non-const, you couldn't directly take advantage of this for mutable objects (this is why you need && instead of &). Now that we have r-value references, you can use this feature with references to non-const objects.
|
# ? Aug 3, 2013 01:40 |
|
Deus Rex posted:Why does this not compile: You could do code:
roomforthetuna fucked around with this message at 01:43 on Aug 3, 2013 |
# ? Aug 3, 2013 01:40 |
|
I wouldn't use a ternary here at all, for what is by now an obvious reason. If I were made to, the 'appropriate long-winded' C++ cast would be static_cast<>, but I would instead use a function-style cast here. I generally use function-style cast wherever static_cast<> seems over the top; I don't like using C-style casts in case I miss a const or something, but for simple types it seems ok. It's usually cleaner anyway due to fewer brackets (though not in this example). It's great for looping through enum values. Rottbott fucked around with this message at 12:27 on Aug 3, 2013 |
# ? Aug 3, 2013 12:21 |
|
I'm just starting out with c++, so I'm playing around with implementing bubble sorts. Both of these functions work perfectly fine, but I'm just curious as to whether either of these implementations would be considered better than the other. The question boils down to whether a for or while loop is more "useful" I suppose; it seems to me that while is better since a new int doesn't have to be declared each time (not that that would be a huge bottleneck, but it seems like a slight improvement to me). Any opinions?code:
|
# ? Aug 3, 2013 12:35 |
It's better to use the "for" loop because for-loops are intended for looping over known-length data, and your list has a known length. Also, consider that after one iteration the final element in the array is guaranteed to be the largest of them all, meaning you know that after "i" iterations, the last "i" elements are in correct order. This can slightly improve the running time of the algorithm (that will stay O(n*n)), though it doesn't change its asymptotic complexity, but more importantly it puts an upper bound on the number of iterations for the outer loop. That will allow you to avoid the "while" loop condition on a flag.
|
|
# ? Aug 3, 2013 13:00 |
|
Great, thanks. I'm also working on a practice dynamic array class which stores an array of integers that can be "dynamically" reallocated. I'm having errors with the destructor, though. Simplified, I have this:code:
code:
|
# ? Aug 3, 2013 15:16 |
|
At first glance I see a couple of things wrong: - Is this the exact code you used? It doesn't compile due to a misplaced semi-colon in the destructor. - You unnecessarily do two allocations when growing, rather than just reassigning 'array' to point at 'temp'. - It's not exception safe. I've never actually used C++ exceptions but it looks pretty dodgy from that perspective. - Repeating the '+ 10' everywhere is just asking for trouble, use a constant. However I can't actually see what's causing your exception, and I don't get one when running it here. Post more details or your complete code or wait for someone smarter than me.
|
# ? Aug 3, 2013 17:53 |
Yeah, please either post the code you are actually using, a minimal example that still shows the same behaviour, or just don't post at all. But the code is poorly structured, as Rottbott points out. You should at the very least have a "resize" function on the class that re-allocates the back storage. If you write it such that it can also handle the back-storage being null (just making an initial allocation) or the new size being zero (delete and null the storage) you can have that handle the meat of the construction and destruction as well. There's a ton of other things you should be doing as well to follow good C++ style, but at least start with this.
|
|
# ? Aug 3, 2013 18:04 |
|
Yeah, I just started working on it for fun/practice and I know tons of little things I should do and there's tons of little/big things I don't know how to do. The problem arises if I use that class code (with proper semicolon, I just typed up a quick version of it) with this simple demonstration: edit: here's everything exactly as i have it. EDIT2: Figured it out! The error is with my calling of new int in the constructor, I set it to the wrong size. Feel free to point out anything especially horrible with the rest of the code. code:
code:
King fucked around with this message at 19:32 on Aug 3, 2013 |
# ? Aug 3, 2013 18:48 |
|
|
# ? Jun 8, 2024 11:56 |
|
King posted:Yeah, I just started working on it for fun/practice and I know tons of little things I should do and there's tons of little/big things I don't know how to do. The problem arises if I use that class code (with proper semicolon, I just typed up a quick version of it) with this simple demonstration: If you read the error message "Heap block at 011E9EE8 modified at 011E9F3C past requested size of 4c" or google "Heap block at modified at past requested size of" you should realize that what's going on is that you are modifying a value past the length of your array. So, you should look for spots in your code where you are allocating the space for your array and where you are writing to the array. Here's your problem: code:
code:
code:
|
# ? Aug 3, 2013 19:33 |