|
Karl Sharks posted:Well, it's not the 'right' way, but we haven't gotten into LU-decomposition, really. We did a single problem, but it felt like we probably did a sort of babby's first for that. We don't really use inverse much anymore, mostly (reduced) row echelon form because If you can get away with it, try Python. Numpy has built in matrix types and has library functions for multiplication, inversion, and pseudo-inversion (also things like gaussian generation, etc). Numpy ties down into C so it's pretty fast. I realize that doesn't help you much if you need C/C++ specifically, but Python was more or less built for this poo poo.
|
# ? Nov 9, 2012 17:57 |
|
|
# ? Jun 9, 2024 00:13 |
|
Optimus Prime Ribs posted:Yeah basically, though it's only XInput and not DirectInput. Why are you provide your own event loop and wrapper, then, instead of just a few utility functions?
|
# ? Nov 9, 2012 21:19 |
|
Rottbott posted:I find it pretty simple and straightforward. I've wrapped it, but only for writing cross-platform. To get the analogue stick angle you just call one function to get the controller state and do some trig with the X/Y vector... To each their own I suppose. I just want to take all the XInputGetState calls and subsequent code that ends up looking like this: C++ code:
Suspicious Dish posted:Why are you provide your own event loop and wrapper, then, instead of just a few utility functions? For the XInput states to stay up to date a loop is required either way, as the XInputGetState function needs to be continuously called, so I figured doing this would provide the best functionality: C++ code:
My thought process for doing it like that is that it allows adding new events as they are required to be rather trivial (such as releasing a button, or pressing a certain combination of buttons). As well it only requires calling two functions to get any kind of input from the controller. Are you saying it would be better to just write a bunch of functions like this? C++ code:
|
# ? Nov 9, 2012 23:15 |
|
Hm, so that means that you'll get dead input frames either way.
|
# ? Nov 10, 2012 02:08 |
|
That 'before' code looks fine to me. There's no reason all those separate if () checks couldn't be done with a loop if that's what you're doing. If you are going to wrap it, you might as well go all the way and do auto-repeat, half axes, relative positions and so on. Also, it would be worth not naming it 'x360' and abstracting it enough so that the same interface could be used on other platforms with a different implementation - e.g. DirectInput or whatever heathen thing they use on Macs. Personally I don't like the event stuff for input over a simple system to query controls - if the user actually manages to press a button for less than 16 milliseconds they probably won't mind if you ignore it anyway, and it might even be preferable.
|
# ? Nov 10, 2012 16:45 |
|
I'm still just beginning coding, so apologies if this question is really basic! I'm working with classes on a library reference practice program, which I have a grasp on, my problem is in trying to get lines from a file and send them to the class. For example the lines are: C8394 Kundera Milan The Unbearable Lightness of Being novel available C1934 Heidegger Martin Being and Time philosophy unavailable So the first thing to get is the call #, Author Last, first, title, genre, availability, which are all parts of the class. Normally I'd just getline And I'm not sure how to send each line to the class and break it up, or if I can just do what I've done here: code:
Is there a way to get the line as a whole, break it up into six parts by TAB, then send it to the array of classes? I'm honestly beyond confused about the whole thing, but it seems like a really simple concept. spooky wizard fucked around with this message at 12:45 on Nov 12, 2012 |
# ? Nov 12, 2012 12:40 |
|
Just pull out all six entries into a bunch of variables and pass them to your constructor?
|
# ? Nov 12, 2012 13:57 |
|
Yeah, thanks. I think just presenting the question helped me realize how simple it was. I need a programming partner to just talk things out with or something I don't think I even need a for loop.
|
# ? Nov 12, 2012 14:25 |
|
Hey guys need some help figuring out why I get a weird bug in my code.code:
quote:The water is in the solid state.
|
# ? Nov 12, 2012 17:26 |
|
Because it says dispState(0) in main.
|
# ? Nov 12, 2012 17:28 |
|
drat it. So simple . Edit: Yep that fixed it. Thanks a lot . Dodoman fucked around with this message at 18:53 on Nov 12, 2012 |
# ? Nov 12, 2012 17:33 |
|
RoryGilmore posted:Yeah, thanks. I think just presenting the question helped me realize how simple it was. I need a programming partner to just talk things out with or something I don't think I even need a for loop. Remember this lesson, and learn it well, and when you get a job the old guys will think you're god's gift because you'll only ask them sensible questions. http://en.wikipedia.org/wiki/Rubber_duck_debugging
|
# ? Nov 12, 2012 23:30 |
|
I'm very confused about both typedef and the syntax of function pointers. Bare with me as I try to lay out the context. I have a structure foo, with a function pointer member: code:
code:
code:
code:
|
# ? Nov 14, 2012 23:34 |
|
1) One returns a void, and one returns a void *. 2) Don't name your fields the same as the types. That's rude. 3) That's bad syntax. You should be doing: code:
|
# ? Nov 14, 2012 23:41 |
|
And you shouldn't be naming your types with the _t suffix, that entire namespace is reserved by the standard.
|
# ? Nov 15, 2012 05:21 |
|
Says what? I've certainly seen libraries that have the _t suffix.
|
# ? Nov 15, 2012 05:28 |
|
Yes; they're broken.
|
# ? Nov 15, 2012 05:49 |
|
pseudorandom name posted:And you shouldn't be naming your types with the _t suffix, that entire namespace is reserved by the standard. To be specific, it's reserved by POSIX.
|
# ? Nov 15, 2012 05:56 |
|
Is it POSIX? I could've sworn it was C.
|
# ? Nov 15, 2012 05:59 |
|
Ya, it is POSIX.
|
# ? Nov 15, 2012 06:15 |
|
If it's POSIX, I think it's a misreading of the spec:quote:The prefixes posix_, POSIX_, and _POSIX_ are reserved for use by IEEE Std 1003.1-2001 and other POSIX standards. Implementations may add symbols to the headers shown in the following table, provided the identifiers for those symbols either: And "_t", of course, is reserved in the table below. What it's trying to say is that any implementation that wants to extend the POSIX spec must use the suffix "_t", not that the suffix "_t" is reserved for POSIX and POSIX alone.
|
# ? Nov 15, 2012 07:02 |
|
The entire point of that section is that if an implementation of POSIX (or a future version of POSIX) uses identifiers ending with _t that conflict with an application's identifier, the application is at fault.
|
# ? Nov 15, 2012 07:38 |
|
Yeah, _t is fine in C and C++. The things C++ reserves for the implementation are identifiers starting with underscore followed by a capital letter, any identifier with two adjacent underscores, and any identifier in the global namespace that starts with underscore.
|
# ? Nov 15, 2012 08:57 |
|
The correct thing to do is to name your type whatever the hell makes sense to you, preferably something evocative of its actual purpose and application, and then be prepared to change it in the extraordinarily unlikely event that someone comes along and adds a type to POSIX named that exact same thing. Also, if this is C++ you should be declaring everything non-local in namespaces anyway. But seriously, code that you're not willing to rename a type in is code that you should have thrown away already.
|
# ? Nov 15, 2012 10:07 |
|
rjmccall posted:But seriously, code that you're not willing to rename a type in is code that you should have thrown away already. Public libraries and API breaks mean that I can't simply rename "cairo_t" for POSIX compliance in the unlikely future.
|
# ? Nov 15, 2012 14:56 |
|
Suspicious Dish posted:Public libraries and API breaks mean that I can't simply rename "cairo_t" for POSIX compliance in the unlikely future. If you're designing a library with binary stability requirements, sure, you have to be more circumspect. Of course, if it's a C library then type names aren't part of your binary interface, and if it's a C++ library then all of your public declarations should be namespaced. But designing the interface to a library with binary stability requirements is never something you should do casually.
|
# ? Nov 15, 2012 18:44 |
|
rjmccall posted:If you're designing a library with binary stability requirements, sure, you have to be more circumspect. Of course, if it's a C library then type names aren't part of your binary interface, and if it's a C++ library then all of your public declarations should be namespaced. But designing the interface to a library with binary stability requirements is never something you should do casually.
|
# ? Nov 15, 2012 20:23 |
|
Volte posted:Are you seriously suggesting that if cairo_t changes its name that it's reasonable to expect every single developer of a Cairo app that has ever existed to change every instance of it in their own code? If you make a change that causes ten thousand other people do have to perform emergency maintenance work then you probably made a lovely decision. code:
But it seems pretty silly of a change to bother making just to avoid the remote possibility that at some point in the future POSIX might want to define a type named cairo_t.
|
# ? Nov 15, 2012 21:34 |
|
Volte posted:Are you seriously suggesting that if cairo_t changes its name that it's reasonable to expect every single developer of a Cairo app that has ever existed to change every instance of it in their own code? If you make a change that causes ten thousand other people do have to perform emergency maintenance work then you probably made a lovely decision. What exactly requires emergency maintenance here? Is it typical for Cairo apps to get spontaneously recompiled and deployed against a new version? It is reasonable for Cairo to expect that a type name like cairo_t is not actually going to conflict with POSIX. If it suddenly does, then okay, Cairo needs to provide workarounds for affected users, and they need to have a plan to fix their poo poo, and that plan is necessarily going to require some amount of long-term effort from their users. I'm not suggesting that Cairo should rename core types in a point update just to gently caress with their users, and if Cairo supports a stable binary interface across versions then they obviously have to maintain that. But yes, it is reasonable for Cairo to change its interfaces with a major version bump if it sees a real benefit to doing so, and it is reasonable to them to expect their users to plan for it.
|
# ? Nov 15, 2012 22:50 |
|
rjmccall posted:What exactly requires emergency maintenance here? Is it typical for Cairo apps to get spontaneously recompiled and deployed against a new version? Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing.
|
# ? Nov 16, 2012 00:38 |
|
I'm trying to use a map as a parameter as a function, which, through reading some old stackexchange posts, I've found to becode:
|
# ? Nov 16, 2012 01:24 |
|
bomblol posted:I'm trying to use a map as a parameter as a function, which, through reading some old stackexchange posts, I've found to be You're right, there's no way to do anything with it without a name. Fortunately, adding one is easy: C++ code:
|
# ? Nov 16, 2012 01:34 |
|
GrumpyDoctor posted:You're right, there's no way to do anything with it without a name. Fortunately, adding one is easy: I'm attempting to do an assignment for a class and the easiest way to do it is to use map. Most of what I'm doing with it is encapsulated in a function, but I also needed to use it for another function, which is why I wanted to reference it in the function rather than have it created in the function. I'm new to programming so I have trouble describing what exactly I'm trying to do, but I got it working now. I feel really dumb about not realizing I can just add the name like any other parameter.
|
# ? Nov 16, 2012 01:44 |
|
Suspicious Dish posted:Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing.
|
# ? Nov 16, 2012 02:51 |
|
Plorkyeran posted:Type names aren't part of the ABI with C. Not strictly, but I'm sure they'll break debugging information like DWARF.
|
# ? Nov 16, 2012 03:15 |
|
Suspicious Dish posted:Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing. Great! Then you have nothing to worry about, because POSIX isn't going to add a type name that breaks tons of source code on Linux, and Linux would never accept it if they did. Also, this is why they put "cairo" in every single one of their type names. My original point was that there is no reason to specifically avoid the _t suffix just because POSIX "reserved" it. It is possible that following my advice could lead to portability problems. So can using stricmp. The general rule continues to be this: do what works best for you in your private code, but be more careful when committing to an API.
|
# ? Nov 16, 2012 03:58 |
|
Yeah, you should avoid using _t because your system or a new standard might want to use it. I recommend using _u for "user-defined" types that you create. (My boss still refuses to believe I was joking when I said this in the work IRC channel.) Now that our product has been released, people have asked us for OS X support. So I have started working on an OS X port. Our type uuid_t has to be renamed because that's already defined in Darwin. So I actually renamed it to uuid_u. I don't know what it'll end up being by the time the port finishes, but really we should have never used _t for everything in the first place.
|
# ? Nov 16, 2012 10:12 |
|
Just port your code to use the native uuid_t type, clearly that'll make it faster too somehow!
|
# ? Nov 16, 2012 12:59 |
|
Or perhaps you could shockingly use three more characters and call it foo_type. Be careful though: three extra characters is one step away from FooProxyAdapterFactoryWrapper.
|
# ? Nov 16, 2012 14:25 |
|
|
# ? Jun 9, 2024 00:13 |
|
Suspicious Dish posted:Not strictly, but I'm sure they'll break debugging information like DWARF. But that isn't part of the ABI either.
|
# ? Nov 17, 2012 06:30 |