|
The input is coming from the keyboard, into a string object with getline(). I would like to be able to display the time on screen if possible, but it isn't strictly required. The timer_create() method seems to work, but I'm having a problem with that. When I use the timer_set() function, it doesn't seem to matter what I set the variables to in the struct that's passed in, it always returns instantly. Here's the code I have for it: code:
|
# ? Apr 17, 2013 02:12 |
|
|
# ? Jun 7, 2024 17:13 |
|
You don't have to pass any flags at all, use 0.
|
# ? Apr 17, 2013 02:42 |
|
Weird. I had tried passing it NULL as I'm used to working in VS where NULL is defined a 0 already, I guess this isn't the case here though. That's done it, thank you!
|
# ? Apr 17, 2013 03:09 |
|
NULL in gcc is either ((void*)0) in C or __null in C++, neither of which will convert to an integer without warning because ints and pointers aren't the same size these days.
|
# ? Apr 17, 2013 05:57 |
|
pseudorandom name posted:NULL in gcc is either ((void*)0) in C or __null in C++, neither of which will convert to an integer without warning because ints and pointers aren't the same size these days. Not true, if you include the right header file NULL will be replaced by 0 in C++ and produce surprise behavior in certain situations. Edit: Maybe I'm actually thinking of clang. But I think it's with gcc.
|
# ? Apr 17, 2013 06:44 |
|
NULL is defined differently in different implementations, behaves differently in C than it does in C++, and requires certain headers to be included in order for it to be used. I know many people disagree, but it's just gross to use in C++, especially in C++11. Use 0 or nullptr if your compiler supports it. I cringe whenever I see NULL and I'm far from one of those "macros are evil" people.
|
# ? Apr 17, 2013 06:59 |
|
shrughes posted:Not true, if you include the right header file NULL will be replaced by 0 in C++ and produce surprise behavior in certain situations. I looked at both gcc's and clang's stddef.h before quoting what NULL is, it's ((void*)0) or __null. (Granted, they both have #define NULL 0 clauses for other compilers, but that isn't particularly relevant.) I suspect you're referring to the plethora of headers from bad third-party libraries that unconditionally #undef and then redefine NULL to be ((void*)0), which does break when used from C++.
|
# ? Apr 17, 2013 07:47 |
|
pseudorandom name posted:I looked at both gcc's and clang's stddef.h before quoting what NULL is, it's ((void*)0) or __null. (Granted, they both have #define NULL 0 clauses for other compilers, but that isn't particularly relevant.) I wouldn't be so sure about that. The only third party library we'd realistically include in the file I remembered it in is Boost. Well maybe a protobuf header or v8 header got included, but that's all the non-system header coverage we have. protobuf is a more likely culprit than v8.
|
# ? Apr 17, 2013 08:39 |
|
Hiya, I am toying a bit with C++ on my Raspberry Pi, but I am not yet very familiar with either... I am currently building an application which communicates wirelessly (not WiFi) with an Arduino. My idea was to have a C++ application looping on my rPi which handles the communication with my Arduino and have a CGI application (also in C++) which I can use to send commands from a webbrowser to the Arduino. The problem I have is that I don't know how I can communicate from my CGI application to my looping C++ application. The simplest solution would be to write my commands from the CGI application to a text file and have the C++ application check it, but I'd rather avoid this setup... Any suggestions?
|
# ? Apr 18, 2013 12:03 |
|
JasH posted:Hiya, Take a look here. In particular, you may be interested in Pipes or Domain Sockets.
|
# ? Apr 18, 2013 13:16 |
|
Jerry SanDisky posted:Take a look here. In particular, you may be interested in Pipes or Domain Sockets. That's exactly what I need; Thanks!
|
# ? Apr 19, 2013 08:41 |
|
Trying to implement Prim's algorithm to find minimum spanning trees, and not having any luck at all. Here's what I currently have: code:
code:
I feel like the problem most likely lies in the implementation of these if-statements code:
|
# ? Apr 19, 2013 22:26 |
I think your problem is that your vectors contain copies of the nodes and edges, not references. So you actually build a large tree or something like that, when you build your graph. E.g. this: C++ code:
C++ code:
One way of doing this would be to make a Graph class that has "master lists" of all the nodes and edges. Each node and edge then only reference other nodes/edges by their index into the vectors of them contained in the Graph. Additionally, each node and edge could possibly contain a pointer back to the Graph object, but I don't think that's necessary.
|
|
# ? Apr 19, 2013 22:48 |
|
nielsm posted:
Yeah, I think you might be right on that. However I'm not sure I really follow your suggestion. Are you saying that the containers should be in the Graph class and everything should be referenced by container index? Something like code:
|
# ? Apr 19, 2013 23:17 |
Papes posted:Yeah, I think you might be right on that. However I'm not sure I really follow your suggestion. Are you saying that the containers should be in the Graph class and everything should be referenced by container index? Yes. C++ code:
Doing this, there is exactly one copy of each Node and each Edge object, and you always reference them through the Graph object. This also has the advantage that a graph has a clear "identity", your initial approach, if it could have worked, would make a graph representable by any collection of nodes and/or edges, or even just a single one if the entire graph was reachable from it in some way. But that's probably not so relevant in this case. One thing you might consider is to use std::map<int,Node> and std::multimap<int,Edge> instead, depending on how you initially create your graph data structure. If you read it in from a file you probably give each node an ID or some such, and having a direct mapping from ID to each Node object, and a mapping from the outgoing node's ID to all edges starting at that node, would make set-up easier to manage, and possibly also algorithm implementation easier.
|
|
# ? Apr 19, 2013 23:37 |
|
I have a (mathematical) vector class which stores its elements in an array. However it'd be nice if I could also access the elements with their common names (v.x, v.y, etc) when the vector is a small enough size. My first try at a solution: C++ code:
It's not the end of the world, I could always add functions and use v.x(), or just use the long names v.elements[0] for mutating, just wondering if there's a better way? seiken fucked around with this message at 19:09 on Apr 20, 2013 |
# ? Apr 20, 2013 19:02 |
|
seiken, you could try creating an accessor class to wrap the "x", "y", and "z" references. You may be able to get your desired behavior using a fancy combination of cast operators. Or of course you can just give in and resort to using: code:
|
# ? Apr 20, 2013 20:51 |
|
seiken posted:I have a (mathematical) vector class which stores its elements in an array. However it'd be nice if I could also access the elements with their common names (v.x, v.y, etc) when the vector is a small enough size. Don't do that thing you're doing with the references. That const issue is just one of a slew of problems. You're making the type larger and making accesses harder to optimize, both of which I would imagine you would like you avoid for something as low-level as a vector type. Just make named accessor functions. As for alternatives, a similar question came up a few pages back I think. What I personally do is I have empty types that I use as accessors, so I can do things like my_vector[x] = 5; or my_vector[right] = 5, where "x" and "right" are just instances of those empty types and the vector type has operator[] overloaded accordingly. Simple accessor functions is more concise and I would just recommend that unless you really want or need something else. harvestsun posted:C++ really doesn't handle const-ness in as complete of a fashion as I would like. One of my few gripes with the language. It's hard to do tricky stuff like this (unless I'm forgetting something obvious). What problem do you have with const? If you're talking about propagation, it's correct that const does not propagate with a pointer or reference. It wouldn't really make sense the other way around -- why would a const pointer imply that what it's pointing to is const?
|
# ? Apr 21, 2013 06:27 |
|
That Turkey Story posted:What problem do you have with const? If you're talking about propagation, it's correct that const does not propagate with a pointer or reference. It wouldn't really make sense the other way around -- why would a const pointer imply that what it's pointing to is const? You may have a point, but I think the argument could also be made that it doesn't make sense that, in this situation, he's able to modify a const structure. You could say "well he just has a badly designed class, it shouldn't be exposing a reference to its own data". But it would be NICE (in my opinion) if there was a way to distinguish between association and aggregation. To be able to say "this is a pointer to something that affects the object's state". I've also run into situations with the opposite problem: I have some member variable which is being used internally (for performance optimization), which doesn't affect the object's state (as seen by external classes). But const-ness propagates to that variable, so I can't modify it from a const member function. I would like to able to say "this is something which DOESN'T affect the object's state", and have const-ness NOT propagate to that object... And obviously these problems could be solved by designing the class differently (or just resorting to the dreaded const_cast), so maybe I'm talking out of my rear end. But I for one think it would be cool to have a bit more control.
|
# ? Apr 21, 2013 07:56 |
|
harvestsun posted:I've also run into situations with the opposite problem: I have some member variable which is being used internally (for performance optimization), which doesn't affect the object's state (as seen by external classes). But const-ness propagates to that variable, so I can't modify it from a const member function. I would like to able to say "this is something which DOESN'T affect the object's state", and have const-ness NOT propagate to that object... That's what mutable is for.
|
# ? Apr 21, 2013 09:41 |
|
That Turkey Story posted:Don't do that thing you're doing with the references. That const issue is just one of a slew of problems. You're making the type larger and making accesses harder to optimize, both of which I would imagine you would like you avoid for something as low-level as a vector type. Just make named accessor functions. As for alternatives, a similar question came up a few pages back I think. What I personally do is I have empty types that I use as accessors, so I can do things like my_vector[x] = 5; or my_vector[right] = 5, where "x" and "right" are just instances of those empty types and the vector type has operator[] overloaded accordingly. Simple accessor functions is more concise and I would just recommend that unless you really want or need something else. Yeah, I knew it was gonna be bad for optimisation, but luckily you've come along with this v[x] idea that I really like. Thank you. Edit: in case anyone else has this problem, this is what I came up with C++ code:
seiken fucked around with this message at 14:27 on Apr 21, 2013 |
# ? Apr 21, 2013 14:09 |
|
harvestsun posted:You may have a point, but I think the argument could also be made that it doesn't make sense that, in this situation, he's able to modify a const structure. harvestsun posted:You could say "well he just has a badly designed class, it shouldn't be exposing a reference to its own data". But it would be NICE (in my opinion) if there was a way to distinguish between association and aggregation. To be able to say "this is a pointer to something that affects the object's state". harvestsun posted:I've also run into situations with the opposite problem: I have some member variable which is being used internally (for performance optimization), which doesn't affect the object's state (as seen by external classes). But const-ness propagates to that variable, so I can't modify it from a const member function. I would like to able to say "this is something which DOESN'T affect the object's state", and have const-ness NOT propagate to that object... seiken posted:Yeah, I knew it was gonna be bad for optimisation, but luckily you've come along with this v[x] idea that I really like. Thank you. Edit: There are technically potential ODR issues. If you're a pedant, the "correct" way to do the declaration of those x, y, and z names is either with externed variables or with references. It's probably unnecessary, though boost often does little dances for declaring objects like this. Here is how Boost.Units does it, for example (this macro is used for things like "meters" and "seconds" when you make a quantity like 5 * meters / second). That Turkey Story fucked around with this message at 17:05 on Apr 21, 2013 |
# ? Apr 21, 2013 16:44 |
|
That Turkey Story posted:Something along those lines should be fine. Depending on whether or not you declare an explicit default constructor will affect your ability to do those declarations of x, y, and z in that manner, at least in a standard-compliant compiler (I think VC++ lets you get away with it). Thanks for the ODR info, I've fixed that. I'm not sure what difference an explicit default constructor would make here, though. For the record I'm using gcc 4.7 with -Wall, which didn't seem to complain about either of the two things you pointed out. seiken fucked around with this message at 17:31 on Apr 21, 2013 |
# ? Apr 21, 2013 17:25 |
|
seiken posted:Thanks for the ODR info, I've fixed that. I'm not sure what difference an explicit default constructor would make here, though. For the record I'm using gcc 4.7 with -Wall, which didn't seem to complain about either of the two things you pointed out. Apparently GCC has stopped emitting an error for the initialization. It used to, and was correct in doing so. decl.init paragraph 6 posted:
The key point being that last sentence. I think it's a silly restriction, but whatever. As for the ODR issue -- it wouldn't warn/error for a couple of reasons. First, since you're not actually using the object here in a way that would violate ODR, there's nothing wrong. Second, even if you were doing so, I don't think any compilers/linkers would notice, and unless you are doing something particularly sneaky, it's unlikely that you would ever encounter any problems in this case (the case being a stateless, dummy object that is only used for its type).
|
# ? Apr 21, 2013 18:39 |
|
GrumpyDoctor posted:That's what mutable is for. Can't believe I didn't know about mutable, that's exactly what I was looking for. You learn something every day... I gotta lurk here more often. I have related question. Say I have a class Foo with some property bar which is only generated as needed (again, for performance). So I have an accessor function like so: code:
harvestsun fucked around with this message at 19:19 on Apr 21, 2013 |
# ? Apr 21, 2013 19:05 |
|
That sort of thing is the intended use case of mutable, so yes. Do keep in mind that by using mutable that way you're deciding that the fact that it's generated lazily and cached is an implementation detail rather than a part of the interface that external code should rely on.
|
# ? Apr 21, 2013 19:39 |
|
harvestsun posted:Can't believe I didn't know about mutable, that's exactly what I was looking for. You learn something every day... I gotta lurk here more often. Yeah, and this is also potentially a good use-case for boost::optional if you use boost, unless one of the reasons that you want it to be lazy is because its static type is very large. I think I remember people talking about proposing a std::optional for the next standard, too, but don't quote me on that. Either way, I find it very useful.
|
# ? Apr 21, 2013 21:35 |
|
std::optional was accepted for C++14
|
# ? Apr 21, 2013 21:42 |
|
I just ran into a weird issue trying to compile fish with Clang 3.2 on Linux. It seems to have generated an infinite loop in some std::wstring method: http://pastebin.com/aaRnBQNs. That's the result of using the AUR script. Compiling straight from the source generates an infinite loop in a completely different function: http://pastebin.com/iyP4VfsF, this time from within fish's source. GCC 4.8.0 compiles it just fine. Is this a Clang bug?
|
# ? Apr 22, 2013 01:04 |
|
I'm thinking of getting back into C++ after not using it for several years, therefore I'm looking for a good, up-to-date book on how to write C++ code. I'm especially looking for advice on C++11 as well as the recommended programming style. Are there any books you'd recommend?
|
# ? Apr 22, 2013 18:59 |
|
scissorman posted:I'm thinking of getting back into C++ after not using it for several years, therefore I'm looking for a good, up-to-date book on how to write C++ code. What have you done with C++ so far? Are you relatively noobic? Would you benefit from reading Koenig & Moo (for pre-C++11 learnings)? To go from there into C++11 mostly involves looking at the Wikipedia C++11 page and being non-retarded.
|
# ? Apr 22, 2013 19:15 |
|
This question might be a bit specific but I thought I'd give it a shot. I use a TBS TV-Tuner card with my Ubuntu system, which I just upgraded from 3.6 Kernel to 3.9RC7. TBS drivers are a mix of open source/closed source so they have to be reinstalled with every kernel upgrade. Making them is now failing with the following errors on one of the open source parts: code:
This is the file in question. My first question is, since these seem like basic syntax errors, why does it still compile fine against 3.6 and below? And secondly, since compiling seems to have failed purely due to this one file, is there anything I can do to fix it?
|
# ? Apr 22, 2013 19:19 |
|
shrughes posted:What have you done with C++ so far? Are you relatively noobic? Would you benefit from reading Koenig & Moo (for pre-C++11 learnings)? To go from there into C++11 mostly involves looking at the Wikipedia C++11 page and being non-retarded. Since then I've done mostly C and Java, so I'd say I'm probably ok at the basics but anything like proper style, using the standard library and other various intricacies is not my strength.
|
# ? Apr 22, 2013 19:26 |
|
My recommendation is to read Koenig & Moo's Accelerated C++, and see how that affects your worldview. Either it'll be useful or it'll be quick and painless. Then... there are other books on C++ that border on insanity. My personal C++ learning pattern went something like 1. Try to read inscrutable completely awful textbook written by a retard who should be driven out of academia, 2. go to college and get Koenig & Moo, get the basics of RAII and implementing data structures down, 3. go off to Haskell Oz Scheme la la land for a couple years, 4. come back to C++ with an appreciation for what looks "dangerous" in programming. There is some other stuff (a job with C#) in between. I'd say start with Koenig & Moo. That's pre-C++11, which is fine. Then write some stuff using boost::shared_ptr and boost::scoped_ptr and other deranged boost crap. Learning C++11 is pretty straightforward, except for a couple of parts, if you understand the pain it tries to solve. Edit: Of course, maybe I'm following the "You should learn programming the way I did" fallacy. However, Accelerated C++ is a universally recommended book.
|
# ? Apr 22, 2013 19:38 |
|
How is Accelerated C++ compared to the The C++ Programming Language book? I've still got an old edition of Stroustrup's book lying around and the new version is coming out soon, so I might get that instead.
|
# ? Apr 22, 2013 20:28 |
|
scissorman posted:How is Accelerated C++ compared to the The C++ Programming Language book? I second shruges recommendation of Koenig & Moo; yes it is pre-C++11, but that is OK. It is a fast read if you're already comfortable and confident, and a great refresher or tutorial otherwise. Also note, Barbara Moo Edits: revised wording in an attempt to moderate the "learn a programming language the way I did", or, more accurately for me, "like the same books as me" sentiment, which is not the goal. This is just, like, my opinion, man. Also, it turns out Moo was added originally on the Fourth Edition of C++ Primer, which was not C++11-related, so I tried to revise and clarify this bit as well. minidracula fucked around with this message at 20:59 on Apr 22, 2013 |
# ? Apr 22, 2013 20:48 |
|
Begall posted:
Try adding a "#include <linux/module.h>" to the top.
|
# ? Apr 22, 2013 21:28 |
|
VLA's too,
|
# ? Apr 23, 2013 01:42 |
|
Should I wait for the C++14 version of TC++PL?
|
# ? Apr 23, 2013 02:12 |
|
|
# ? Jun 7, 2024 17:13 |
|
Vanadium posted:Should I wait for the C++14 version of TC++PL? At that point you might as well just wait for the C++17 version!
|
# ? Apr 23, 2013 14:02 |