Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Reading the reviews at Amazon and ACCU suggests that John Lakos' book, Large-Scale C++ Software Design may be the Rosetta Stone for modularization.
At the same time, the book seems to be really rare: not many have ever read it, and no pirate electronic copies are floating around.
So, what do you think?
I've read it, and consider it a very useful book on some practical issues with large C++ projects. If you have already read a lot about C++, and know a bit about physical design and its implications, you may not find that much which is terribly "new" in this book.
On the other hand, if your build takes 4 hours, and you don't know how to whittle it down, get a copy, read it, and take it all in.
You'll start writing physically better code quite quickly.
[Edit]
If you want to start somewhere, and can't immediately get a hold of the book, I found the Games From Within series on physical structure useful even after reading Large Scale C++ design.
Interestingly, "More C++ Gems" contains a shortened (to 88(!) pages) version of Lakos' book, which can also be browsed (fully, I believe, as it belongs to the first half of the book) online at Google books.
So, enjoy everyone interested:)
Lakos used to work for Mentor Graphics, who makes EDA software. He was involved in building EDA software in C++, where they wanted to use C++ efficiently ('no more than 5% overhead over C code') and sort out how to build software on early workstations that really would take a long time to compile a large C++ application.
The book is quite a good read - it discusses a wide variety of topics, and Lakos really did know his stuff. He really comes from a background of having to get efficient code out of a C++ compiler, as well as how to set up a C++ program so it is maintainable and compiles and links reasonably quickly.
I think that Lakos has a lot of insight, and I would recommend that you read it. However, it is 'trad' C++ from a time before features like templates were widely available. My copy is not for sale ;^)
I thought the book was a good read back in the late 1990s. It was out of date back then, now about as relevant as telephone book from the 1950s.
I worked with Lakos for several years where he tried to implement these ideas. I also had my modern C++ project I built of about 2000 source files-- large scale enough, and I've built a few more since. Build times are easily reduced by parallel distributed builds, using programs like icecream. Every complier will cache opened headers-- only by doing something really outrageous any modern build tool like scons will scale to thousands of translation units without doing anything really special, with build times, including tests, takes a couple minutes from clean.
Limiting your libraries interface to a few "vocabulary types" (not the same sence as the OO concept, he means just use Int, float, string, char, and a couple of other I don't recall) is extremely poor advice to scale anything. Your build is going to be looking for a type mismatch, you don't want this at runtime just to make it easier to write a make file.
And that's largely the gist of the book-- how do I write C++ in order that it works with tools from 1993? Additionally, the Mentor Graphic project the book describes was a disaster from all accounts. Even the book itself alludes to that.
Large Scale C++ is delivered in source code form-- these are the "physical dependencies," not link libraries (and the book never mentions other more important dependencies like databases, sockets, processor architecture, etc.).
The book is full of ideas that sound good, but there are much better ways to scale up in practice. If you want to study large C++ libraries, take a look at Boost or Xerces and see what they did. They really are implementing large projects, not writing about them.
It's a little out of date (in fact it was out of date when it was written). If I recall correctly, a lot of it was about reducing dependencies which you would probably do now with templates.
Although that's probably one of the lessons to learn on large scale projects, you aren't usually using cutting-edge features and tools.
Is “Large-Scale C++ Software Design” by John Lakos a mind-provoking (but usually overlooked) gem?
Yes.
It is an excellent book and an important one from a historical point of view.
Note that to implement the practices described in the book, you need considerable discipline and agreement within the team. Here are a few things to note:
Lakos has precise definitions for what he calls "components" and "packages". These are key for large scale design. However, they require adherence to conventions for how source and header files are named and the sequence in which they are included. It is a shame that most people (including those who quote Lakos) rarely follow these conventions.
The book is all about C++ but the concepts are more widely applicable. However, because C++ is such a complex language, a large part of the book is teaching you how to use C++ effectively. If you can get past that, you can actually find it useful even if you use other languages.
Some of the prescriptions such as on the use of "name spaces" maybe considered controversial now. Many believe that name spaces should be used in a limited way in C++.
Yes, in some ways, the book is a little dated and some of it is C++ specific. Nonetheless, it offers a lot of useful advice about dealing with complexity and coupling in large programs, and most of his advice applies to any object-oriented language. I also found it very readable.
If you can track down a copy, I'm sure you'll find it worth reading. It's in my top ten list of programming books.
I read it a long time ago, but I remember getting quite a lot from it; though as MadKeithV points out, that may just have been that I knew less then ;)
Certainly from a "how do I reduce how long this takes to build" perspective it's has lots of useful stuff, especially around reducing compile time dependencies, though possibly some of it is no longer relevant, or even possible, given how much templates are used these days.
And no, you can't have my copy either :)
Related
I am a new to professional development. I mean I have only 5 months of professional development experience. Before that I have studied it by myself or at university. So I was looking over questions and found here a question about code quality. And I got a question related to it myself. How do I increase my code understanding/reading skills? Also will it improve the code quality I will write? Is there better code notation than Hungarian one? And is there any really good books for C++ design patterns(or the language doesn't matter?)?
Thank you in advance answering these questions and helping me improving :)
P.S. - Also I have forgot to tell you that I am developing with C++ and C# languages.
There is only way I've found to get better at reading other peoples code and that is read other peoples code, when you find a method or language construct you don't understand look it up and play with it until you understand what is going on.
Hungarian notation is terrible, very few people use it today, it's more of an in-joke among programmers.
In fact the name hungarian notation is a joke itself as:
"The term Hungarian notation is
memorable for many people because the
strings of unpronounceable consonants
vaguely resemble the consonant-rich
orthography of some Eastern European
languages."
From How To Write Unmaintainable Code
"Hungarian Notation is the tactical
nuclear weapon of source code
obfuscation techniques; use it! Due to
the sheer volume of source code
contaminated by this idiom nothing can
kill a maintenance engineer faster
than a well planned Hungarian Notation
attack."
And the ever popular linus has a few words to say on the matter.
"Encoding the type of a function into
the name (so-called Hungarian
notation) is brain damaged—the
compiler knows the types anyway and
can check those, and it only confuses
the programmer."
- Linus Torvalds
EDIT:
Taken from a comment by Tobias Langner.
"For the differences between Apss Hungarian and Systems Hungarian see Joel on Software".
Joel on Software has tips on how to read other people code called Reading Code is Like Reading the Talmud.
How do I increase my code
understanding/reading skills?
Read read read. Learn from your mistakes. Review answers on SO and elsewhere. When you can think back on a piece of code you wrote and go "aha! I should've done xyz instead!" then you're learning. Read a good book for your language of choice, get beyond the basics and understand more advanced concepts.
Then, apart from reading: write write write! Coding is like math: you won't fully grock it without actually solving problems. Glancing at a math problem's solution is different than getting out a blank piece of paper and solving it yourself.
If you can, do some pair programming too to see how others code and bounce ideas around.
Also will it improve the code quality
I will write?
See above. As you progress you should get more efficient. It won't happen by reading a book on design patterns. It will happen by solving real world problems and understanding why what you read works.
Is there better code notation than
Hungarian one?
It depends. Generally I avoid them and use descriptive names. The one exception where I might use Hungarian type of notations is for UI elements such as Windows Forms or ASP.NET controls, for example: using btn as a prefix for a Submit button (btnSubmit), txt for a TextBox (txtFirstName), and so on but it differs from project to project depending on approach and patterns utilized.
With regards to UI elements, some people like to keep things alphabetical and may append the control type at the end, so the previous examples become submitButton and firstNameTextBox, respectively. In Windows Forms many people name forms as frmMain, which is Hungarian, while others prefer naming it based on the application name or form purpose, such as MainForm, ReportForm, etc.
EDIT: be sure to check out the difference between Apps Hungarian and Systems Hungarian as mentioned by #Tobias Langner in a comment to an earlier response.
Pascal Case is generally used for method names, classes, and properties, where the first letter of each word is capitalized. For local variables Camel Case is typically used, where the first letter of the first word is lowercase and subsequent words have their first letters capitalized.
You can check out the naming conventions and more from the .NET Framework Design Guidelines. There is a book and some of it is on MSDN.
And is there any really good books for
C++ design patterns(or the language
doesn't matter?)?
Design patterns should be applicable to any language. Once you understand the concept and the reasoning behind that pattern's usefulness you should be able to apply it in your language of choice. Of course, don't approach everything with a "written in stone" attitude; the pattern is the goal, the implementation might differ slightly between languages depending on language features available to you. Take the Decorator pattern for example, and see how C# extension methods allow it to be implemented differently than without it.
Design Pattern books:
Head First Design Patterns - good beginner intro using Java but code is available for C++ and C# as a download (see "book code and downloads" section on the book's site)
Design Patterns: Elements of Reusable Object-Oriented Software - classic gang of four (GOF)
Patterns of Enterprise Application Architecture - Martin Fowler
If you're looking for best practices for quality coding in C++ and C# then look for the "Effective C++" and "More Effective C++" books (by Scott Meyers) and "Effective C#" and "More Effective C#" books (by Bill Wagner). They won't hold your hand along the way though, so you should have an understanding of the language in general. There are other books in the "Effective" series so make sure you see what's available for your languages.
I'm sure you can do a search here for other recommended reading so I'll stop here.
EDIT: added more details under the Hungarian Notation question.
I can't speak for everyone else, but in my experience I've found that the best thing I learned about making readable and/or in general better code was reading (and ultimately cleaning) a lot of other people's code. Some people may disagree with me but I think it's invaluable. Here's my reasoning:
When you start programming, its difficult to determine what is crap vs. not crap vs. good. Being logical, rational and extremely intelligent help in making good code, but even those factors don't always contribute. By reading others works and doing the dirty work, you'll have gone through the experience of what works and what doesn't. Eventually, you'll be able to mentally navigate those minefields that others had to cross and you'll be prepared to avoid those identical minefields.
By reading other's works, you gain insight into their mind and how they tackle a problem. Just from an architecture or technique aspect, this can be very useful to you whether their
tactics were good or bad. By reading other peoples successful or unsuccessful implementation, you've gained that knowledge without putting in the actual time it took them to learn it.
Design patterns are extremely useful. Only time and experience with them will help you in knowing what the appropriate pattern for whichever problem. Again, read other peoples' code for this if they've successfully built some pattern that may be useful for you.
When dealing with extreme problems where people's work falls short, you learn to research and dive into the internals of whatever system/language/platform/framework you're working with. This research ability on your own is very useful when all else fails. But you'll never know when to start looking or for what until you get through the crud of other people's work. Good code or bad, it's all valuable in some form or fashion.
All these notations and formats and nomenclature are helpful, but can be learned or implemented rather quickly and their payoff is fairly substantial. By reading code from other people, you'll develop your own style of logic. As you encounter other peoples work and the tremendous amount of effort it takes to read through, you'll learn what logical pitfalls to avoid and what to implement the next time for yourself or even how to fix bad code even faster.
I've never felt as if I was a great programmer. Not to say I'm a bad one either, but I feel confident in my abilities as my experience has taught me so much and my ability to adapt to every situation is what makes me a solid programmer. Learning from other people and their code has helped me. Whether their work was good or bad, there's always something you can take from them and their experience, add it to your memories, knowledge, etc.etc.
Ask other people to read your code! Try and see if you get a fellow coworker or similar to have a code review with you. Having someone else comb through your code and ask you questions about your code will provide new insights and critiques to your style and techniques. Learn from your mistakes and others.
Just to give you a bit of encouragement, I've been a professional programmer for 30 years now, and I still find reading other people's code very difficult. The major reason for this, unfortunately, is that the quality of the code follows Sturgeons Law - 90% of it is crap. So don't think it's your fault if you find it hard going!
The biggest improvement in readability of my code came about when I started liberally using white space.
I found this article on Joel on Software to be very relevant to the Hungarian notation debate.
It seems that the original intent of the notation was to encode type information that wasn't immediately obvious- not whether a variable is an int (iFoo), but what kind of int it is- such as a distance in centimeters (cmFoo). That way, if you see "cmFoo = mBar" you can tell that it's wrong because even though both are ints, one is meters and the other is centimeters, and thus the logic of the statement is incorrect, even though the syntax is fine. (Of course, I personally prefer to use classes such that that statement wouldn't even compile, or would do the conversion for you).
The problem was at some point people started using it without understanding it, and the world was cursed with lots of dwFoos and bBars.
Everyone needs to read that article- Making Wrong Code Look Wrong
How do I increase my code
understanding/reading skills?
Reading code is like dancing by yourself. You need a partner, and I suggest a debugger.
Stepping through code with a debugger is a true, lively dance. I recommend getting a quality, open-source project in the language of your choice, and then step through with the debugger. Concepts will come alive if you ask "why did that happen?", "what should happen next?".
One should ultimately be able to reason about code without a debugger; don't let it become a crutch. But that said, it is a very valuable tool.
Reading code is a lot like reading literature in that you need to have some insight into the author sometimes to understand what you're looking at and what to expect. They only way to improve your comprehension skills is by reading as much code and possible and trying to follow along.
I think a lot of what is mentioned here is applicable to coding...
Reading and understanding skills are a question of time. You will improve them as you get more experienced. Also depends in the quality of the code you are reading.
Keep in mind that sometimes it's not the best idea to learn directly from what you see at work. Books will teach you the best practices and you will be able to adapt them to yourself with the experience.
I am reading the Head First Design Patterns at present and it is very useful. It presents the information in a novel way that is easy to understand. Nice to see they have a C# version for download.
There will always be struggles with reading code unless you are Jon Skeet. This isn't to say that it is a big problem, rather that unless you can eat, sleep, breathe in that programming language, it will always take a little time to digest code. Looking at other people's code is certainly a good suggestion for helping in some ways but remember that there are many different coding conventions out there and some may be more enforced than others, e.g. interface names start with an I to give a simple example. So, I guess I'm saying that even with Visual Studio and Resharper, there is still a little work to understand a few lines of code since I can't quite write out sentences in C# yet.
1) Educate yourself. Read relevant literature.
2) Write code
3) Read code
4) Read relevant blogs.
Visit http://hanselminutes.com . He is a programmer from microsoft. Even though you don't program on microsoft stack, it's good to read through. There is a podcast in there that answers this question.
Another suggestion is to make sure you have the appropriate tools for the job before you start digging into a piece of code. Trying to understand a code-base without the ability to search across the entire set of files is extremely difficult.
Granted, we very rarely have the entire set of files, especially in large projects, but whatever boundaries you draw, you should have good visibility and searchability across those files. Whatever lies outside those boundaries can be considered 'black box' and perhaps lies outside the scope of your grokking.
There are many good open source editors including Eclipse and the CDT. Spending some time learning how to effectively create projects, search across projects, and enable any IDE-specific tooltips/helpers can make a world of difference.
I've studied C++ as a college course. And I have been working on it for last three years. So I kinda have a fairly good idea what is it about. But I believe to know a language is quite different from using it to full potential. My current job doesn't allow me to explore much.
I have seen you guys suggest studying a open source project and perhaps contributing to one too. So my question is, can you suggest one(of both?) to start with that is simple and doesn't overwhelm a starter.
I was in the same situation 12 years ago when I got my first programming job out of college. I didn't do any open source but I managed to gain a lot of practical and advanced C++ knowledge by reading books (the dead tree kind).
In particular, there was an excellent series by Scott Meyers which I feel helped the most in turning me from newbie to professional:
Effective C++: 55 Specific Ways to Improve Your Programs and Designs
More Effective C++: 35 New Ways to Improve Your Programs and Designs
Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library
The topics in these books range from beginner to advanced. It took me about 2 years working in C++ to understand every chapter in these books, so don't be disheartened if it goes over your head at some point... just try reading it again later :)
If you're willing to climb the very steep learning curve, I would think that you could do worse than studying parts of the boost libraries. I don't think there is another similar body of C++ code out there that is pushing the boundaries of what can be done in C++.
re project selection: you'll want to hack on something that has some relevance to you, otherwise it's just unpaid work. i might suggest eg. Pure, but will you find enough interest?
re advanced code: see Boost
Obviously learning something like this does not happen overnight; You can study existing open-source projects like other posters suggested. However, I have one more suggestion: I suggest joining one of the big IRC c++ channels (for example #c++ on efnet or freenode). Of course most of the questions / discussions going there are basic; however quite often interesting discussions and questions come up. Over the several years I've learned quite a bit just by participating in channel discussions.
My main advice would be that you do not need to stick to C++ to learn technique.. Study Erlang, Lua, and Haskell (lots of others). You will learn so much from these language that you can apply in C++.
Google protocol buffers is a very well written C++ application that sticks to the features of C++ that are proven in the industry -- i.e., they don't go over the top with features that cause headaches for using the code.
In terms of learning to use C++ to its full potential, well the full potential is often hidden. There are very few exceptional C++ programmers, even in the open-source community. So I suggest you read some books. Like the books from Scot Myers and Herb Sutter (all 6 of em).
Boost is an amazing library and has a lot of good code, ranging from simple techniques to very advanced techniques. It definitely touches all of the bleeding edge of C++ idioms. The problem with boost is, it doesn't work well with modern IDE features (code-completion being the main problem), and it has a LOT of symbols :D. It is the place to learn about generic programming and template meta-programming, the former represents the most advanced and immediately-usable idioms, and the latter you can skip for the immediate future.
Apart from the Scott Meyers books DSO has already suggested: Participate on SO and try to answer other people's C++ questions. If you don't know the answer, wait a little until some good answers are posted. You will probably get some idea where the gaps in your knowledge are and you could do some more reading to fill those afterwards.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know that C++ is a very complex language that takes many years of practice to master.
Taking that into account do you know of a small project (around a 1k of loc) that tests all of C++ major features (inheritance, pointers, memory management, etc).
The thing is I'm a Java/Python programmer and I really want to learn C++ so I've been studying C++ for a while but haven't tested anything of what I've learned beyond small exercises.
I want to take all of that knowledge and put into practice.
Doing this alone you will obtain many harmful habits. It's much better to get an internship with a company that has high competence in C++ development and train under guidance.
C++ is like a grenade without a safety pin – looks cool and you've heard that all "real professionals" use it, but you don't know when it is to explode. A tremendous amount of features that can be used for good or for evil without knowing whether it's really good or evil. That's why guidance is a must here.
A memory manager. That should get you thinking about:
free store management
pointers (of course!)
inheritance (you will want your driver code to use this)
templates (another way to pass the manager around -- driver #2)
designing user defined data structures (a memory block)
efficient use of standard container(s)
algorithms (to move around, figure out empty blocks, defragment)
Effective C++ and More Effective C++
Other than that, pick a (small?) personal project you want to write and do it in C++. You are not going to learn C++ by reading a 1000 line project.
I'm not sure about anything that tests all major features. There are a lot of them, and some are rarely used together (templates and virtual functions come to mind. Both achieve a form of polymorphism, so you often use one or the other depending on your needs.)
A suitable project in that it'd touch on all the important features might be something apparently simple like writing a correct container class, similar to std::vector or std::list. Ensure exception safety, iterator validity, the appropriate time complexity on all operations and every other requirement specified in the standard.
The problem with this, as well as most other projects, is that you won't really know when you're done. Making a resizable array might take 50 lines of code, and 20 minutes of your time. And then a beginner would think he's done. Making it exception-safe requires you to be able to spot all the places where the class might be thrown into an inconsistent state by an exception.
That's a kind of general problem with C++. It's easy enough to think you get it, and the compiler certainly won't notify you of aspects you've forgotten to handle. So you might think your code is perfect, and yet it'll crash for all sorts of odd special cases.
As sharptooth said, for a language as messy as C++, writing code on your own is risky. It is easy to fall into the trap of "I've written some code, it compiles and it seems to run. Therefore it is correct".
Of course you could post your code here or on other sites for review, or maybe just supplement your coding with reading the docs for actual high quality C++ code (most boost libraries tend to have comprehensive documentation, specifying both the rationale for various design decisions, and how it safely handles all the weird special cases that tend to crop up in C++. The C++ standard itself would be another excellent resource, of course. In either case, these might help you determine what problems to look out for)
When I was learning C++, I used it to write my own language for writing Colossal Cave style adventures. Like most computer languages it never saw the light of day, but it did teach me a lot about C++.
Whatever you choose the thing to avoid when learning C++ is GUI programming, which is a trap which will drain all your gumption and probably teach you bad C++ habits in the process.
I'd recommend creating a text based game. That really helped me firm up my C++. Doesn't take too long and you can exercise all the features you want. Come up with the game yourself. It is more fun that way.
Another great idea is to write a simple mathematics library, supporting Vectors Matrices etc.
But with todays libraries, that is only of academic use.
In order to learn C++ it is useful to look at a lot of well written C++ code.
I think the Qt library is quite nice for this so I suggest: Write an Qt application.
Look how they use C++ and create your own graphical components in a similar fashion.
Ideas:
- Stock chart viewer widget that connects to one of the financial websites and scrapes history data.
- Simple Excel like spreadsheet widget.
Depends on what area you want to work in. But nothing worth doing correctly comes in at less than 1000 lines of code.
If you are going to be writing games then try writing a Tetris clone.
If you think you will be using sockets etc then writing a simple chat/irc client would help.
Do you have a specific itch that needs to be scratched? When was the last time you thought "this sucks, I could do better?". Can you do better?
I would recomend writing a Tetris clone.
You can learn a lot of c++ concepts with this and learn a 2d library like SDL or maybe even OpenGL throgh SDL.
It is always good to have a project with visual results and at the end of it you can play it.
There seem to be two themes coming from the answers:
You need to pick a project that might involve more than 1K LOC in order to get the true experience of the project.
You need to also pair up with an experienced C++ developer, who can help you think through problems and avoid pitfalls associated with the language.
You can get around both of these by swing by sourceforge.net and signing up to help with an existing C++ project. As long as you don't mind your code being open source, you should be able to find an existing project to learn from plus experienced developers who can help by reviewing your code and offering guidance.
An interactive world:
A matrix where each position can be a Void or a Being.
A Being is something with a few attributes: age, Time left, gender, neigbor connections, etc. Capable a few interactions: fights, having sex and kids, friendships, etc. Some have special Skills, depending on their fathers (inherited trades)... like ability to kill, ability to make food,, etc...
Possible outcomes of those interactions and skills are changes on the self attributes, or creating offspring (when possible), or change neigbor attributes.
At each iteration, print the matrix as symbols/numbers on the console (depending on the attributes, etc), starting from a Biblical iteration 0 (initial conditions of your choice... you're God here).
Now you got some real-life pattern simulator, and learned something about inheritance, polimorfism, virtual functions, instantiation of classes, etc.
I would suggest a simple text editor would be a reasonable goal.
It's a problem domain that you have a good grasp of.
You have memory management issues, library class reuse issues (stl/curses?), pointer issues, and lots of options where derived classes can be used.
For polymorphism, perhaps, you can have the editor read from a keyboard, or suck commands in from a text file.
There is another good one.... dealing with files.
You don't have to cross platform it. You don't have to open source it. You don't have to show it to anyone. You don't even have to finish it. It can be an exercise just for you.
If you're learning fron a book, it must have plenty of well-thought-out exercises you can implement and learn from. Also check out the university sites and their C++ labs / assignments.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is anyone out there using D for real world applications? If so, what are you using it for? I can't seem to find anything big on the web written in D.
Despite the lack of known big users, D seems like a very promissing language to me, and according to TIOBE, it's fairly popular.
I do bioinformatics work in D. For me, the key thing about D is that it takes a very level-headed approach to tradeoffs and recognizes the principle of diminishing returns.
Unlike C++, which adheres rigorously to the zero-overhead principle, D allows features that may have a small performance/space cost if they make the language a lot more usable. These include garbage collection, a monitor object for each class, runtime type info, etc.
Unlike Ruby, Python, PHP, etc, D tries to be almost as fast as C, even if it is less dynamic and slightly more difficult to program in than scripting languages.
The result is a language that is optimal when both development time and execution time matter about equally, which in my field is most of the time.
Similarly, D takes a very level-headed approach to safety vs. flexibility. It assumes that programmers basically know what they're doing, but do make mistakes.
Unlike C and C++, it assumes that you don't want to use pointers, unsafe casts, manual memory management, etc, everywhere in your code, because they're error prone, and assumes that you don't want to sift through multi-page template error messages when you screw up just to use resizable arrays.
Unlike Java and other bondage-and-discipline languages, D assumes that sometimes pointers, unsafe casts, manual memory management, etc. are a necessary evil, and assumes you're smart enough to handle real templates, operator overloading, etc. without writing obfuscated code. It also assumes that you may screw up and access an array out of bounds, but that the programmer knows best what tradeoff should be made between safety and speed in any given situation. Therefore, whether arrays are bounds checked is simply determined by a compiler switch.
I'm using D for my research work in the area of computer graphics. I and others have had papers published in our fields based on work done using D. I think it's definitely ready for use on small to medium sized research projects where performance matters. It's a nice fit for research work because often you're starting from scratch anyway, so you don't have much legacy code to worry about integrating with.
Another popular area for use seems to be web services. Hopefully someone else can comment who's in this space, but there too I think the idea is that performance often really matters so you want a compiled-to-the-metal language. Services are often fairly small, self-contained processes, so interop with large amounts of legacy C++ code is not really necessary or useful. Thus D can get its foot in the door.
I think D will continue to gain grass-roots followers in this way -- on smaller projects that for whatever reason can afford to ditch the C++ legacy in order to gain a programming language that's much more enjoyable to use, and perhaps more productive too.
But until there's a huge number of grass-roots users there won't be much in the way of big corporate users I suspect.
I know of one smallish company that have sent a mail server product to the market. They had at least 2 people working full time on the project.
Also, a major player in the IT business have several employees using D in larger internal projects.
Further I know of one company seeking venture funding, several (at least 4) employees in smaller companies using D either part or full time, and at least a couple (including me) actively seeking opportunities in the consulting market.
I've probably left out a few that I should have known about, and probably some I haven't heard about, but that still exists, as the above is more or less those I know myself via the community.
A small percentage of my current income comes from D.
I use D for web development and it proved quite a lot more productive compared to C/C++.
There are a lot of frameworks based on ruby/php/python, of course.
But when you want to develop something unique that also have to be as fast as C and nearly as easy as to program with as you do in many script languages, then D is a good choice.
I use D for a hardware in the loop (HIL) test environment. This is for software tests in the automotive area. D can be used here, because as a system programming language it is possible to be used in real-time programs (IRQ handlers in a linux real-time extension RTAI-LXRT).
With the ongoing port of SWT/JFace I plan to do more and work in D which I would have been done in Java before.
Facebook announced that they are using it in production as of today.
I'm using D in research about compile time code translation. The advanced templating combined with tuples and mixins makes code translation much easier and allows for code translation to be done during compile time without requiring a separate tool.
There are some examples of physicists using D to enhance their programs with meta-programming in D.
video - Conference talk, could not find source site of physicist use.
Our whole (high-traffic) network infrastructure is based only on D1 and tango. We are a young startup company in Berlin: sociomantic.com
My current work task is a system to translate C# to D. This is as part of a for profit project to develop a software system.
Well, I have written a couple of research papers in D as have others.
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=13337
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=9466.
It seems that Remedy Games has a large D2 codebase for their games (cf. Using D Alongside a Game Engine by Manu Evans - DConf 2013).
They are a big company, knowing that a big company is using D is very good.
A lot of the games released by ABA Games are written in D 1.x, though I imagine the console ports had to be rewritten in C++.
I've written quite a few game prototypes in D, but I'm not sure if that qualifies as 'real world' since I wrote them for my own benefit and have never released any of them.
I wrote (and I am still maintaining and developing) a software for the conversion of tester protocols from various hardware testing stations to a standardized output format for traceability and stuff like that.
All together over 5k lines of code, written with D 1.x and the Phobos library.
D is so easy to learn, and disregarding some pitfalls (in the Phobos library) a real joy to program.
I used D for my research project on developing a global optimization algorithm. I applied it to the problem of training neural networks. It's up to you whether you want to call this "real world".
I wrote a wrapper script that builds DGCC on OS X
http://github.com/davecheney/make-gdc-apple/tree/master
I'd love to hear from other DMD programmers out there
I use D2, the second standard of the version. I wrote real-time applications (3D engine, for instance).
The language gets more and more powerful each day. D is very pragmatic and all the embedded features, especially the metaprogramming paradigm, makes it far over C++, in my opinion. The syntax is clearer, you can use the strength of functional programming through functions such as filter or reduce, and one of the most important feature: you can use all the C libs.
Definitely my favourite language, and I’m pretty sure it will be a spread used language.
I suppose we can read something into the lack of immediate answers to this question and that is that not many/any of the acive stackoverflow responders are using D. I was also a little surprised about the level of its ranking in the TIOBE listing that you link to.
Having said that, Walter Bright has been working on the language for quite a number of years now and I think he has quite a number of `followers' who remember what a good job he did with the Zortech C++ compiler back in the '90s. I also note that the language appears to be leaning towards the functional direction now.
The D's official website enumerates the organizations that are currently using D.
http://dlang.org/orgs-using-d.html
The D wiki also provides a list of organizations, but it's outdated.
Just watch carefully DConf talks.
DConf 2013
DConf 2014
Almost all people there work for some company, and they use D at work.
I am starting a project to rewrite some of our internal tools from Perl to D. I chose D because I'm pretty excited about the design philosophies of the language. I've been programming for a long time and used a lot of languages, from assemblers to high-level (mostly C) to scripting languages (mostly Perl), and D is the first language I've been enthused about learning in many years.
I decided to move to a compiled language for one main reason - security. Functionally, Perl works quite well for the toolset I work on, but it's insecure - anyone that can run a script can also read, copy and create their own modified version of the tool. (And they do.) I know there are circuitous methods to get around this problem (sort of), but to be honest I don't have enough hours in the day to manage all of that and still get my primary job done.
I started a ray-traced renderer in D with ldmd2.
http://palaes.rudanium.org/SubSpace/render.php