Master C++ Programming with Open-Source Books(ossblog.org)
ossblog.org
Master C++ Programming with Open-Source Books
https://www.ossblog.org/master-c-programming-with-open-source-books/
105 comments
I find Stoustrop's writing quite the opposite, concise, informative and a touch entertaining at moments. But I can understand why you might see it otherwise, to each his own.
You may find his book "Principles and Practice Using C++" [1] more accessible.
[1] http://www.stroustrup.com/programming.html
You may find his book "Principles and Practice Using C++" [1] more accessible.
[1] http://www.stroustrup.com/programming.html
As someone who knows a number of programming languages more or less fluently, I found that book to be invaluable when I started working in C++ professionally. It's not a book to teach you programming or any of the General concepts of OOP, FP, or the like. It is, however, a great resource for learning C++ assuming you know the high level concepts already.
While it's rather introductory, "A Tour of C++" is a much more concise book. Read that and then maybe look at some Scott Meyers books (I haven't read "Effective Modern C++" but the other entries in the series are good and I'd expect this to be a good place to start after the tour book).
>thinking it's the K&R of C++.
You nailed it with that analogy though.
K&R is a "first book" and important historically, but right now it's an atrocious book if you want to learn current C and this has been the case for a long, long time.
Sometimes these first books don't withstand the test of time.
You nailed it with that analogy though.
K&R is a "first book" and important historically, but right now it's an atrocious book if you want to learn current C and this has been the case for a long, long time.
Sometimes these first books don't withstand the test of time.
That's not entirely fair - it's not just about being first.
K&R may be archaic now, even obsolete. However, for decades it has was held up as a an example of what a good technical/language book could be. You don't have to agree with the assessment to agree with the fact - that this was touted as a very good technical book for various reasons.
There never was a "K&R" of C++. That's not unusual, many languages are in the same boat. If you want to go back to the "firsts" it would be a combination of The C++ Primer and Strousoup, putting them together gave you something that was both more and less that K&R was for C.
K&R may be archaic now, even obsolete. However, for decades it has was held up as a an example of what a good technical/language book could be. You don't have to agree with the assessment to agree with the fact - that this was touted as a very good technical book for various reasons.
There never was a "K&R" of C++. That's not unusual, many languages are in the same boat. If you want to go back to the "firsts" it would be a combination of The C++ Primer and Strousoup, putting them together gave you something that was both more and less that K&R was for C.
I first studied the K&R in the early 90s, and it was already terrible by then. Especially if you wanted to teach anything other than quirky systems programming.
From the software engineering point of view, almost every single code example is terrible. Abundant implicit casts depending on the OS, loops that leak buffered reading between iterations, etc etc.
Just no. Never, ever recommend K&R to anybody as a general programming book neither for C or in general. Only the intro descriptions of language characteristics and important functions of the standard library are any use, and then again even these are extremely obsolete now.
From the software engineering point of view, almost every single code example is terrible. Abundant implicit casts depending on the OS, loops that leak buffered reading between iterations, etc etc.
Just no. Never, ever recommend K&R to anybody as a general programming book neither for C or in general. Only the intro descriptions of language characteristics and important functions of the standard library are any use, and then again even these are extremely obsolete now.
Sure, it was a snapshot in time. By the nineties it was already old. I'm not defending it at all as book to learn C from.
There is, however (like or not), a reason we even now say "X is the K&R of Y". As such it is a bit silly to claim that the only reason K&R succeeded as well as it did was by being early....
There is, however (like or not), a reason we even now say "X is the K&R of Y". As such it is a bit silly to claim that the only reason K&R succeeded as well as it did was by being early....
True, but it maintains a cult following, for lack of better wording.
> but right now it's an atrocious book if you want to learn current C and this has been the case for a long, long time.
Strongly disagree.
Strongly disagree.
What's a good book for learning current C?
Ben Klemens' 21st Century C is good.
I can recommend "C Programming: A Modern Approach 2nd Ed."[1].
1 - http://knking.com/books/c2/index.html
1 - http://knking.com/books/c2/index.html
Even though it was published in 2008?
Absolutely!
There's not a whole lot that's changed in C11, (C is kind of "done" at this point) and there's not been a newer book that teaches the language so well.
There's not a whole lot that's changed in C11, (C is kind of "done" at this point) and there's not been a newer book that teaches the language so well.
That's his reference book. It's not designed for systematic learning. It's designed as a reference, as in "cut-and-paste stuff". You want one of his other books, meant to take you from zero to literate in not just C++11 but programming in general: https://www.amazon.com/Programming-Principles-Practice-Using...
Bjarne's text is just that, a text, not a read. It should be referred to as a reference. I completely agree with all your accounts because I did EXACTLY what you did a few years ago. I'm still working through the book, but I kinda said "eph it" and enrolled in a solid course. Worth the G I spent? absolutely. THat said, the 'effective' and 'Exceptional' books are well written.
Maybe I suffer from Stockholm syndrome since I read all Bjarne's books, but I really like the book, to the point of having multiple editions of it.
Would you please define which of his books you read? Just saying "Stoustrop's book" doesn't really help anybody.
He wrote a few books, as you can see here: http://www.stroustrup.com/books.html
Edited original comment. Sorry for the confusion.
That book works well as a reference, as a supplement to the C++ Primer, 5th Edition.
Not to be confused with C++ Primer Plus.
Not to be confused with C++ Primer Plus.
I think you'd like Accelerated C++ by Koenig and Moo.
It's by far my favourite C++ book and it's nice and short.
One drawback may be it's age; it's 17 years old. On the other hand it was way ahead of it's time and good writing doesn't get old.
(ps. I quite like Stroustrup's books but to each their own)
One drawback may be it's age; it's 17 years old. On the other hand it was way ahead of it's time and good writing doesn't get old.
(ps. I quite like Stroustrup's books but to each their own)
[deleted]
Some of of these books are not "open source" [0]. For example, "The Boost C++ Libraries" book clearly gives a non-commercial license [1] as does "How to Think Like a Computer Scientist" [2]. I haven't checked them all but a lot of look to be under a free license [3] [4], so maybe the majority of them are actually under an open source license.
[0] https://en.wikipedia.org/wiki/Open-source_license
[1] https://theboostcpplibraries.com/
[2] http://greenteapress.com/thinkcpp/index.html
[3] http://opendatastructures.org/ods-cpp/About_this_document.html
[4] http://www.network-theory.co.uk/about.htmlThe best place to master c++ is StackOverflow. Many people share knowledge accumulated from experience and they explain much better than Herb Sutter or any gray beard people in C++ community.
Another important thing, no matter how many books you read, you can't be a master without actually solving a lot of problems.
Another important thing, no matter how many books you read, you can't be a master without actually solving a lot of problems.
SO is a great resource but it's about as good a place to learn something as Wikipedia is to do serious research.
Questions from learners are often poorly formulated and then poorly answered. Since many people are just looking for getting their code to run or finishing their homework, this sort of stuff just piles up without getting fixed.
If you're trying to learn anything non-trivial, don't rely on SO alone.
Questions from learners are often poorly formulated and then poorly answered. Since many people are just looking for getting their code to run or finishing their homework, this sort of stuff just piles up without getting fixed.
If you're trying to learn anything non-trivial, don't rely on SO alone.
SO launched a new feature recently called Documentation. Check out the C++ section [1]. Personally, I'm enjoying it a lot. I think they managed to find a very concise way of showing the basic grips of a language and some advanced ones. Most stuff are through examples, which I think works better when you're already familiar with the language, and just wants to do some specific thing. From time to time, I find myself on the page surfing through the C++ topics.
[1]: http://stackoverflow.com/documentation/c%2b%2b/topics
[1]: http://stackoverflow.com/documentation/c%2b%2b/topics
There is a lot of wrong and dangerous advice on Stack Overflow about C++. I also disagree that it is good as a learning tool. The C++ Annotations book linked to will much better place to master C++. As it turns out, 'gray beard people in the C++ community' actually know the intricacies of the language, and you better learn them too otherwise you're never going to be productive with it.
please show some 'wrong or dangerous' advice on SO with more than 10 upvotes.
I've just skimmed through "How to Think Like a Computer Scientist: C++" and I've got to say it seems like the best intro to programming and C++ I've ever seen. Definitely better than Bjarne's "Programming Principles in C++" and others.
Bjarns books are dire.
Programming Principles and Practice using C++ 2nd Edition (god what a horrible title to type) is a strange book. It has a lot of great info in it but it is a very hard read. The first 4 or 5 chapters are ok albeit too wordy. But then after that they seem to rocket up in difficultly. Not impossible but damn hard for a beginner.
Yes, he writes standards for a living and it shows.
Disagree completely on the latest ed
Yes Allen B. Downey is an excellent technical writer. His books are very good.
Can you ever really master C++? I've been at it more than 20 years and I'm still delighted to learn new things about the language and the library.
And that's the real problem with C++. You can spend 20 years solving real problems with it and still feel like a noob when you take a look at "idiomatic" template code from the standard headers.
On the other hand, people like Scott Meyers have spent their lifetime and careers explaining its intricacies, without solving any real problems.
On the other hand, people like Scott Meyers have spent their lifetime and careers explaining its intricacies, without solving any real problems.
Yep,the language it self became a problem.The designer and experts should(Which I hope) make the language easy to use without any mental burden.
Make the language easy to use without any mental burden? But you do realize programming is not easy, especially when you're aiming for high performance. How can you make a language easy to use "without any mental burden"? Programming is hard, programming well and with performance in mind is even more so. Some things you just can't magically make easy.
You can program with "performance in mind" in C and the big difference will be that the problem itself will be the obstruction, not the language.
In C++, you fight with the language first and then face the problem.
In C++, you fight with the language first and then face the problem.
I actually feel the exact opposite when I program in C. C is so bare that most of my time is spent building the correct constructs I need to solve my problem. C++ on the other hand has a decent set of high level features that makes it easier for me to focus on the problem.
You can write a C++ program to solve a problem that looks almost exactly like the C program you would write. But C++ brings a couple of nice features, like resource management with constructors/destructors and type-safe data structures that you just can't have in C.
How can that be true, if C++ is (almost) a superset of C? Surely you can do anything in C++ identically to C, in the worst case scenario.
What fight are you having with C++?
Problem? On the contrary, it's one of the wonderful things about the language and community. It's alive and evolving.
And what's with the Scott Meyers ding? I think of him mostly as an educator and in that respect he's very accomplished.
And what's with the Scott Meyers ding? I think of him mostly as an educator and in that respect he's very accomplished.
I think it boils down to a wider philosophical question that deserves some discussion in software development circles. The question basically is "Should we get obsessed with our constantly evolving tools at the cost of devoting significantly less time to understanding the intrinsic problems we are trying to solve?".
Each time I hear a discussion between programmers, it is always these arguments of whether build tool A is better than build tool B, or whether VCS A suits their workflow better than VCS B, or how cool is the latest language feature. I never see programmers discussing the merits of their solutions, regardless of the language or environment.
Each time I hear a discussion between programmers, it is always these arguments of whether build tool A is better than build tool B, or whether VCS A suits their workflow better than VCS B, or how cool is the latest language feature. I never see programmers discussing the merits of their solutions, regardless of the language or environment.
We talk about tools all the time because it's fun and it's something we all have in common. Every once in a while something like clang comes along and it can change everything.
What we don't have in common are the exact problems we are trying to solve. That's where design patterns and other higher level concepts become useful. Because the problems and solutions are so context specific, they happen on mailing lists. Tool discussions, on the other hand, are more generic and I think that's why you see them in more places.
What we don't have in common are the exact problems we are trying to solve. That's where design patterns and other higher level concepts become useful. Because the problems and solutions are so context specific, they happen on mailing lists. Tool discussions, on the other hand, are more generic and I think that's why you see them in more places.
Unless we are speaking of Go, all programming languages are like that.
Sometimes people think they know their favorite language, but most would fail a language puzzle quiz.
Sometimes people think they know their favorite language, but most would fail a language puzzle quiz.
> Unless we are speaking of Go, all programming languages are like that.
Right, I'm sure Go is the one and only language out there without a single pitfall or quirk.
Right, I'm sure Go is the one and only language out there without a single pitfall or quirk.
> Sometimes people think they know their favorite language, but most would fail a language puzzle quiz.
But that is especially true for C++. People who are confident in knowing it often lack the fundamental C knowledge (i.e. pointer arithmetic, the complete C type system, the subtle conversion and promotion rules, etc.), but would insist on knowing C++ very well just because they know how to define classes, virtual functions and throw a shared_ptr or a vector or a map at every problem.
But that is especially true for C++. People who are confident in knowing it often lack the fundamental C knowledge (i.e. pointer arithmetic, the complete C type system, the subtle conversion and promotion rules, etc.), but would insist on knowing C++ very well just because they know how to define classes, virtual functions and throw a shared_ptr or a vector or a map at every problem.
And most people that say that they know C and how simple the language is, cannot differentiate between their compiler extensions and what is written in ANSI C.
Nor can they correctly point out all the cases of expected semantics, UB and implementation specific behaviour.
Regarding the fundamental C knowledge, part of it just leads to bad C++ code.
Nor can they correctly point out all the cases of expected semantics, UB and implementation specific behaviour.
Regarding the fundamental C knowledge, part of it just leads to bad C++ code.
You can spend 20 years solving real problems with it and still feel like a noob when you take a look at "idiomatic" template code from the standard headers.
It can be misleading to think of standard header code (especially template code) as "idiomatic C++". It'd be better described as "idiomatic standard-library-implementor C++", since the folks implementing stuff in std are operating under a whole set of constraints that don't affect ordinary C++ programmers. Arbitrary user-defined symbols that could be in scope, user-provided types that could have overloaded operator-comma, etc.
It can be misleading to think of standard header code (especially template code) as "idiomatic C++". It'd be better described as "idiomatic standard-library-implementor C++", since the folks implementing stuff in std are operating under a whole set of constraints that don't affect ordinary C++ programmers. Arbitrary user-defined symbols that could be in scope, user-provided types that could have overloaded operator-comma, etc.
Yes, and I think this same principle is roughly true for a lot of programming language implementations. It's one of the reasons it pays off to know some details about your implementation -- People should always keep this in mind.
Designers and implementors are traditionally under a very different set of constraints than "average users" (who in this case are programmers), though their goals do align. But this leads to very different set of assumptions, optimizations, and tools being available. Things that would generally be overkill are suddenly very viable and worthwhile goals to achieve (e.g. micro-optimizations add up repeatedly so they're very worth it, vendoring is much more useful to control dependencies/scope of bugs), and vice versa.
So I wouldn't be extremely miffed if you look at libstdc++ or libcxx or <whatever> and find it somewhat unkempt or gross compared to average code. It's often very much not-average. In fact it's likely given careful understanding of the constraints that code exists under -- you'd come up with similar results.
Designers and implementors are traditionally under a very different set of constraints than "average users" (who in this case are programmers), though their goals do align. But this leads to very different set of assumptions, optimizations, and tools being available. Things that would generally be overkill are suddenly very viable and worthwhile goals to achieve (e.g. micro-optimizations add up repeatedly so they're very worth it, vendoring is much more useful to control dependencies/scope of bugs), and vice versa.
So I wouldn't be extremely miffed if you look at libstdc++ or libcxx or <whatever> and find it somewhat unkempt or gross compared to average code. It's often very much not-average. In fact it's likely given careful understanding of the constraints that code exists under -- you'd come up with similar results.
What do you use it for?
It's such a complex language brimming with idiosyncrasies that I'd be inclined to really test anyone claiming to be a master. The standard is one thing, then there's the compiler you're using...
It's such a complex language brimming with idiosyncrasies that I'd be inclined to really test anyone claiming to be a master. The standard is one thing, then there's the compiler you're using...
I claim on my CV to be an "expert" C++ programmer, but I'm quick to point out the curve that I imagine being graded on. At least in my head, there's an implied context around someone's C++ proficiency. An expert Java programmer should be able to answer most questions about Java. An expert C++ programmer should simply get to the "I have no idea" answers when the questions get interesting.
I do Java, .NET and C++ consultancy and I bet an Java expert would fail most Java Puzzle questions.
Also a programming language is not used alone and C++ standard library is quite tiny when compared to Java's standard library.
Also a programming language is not used alone and C++ standard library is quite tiny when compared to Java's standard library.
That's true, but there's virtually no aspect of the C++ language or library that doesn't have a wealth of "gotcha" questions one could ask.
Even parts of C++ that are "normal user" features can be remarkably tricky. I know tons of C++ programmers who I'd happily trust to write code for me who would fall flat on their faces if asked to explain some detail of what std::forward does with an rvalue reference parameter bound to an lvalue argument.
There's a reason why a very common recommendation is to pick a subset of C++ and stick to it, and I've never heard of such a recommendation for any other language (outside of perhaps for portability reasons).
Even parts of C++ that are "normal user" features can be remarkably tricky. I know tons of C++ programmers who I'd happily trust to write code for me who would fall flat on their faces if asked to explain some detail of what std::forward does with an rvalue reference parameter bound to an lvalue argument.
There's a reason why a very common recommendation is to pick a subset of C++ and stick to it, and I've never heard of such a recommendation for any other language (outside of perhaps for portability reasons).
> I know tons of C++ programmers who I'd happily trust to write code for me who would fall flat on their faces if asked to explain some detail of what std::forward does with an rvalue reference parameter bound to an lvalue argument.
That is true.
I can also remember other ones like differences between auto and decltype, or between auto and template parameter deduction across language revisions.
However, Java puzzles like the ones presented at Java ONE, or .NET changes in how native error handling changed on .NET 4.0, among many other examples, are also interesting as quiz questions.
That is true.
I can also remember other ones like differences between auto and decltype, or between auto and template parameter deduction across language revisions.
However, Java puzzles like the ones presented at Java ONE, or .NET changes in how native error handling changed on .NET 4.0, among many other examples, are also interesting as quiz questions.
> explain some detail of what std::forward does with an rvalue reference parameter bound to an lvalue argument
std::move?
std::move?
I was reminded of this yesterday: I work on a research-oriented C/C++ compiler with several people who would certainly be considered C++ "experts". We came across a bizarre bug introduced by static destructor ordering. Even with the lines of code highlighted and a detailed paragraph explaining the error, it took us almost 30 minutes to figure out how the undefined behavior was causing the bug we saw.
For me, that's the standard argument about C++ having unnecessary complexity.
You don't keep learn new stuff because C++ is super, uber, powerful. It is because it is not designed well and there are far too many dark corners.
You don't keep learn new stuff because C++ is super, uber, powerful. It is because it is not designed well and there are far too many dark corners.
As I answered in another comment, I keep learning new stuff because the language is alive and evolving. IMHO it's getting safer and easier to use and understand.
I've been at it more than 20 years and I'm still delighted to learn new things about the language and the library.
And it's under active revision and improvement. There are great new things to learn every few years.
And it's under active revision and improvement. There are great new things to learn every few years.
I feel like I'm slowly marching toward a mirage. In a way, I dread the c++14/17 changes because it means that much more that I'm going to have to learn. Even if they stopped revising the language today, I'm probably going to learn my last C++ factoid on my deathbed.
For me personally, that would be a positive statement. I don't think any good programming language can stay good unless it keeps evolving (and yes, to me, C++ counts as one despite the occasional gotcha it comes with).
That is - any language except for Lisp :-)
And to be frank: I'd say that anyone opposed to continue to learn new things is entirely in the wrong field if he/she works on any technology-related job.
And to be frank: I'd say that anyone opposed to continue to learn new things is entirely in the wrong field if he/she works on any technology-related job.
I mostly agree with you. However, there's something to be said for being conservative and not always tweaking things. C++11 is amazing. I'm still working to solidify my knowledge in it and haven't even peeked into c++14 or higher yet.
However, constantly learning and updating things has its drawbacks. One of the rare times I tried to be hip and use the latest stuff, I tried rewriting parts of a small Android app of mine using java 8 and lambda closures. I made it work, but it required upgrading my minimum build version (locking out older devices), the compiler could barely handle it (gave some strange indecipherable errors relating to lambdas), and ultimately it was just a step backward. That kind of thing really frustrates me, because it's wasted (at best, deferred) effort.
However, constantly learning and updating things has its drawbacks. One of the rare times I tried to be hip and use the latest stuff, I tried rewriting parts of a small Android app of mine using java 8 and lambda closures. I made it work, but it required upgrading my minimum build version (locking out older devices), the compiler could barely handle it (gave some strange indecipherable errors relating to lambdas), and ultimately it was just a step backward. That kind of thing really frustrates me, because it's wasted (at best, deferred) effort.
On one hand, I'd agree with you on that; I think we all know the urge to "modernize all the things!", whenever a language implements something new and shiny. And there's definitely much merit to resist that urge to some degree. However, it also is rarely really necessary to do this all in one go; one can also polish things up with strategies like the boyscout rule. And if there is no test for a piece of code - maybe leave it until you have corrected that.
Being conservative with new additions to your codebase seems a bit backward, though. Why not use the new, improved shiny language feature™ if you can?*
Of course, if you are prohibited by business requirements (e.g. missing modern compilers for a certain target platform) that's another story. Basically, it always comes down to practicality.
* A prime example would be the new way you can implement Singletons with C++11. Once you've used that, you realize how horrid pretty much all C++98-based attempts at this are.
Yes, I realize Singletons are often a bad idea.
Being conservative with new additions to your codebase seems a bit backward, though. Why not use the new, improved shiny language feature™ if you can?*
Of course, if you are prohibited by business requirements (e.g. missing modern compilers for a certain target platform) that's another story. Basically, it always comes down to practicality.
* A prime example would be the new way you can implement Singletons with C++11. Once you've used that, you realize how horrid pretty much all C++98-based attempts at this are.
Yes, I realize Singletons are often a bad idea.
Learning the shortfalls of new technology isn't wasted effort.
I have experience with Objective-C, C#, and Python and I'm currently learning C++ for a course in "Advanced C++" at university. I'm using "C++ Primer" by Lippman et al. and think it's quite nice. It might be a bit to basic, especially the first few chapters, but I kind of like the exercises in each chapter.
Have anyone read it and know how it compares to the books recommended in this article?
Have anyone read it and know how it compares to the books recommended in this article?
The link to the "Open Data Structures (in C++)" book seems to be wrong. The book can be found at http://opendatastructures.org/ods-cpp/
Further to the parent, though it moves away from C++, Pat also teaches an advanced data structures course for which the notes and assignments are available:
http://cglab.ca/~morin/teaching/5408/ https://github.com/patmorin/tds
http://cglab.ca/~morin/teaching/5408/ https://github.com/patmorin/tds
The best way to master C++, although perhaps not the most practical, is:
- Build a time machine
- Go back to 1988 and get hold of Bjarne's first book and a Zortech compiler
- Grow old, tinkering with and constantly keeping tabs on the language's evolution.
In this way, what seems to the modern neophyte like a massive indigestible meal is actually presented as a procession of smaller courses, most of which are an improvement on the ones preceding.
- Build a time machine
- Go back to 1988 and get hold of Bjarne's first book and a Zortech compiler
- Grow old, tinkering with and constantly keeping tabs on the language's evolution.
In this way, what seems to the modern neophyte like a massive indigestible meal is actually presented as a procession of smaller courses, most of which are an improvement on the ones preceding.
do you have something more focused on c++11 changes ?
Are these books suitable for beginners or more for an experience programmer looking to advance their skill?
For absolute beginners, The Rooks Guide to C++ is out there. (It is mentioned on the article)
Open source at: https://github.com/jeremyhansen/rooksguide-cplusplus
Previously discussed at https://news.ycombinator.com/item?id=6806598
Full disclosure: I joined as a technical editor on the kickstarter just before publication.
Open source at: https://github.com/jeremyhansen/rooksguide-cplusplus
Previously discussed at https://news.ycombinator.com/item?id=6806598
Full disclosure: I joined as a technical editor on the kickstarter just before publication.
Are the two Qt books on the list really worth the effort, considering they cover old versions? The Qt 5 is already around for 4+ years.
I didn't see Bruce Eckel's Thinking in C++; the PDF is free: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
I thought Eckel's book was especially good for someone who already had a background in C.
I thought Eckel's book was especially good for someone who already had a background in C.
Anything that hasn't been updated to take into account C++11 is going to do more of a disservice than be of help.
Has anyone else found it much more efficient to learn C++ (or any other programming language for that matter) using books like this one, YouTube videos, and help from forums than sitting in a classroom at a college?
Thank you so much,
I have one question though, Is there any pdf version for "The Boost C++ Libraries"? I really need it.
I have one question though, Is there any pdf version for "The Boost C++ Libraries"? I really need it.
I would consider using Chromium internal libraries as a boost equivalent.
Theres a lot of good stuff in there..
Just get: src/base, src/ipc, src/net (and something else you are interested in) and you are good to go
Theres a lot of good stuff in there..
Just get: src/base, src/ipc, src/net (and something else you are interested in) and you are good to go
They are awesome as far I know too, but I don't know about their documentation status, Can I find my way out? Boost is very well documented and there is so much book about Boost, But I don't know about chromium internal lib .
Well.. First you can learn a lot from here:
https://www.chromium.org/developers
Then, if you need more, you will have to do it the "hacker way", by reading the chromium source code.
But hey.. you are a C++ dev, source code should be your stack overflow, and primary source of "documentation".
hint: The unit test files, can make the "how to use this" much more obvious
https://www.chromium.org/developers
Then, if you need more, you will have to do it the "hacker way", by reading the chromium source code.
But hey.. you are a C++ dev, source code should be your stack overflow, and primary source of "documentation".
hint: The unit test files, can make the "how to use this" much more obvious
> There's a lot of good stuff in there.
Also it can break any time.
Also it can break any time.
But if you are just interested in the core libs.. you can just fork and forget.
Now, if you want more functionality than that.. like access to the last blink/webkit api, than you will suffer a little bit.
Now, if you want more functionality than that.. like access to the last blink/webkit api, than you will suffer a little bit.
Would someone care to ELI5 the differences in functionality between C, C+, C++, and C#?
C - Compiled language, imperative, pretty basic constructs (no OO, no GC), basically portable Assembly
C+ - No idea.
C++ - C with a bunch of stuff added on (mainly OO, other goodies too). Still no GC.
C# - not related to C at all. It's basically Microsoft's Java, with GC, OO, higher level constructs, lots of sugar, etc...
C+ - No idea.
C++ - C with a bunch of stuff added on (mainly OO, other goodies too). Still no GC.
C# - not related to C at all. It's basically Microsoft's Java, with GC, OO, higher level constructs, lots of sugar, etc...
C+ isn't a language, they went straight from C to C++ (++ is the increment operator)
Try reading OSS C++ code and cross check it with C++ FAQ;
I'd sooner master rust, which seems to have a lot of buzz around it. the world has needed a low-level prog-lang that's less painful than C/C++ for a while, rust may have enough merit to displace a lot of C/C++ dev - I just hope it gets well standardised, in such a way that C++ isn't.
C++ has an ISO standard. It doesn't get much more standardised.
It has a few standards, which is the problem.
Furthermore, I'm not just talking about the existence of a standard, but the complexity of the standard (C++is v. big), and also how much that standard restricts, and hence results in conformal, predictable code.
Furthermore, I'm not just talking about the existence of a standard, but the complexity of the standard (C++is v. big), and also how much that standard restricts, and hence results in conformal, predictable code.
> It has a few standards, which is the problem.
You mean C++03, C++11, C++14, C++17? Or something else?
If you mean those, I fail to see the problem. The language isn't dead, so it's not static, and it evolves over time. Publishing a new standard every few years is the only way to keep all compilers aligned, rather than each going off in its own "with extra features!" direction.
You mean C++03, C++11, C++14, C++17? Or something else?
If you mean those, I fail to see the problem. The language isn't dead, so it's not static, and it evolves over time. Publishing a new standard every few years is the only way to keep all compilers aligned, rather than each going off in its own "with extra features!" direction.
Yes, those. The differences between standards aren't trivial, and often the older standards have to be maintained.
The standard already has lots of features, including a turing-complete sub-language.
It is difficult to write code to standard (nothing that works, but is undefined either), that is safe, no segfaults, memory issue, secure, and all within a practical budget/timeline.
Just being able to reason about the code more easily helps, or make strong assumptions (e.g. about safety).
The standard already has lots of features, including a turing-complete sub-language.
It is difficult to write code to standard (nothing that works, but is undefined either), that is safe, no segfaults, memory issue, secure, and all within a practical budget/timeline.
Just being able to reason about the code more easily helps, or make strong assumptions (e.g. about safety).
What about smart pointers from c++11 onward? Seems like there are less reasons to have code seg fault these days.
So?
Do you know by heart the differences between each Ruby, Python, C#, Perl ..... version?
Do you know by heart the differences between each Ruby, Python, C#, Perl ..... version?
You're reducing the argument here. qualitative arguments (true/false) over quantitative (to what degree).
Your argument is similar to: "Hitler is bad, but no one if perfect" - does that mean than anyone not perfect is equivalent to Hitler?
Moving on; to focus on python it's not difficult to know the handful of changes between, say, python 2.5 and 2.7, nor to understand them. py3 is different, and the fork caused a lot of controversy, there is still resistance to py3. There is a python-2-to-python-3 tool (could any such thing practically exist between C++ versions?), but it's not perfect.
A language like Java almost suffers from trying to remain backwards compatible, yes a) the feature is nonetheless appreciated, and java is heavily used and praised in 'enterprise' b) Java tends to make breaking changes rarely, and only when necessary - can the changes between C++ specs be described the same?
Your argument is similar to: "Hitler is bad, but no one if perfect" - does that mean than anyone not perfect is equivalent to Hitler?
Moving on; to focus on python it's not difficult to know the handful of changes between, say, python 2.5 and 2.7, nor to understand them. py3 is different, and the fork caused a lot of controversy, there is still resistance to py3. There is a python-2-to-python-3 tool (could any such thing practically exist between C++ versions?), but it's not perfect.
A language like Java almost suffers from trying to remain backwards compatible, yes a) the feature is nonetheless appreciated, and java is heavily used and praised in 'enterprise' b) Java tends to make breaking changes rarely, and only when necessary - can the changes between C++ specs be described the same?
From the point of view of the ISO, my understanding is that they consider it to only have a single standard, with newer versions completely subsuming the existing one. I would actually argue that if C++ has a standards problem, it's that major revisions (1998, 2011, 2017, etc) are not treated as being distinct standards.
Have to agree.
Both Rust and Go (big in China) are worth looking at. Unless you're doing games programming C++ is neither C/ASM (which is popular for hardware) nor Java/C# (popular for business software) or PHP/RoR/Java (popular for web back ends).
Plus when you learn C++ you don't have to learn one language, it is more like learning four or five as they completely re-invented the language every time a standard ships. This might sound good, except a lot of these constructs are a pain in the butt to intermingle.
Both Rust and Go (big in China) are worth looking at. Unless you're doing games programming C++ is neither C/ASM (which is popular for hardware) nor Java/C# (popular for business software) or PHP/RoR/Java (popular for web back ends).
Plus when you learn C++ you don't have to learn one language, it is more like learning four or five as they completely re-invented the language every time a standard ships. This might sound good, except a lot of these constructs are a pain in the butt to intermingle.
Rust is better than C++, but most people work in legacy applications. And C++ ecosystem has a lot more stable libraries, frameworks and very active community.
It's the worst programming book I have ever read! It's introduction made me hate C++ and if I didn't had to work with other C++ libraries, I would have avoided C++. The text is full of bloat, for the lack of better word. It's the opposite of crisp writing.
I read some good language books like K&R's C, Joe Armstrong's Erlang book. I loved them and I thought this would be in same league. It's not.
I would like to learn C++ systematically, like not cut-and-paste stuff. "How to think like a computer scientist: C++" seems like a good book. I read the book "How to think like a computer scientist", which is an introduction to programming in Python. I think that would be a good start. Is it a good book for experienced programmers wanting to learn C++?
To people wanting to learn C++, please avoid Stoustrop's book like Plague.
EDIT: I read "The C++ programming language 4th edition" which explains C++11 https://en.wikipedia.org/wiki/The_C%2B%2B_Programming_Langua...