You are not logged in.
Hi!
I'm trying to learn some c++ and it just took me half an hour to figure out the name of the standard library in which "usleep" is ("unistd.h"). In the end I only managed to find it by browsing different tutorials until I saw one that uses usleep and includes only 2 libraries (which I then tried out).
I've already wasted a lot of time just trying to find manual pages (NOT TUTORIALS!) for various standard functions . Where can look up those things if I don't want any tutorials? Google and all the sites I get on the first pages in searches seem to be useless in this regard, unless you're looking for a video of a random guy who's trying to figure out how to eat his own compiler in front of his webcam or stuff like that.
Am I supposed to just "grep -r" over all the header files or something? Or is there a website like the php/manual where I can search for function names, etc (and NOT get 20 pages of forum comments mixed in with the documentation)?
EDIT: OK, looks like I didn't find "usleep" because it's obsolete in windows? It would have had a man page... but now I'm confused and think, I probably should use something else. But that's just an example. Am I really supposed to research every smallest function/method/whatever for half an hour when I first need it or am I doing this wrong somehow?
edit: I think I'm definitely doing this wrong. I just wanted to "sleep for 10ms", and now I'm using threads and "chrono" and other stuff for some reason -.- I miss zsh.
Last edited by whoops (2015-02-08 14:56:37)
Offline
I often check http://www.cplusplus.com/
I don't even use C++, just C, but the C standard libraries (and many other common libs/headers) are covered there.
For example, search there for strftime.
EDIT: this is my second stop, if `man` fails. Or third really if `man <func>` and `man 3 <func>` have already failed. But in your case, what was wrong with `man usleep`? Why did it take half an hour to find a man page saying what hearder it is in when it is installed on your computer?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
google works...
http://lmgtfy.com/?q=what+header+is+usleep+in
Offline
Thanks!
google works...
http://lmgtfy.com/?q=what+header+is+usleep+in
I know (now), I though that was a different (shell program) usleep because I didn't realize there were linux manpages for cpp header stuff at first - that's good to know! I was focusing too much on that here: http://www.cplusplus.com/search.do?q=usleep -.-"
Ok, so it works about like this I guess...?
- "cplusplus.com" should have everything that works with windows too and not give me weird forum posts if I only use it for those
- "linux.die.net" or simply "man pages" should have the stuff that's linux only?
- If I can't find it there, it's probably in one of the non-std GNU libraries I'm using which all have their own homepages but some bring a man page and I should be able to find those, because I included/linked them in the first place?
- Except for sometimes when it's from X11. Then I'm screwed
Hmm, still feels like I'm doing it all wrong... probably need to try around for a few more hours and see if I get faster at finding stuff after I wrap my head around it a little better.
edit: OOOh, also I was looking for std::usleep and it doesn't seem to be in namespace std!?- I guess that's not a standard library after all? *sigh* nope, got the wrong thing again, also don't need usleep any more -.-
Last edited by whoops (2015-02-08 13:07:04)
Offline
You really want std:nanosleep in <ctime>. usleep is a Linux thing and is deprecated. There is no such thing as std::usleep
Offline
@whoops
You are mixing two things: C++ standard libraries and system libraries. These are two different things. C++ has no usleep. This function comes from a system library specific to the platform.
Tribly has suggested already two sources of standard library documentation, I'll add one more: cppreference.com. In the past they were inferior to cplusplus.com, but recently they have greatly improved.
If man is not enough for POSIX functions, search for it on opengroup.org.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
@whoops
You are mixing two things: C++ standard libraries and system libraries. These are two different things.
Yes, I think that might have been one of the roots of the problem, thanks! Also probably mixing up a lot more stuff, but already things are starting to make more sense...
Should have guessed that not everything that has an "std" is a c++ standard library...
Also something I didn't totally realize before it was mentioned here: "I really should look EXPLICITLY for the header FIRST if I haven't seen it yet!".
( Probably wasted a LOT of time and nerves searching for - among other things - combinations of code fragments, class names, what I was trying to do in general or library names)
Marking this as [solved] - for now, I should be properly equipped to waste most of my time on tracking down segfaults instead of googling classes.
Last edited by whoops (2015-02-08 14:57:16)
Offline
Hmm... that takes almost 10 Minutes to start at least. Is the extra information I get in comparison with gdb + ASAN worth it when I'm just looking for segfaults? In the time it takes valgrind to do one single run, I can can do about 5 full rounds of "looking at asan's / gdb's output, changing the code, popping in additional cerr<<debug output lines, and recompiling"... maybe with valgrind there'd be less random trial & error involved? Not sure if I want to trade that for more "sitting there staring at the screen, waiting". .. or are there other advantages?
I don't really care about memory leaks just yet. My stuff only eats ~200MB every other minute and usually segfaults or freezes LONG before I run out of RAM and then I get my RAM back (...probably - i think... because this isn't an amiga, right?)
Last edited by whoops (2015-02-08 17:21:44)
Offline
Given ASan works fine, no. If segfaults are your only concern now, I would go for higher performance and stick to the tool.
But then... why is finding segfaults such a hell if you can see where the bug is located? I'm not into ASan because valgrind provides more features, so I've only checked it few times upon introduction of -fsanitize=address into GCC. However, as far as I remember, it provides readable output comparable to this of valgrind. Am I wrong? Should be quite easy. At least compared to hell from ten years ago, when gdb was the only option - given the bug was reproduceable under it.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Maybe the problem is that I'm not familiar enough with the places those segfaults happen in and need practice? And I have no idea what "debugging" looked like 10 years ago... I went straight from: "I should write a text adventure on my C64!" to "Hey, those voxel engines look fun!". Might have missed some stuff in between. And "some" of the...errm... basics...
Didn't encounter any serious segfaults that pointed directly to my own code (maybe my compiler settings prevent me from making those... -wextra and -pedantic and such)... most of the segfaults so far were either in nvidia libgl or in that std hash thing that is called when unsorted maps are used with custom types... and then there's 3 or 4 more libraries I'm unfamiliar with in between those and the code I wrote (something from boost, or something from GLM or glew stuff) in the backtrace.
And then usually I have problems figuring out how and why my code is mistreating those libraries, which usually results in me tracking parameters I give to those libraries beginning from both sides trough ~6 classes until I can find the place where they go bad somewhere in the middle. IF I can even figure out what's "bad" about the way the variables look in the first place -.-".
Most of those libraries don't bother to mention whether they're thread-safe - when I started out with unsorted map, I though all those standard containers were, but they're not which resulted in me passing around NULL-pointers instead of vertex vectors just 1% of the time... also took me a whole while longer than it probably should have to even find out about basic stuff like "encapsulating" and using "new"... and stuff like that.
Hmm... don't know... does that sound about ok or am I doing this whole "debugging" thing wrong somehow? Maybe I should take a closer look at valgrind after all... but the last few times I tried it only complained about some "blah variable in conditional thingy or something" (yes, I know those variables are "blah", that's why I put the conditional thingy there" D: ) and other useless stuff... now that I think of it, maybe I really should learn how to read some more of all that output and how stuff is called in general...
Last edited by whoops (2015-02-09 09:18:40)
Offline
Segfaults in your own code are, suprisingly, pretty rare. Mostly because one rarely works directly on pointers and instead pass them to library functions. And this is where it's "discovered". So basically backtraces will contain¹ lots of internal library calls and then your own code. The first can be nearly always ignored (a bug in a library is a rare thing) and the search for the problem starts from the first place that refers to your code. Now the only problem is tracking the source of the bad pointer. assert (header cassert) helps a lot... just mentioning in case you don't use it yet .
If you are using threads than indeed you are encountering debugging hell. This is, unfortunely, somewhat unavoidable when it comes to concurrency.
As I said before, if ASan is enough for you, you may stick to it if it's just for finding segfaults. I don't think valgrind will help much more in this particular case.
____
¹ If indirect calls are used then most probably the backtrace will take form (library, your-code, library, your-code) or (library, your-code, library), but the rest stays the same.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Segfaults in your own code are, suprisingly, pretty rare. Mostly because one rarely works directly on pointers and instead pass them to library functions.
I strongly disagree with both of those assertions.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Oooh... "asserts"... those things will considerably reduce the amount of after-debug cleanup I have to do so my debug output doesn't bring everything to a crawl.
Thanks!
( gprof2dot.py turned out to be great too btw - I'd recommend every newbie programmer to use it from the very start. )
Offline
@ewaller:
I moderately disagree with your strong disagreement .
What's the reason you think my statement is wrong? Maybe they're a bit more common than "pretty rare", but still I don't see a place for strong disagreement. Where can occur pointers not wrapped in shared_ptr or weak_ptr? Function calls that will usually pass them to some kind of collection or store in object's field? Glue code? Where else? And while *_ptrs are not a golden hammer, they considerably reduce risk of creating dangling pointers, not mentioning nulls.
@whoops:
If you need an interactive GUI, take a look at KCacheGrind (kdesdk-kcachegrind package).
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
@ewaller:
I moderately disagree with your strong disagreement.
What's the reason you think my statement is wrong? Maybe they're a bit more common than "pretty rare", but still I don't see a place for strong disagreement. Where can occur pointers not wrapped in shared_ptr or weak_ptr? Function calls that will usually pass them to some kind of collection or store in object's field? Glue code? Where else? And while *_ptrs are not a golden hammer, they considerably reduce risk of creating dangling pointers, not mentioning nulls.
Well, my code often generate more segfaults than I care to admit -- that is my objection to the first assertion . Over the years, I have trended towards fairly heavy use of pointers. A lot of my programs are data driven with many structures that implement linked lists, callback functions, arrays of pointers, etc... I work with USB HID devices whose capabilities have to be learned through introspection. I also have done things like designing hardware with dozens of UARTS -- these UARTs have a register architecture that can be defined as pointers in a struct. If one arranges the register maps for the UART sequentially in memory space, you can create an array of these structs in memory and assign the address of the array to the starting memory location of the first UART. In other words, a lot of opportunities for FAIL. But, as to my assertion, it is not true that code I write does not make use of pointers.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Hmm... I have hardly anything except for pointers anywhere because I haven't figured out how to reach my objects around without making copies otherwise -.-
Might use mostly shared_ptr in the future though, now that I know those exist :3
(didn't use KCacheGrind so far because callgrind needs 15 minutes until my stuff even starts running and that gcc builtin gmon thing on the other hand works with hardly any loss of speed at all )
Offline
For C, whenever i forget something from the headers i quikly check this page ; http://www.tutorialspoint.com/c_standar … tdio_h.htm.
Offline
@ewaller:
What you're talking about with USARTs is not something one encounters in their avarage program . What I'm mostly encountering is desktop/server software. Sometimes very badly written, so at time it may have large amounts of pointer-related bugs. However for well written code, which doesn't let bad pointers to enter objects graph and has multithreading done right (this is the hard part
), the only location at which FAIL can happen is inside a method, when something is created there and then passed down the call tree.
Seems like different experiences from different fields.
@whoops:
I was not criticizing your use of pointers. Just pointing out where the bug symptoms usually occur. Of course you can't do imperative programming without pointers¹.
Sorry for KCacheGrind suggestion. For some reason I was sure it supports gprof. It seems it doesn't.
@exidux:
I would not trust a site that looks like a typical tutorials/info garbage can (and I doubt it's anything more than that). Looking up two random functions reveals errors already and the descriptions look like they are partially copy-pasted from other websites. Unfortunely only partially, missing lots of quite important information.
____
¹ Or, more generally, references.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline