Ask Slashdot: Best Programs To Learn From? 329
First time accepted submitter camServo writes "I took C++ classes in college and I have played around with some scripting languages. We learned the basics of how to make C++ work with small programs, but when I see large open source projects, I never know where to even start to try and figure out how their code works. I'm wondering if any of you have suggestions for some nice open source projects to look at to get an idea for how programming works in the real world, so I can start giving back to the FOSS community." Where would you start?
Pick small libraries/utilities (Score:5, Insightful)
Re: (Score:2)
Compare to a large project, like Sage. There are lots of bugs, lots of features on the todo list, and an active, thriving community. There's documentation and community support to help new developers
Re: (Score:2)
I think the first desire is to "try and figure out how their code works" and find some nice open source projects to look at to get an idea for how programming works in the real world." I'm not sure that a large, buggy project would be the best option for this.
Once these are satisfied, though, such a project would be a good place to address the overall objective: "start giving back to the FOSS community."
I generally start with small programs to learn how do something so that looking at a larger one isn't ov
Re: (Score:2)
Anything + Doxygen (Score:2)
Whatever you start off with, give it a run through doxygen [doxygen.org] first. Esp. with C++, this will save you a lot of time looking up definitions of objects and other stuff buried in various (and overridden) header files.
Write a large project yourself (Score:2, Insightful)
Re: (Score:3)
And as your codebase grows, I strongly recommend taking breaks to read books on design patterns, clean code, unit testing, etc. Without learning the various architectural techniques out there, any codebase will devolve into spaghetti the moment you try to implement any mildly interesting features. However, you won't see the obvious need for those techniques until your project reaches that point.
Re: (Score:3)
FTFY
Re: (Score:2)
That was the whole point of this question: he wants to learn from master practitioners before making mistakes i.e. drowning.
camservo: I don't know of a particular program to learn, but I found great pleasure reading the JVM's source code. I do recommend to be suspicious of everything you read. You may find code that doesn't look right, e.g. excessive use of Header Interfaces [martinfowler.com]. The best thing to do is ask other people why they used it there.
Re: (Score:2)
Really good question. (Score:5, Insightful)
Re:Really good question. (Score:4, Insightful)
Re: (Score:2)
The other way you can win some trust is in the realm of documentation. For instance, if you discover (via code) that there's some incredibly useful option that's mentioned nowhere in the docs, you can write a blurb on it and see if they're interested in adding it to their online docs.
Re: (Score:2)
Re:Really good question. (Score:5, Insightful)
I have often wondered the same thing. People tell me, "read the code and submit patches!" It may sound like hand-holding to experienced developers, but many new coders could really use an introduction to becoming a part of a community around a project.
I wouldn't call myself an open-source developer by any means, but I've submitted patches to open source projects on occasion, and it wasn't too hard, even back when I had no experience with any large program. The trick is in the approach. Here's my recommendation:
Don't just download the code and start reading trying to figure out how everything works. That's when you drown in too much information, become frustrated, and decide you can't do it. It's a large, complex program. If you don't have a purpose, you can't navigate it. Instead:
Re: (Score:2)
I heard something very similar about going in for a job interview.
If you say, "I'm willing to do anything, and learn what I don't know!" you've just created more work for everyone else (very likely the person interviewing you) as they will need to spend time figuring out what to have you work on.
If you say, "I have an interest/experience in X, and based on what your group does, I'd be interested in starting to try something with Y, unless you have something else pressing for me to start with" you've just sh
Re: (Score:2)
Nothing big, but it was a bug I experienced, I patched it locally, but by pushing it upstream I never had to repatch my own version with the same fixes.
That's exactly the type of thing I advocate. Not only does it mean that things work better for you, but you also get this nice sense of satisfaction from knowing you've contributed something to the whole, instead of just using the work from others. It's a valid sense of satisfaction too. Even if you don't become a regular contributor, you've given back something that was valuable.
Also, if you start off like that and if you keep submitting small patches to the same program, you start to become more and mo
Re: (Score:2)
Indeed... :-)
Start with slashcode (Score:3, Funny)
And then do the opposite.
Works every time.
Re: (Score:2)
Re: (Score:2)
Node (Score:2)
Wesnoth (Score:2)
Re: (Score:3)
Step through the code with a debugger too, of course. I find that "ok, I'm gonna try to make the code do this", i.e. starting with a specific goal, setting breakpoints, and stepping through the code is the best way to get comfortable with an unfamiliar codebase, no matter its size.
Very true. With very large projects, this really is your only option.
Easy! (Score:4, Informative)
For C++ I would suggest Qt [nokia.com].
For C I would suggest Minix3 [minix3.org].
Re: (Score:2)
Re: (Score:2)
Qt is very cleanly written and well commented where it matters. Most F/OSS code tends to have no comments of any sort, for some reason.
Re: (Score:2)
MINIX started as an educational tool and now is also being developed to be an OS for real world use on low resource systems. So it has thorough, useful comments, and it compiles into a stable and usable system. I learned a lot from it.
From stuff I've seen... (Score:4, Funny)
If you want examples of 'real world' programming, take a bowl of spaghetti, add some additional ingredients that you wouldn't normally expect to see in spaghetti, and then fling the whole thing against a wall.
That's what the vast majority of modern day code looks like, especially if the organization that wrote the code tried to outsource the development effort 'to save money' at some point during the dev cycle.
Spaghetti sells ..... (Score:2)
I'm going to get a little bit snarky here, but there's a point to it.
Why go to all this effort to learn a language like C++ these days, if you're not already employed someplace where you're clearly able to earn more income fixing/building something specific for your employer that requires that skill-set?
As one of my good friends just realized, he's been struggling to master Objective-C so he could learn to code a few apps for the iPhone and iPad -- but he's "going about it all wrong", ultimately. After all
Re: (Score:2)
I've seen that on those outsourcing/freelancer project websites. These days, one contractor at a client site will just subcontract all the other tasks onto one of those websites. You can never tell who actually did the work.
There used to be a trade term for startup companies bidding to for a contract only to subcontract the work out - "dutch windmills". Each company would take enough work to keep a group of engineers going at full speed and then pass the work downstream for someone to complete. It would con
Re: (Score:2)
> ... and then fling the whole thing against a wall.
Don't forget to pick everything up, dump it into a paper bag, light the bag on fire, and leave it at the entrance to the Marketing department. They sold the client a "candle light dinner"... let them deliver it.
Re:From stuff I've seen... if you mean businesses (Score:4, Interesting)
If "the real world" means the corporate world, do this. Take an application you don't care about and don't know how to use, and assign yourself a bug to fix, and give yourself a deadline pulled from a RNG.
Code is developed this way:
Start developement
Shrink the team
Fire all but 1 guy who does all the maintenance
Bring in contractors
Add a few people
Shrink the team
Fire the 1 guy who knows everything
Scramble to find someone who knows the application
Bring in contractors
Select any step above at random
I'm not trying to be funny. End result is quirks, inconsistencies, inexplicable code blocks, bugs, performance issues, and all kinds of other bad things.
Re: (Score:2)
You work at crummy companies I guess. The code at the organizations I've been at has been, for the most part, pretty good (Of course with a few crufty corners of crap code that every project has)
Most of the code where I work is okay, but I've certainly encountered code that I called "spaghetti code with meatballs". Some of it was around for years because everyone was afraid to touch it.
Goals? (Score:2)
Why do you want to do this? Are you just curious or trying to get something on your resume? This is an important question because a diversity of advice can be given without knowing the answer to this.
I'm not an expert and probably not qualified enough to answer this question, but in my experience, you can't just start looking at a large project on your own and expect to get anywhere. As an example, any undergrad level OS course will only dig you skin-deep into the Linux kernel. The way I imagine things to w
Re: (Score:2)
Irrlicht 3D engine (Score:2)
Graphical Text Editors (Score:2)
The code *you* wrote a year ago ... (Score:5, Insightful)
Re: (Score:2)
This is typical of all creative types. They never like the work they did last year. This has nothing to do with the quality of the work and everything to do with the psychology of creativity.
Scratch your own itch... (Score:2)
The best program to learn from is the one that you have some idea for improving, something you use and can make better. The first patch I made to open source software was for bash. At the time I was use HP-UX at work and Linux and HP-UX at home. The KSH under HP-UX would do "tab expansion" with Esc-Esc, and it was killing me going between Esc-Esc and Tab (neither worked on the other). I first tried making a macro for it, but found that I had to change the C code to make it work.
So, don't look for the pr
Your Own (Score:4)
A tip I always give:
1. Start writing something you want. (It'll keep you interested)
2. Google the SMALLER hard parts (String Parsing, data models, misc functions, etc)
3. Use that code. (No one is going to blame you for copypasta on your own project.)
Eventually you'll understand how the copied code works. After a few projects you end up writing your own version because you're better than "that guy you copied from".
Re: (Score:2)
3. Use that code. (No one is going to blame you for copypasta on your own project.)
Just be careful, if you distribute whatever you come up with in this process, that you follow the licensing rules - if it's GPL'd stuff you're copying, release your stuff under the GPL. If it's BSD, do whatever you want with it. If it's just on a forum somewhere, it's probably public domain and you can do what you want.
trace startup of mplayer (Score:2)
... at least back in the days i was amazed how deep you could bury the int main() {}.
i think that the best one would (regardless of the source code qualities) an open source application that does something you are really interested in, or just find a simple usability problem or a simple bug.
then post your bugreport up on their tracker/mailinglist and offer to help with a patch with a little bit of help.
even if you don't manage to implement it, you might come up with a test case or at least discussion which
one step at a time (Score:3)
1. Find a program that interests you.
2. Find something you want to change about it.
3. Hack away.
4. Find a different program that interests you.
5. Goto 2.
Trying to understand all of the code in a large project may be an impossible task, and it's frequently not necessary if you just want to make a simple change.
how programming works in the real world
There is no such thing. Each project will have its own structure and idiosyncrasies, and even after looking at 10 of them you will only understand those 10, not "the real world" in general.
Re: (Score:2)
1. Find a program that interests you. 2. Find something you want to change about it. 3. Hack away. 4. Goto 1.
Sorry, your code was inefficient. I had to fix it for you.
The compiler would have optimized it anyway.
Experience Is key. (Score:2)
It is often a bad idea to teach yourself how to program by looking at someone else's code.
Why?
1. You are not getting best practices. There are coding guidelines that should be followed but there are always exceptions, and not everyone knows all the rules and will break them needlessly. I am a profession coder with decades of experience... But I am still learning new and better ways to do things and I look back at my old code and I go what the heck was I thinking. And the answer was Oh yea, I needed to ge
Re: (Score:2)
Best practices are good, but reading code is its own education. Reading forces you to think and care about how the code communicates its own organization and intent. In turn, this spurs you to really think about what your own code means instead of just what it does. While books and articles on best practices can teach you a lot about code formatting, language-specific idi
I couldn't recommend this more: (Score:2)
Re: (Score:2)
Re: (Score:2)
I came here to post this exact link. It's a great book, and a great way to learn how 25 different popular applications are architected, how they work, how they grew to be what they are today, and they show you the value of having planned your apps for the future. (or at least how they were forced to confront the future at least once in their histories. )
For someone just starting out, any of these giant apps would seem daunting to start reading the source at main(). I'd recommend reading the book first, th
Programming in the Large (Score:2)
Since the 90s I have been a proponent of reuse, not only internally to an organization, but as interface libraries with a low bar to entry. I found this book to be seminal in identifying issues that show up in large programming efforts and general dependency decoupling for interfacing:
Large Scale C++ Software Design by Lakos
Code Reading (Score:2)
My advice: don't just look at apps (Score:2)
Don't go looking for "best programs to learn from." You won't "get" it. Each program has its own focus, and unless you are very interested in the subject matter, you'll just gloss over the important parts. I've worked with tons of other libraries and I always find myself asking "Why the hell can't I just do X" or "Why they hell did they do it this way?" Invariably it was because the library was written with a mindset with a better understanding of the topic and contract than my own. When I say "contract" I
Here's my method (Score:2)
Pick any project that's not *too* huge, and preferably not GUI, because that adds many more layers to try to understand. What I do, when I've started new jobs, was to look at the main{}, and see what it does, to try to get an overview. Then I'll look at whatever calls I need to understand for what I've been asked to work on. I'll continue working at the highest level, until I get to what needs fixing or enhancement: that way, I try to avoid breaking something else by seeing where the changes will correctly
Good luck with that (Score:5, Insightful)
I think you already do.
This is the difference between C and C++: in C, whatever the code of a function says it does, it does; in C++, whatever the code of a function says it does is subject to be changed by templates, operator redefinitions, etc. Because of this it is impossible to make small changes without reading and understanding the entire codebase first.
Basically, if you want to get involved in a large C++ project, you either have a tour guide or very good documentation or make the huge investment of learning the entire superstructure of the program before making any changes to any part of it. It's kinda interesting how C++ encourages this kind of greater dependency between different parts of a program than C.
Re: (Score:2)
That's true, if the program was poorly architected from the outset. In my experience, it's very unusual to encounter someone abusing operator overloading in ways that aren't very localized, or are otherwise counterintuitive.
C++ allows you to do bad things, but if you're playing with anyone but yourself, there are threats of physical harm to consider before you make life difficult for everyone else.
Re: (Score:2)
If you're looking for a big project... (Score:2)
...take a look at the source code for Luminance-HDR. While it's buggy, I've been pleasantly surprised at how well-organized it is, and it should prove to be very hackable.
mediawiki (Score:2)
I'm not a big PHP fan, but I had to dive into mediawiki and found it to be very well organized. It made me realize that PHP didn't have to be bad :)
QMail (Score:2)
I suggest QMail. The code isn't that big, it's well written, and it's modular (lots of executables calling other executables). I wrote some authentication plugins for it about 10 years back and as I recall it wasn't too hard to figure out what was going on.
Kernel (Score:3)
The Linux kernel is a piece of good crafted code in comparison with most desktop projects. This is mainly due to working community processes which Gnome or Freedesktop.org lack. Before someone marks this as flamebait. There is and was a lot of bad communication between parts of the Gnome community e.g. between Ubuntu and Gnome, between users of Gnome and the GnomeShell team etc. And arguments like: "It is open source take it or leave it" where send out, which is nonsense as software is not only designed by the programmers and designers, but also shaped by user needs. So the feedback of users is important. That's why Ubuntu became so popular in the beginning. Lately that changed a bit and therefore their loosing user base.
However, there are projects with a good community model such as the Linux kernel (even if Linus is sometimes a little harsh). The Apache projects seems to have a good process too and Apache HTTP is a smaller project so it might be a good starting point.
The best thing right not to help the desktop FOSS community would be real community building. There are some efforts with common conferences from Gnome and KDE, but there are still big issues for users to be heard by the developers. So help building community processes is even more important than coding.
Re: (Score:2)
Duh, FOSS makes it easy (Score:2)
techniques (Score:5, Funny)
the most important thing is to have techniques that allow you to find your way. the language doesn't actually matter, but it does definitely definitely help if the code is documented in some fashion. i tried, for example, to work on fontforge with my usual techniques, and the code was so incredibly dense and uncommented that it was absolutely impossible to understand. but, exceptions aside, here's a starting point for getting into large projects:
* use vi. do not use graphical editors. do not use emacs :e # to go _back_ to the file you were originally editing (after using ctrl-])
* get a damn big monitor (or 2 monitors). open xterms at 80x60, as many wide as you can get.
* use a multi-window desktop manager (i use fvwm2 and i run a 6x4 grid: that's 24 desktops.
* be prepared to open (and background) up to 200 simultaneous files, across multiple windows.
* make sure that you open the files from the *root* of the project.
* open the files "by name", explicitly, so that you can do "jobs | grep {filename}"
* run "ctags -R" - it is your friend. then use ctrl-] on a function you don't know, and read about it.
* remember to use
* be prepared to print out the ENTIRE codebase, and flip through it, off-line, very very quickly.
* be prepared to do page-down, page-down, very very quickly, through as many files as you can stand
the main thing to do is to get a vague map of the code into your subconscious, as quickly as possible. then you will go "i've seen that before..." and you stand a chance of being able to hunt for it and find it.
you *don't* have to memorise the entire codebase - you *don't* have to even understand all of it. but you *do* need to at least have the techniques which will allow you to jump to wherever it is that you want to go.
ultimately, though, you need a goal. what, exactly, is it that you want to achieve? if you have no goal, you are pissing in the wind.
i added NT Domains Security to freedce - that's a good, simple goal. FreeDCE is 250,000 lines of code, and very well laid-out. it was therefore quite straightforward to add 6,000 lines of code to do NTLMSSP. took a couple of weeks.
i added python bindings to webkit - that's a good simple goal (ok, it was horrendous, requiring over 12 different skillsets, including c, c++, python, perl, autoconf, gtk, python c modules, IDL files parsing - the list just went on and on). webkit is a massive project, and also very well laid-out and structured. the first version of the python bindings took about 8 weeks, and the 2nd (faster, better) version took only 2. the reason why the 2nd version took only 2 weeks is because i hunted down the mozilla xulrunner IDL file parser, hunted down python-gobject's code generator, adapted the xulrunner IDL file parser to understand the webkit IDL file-format (2 days), then spent the rest of the time hacking codegen.py to spew out the data types from webkit, and to create a standard python c module.
so you say "you don't know how to get familiar with a free software project", well, i am not - i wasn't familiar with webkit, but that didn't stop me. i wasn't familiar with xulrunner, but that didn't stop me. i wasn't familiar with python-gobject's codegen, but that didn't stop me. i just got on with it, and just trusted that the surrounding code would do its job, and trusted that the bit of code that i picked up could be adapted.
so in many ways, tackling a large codebase is more about overcoming your own fear and feelings of inadequacy. sometimes not even i can do that, and sometimes i can.
Re: (Score:3)
Re: (Score:3)
Maybe because you have never tried working without an IDE?
Sorry, I've been coding for 40 years. I've done everything from punching paper tape, and keying punch cards, to filling out optical scanning documents, edlin, ed, vi (but never emacs), Turbo $(LANGUAGE), Visual Basic from 3+, Eclipse, and so on all the way up through the latest editions of Visual Studio. I'm intimately familiar with many various ways to write programs. And I have to say the IDEs absolutely rock in terms of productivity. Autocomplete, the ability to have every manual at your fingertips i
You can help others learn on WiBit.net (Score:2)
Just start (Score:2)
There is no way to learn without failing. Start something small and let it grow as needed while trying to maintain quality.
Doxygen is your friend (Score:2)
Understanding a code base that is large and new to you is a challenge.
Especially if it is crappy architecture.
What I do is use Doxygen to map out the code base.
Once mapped, you can use your browser to get the basic layout and workings of the project in matter of minutes.
Google Doxygen, and install it (install graphviz/dot first).
Then play with it.
You will be glad you did.
Especially the dependency graphs are a life saver:
use them to identify and weed out header file dependencies, and you can orders of magnit
You have much to learn grasshopper! (Score:2)
Most of the more
Develop a personal Framework (Score:2)
Aspirations of tackling a large coding project are usually less than imagined. Most successful projects start as the kernel of one programmer who strikes the landscape and envisions how things will work. Then they flesh it out to a degree and move on or otherwise becomes involved in managing the code base. At some point they leave or move on. So the majority of new or junior programmers end up interpreting that code base, usually with little or no documentation. In the best of all worlds they attempt to int
Whatever you're interested in, and step through (Score:2)
Take something you like and/or use. Or something like what you do if possible. Load it in a debugger, trace in to main or the language equivalent, and see where the calls go. You'll see quickly how the files are organized (if they are organized).
The more familiar you are with the app, the more sense the code will make.
Choose several - I've found every project has its own style, organization, or other peculiarities.
As someone said above, the real world is not all open source. Most of what I've seen in op
Get the book ? (Score:2)
There is a book on that subject called:
Code Reading: The Open Source Perspective: Open Source Perspective by Diomidis Spinellis
ISBN-10: 0201799405 | ISBN-13: 978-0201799408 | Publication Date: June 6, 2003
Tcl/Tk source (Score:2)
For C code, I recommend reading the source to Tcl/Tk [www.tcl.tk]. It's beautiful code, well-structured and portable.
Re: (Score:2)
Following up on myself... as a bonus, most of the important C functions and data structures have man pages.
DOOM (Score:2)
For C, learn from the best, and that would be John Carmack. :)
http://doom.wikia.com/wiki/Doom_source_code_files [wikia.com]
Discussion on Reddit about good code bases (Score:3)
There was some discussion of this on Reddit [reddit.com] a while back.
I second Mike Pall's comments. The Lua codebase is relatively small, and your puny brain can probably understand all of it from top to bottom. Other systems, like GCC and GHC, would be much more challenging to understand completely.
The GNU Standard C Library (Score:3)
It is extremely well documented what every function in there is supposed to do, and most of the functions are actually written in C. Though I suggest you avoid printf. You'll learn things about C that you really can't learn any other way.
Some of the other standard unix utilities are also pretty good. I seem to recall that reading the source to awk and vi were very enlightening.
Re:The kernel (Score:5, Insightful)
Off you go
Oh yeah, Good ol' BSD kernel. The best one in town.
Re: (Score:2, Interesting)
No, it isn't. It's been maintained by a sequence of cliques via contributor-mentor relationships and is badly documented, with certain subsystems displaying a horrible lack of orthogonality.
Linux, on the other hand, is well worth studying - it's really been written for practical engineers by practical engineers, arranged and documented so that anyone sufficiently competent can contribute. Don't forget the O'Reilly books on understanding the kernel and writing device drivers.
Re:The kernel (Score:4, Informative)
Um the "kernel" (by which I assume you mean Linux) is not written in C++.
It should be, but it isn't.
I mean, it's full of objects with derivation and virtual functions, and structs on which constructors and destructors have to be called for everything to remain in one peice. Seems odd not to use a language which is every bit as efficient, has a familiar syntax and yet does a large number of common tasks automatically and without errors.
Oh, and the other thing is that linux has the vtable inside the classes rather than a vptr, presumably because they syntactic overhead of a vptr is too high. C++ is by default significantly more memory efficient in this regard.
Re: (Score:3)
Re: (Score:3, Insightful)
The special treatment that C++ gives to constructors and destructors makes things harder, though. They don't return any value. If the constructor fails your only option is
Re: (Score:2)
Re:The kernel (Score:4, Insightful)
I finally found you. I hate you. Not personally, but this kind of thinking. A TCP class raises a disconnected exception, the stream class raises an interrupted exception, the object class raises an error exception, and the application says "There was an error." What kind, and how do I fix it?
OOP error handling and code reuse can be done well, but it generally is not. The basic idea of a "return code", giving some sort of information or context about the error, is very important. Even if it's just preserving the exception information to bubble up.
I've collected probably a hundred Microsoft-specific error messages that don't mean what they say they mean. They add helpful text to say what you might fix, but that's a red herring. There is an underlying error which is caught but not bubbled up, and it leaves the user with little or no idea what to do.
You have to have the idea, if not the implementation, of returning something to the user.
And, I take exception to your assertion that exceptions don't make the code slower. Each class wraps its code in try/catch and has to deal with fairly complicated Exception objects in many cases. Did the file open? fopen() returns null, and you can get more information if you want it. OOP says you have to make an exception object and run catch code, and go up the stack and to the exceptions there.
Code that experiences no exceptions will not be noticeably slower, but code that relies on exception processing to try alternate methods or re-try will be a lot slower. This from someone who looks at C++ code at the (dis)-assembler level.
Re: (Score:3)
Exceptions actually add a lot of overhead (it used to be 20%+, I haven't benchmarked in a few years). And while they're useful in some circumstances, they can also lead to a lot of spaghetti code. They also require a very specific form of programming- everything needs to be a smart pointer, or you will leak. In addition, they aren't really all that readable- they're a glorified goto where the label can be multiple levels up. In general they should be avoided, and cases where they are used should be eva
Re: (Score:3)
The special treatment that C++ gives to constructors and destructors makes things harder, though. They don't return any value. If the constructor fails your only option is to throw an exception. But C++ exceptions make code execution slower. Another alternative is to check the object through a method after construction, which a lot of STL objects do, but that's kind of messy.
Well, bear in mind that what was true 5 years ago is not necessarily true now.
The C and C++ non RAII ones are pretty similar in struct
Re:The kernel (Score:4, Insightful)
Exception enabled code used to be slow, especially in GCC. These days it is much faster.
Yes, exception-enabled code is fast, until you actually have to process an exception. Merely enabling exceptions typically also doubles the footprint of code, without a single actual exception handler or exception thrown, simply because the compiler has to emit cleanups to unwind each and every stack frame, from each and every scope, in case an exception *is* thrown somewhere. Code to actually work with exceptions then add on top of this.
Given the outrageous expense of processing exceptions, anything that resembles normal or non-exceptional should never be handled as an exception. This includes things like TCP FIN (*all* connections end with it), EOF, poll timeouts, event processing (yes, I've seen it done!), not to mention regular C library and syscall error returns. I've seen people wrap things like mkdir() with an error check that throws an exception if it returns -1. Well, the program that used the wrapper of course used mkdir() all over the place just to make sure a directory existed (and to create it if didn't). So it got an exception in the TYPICAL case. Every call point was then wrapped in an exception handler that, well, did nothing! I consider that borderline incompetent. But I digress. On the other hand, the things that really ARE exceptional - heap corruption, out of memory, deadlock detection, out of file descriptors, thread creation failure, unmounted root fs, kernel resource errors, etc, etc - there's nothing to be done about. And any attempt to do anything at all will likely aggravate the problem. In the case of say a heap corruption, or stack overflow, it's unlikely that attempting to process an exception is going to do anything more than crash. And serve only to make it harder to debug because it crashed somewhere in a runtime routine that walks a table with links to procedures to unwind the stack, not the place where it was actually first discovered. You're IMO better off simply calling a panic routine that stops then and there rather than attempt to do anything else that would only aggravate the problem further (possibly leading to real data loss - "oh, a corrupt heap... lets try to save the document before bailing" or similar brilliance). Between the two, and given the footprint overhead and the inevitable abuse in the absence of adult supervision, it's best not to use them at all. The sliver of cases between the two where exceptions are useful is so narrow that it's no longer meaningful formalism.
Note that you typically don't get away from the error check of a return value. Instead you move it further down the tree, to the position where you conditionally throw the exception, instead of at the return of the function. The difference is there, but trivial.
Re: (Score:3)
If "being uninitialized" is a well-defined state for the object, then I agree. For example, you can have an empty container, an empty string, or a disconnected TCP "connection" (fd==-1 is a natural state, and instead of init() you have connect() or bind()). OTOH, I frequently discourage my co-workers from reusing value-objects. It's just as easy to say homeAddress=StreetAddress(street,unit,
Re: (Score:3)
Maybe you're doing too much in a constructor? You could offload anything that can fail into a method that can return a value.
That's kind of the point of a constructor. If it *has* to be called to make the object valid then putting in the constructor makes it impossible to forget.
But I do Java/C#, so I'd throw the exception and tell the customer to buy more hardware.
Not even that. Whole classes of bugs simlpy won't happen, leaving more time to optimize the rest of the code.
Re:The kernel (Score:4, Interesting)
Re:The kernel (Score:5, Insightful)
Um the "kernel" (by which I assume you mean Linux) is not written in C++. It should be, but it isn't.
There are reasons [gmane.org] the kernel doesn't have any c++ in it (link is about git, but same deal for the kernel).
Re: (Score:3)
There are reasons the kernel doesn't have any c++ in it (link is about git, but same deal for the kernel).
Those reasons are so terrible. It amount to:
Xorg, not the kernel (Score:3)
Re: (Score:2)
Here are some more links:
Re: (Score:2)
Your message is a confusing. PostgreSQL is written in C, with a few Perl scripts for building the code and some other scripting language bits. Were you trying to say only writing C++ code is worthwhile?
I work on PostgreSQL projects and hacking the source code for a living. The development community has extremely high standards, but there is a pretty formalized process to bring new people up to speed. The recommended way to start is doing patch review [postgresql.org]. Reading a patch that's similar to what you're inter
Re: (Score:2)
Your use of "it", such as "if it were C", reads like you're talking about PostgreSQL--when apparently the "it" you actually mean is the person's experience.
There's no formal bug tracker for PostgreSQL. Following the mailing list traffic about it on pgsql-bugs [postgresql.org] is the only way to know what happened right now. It's hard to justify the overhead of a better bug tracking system when the project has a zero tolerance policy for bugs, meaning there's very few of them open at any time. It has been looked at [postgresql.org] and th
Re: (Score:2)
JavaDoc comments in your code would be a good start.
Re: (Score:2)
That and with Class Diagrams for C++ are incredibly useful for getting a hierarchy view of the code. XCode comes with a tool as do at least some versions of Visual Studio (I have Ultimate at work, so I'm a bit spoiled) and there are at least standalone versions that are FOSS (some may integrate, but I'm a bit out of touch with FOSS IDEs). The diagrams take a while to generate, but simplify the code down and put it in a dependency drawing so you can see the dependency chain. You also can open any files from