|
shrughes posted:Half? Should cut it down a bit more than that. Yeah, late night. Meant to type 'over' instead of 'nearly'. Guess that's a pretty good indication I should go to bed. Also, no it doesn't. Output for 100 is simply 2 and 5.
|
# ? Sep 10, 2012 06:28 |
|
|
# ? Jun 8, 2024 08:15 |
|
Papes posted:Yeah, late night. Meant to type 'over' instead of 'nearly'. Guess that's a pretty good indication I should go to bed. Okay, it outputs 2 if that's a factor, and then it outputs all the odd factors. Try 81 or 225.
|
# ? Sep 10, 2012 09:13 |
|
Papes posted:Trying to optimize this factoring program and am getting absolutely nowhere, so I've come for help . Google is your friend. The quickest way of doing this is to do Miller-Rabin and Pollard's rho algorithm. Use Miller-Rabin to figure out whether or not the number is composite - Pollard's rho algorithm does not work if the number is prime, so you need to run a prime detection algorithm before you factor a 64-bit integer. After that, use trial division for like the first 1000 primes, then clean up with the Rho detection algorithm.
|
# ? Sep 10, 2012 14:16 |
|
hieronymus posted:Google is your friend. I get the feeling this is for an assignment for a fairly beginner programming class or something of that sort so while your advice is certainly mathematically sound, it's probably overkill and/or not necessarily helpful in this case. The object probably really is just to demonstrate understanding of loops and such, only do these real-world algorithms if you wanna be a superstar! seiken fucked around with this message at 17:37 on Sep 10, 2012 |
# ? Sep 10, 2012 16:41 |
|
shrughes posted:Okay, it outputs 2 if that's a factor, and then it outputs all the odd factors. Try 81 or 225. 81: 3 225: 3 and 5 What is making you believe that it outputs non prime numbers? I've tested it many times and I've never gotten a nonprime number. Granted it can output duplicates, as the actual output for 225 was 3, 3, 5, 5. I've just been ignoring the duplicates for now as getting rid of them is outside the scope of this assignment. I'll probably fix it for fun when I have free time. hieronymus posted:Google is your friend. Really appreciate that, I'll look into it later. But as our fellow friend said, it's a bit overkill for this particular assignment. Papes fucked around with this message at 17:35 on Sep 10, 2012 |
# ? Sep 10, 2012 17:29 |
|
I've recently started learning C++ by myself, after 10 years of Python/PHP/etc. I'm reading the free Thinking in C++ and trying to port a Python project to C++ as I go along. I'm now messing with inheritance and have been battling this specific problem for about 4 hours, without making any progress. I feel like a retard and I now realize why I stuck with Python all these years. No matter what I do, I get the generic linker error: main.o In function `main': main.cpp 34 undefined reference to `Living::move(int, int, int)' I'm sure it's a stupid mistake, but I just cannot understand why the linker cannot find Living::move(), when it's clearly defined and declared. I've seen many examples do pretty much the same thing as i do, but usually examples on the web are all in the same file for simplification. Is it caused by spreading my classes in different files/headers and I'm not linking them properly or in the right order? This is something that confuses me a bit, coming from "simple" languages. main.cpp: code:
code:
code:
code:
code:
- If I call derp.move_to() it works fine, so the Living instance clearly inherits it from the Thing class. - I use Code::Blocks with GCC on Windows, if it matters. - All my headers are wrapped in #ifndef/#define, I just didn't include it here for clarity. Senso fucked around with this message at 08:47 on Sep 11, 2012 |
# ? Sep 11, 2012 08:45 |
|
Senso posted:No matter what I do, I get the generic linker error: First guess: are you sure it's a linker error and not a compiler error? Your quoted code for main.cpp doesn't #include "living.hpp" (unless that was included within game.hpp, which we can't see). Second guess: if it is a linker error, are you sure all the cpp files are included in the compile and link? Does your IDE show the command-lines it's executing? You'd need living.obj or living.o to exist and be included in the linking command line.
|
# ? Sep 11, 2012 08:59 |
|
roomforthetuna posted:I'm not familiar with your particular tools, so I'll make a couple of guesses. Yes, game.hpp contains: #include "thing.hpp" #include "living.hpp" #include "map.hpp" Here's the full build log: Compiling: main.cpp Compiling: map.cpp Compiling: thing.cpp Compiling: game.cpp Linking console executable: bin\Debug\derp.exe obj\Debug\main.o: In function `main': E:/derp/main.cpp:34: undefined reference to `Living::move(int, int, int)' In obj/Debug, I have game.o, main.o, map.o, thing.o so it looks like they were compiled fine. Code::Blocks does not seem to show the full command line used though... EDIT: Huh, I don't have a living.o though, it looks like it was skipped. I feel like my stupid mistake is there, but I'm including living.hpp properly it seems. EDIT: Yes, huh. It looks like CB somehow removed living.cpp from the project so it was not included in the compiling/linking. What a waste of time, ugh. I spent all this time trying to debug a weird IDE behavior. I should code with Notepad++... Senso fucked around with this message at 09:13 on Sep 11, 2012 |
# ? Sep 11, 2012 09:04 |
|
Senso posted:In obj/Debug, I have game.o, main.o, map.o, thing.o so it looks like they were compiled fine. Code::Blocks does not seem to show the full command line used though... Edit: Yeah, including the hpp has nothing to do with compiling the cpp. You have to add the cpp to the project somewhere in the IDE or Makefile or whatever Blocks uses to define the project.
|
# ? Sep 11, 2012 09:08 |
Senso posted:Yes, game.hpp contains: Note that it never says compiling living.cpp, your project is set up wrong somehow. I'm not familiar with Code::Blocks so I can't tell you what to do, unfortunately.
|
|
# ? Sep 11, 2012 09:08 |
|
4 hours chasing a typo, re-reading all the inheritance tutorials, only to find a stupid Code::Blocks error. I guess it's perfectly normal for experienced C/C++ programmers, you develop an eye for spotting config/makefile errors like that early. I'm too used to just launching "python mainfile.py" and if there's an error it tells me clearly why and where. Oh well, at least I can move on now!
|
# ? Sep 11, 2012 09:18 |
|
Sorry if this has already been answered on page 76 or something! I'm wondering about the difference between putting stuff on the stack or the heap. I know the general recommendation is that large amounts of data go on the heap (as stack space has a limit), but I was under the impression that nearly all data containers ended up storing their stuff on the heap, so that in reality, a 100mb list stored on the stack only has a few pointers actually stored in the stack, the rest is on the heap. This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries. The internet seems to be all "Do whatever feels best" about the issue, but I really want to know the "right way". Can anybody help, or at least give me something to read that's a little deeper than basic definitions? Edit: I know about the rare cases where an object needs to be referenced by several classes and such, but I rarely actually run into them, most of the time I find I can avoid it by writing the code a little more elegantly. Jamus fucked around with this message at 10:46 on Sep 11, 2012 |
# ? Sep 11, 2012 10:43 |
Jamus posted:I'm wondering about the difference between putting stuff on the stack or the heap. Will you be using the object after the function creating it returns? If "yes" or "not sure", then make a free-store allocation. "Auto" allocations (as C++ calls what almost always turns out to be stack allocations) are really only for short-lived things. If you need something to outlive the function that creates it you will either need to allocate it on the free store/heap and return a pointer (better, a suitable smart pointer) to it somehow, or you will have to return the object itself which can very well start to involve copying of large amounts of data if you aren't careful. And of course, stack space is much more limited than the heap.
|
|
# ? Sep 11, 2012 11:07 |
|
Jamus posted:I was under the impression that nearly all data containers ended up storing their stuff on the heap, so that in reality, a 100mb list stored on the stack only has a few pointers actually stored in the stack, the rest is on the heap. You have it about right!! If you put an object on the stack, it's necessarily fixed size so even a lovely library will have to allocate their additional memory needs on the heap. (There is stuff like std::array<> where it's just a struct with an array in there, but it's gonna be fairly obvious because you have to specify the size in the template arguments.) There'd be the argument for putting poo poo on the heap so you can pass it by pointer without worrying about it going out of scope rather than copying it around, but you'll be worrying about just when to delete it anyway.
|
# ? Sep 11, 2012 11:49 |
|
I recommend always defaulting to the stack for objects unless you have a very specific reason to directly use the heap. If the object's lifetime has a clear scope, there is usually little reason to dynamically allocate, but if you do decide that it is a good idea, perhaps because it is a very large object, use something like std::unique_ptr. Remember that if you are using a dynamic container, as you already pointed out, it will generally be using the heap internally anyway. Don't just start explicitly putting things on the heap for no reason. C++ excels with value semantics, especially C++11. That along with move-elision makes things a lot more efficient than what programmers often assume. Unless you are doing a lot of recursion, you're probably not going to have to deal with stack overflows. Also keep in mind that if you really want to, there are often ways to increase the size of your program's stack. Jamus posted:This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries. Jamus posted:Edit: I know about the rare cases where an object needs to be referenced by several classes and such, but I rarely actually run into them, most of the time I find I can avoid it by writing the code a little more elegantly.
|
# ? Sep 11, 2012 17:27 |
|
I've come to consider shared ownership a pretty strong code smell. It's not inherently terrible, but my experience has been that refactoring code to eliminate it nearly always results in cleaner and easier to understand code.
|
# ? Sep 11, 2012 17:44 |
|
I'm trying to write an asynchronous logging class and can't decide on when to write the logs to the file. Right now, I'm thinking of storing all the logs in a vector and then sort them by their timestamps. The problem is when should I write the logs to a file? If I wait for N logs before writing to disk, I might miss a log entry or one might be written to the log out of sequence if we already reached N logs in the vector. I was thinking of maybe using a timer of some sort but I'm not sure if that would be any better. I would appreciate any ideas, thanks. Acer Pilot fucked around with this message at 00:55 on Sep 12, 2012 |
# ? Sep 12, 2012 00:49 |
|
KNITS MY FEEDS posted:I'm trying to write an asynchronous logging class and can't decide on when to write the logs to the file. Use a concurrent queue and have a thread that pulls stuff off of it and writes it immediately.
|
# ? Sep 12, 2012 01:06 |
|
Ok so I'm sure I must have encountered this issue before but I'm not sure if there's a usual way to deal with it:code:
seiken fucked around with this message at 01:18 on Sep 12, 2012 |
# ? Sep 12, 2012 01:12 |
|
Is there a reason you have to have Foo*'s in the set, or can you have just Foo's? Otherwise I think you can write a replacement comparison function so that it looks at the ZombieApostate fucked around with this message at 02:27 on Sep 12, 2012 |
# ? Sep 12, 2012 02:21 |
|
b0lt posted:Use a concurrent queue and have a thread that pulls stuff off of it and writes it immediately. I just ended up using log4cxx. Anyone know of any issues with this library?
|
# ? Sep 12, 2012 04:07 |
|
ZombieApostate posted:Is there a reason you have to have Foo*'s in the set, or can you have just Foo's? Otherwise I think you can write a replacement comparison function so that it looks at the Storing pointers in containers is a perfectly reasonable thing to do and a custom comparator has nothing to do with the argument types of the functions I'm afraid. My question is about how to be const-correct in a relatively simple situation without needing a const_cast
|
# ? Sep 12, 2012 10:22 |
|
Jamus posted:This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries. The internet seems to be all "Do whatever feels best" about the issue, but I really want to know the "right way". Can anybody help, or at least give me something to read that's a little deeper than basic definitions? Of course if you never connect() a signal to the object than it shouldn't matter and creating it on the stack should be fine. But better safe than sorry and always instantiating QObjects on the heap for consistency's sake is a good idea. In my opinion anyway.
|
# ? Sep 12, 2012 11:07 |
|
seiken posted:Storing pointers in containers is a perfectly reasonable thing to do and a custom comparator has nothing to do with the argument types of the functions I'm afraid. My question is about how to be const-correct in a relatively simple situation without needing a const_cast You just need a const_cast. All of the internal machinery in std::set wants to pass around values of the key type, not values of types to which the key type is convertible. One reason why is that that's all the comparator is known to support — you may have given your set a comparator that takes const Foo*s, but an arbitrary std::set of Foo*s is allowed to have a comparator that just takes Foo*s. It comes down to philosophy. What types should you be able to pass to find()? There are two ways to answer that: intrinsic and extrinsic. There's only one type which you should intrinsically be able to pass to find(), and that's the set's actual key type, because the comparator promises to work with that. But extrinsically, you should be able to pass anything which can sensibly work with the comparator you've provided. The extrinsic answer is generally the more flexible and accepting answer, but it requires type-checking and rebuilding basically the set's entire search machinery with an arbitrary new type — i.e., in C++, it requires templating everything to hell and back. That in turn means inferior error messages, build times, generated code size, etc.
|
# ? Sep 12, 2012 11:43 |
|
rjmccall posted:You just need a const_cast. All of the internal machinery in std::set wants to pass around values of the key type, not values of types to which the key type is convertible. One reason why is that that's all the comparator is known to support — you may have given your set a comparator that takes const Foo*s, but an arbitrary std::set of Foo*s is allowed to have a comparator that just takes Foo*s. Thanks, great answer, just wanted to make sure I wasn't missing something obvious & better (const_cast is what I've been doing so far)
|
# ? Sep 12, 2012 12:20 |
|
That Turkey Story posted:Do not look to QT for good programming practices.
|
# ? Sep 12, 2012 13:01 |
|
Sagacity posted:Is it still worth looking at QT for doing cross-platform GUI programming in C++? Yes. There's also wxWidgets and GTK+, but they're not better.
|
# ? Sep 12, 2012 18:37 |
|
PiotrLegnica posted:Yes. There's also wxWidgets and GTK+, but they're not better. Pretty much this. GUI programming is just an unfortunately sad state of affairs in C++.
|
# ? Sep 12, 2012 18:44 |
|
gtkmm is quite nice. Do you have any issues with it?
|
# ? Sep 12, 2012 18:53 |
|
Suspicious Dish posted:gtkmm is quite nice. Do you have any issues with it? I haven't used it but it actually looks pretty good.
|
# ? Sep 12, 2012 19:19 |
|
gtkmm is nicer (and more idiomatic C++) in its interface than Qt is, but at their core any C++ bindings to GTK or any updates to the interface of Qt cannon do more than paper over the fact that both widget toolkits are clusterfucks
|
# ? Sep 12, 2012 19:32 |
|
Otto Skorzeny posted:gtkmm is nicer (and more idiomatic C++) in its interface than Qt is, but at their core any C++ bindings to GTK or any updates to the interface of Qt cannon do more than paper over the fact that both widget toolkits are clusterfucks I work on GTK+, so I'd be welcome to hear any suggestions or comments you have.
|
# ? Sep 12, 2012 19:42 |
|
1) Detonate GObject 2) THemes blow goat dick, fix them I'm sorry these aren't very constructive it's been a long day
|
# ? Sep 12, 2012 20:20 |
|
Otto Skorzeny posted:1) Detonate GObject No. I'd hate to get in a C/C++ discussion, and I understand GObject sucks in some parts (properties), but overall I really like GObject. What do you dislike about it? Otto Skorzeny posted:2) THemes blow goat dick, fix them We are. Themes are now CSS (limited, but we're adding more every day, and believe me we'll never use CSS for layout). Otto Skorzeny posted:I'm sorry these aren't very constructive it's been a long day I understand.
|
# ? Sep 12, 2012 20:34 |
|
My problems with GTK+ usually revolve around Windows support being not-so-stellar. Maybe that improved, though it seems there are no official 3.x builds. Either way never use wxWidgets.
|
# ? Sep 12, 2012 21:29 |
|
If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.)
|
# ? Sep 12, 2012 21:50 |
|
GrumpyDoctor posted:If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.) Could be. Can you post a minimised example code?
|
# ? Sep 12, 2012 21:52 |
|
I can try. This is one of those delightful problems where pulling a simple reproduction out of the code is at least as much work as just working around the original problem.
|
# ? Sep 12, 2012 22:00 |
|
GrumpyDoctor posted:If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.) It's been a while, but I think it will tell you if substitution failed. You could always test it by purposely writing a template where substitution fails and try to call it, then see what the error message says. I.E. code:
|
# ? Sep 12, 2012 22:09 |
|
|
# ? Jun 8, 2024 08:15 |
|
PiotrLegnica posted:My problems with GTK+ usually revolve around Windows support being not-so-stellar. Maybe that improved, though it seems there are no official 3.x builds. Windows support is improved, and Alex worked on it a ton. There's no official builds, yeah, which is a thing we're working on, believe it or not. We're first creating nightly build infrastructure (Colin is working on this), and then we'll have Windows builds.
|
# ? Sep 12, 2012 23:38 |