One is never proficient in C++. One merely... learns to adjust ones ignorance to practical constraints. I.e you choose such a subset that you can deal with it. But which subset? Hence, a shitload of books. The point is to read about all sorts of styles and pick whatever feels practical for you.
And I'm completely serious. I've earned my living with C++ for over a decade, am considered a valuable contributor and still... so clueless towards so many details.
Then C++ has failed. If it has so many competing standards and subsets, then it is too fragmented. This is why when you see C++ written in one standard it looks like a whole other language when you look at other C++.
If after a decade there are so many details still obscured from you, then that's pretty much again a fault of the overly-engineered and tacked on language called C++.
Other mainstream language work fine and allow you to still write clean and modern code without having literally dozens of subsets and implementations. So why is it that C++ feels the need to have so many?
On the contrary, the one nice thing about C++ is that it is 'multi-paradigm'. Don't like boost's philosophy of overengineering every little detail? Then don't use boost. C++ without exceptions, RTTI, or even the whole STL? Perfectly fine. Other languages don't have this freedom. It's a double-edged sword of course. Less freedom also means wasting less time with pointless discussions about which combination of C++ features is 'right'.
After using boost in several projects and regretting it each time (slow compile times, painful to configure), I finally learned my lesson and "don't use boost" is now one of my guiding principles when programming in C++.
While I would mostly agree, I would humbly suggest a small nudge in perspective: Boost does not equal Boost. While I passionately hate most of Boost, I find boost::optional to be one of the most useful template classes. So you shouldn't treat Boost as one library, but as a collection of different libraries. Same goes for STL in my opinion.
I think boost has definitely had a positive impact on c++ and the fact that large amounts of it are now in (or had a major influence on) the std library certainly makes it much easier to forgoe using it.
Sure, threads and datetime has been in certain implementations, too. I think anyone can appreciate the fact that these libraries are not compilation hogs (such as phoenix or mpl) and are portable and save a lot if time.
We use C++ because of the C++ the ecosystem not because of the C++ the language.
There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.
Gotta say I'm looking forward to it too, even though I might not ever use it.
There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those.
That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines.
Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful.
The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like:
name: type = value
...so:
foo: int = 0;
...but functions are defined as:
name := () -> return_type {}
ie:
bar := () -> float {}
I would have thought that a function would be defined as:
name: return_type = () {}
so:
baz: float = () {}
...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.
> The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor.
Go, Rust, Swift, Ada, Pascal - languages both modern and old also use that inverted syntax and it's not such a burden to get used to.
> I don't like are the lack of exception handling
If done properly, it's possible to do without exceptions and have more robust and readable code - see for example Rust with its Error type and the try macro/? operator, which I've found I much prefer to exceptions.
I'm not an expert at parsing, but one main issue I can imagine with having the same syntax for declaring functions and variables is that you need to look at six tokens to understand if it's a function declaration or a variable declaration. I say six because you have the name, colon, type, equal, parentheses (certainly you can't use this because then I couldn't declare a variable using parentheses, e.g., foo: int = (4 + 5) * 3;), and finally a pair of curly braces. And even then, I don't know Jai at all so it may be legal to use them in variable declarations.
With the name := () -> return_type {} syntax, you know whether it's a variable declaration or function declaration after two tokens: name (for either), then colon or colon-equal to differentiate the two.
Then by that point of view, C (hello UB), Python, Ruby, JavaScript, Java, among many other programming languages have failed as well.
Using my favorite scripting language (Python) as an example, I always need to check which version is installed on a given OS and then validate at https://docs.python.org/ if all the features I want are actually available on that version.
Not to mention CPython, PyPy, Cython, JPython differences on top of that.
Which other systems language allows the same style of programming while giving the same performance? You pretty much know if and when you need C++ - which is rare unless you live near the hardware.
That said, I'm not sure how you wish to engage people here with that comment. Do you have any specific criticisms of C++ (there are many!) that we can discuss beyond your personal feelings?
I would disagree that C++ is only useful "near the hardware" I have spent the bulk of my career not near the hardware and have found C++ to be the most useful of languages I have learned. My current job is as close to the hardware as I have gotten, I am even on the "Firmware Team" and I feel pretty removed.
If you need interop between two languages you almost always have to drop to C, if you want to do that while keeping high level concepts like object, then use C++.
If you need more performance and you have already maxed out perf in some "higher" language. Then a naive C++ rewrite is often just faster. Then when you start breaking out C++ profiling tools and carefully managing memory you get insane speeds that didn't seem possible before.
With some of new stuff in C++11/14/17 it is actually fun to work in C++, not as fun as Ruby... up until 3d things start appearing on the screen.
>I would disagree that C++ is only useful "near the hardware"
Okay, but I didn't say that? I said C++ has limited uses, _unless_ you're near the hardware, where its much more common. You can disagree, but its better if you disagree with what I actually said :P
But to your reply, Personally, I don't agree that C++ is fun to work with. Like any other language, I tolerate it as and when I need to. And like I said in the previous reply, sometimes C++ is the only choice, and you accept that and do the best you can. I've found that good tooling does reduce some of the headaches, especially when it comes to debugging (although stepping through optimized production code still remains a giant pain in the ass). I'm happy that the language is progressing and with all of the new features, its like a cafeteria where you chose what you like and what works for you and your team. I certainly don't agree with all the advice that the C++ cheerleaders put out on the internet about inserting every new feature into production code. Personally I take a very conservative approach and only use features that have shown tobe useful across the entire dev cycle of - helping to conceptualize an idea, being easy to reason about by everyone on the team, being easy to debug, and being reliable enough for 24/7 execution (though this applies more to the library side of things). My code runs automation machinery, and it has to have zero bugs in it. I choose C++ because currently its the best tool for the job.
I figured that by providing examples of where C++ was required that cases near those were it is used but not required would be evident.
In pretty much every type of application domain there are a large number of C++ applications. It is used in finance, business, games, medical, as you point out it is used very close to the hardware particularly when that hardware is custom and image the web with many fewer browsers and servers. The only kind of developer that might outnumber C++ devs is Java devs because there are so many custom internal enterprise applications that place higher emphasis on being barely functional than performant (and they are largely correct in their decision).
I find no need for your needlessly specific separation of limited vs whatever my wording used. I hope that whatever your take from this, should you choose to continuing nitpick, is that C++ is hugely useful in many places it just is new and glamorous so it doesn't get much press.
Fun to work with? Perhaps not. But 99% of the software you're using to post your reply (and generally do just about anything on your computer) is written in some derivative of C or C++. So C++ has that going for it, which is nice.
My philosophy is "If you have fewer than 5 years' experience with C++ and think you are an expert, you just don't know how much you don't know. If you have more than 5 years', then you're a liar."
Only time I had C++ on my resume was when I was looking for my first internship and was desperate to pad my resume with _something_... Hey, I took a course in C++, so I can put it down, right?
I soon removed it afterwards after knowing what "knowing c++" implied.
> "If you have fewer than 5 years' experience with C++ and think you are an expert, you just don't know how much you don't know.
That pretty much applies to any subject. Some bachelor's degrees take longer than that, and no one becomes an expert with a bachelor's or even a master's degree.
Therein lies its strength. It filters out both those too weak and those who want to appear smarter than they are. The first group just never can get anything done in C++, the second writes code they can't understand themselves 3 months after they wrote it, so it either ends up in Boost or nobody uses it.
My subset is the one that I require to interoperate with managed languages (Java, .NET, Swift,...) and makes me feel as I if am using Ada/Turbo Pascal with curly bracket syntax instead.
Nope, that's a pretty good stack. Of course, you don't (A) read the books, and then (B) start programming. You read a chapter, try stuff out, read another chapter, read some code, try more stuff out, read a LOT more code . . . and about ten years later you're a very good C++ programmer.
I'm not kidding.
I've got several linear feet of C++ books on my bookshelf, have read most of those books, and I consider myself an average C++ programmer, not a language guru by any means.
> Surely you are joking right? I just can't imagine one has to go through all those books to be proficient in one language.
It's easily one of the most complex mainstream languages and one with the most pitfalls which is why higher level languages are preferable when feasible.
> I just can't imagine one has to go through all those books to be proficient in one language.
I don't know if you know the meaning of "proficiency", but if you are trying to argue that it takes work to become an expert in a subject then it seems you aren't aware of what being an expert actually entails.
Moreover, Those books appear to be a lot mainlyl because the subjects covered by half of them actually overlap.
So I hate C++. What I really want is the speed, flexibility, universality and simplicity of C. But I wish structs had destructors, and a way to bind namespaced related functions. Only since I basically now have classes, I should really think about adding inheritance. And I also find prototyping, testing and non-speed critical programming is a pain without a good generic container library. Containers can be implemented fairly elegantly with templates, but then I probably also need some compile-time processing ability. Oh crap, I just ended up at C++ again. And so I persist with C++ as my main language, with a constant voice in the back of my mind saying, "this is just stupid, there must be a better way. Why is there SO g-d* much accidental complexity in this language?". In my view, C++ has probably wasted more programmer hours, and added more sadness and despair to the world (at the very least MY world) than any other technology. But given my language wish list it's very, very hard not to be tempted to fire up c++-mode for just one more hit.
Other than C, are there any languages that interest you? Are languages like Rust or D or other systems languages not what you're looking for? How come?
I use Python a great deal, especially for tooling and prototyping and appreciate the fact that programming is fast, easy and focused on the inherent complexity of the problem. Similar positive experiences with Smalltalky and Lispy languages as embedded languages. But I write a lot of performance-critical libraries for programs that need good C/C++ interop and where C++ is pretty much the lingua franca. Swift, D and Go, for example, all have their strong points, and I plan to do more experiments when I have some time ... after this one last C++ project, though!
I might be extremely biased about this, but I can't not recommend to follow Folly as well (https://github.com/facebook/folly). There is some very good C++ there (and some bad C++ too), and it is generally more readable than Boost. Some ex-Boost people work on it too.
There's also a lot of interesting things happening in concurrent data structures under experimental/ (and the widely used MPMCQueue and LifoSem are also excellent).
Can anyone recommend a good compiler/IDE learning setup?
I studied C and C++ back in university (I was in the wave of students that came through after they switched from Pascal as the teaching language, and before they switched to Java). And my first job or two back in the early-2000's was using C++ in HP-UX servers, to talk to other systems via CORBA.
But that was ages ago, and once I stumbled into a Java job I never left. Every so often decide to scrape off the rust and check out C++ again, but the ENVIRONMENT setup scares me off.
Should you use GCC or LLVM? If you're on a Windows box, do you try one of those? (there's at least three different distributions of MINGW available) Or do you use Microsoft's compiler? (VS has potential licensing issues, while the freeware build tools are pretty arcane and it's hard to even find an installer or know which exact thing to install) Or Cygwin? (I'm not 100% sure on the current state of its licensing)
I've tried to build the wxWidgets library at least 100 times. It gives you dozens of options for compiler and environmental setup, and yet I've never found a choice that successfully built all the sample apps.
Once you have a compiler setup, what about an IDE? (Don't even start with the "just use Vim or Emacs" crap, I'm not an animal!) I love IntelliJ in the Java world, but don't want to pay for JetBrains CLion just for hobby/personal use. The last time I tried Eclipse's C++ support it felt pretty half-baked. Qt Creator is actually really nice IDE (a C++ IDE should be written in C++!), but it feels very specific to writing Qt apps.
What about build tools? It's hard enough for Java newbies to wrap their heads around Maven or Gradle. But makefiles and "configure" scripts are far more arcane, and which flavor of make should you be using in 2017? It's hard enough to build a project that uses one of these large frameworks with opinionated build systems. I wouldn't even know where to begin in combining two opinionated build systems as dependencies of a single project, or creating a new build system from scratch for a greenfield large project.
Once you have a compiler, IDE, and build system and are ready to start coding, what about a standard library? Is Boost still the thing everyone uses? STL? Something else?
I really can't imagine that learning C++ syntax is THAT challenging in comparison to Java/C#, Rust, D, or anything else. But I'd love to see an "Effective C++ Environment" book.
On Windows, just use Visual Studio Community. You don't need anything else, Microsoft's support for C++11/14/17 features is excellent. I'm not aware of any killer licensing issues with the free version, the only limitation is that if you're an enterprise (> 5 users, > $1M revenue, that sort of thing) you need to buy a license. There isn't a problem with commercial development using the free version. You may also need to provide the VC++ redistributable with your application though.
As for standard libraries, the STL is the standard library and you 'should' use that where possible. Boost is a mix of potential features for C++, a few modules that lots of people rely on (e.g. json, timers, asyncio), and a whole lot of undocumented and unmaintained code. I get by without it most of the time.
Qt Creator is pretty decent even if you don't use Qt. You can use the qmake system which does lock you in somewhat, but it's easier to configure than cmake for a newcomer. You still get debugging/profiling and intelligent autocomplete/linting.
If you don't mind the large library overhead, you can use Qt for a lot of brick-and-mortar code like dealing with filesystems, sockets/serial comms, parsing XML, etc. It's very well documented, updated often and it's GPL which is nice. Or you could statically link it. Personally I've found the Qt GUI framework much more intuitive than the native Windows stdafx stuff.
I second Visual Studio, since it has a decent debugger (light years ahead of GDB when it comes to usability) and is relatively user-friendly (almost everything is customizable, but there are sane default values).
I recommend starting a blank C++ console project and adding files as you go, otherwise you risk getting confused (e.g. "what the hell is stdafx.h and why is it included by default in my main file") and trapped by Microsoft's ecosystem.
> What about build tools? It's hard enough for Java newbies to wrap their heads around Maven or Gradle.
You don't have to worry, Visual Studio has everything integrated. There is a build system (MSBuild? last time I checked) that you could theoretically use outside of Visual Studio, but you probably don't even need to be aware of its existance.
Also, if you do Android development, Visual Studio abstracts Gradle away, which is basically the way development is supposed to be done.
> If you're on a Windows box, do you try one of those?
No, I just use Visual Studio.
If you don't want to pay for it, there is the Visual Studio Community edition available for free for personal use, which is basically Visual Studio Professional re-branded with a different license.
>Qt Creator is actually really nice IDE (a C++ IDE should be written in C++!), but it feels very specific to writing Qt apps.
No it is not, I use QtCreator 99% of times with CMake projects. QtCreator with ClangCodeModel is the best you can get. Nothing even comes close to this combination.
I have to say I am obsessed with IDE's, and I have tried all of IDE's you mentioned, nothing can even come close to QtCreator.
The only drawback is when you use ClangCodeModel in Windows.
It seems there is problem of Clang Parser in windows (there was a serious discussion with Clang developers on their mailing list). Parsing and Autocompletion are slow in Windows platform. But it is completely fine in *nix, OS X.
On Windows, just use Visual Studio. It's free (one of Microsoft's better decisions of the last few years) and it's pretty damned good.
Resist the temptation to switch tools a lot, or tweak things continually with plugins or code generators or whatever. I've seen people do this; they get distracted by tooling and tend to learn more slowly.
All you really need to do is sit your butt in a chair in front of a good C++ compiler/debugger, and stock VS without any tweaks fits that perfectly.
On the other hand, the Whole Tomato refactoring tools are pretty awesome, and most of my cow-orkers have them installed. They make large projects a lot easier to deal with (near instantaneous search across a large project is a wonderful thing). But you don't need them, especially when you're starting out.
My basic principle is, when learning a language, doing stuff that isn't involved in learning that language is, well, not learning the language. It's like the aspiring writer who just needs to find the right laptop, the right software, the right printer / coffeeshop / corner of the house . . . it's all excuses and procrastination, just sit down and write.
GCC still compiles faster and produces faster binaries for me. But I like to swap to clang once in a while since it has better compiler messages (always use -Wall -Wextra).
> If you're on a Windows box, do you try one of those? (there's at least three different distributions of MINGW available) Or do you use Microsoft's compiler? (VS has potential licensing issues, while the freeware build tools are pretty arcane and it's hard to even find an installer or know which exact thing to install) Or Cygwin? (I'm not 100% sure on the current state of its licensing)
Instead of Cygwin you should check out MSYS2: http://www.msys2.org/
It has a package manager which can install both GCC and LLVM.
> I've tried to build the wxWidgets library at least 100 times. It gives you dozens of options for compiler and environmental setup, and yet I've never found a choice that successfully built all the sample apps.
Check out this wxWidgets project of mine: https://github.com/jhasse/pwcalculator
It should build on all operation systems, if not please create an issue and I will take a look :)
> Once you have a compiler setup, what about an IDE?
I'm using Visual Studio Code with the C++ extension (on both Linux and Windows).
> What about build tools?
I'm using Waf (and SCons for older projects), mostly because I also like Python. In my experience you should avoid qmake, most others are fine.
> Once you have a compiler, IDE, and build system and are ready to start coding, what about a standard library? Is Boost still the thing everyone uses? STL?
Yes, both are pretty popular. Nowadays the STL covers most of the older Boost stuff (e.g. shared_ptr, thread, regex, ...).
make and configure and autotools are things of the past. You should learn cmake, but only after you have already familiarized yourself with C++ with Visual Studio Community Edition.
Don't use gcc or clang on Windows as I have had been bitten by their bugs for a lot times. Always use the native tool on that platform or you will face constant headaches (VS on Win, GCC on Linux and Clang on macOS).
Run some friendly flavor of linux in a virtual machine and do your C++ inside of it. Serious and not sarcastic advice. There's nothing to be afraid of, it isn't really that hard, you just need patience.
This was/is the biggest gap in my knowledge. Setting up cmake, or make, or the autotools on Linux, or setting up cmake and Visual Studio (the configuration options) was always a big stumbling point for me. I've only gotten the hang of it through trial and error, it seems like tutorials and documentation just lacks the connection to why you need to set things up a certain way.
> Setting up cmake, or make, or the autotools on Linux, or setting up cmake
Don't do this to yourself, just stick with regular Visual Studio and its build system. Nowadays you can even use it to build Linux binaries, so why put yourself through the hassle of using stone age text files to configure your build when Microsoft has been providing a perfectly usable solution for almost two decades?
I have never had visual studio "work right" it always tried to compile my stuff as C++/CLI, force linking against libraries that weren't needed or just didn't have the core language features I needed. Is there a simple flag to statically link the stdlib yet? Did they get rid of the crazy errors in the std lib when building with /w4 yet? I could on with gripes forever...
My life got so much when I just worked in Linux, then used CMake to hide all the visual studio grossness. My software all still builds over there and my unit tests still pass, but I get an environment that works and is understandable. I started with visual studio too, I never understood what the hell it was doing or why, there was always one more corner case or one more confusing exception to a rule or one more thing that wasn't standard C++ but msvc wanted.
I think windows and visual studio was designed to be impossible to understand intentionally, and this gets confirmed every time I ask some MCSE or or other cert holder "why" or "how" to some specific feature. I am fine with them not knowing, but they don't even know how to look it up of use technical tools to inspect it. With any other OS it is pretty easy to follow technical stuff all the way down to the bare metal and back up if that is what solving a problem takes and you can do this through the documentation or through the inspection tools like debuggers profilers. I have tried with MSVC on windows and get blocked the first time some "feature" I have never heard of and didn't ask for gets in the way. Now that understand some of what the older versions are doing I still don't understand why they do it, there is no clear technical reason to do much of the non-sense they do.
One last gripe, why does the installed thing fill like 20GB and take an hour to install when QtCreator, gcc and clang takes 3GB with all their dependencies and like 2 minutes to install from apt-get?
OP mentioned an environment to learn C++. Having to additionally learn a build system is cumbersome at best, whereas Visual Studio provides all the right defaults for most use cases - especially good for beginners.
> it always tried to compile my stuff as C++/CLI, force linking against libraries that weren't needed
I'm pretty sure you can change these things in the project settings.
> just didn't have the core language features I needed
Each new version of Visual Studio usually includes new core language features, just like gcc or clang or whatever.
> Is there a simple flag to statically link the stdlib yet
Yes, I think it's been there for a very long time (just switch the runtime library to "/MT" if I'm not mistaken).
> Did they get rid of the crazy errors in the std lib when building with /w4 yet?
I don't think remember anything out of the ordinary when using /W4; when using /Wall you do get indeed lots of warnings, but that's because it activates some sort of static analysis that is most of the time overkill.
> My life got so much when I just worked in Linux, then used CMake to hide all the visual studio grossness.
Funny, for me it was exactly the opposite. For every checkbox and textfield Visual Studio provides as a simple option and/or toggle, there's an equivalent horrible CMake configuration line (or, more common, set of lines in multiple CMake files). Because when I'm busy plowing through a huge C++ codebase, all I need is worry about the syntax and state of my CMake scripts.
> With any other OS it is pretty easy to follow technical stuff all the way down to the bare metal and back up if that is what solving a problem takes and you can do this through the documentation or through the inspection tools like debuggers profilers.
Easy to say, except that in practice, when you're on a deadline, all that source code becomes most of the time a liability. When you're trying to understand why this CMake script doesn't do exactly what you want it to do, are you actually going to start debugging it? It's probably a better option than reading its very poor documentation, but still.
> One last gripe, why does the installed thing fill like 20GB and take an hour to install when QtCreator, gcc and clang takes 3GB with all their dependencies and like 2 minutes to install from apt-get?
I think you can customize your installation to take less than 20 GB. I don't know why the big size compared to other compilers/environments, but to be honest it's not really a big issue for me. When looking at the bigger picture, I waste an extra 5 minutes installing the environment but I win a huge amount of time by not having to be bothered with the build system, compiler options and other minutiae (unless I explicitly want to).
If you have a specific use case that makes it difficult for you to use Visual Studio I sympathize, but overall, having used gcc/qt creator/eclipse/whatever, Visual Studio is a one-size-fits-all solution that made my life easier than the alternatives.
If the OP really wants to learn then a close to ideal way is build the files in a command line and use a plain old text editor such as Gedit or Notepad++.
If he start with either you or my professional choice in IDEs he will have a ton of neat details to explore that will do him no good but can easily break his setup.
Eventually he will want an editor that can launch a command to do his build for him and he will learn the how and whys of IDEs. As his project gets bigger he will start a shell script or batch file and intuit why build systems exist.
He will learn the kinds of problems that come from software and not be bogged down by a bunch often useless details in professional tools until he needs those details. By the time that happens those details can't help but be useful.
> I'm pretty sure you can change these things in the project settings.
Those things could be changed, in the current versions it is easy, but in the version from from around 2012-2014 it was a huge and it would automatically be changed back if you selected certain items from the menu. Not all project have the luxury of being able to be up to date. Particularity in shops that have bought all-in to the microsoft philosophy, where tools cost an inordinate amount of money for no reason I and suss out.
> Each new version of Visual Studio usually includes new core language features
And they are slower to get the features if they ever get them, unless they lead development I am sure it A+ module and co-routine support but msvc 2015 rev 3 didn't have thread_local and every other compiler did. This is the kind of you can replace with a macro I had to rewrite an algorithm to make work it on that compiler.
If I want to ship a source library and want people to be able to build it on msvc, I pretty much don't get to use thread_local even though it enables a bunch of really cool things. This is just my most recent pain. I have written many things that worked great on the 3 PC platforms as long you weren't using msvc, but as soon as you switch from mingw to msvc something ridiculous broke. Whether it be the preposterous macros set in windows.h or the completely unique semantics for their very bad pre-compiled header implementation I have to deal with a break on just windows/msvc about every two months. Good luck dealing with std::uncaught_exception or any other feature that super useful in niche circumstances.
> Yes, I think it's been there for a very long time (just switch the runtime library to "/MT" if I'm not mistaken).
Except it doesn't enable static linking, like you said it switches which library you build against and some things are still dynamically linked. This non-sense is also all bound up with debugging and thread support. Every other compiler lets you choose these option independently but with msvc you have to choose one of 4 /MX flags and hope its good enough.
On /W4 and /Wall I am cool with all manner of errors being found in my code. I expect that and even some spurious ones. What I don't like is the huge amount of non-virtual deconstructor noise coming from the std library or other warnings from headers that the compiler controls. Those should either be fixed or exempted from warning generation. I have never gotten a warning from Gcc or Clangs std library, I don't know how they do it, I don't need to, but with a sufficiently high warning level and all warnings as errors I need to wrap certain includes like <vector> in pragmas to disable warnings. I now understand why some windows devs think coercing all warnings to errors is a bad idea that can only hurt productivity, because with their tool-set it is.
> Funny, for me it was exactly the opposite
Then, I suspect your builds are simple. As soon as a project needs to do things like support multiple platforms or multiple compilers or even needed to generate code as part of build the menus become pretty limiting. You can run arbitrary build steps using the menus in visual studio, but it is a pain. If you want to use SWIG to generate bindings or configure Doxygen to generate API docs and get the errors from it in your IDE the difficulty level gets super high.
That might not affect a fresh minted developer still learning, but the other side of the massive menus is that if you don't know what those options are or do finding the option that changes some behavior involves a huge amount of googling. That itself isn't bad if it can be avoided, but inevitably all that googling gets you to the msdn or technet, the two worst piles of shit for documentation and answers on the internet. And every one links to them. They are often stale, contradictory, light on detail or just plain wrong.
This never happens with CMakes docs (sometimes they are light on detail but then there is stack overflow) their docs are versioned, skill with one version moves with you to the next version and it is the de facto standard for projects not mired in vendor lock-in so there are countless examples of CMake project to learn from. Plus it is a full blown programming language so if you need to do something unfortunately interesting in your build you just do it, wrap it in a function to hide, document it and move on.
This is turning into a msvc vs cmake showdown. This is apples and oranges and needless I won't participate further other than to say the community has spoken and CMake is the build system of choice and visual studio is the IDE to use on windows.
> I think you can customize your installation to take less than 20 GB.
You can; I was almost going to say I was speaking in hyperbole, but no I meant 20GB. I have seen isntalls in excess of 45GB... Who the hell needs 45GB of IDE and compiler.
The problem with trying to get smaller installs is that the menu options in the installer are undocumented or poorly documented to the point that someone who has painstaking researched it needs to give you a list of boxes to check for your project or you include a bunch of needless BS.
Even if msvc were a pleasure to use I probably wouldn't at this point. Too many times microsoft has tried to screw me. They are just a horrible company and treat people poorly. Sticking in the space of compilers and IDEs they made too many technical decision for marketing and vendor lock-in reasons for me to trust them again. Their tools sucking just make it easier for me to avoid them, if they released stuff with the quality of Jetbrains or Qt I would have a harder time resisting.
It seems you were overly polite, so you may have misread my post. I am not angry with you as you have been quite cordial and earnest, but please reread my post with your internal voice screaming and deeply enraged as though you just saw an orphan, a puppy and a baby seal all run over by a lawyer driving a hummer that is "rolling coal" fueled only by endangered redwood chips who works for patent trolls and is on his way to defend a giant oil company's right to defraud the founders of a tiny tech startup in a totally skeezy but technically legal way. If your politics don't lean that way, then you will need to settle for the phrase "Please, reread that in an extremely angry voice". These tools that microsoft makes have caused me many years of pain and will continue to do so even though I heavily invested in open source, and I have wished many times for a button I could push to make them all disappear.
EDIT - Have an upvote for remaining so polite and attempting to help me fix my problems, even thought we are well past that.
I feel your pain. If only we could harness programmer frustration into energy, we could stop burning fossil fuel. And don't get me wrong, I have my own long list of gripes with Microsoft and Visual Studio, they're nowhere near perfect.
The problem at my current job involves a metric crapton of CMake files that don't have a clear maintainer (big company, anyone forced to touch those files just does the minimum required to get the desired effect) and it's a general hassle to understand what exactly the project settings will be for any given directory. I find the CMake syntax so confusing that I switched to Meson as build system for my personal projects; it's not ideal, but I find it easier to digest.
Anyway, I understand your point of view. Have a nice weekend.
While it's not representative, the last time I touched Visual Studio was to work on fixing bugs in software that had to be deployed to an Xbox 360. Let me tell you, the process for that involved nasty build settings and a small constellation of batch files and it was not especially usable. Text files aren't "stone age", they are the past and I would always bet on them being the future.
Without knowing the specifics of your software I can't really tell if the problem was with Visual Studio or the process itself. I do believe you can have a shitty work environment whatever you use, and that some tools aren't good for every job (and that includes Visual Studio).
> Text files aren't "stone age"
The issue is whether your build system provides you with an UI that enables you to be productive (e.g. Visual Studio), or if it forces you to manually edit some configuration files using some arbitrary syntax that doesn't seem to display any sort of internal logic (e.g. CMake). In this respect, being forced to deal with text files is stone age, just like debugging a C++ program with stock GDB.
In the end, it's a matter of preference. Do you want an IDE so that you can focus on programming, or do you want to set up and maintain a string of loosely coupled tools that, when the stars align, do what you want to.. kind of.
The Visual Studio options menu is an abomination of a GUI. The things you need to change to do any particular task, like integrate a library, are scattered around multiple different pages. It's also very easy to screw things up, so that only debug or only release mode work properly.
I lived the pain of hunting for binary downloads that match my exact Visual Studio version. Even if you were lucky enough to not need to compile from source, you'd still need to manually configure each library and include path for both debug and release mode separately. And, when you later move the project onto a new computer or share it with a friend, you're likely to discover that hidden somewhere in that mess is a path that's no longer valid.
By comparison, adding a library on Linux is usually trivial. Call 'apt install foo', call 'FindFoo' in your CMakeLists.txt, and use the variables FindFoo provides. Done.
The Visual Studio debugger, Intellisense and plugin integration are great, but project configuration is atrocious and nobody should be emulating Microsoft's approach on that.
But what about configuring additional libs in VS, or autoincrementing the version in the resource file? Or when you import and very old VC++ project and the auto conversion process only sort-of fixes things?
That's what I'm talking about. VS works great out of the box using the Wizard, but the learning curve gets real steep right after that.
> But what about configuring additional libs in VS
I'm not really following. Just add the other library's project to the solution?
> or autoincrementing the version in the resource file
There are probably multiple solutions, but off the top of my head you can add pre/post build steps to a project, so you can invoke a script that will autoincrement the version for you.
> Or when you import and very old VC++ project and the auto conversion process only sort-of fixes things?
I agree, this sometimes causes problems. When that happens, creating a new project from the existing source code can be better than trying to fix the imported project.
> VS works great out of the box using the Wizard, but the learning curve gets real steep right after that.
As far as IDEs go, I feel VS is tolerable. I agree there is a learning curve once you start customizing your project, but in my opinion it's not as steep as it is in Eclipse, for example.
I've spent my first 15 years in video games, then 2.5 years in Google, and I'm moving again to video games.
I'll stick to C++, IDEs and BUILD files.
Before any project, it was Turbo/Borland Pascal and TPU files. No real projects, but it was very easy to use a module, no header files, just "Use Something;" done. C# carried that in there, and Java too.
Then for C++ it was first a simple text files with what to compile, later Makefiles (I still love them), .vcproj, .vcxproj/.sln, scons, cmake, qmake, qbs, custom tailored makefiles, etc. I've never found any of these good, until I used Blaze (Bazel on the outside) at Google (alternatively generate-ninja (gn) for Chromium/Fuchsia, close but not the same).
So what do I like about BUILD files, Bazel and WORKSPACES? It's simply this:
cc_library(
name = "my_lib",
srcs = [ "one.cc", "two.cc" ] # has glob() too
hdrs = [ "one.h", "two.h" ]
deps = [ "//base/something:project" ], # // is like a root for all projects.
)
No transitive dependencies, e.g. if A depends on B, B on C, A can't use "C" just because B did. A also needs to declare it. It takes a while to convince yourself, but then it becomes clear why this is done so.
Bazel (blaze) gets a little bit harder to use if you target different platforms (say ps2, ps3, ps4, xbox, wii, pc, etc.), but there is way to declare that, in this respect GN is much easier, just use "if (is_pc) {}" in the declarations (they are BUILD-like), and you are done.
I just bought the IntelliJ package /yearly, got CLion, also some other things, and started using it for home projects. It comes with bazel support (plugin), so that helps.
--
On the other hand there is QtCreator, Visual Studio (the current free version is almost like professional except CodeLens), then some more experimental ones like the Juce's Projucer, and plenty more.
On Windows save yourself a bunch of headaches and just use visual studio. On Linux either gcc or clang will get the job done. The biggest headache in the C++ ecosystem is by far building large cross platform projects. All the existing build tools suck.
I don't know C++ but I think a good way to address these questions is by checking popular C++ projects on GitHub. I'm a solo developer and have learned a ton in terms of "lay of the land" type stuff seeing what people do in other projects. GH has been invaluable to me.
Like everybody go with Visual Studio. If you have to be on Mac then maybe you can go with XCode or else for Linux Qt Creator. I never tried CLion from JetBrain but it can be good too.
> Can anyone recommend a good compiler/IDE learning setup?
Given your post, I'm assuming Windows.
There's BloodShed Dev-C++ which has Mingw-GCC bundled but you can use another. [1]
Then there's Code::Blocks, which has a Mingw-GCC bundled version - [2]
One IDE that impressed me recently was CodeLite [3]. It doesn't come with a compiler, but its support for GCC is very good, especially gdb. You mention wxWidgets and IIRC it has built-in tools for that as well.
I didn't downvote you but I suspect you got downvoted because DevC++ is super stale. Their last release was pre-C++11 and likely more than a decade ago.
As others have said, both are great. Some bits of the first book may be obsoleted by newer language features, but will still give insight into why these features came to be. Also note, in my impression, Effective Modern C++ is pretty hard if you are not quite familiar with C++11 already.
Keep in mind, Effective Modern C++ is not a good book to learn modern C++. You learn modern C++ (11/14/17) from other resources and then come to this book to read about quirks and corner cases.
As a non-C++ programmer with a background in functional programming, this similarity was a big surprise to me when I read a recent article on C++ template metaprogramming -- it's all basic functional programming techniques, with recursion, (kinda) pattern matching, etc. Very interesting!
I could see how mixing templates with other C++ paradigms could quickly get messy in the wrong hands, since it's very powerful.
Bookmarked, thanks for this! You've covered books, course pages, tutorials and videos as learning resources. Do you have any audio/podcast recommendations with C++ material?
Thank you! Well there is one podcast dedicated to C++: cppcast.com.
Also I'll publish a post dedicated to books about C++ that shows more recommendations, during this summer.
Just a nit pick for the author, take it or leave it: You use "STL" quite a bit through your blog, when you probably mean to say "C++ Standard Library". They are different beasts. You probably know the differences but beginners might not and could become confused.
Otherwise, great article--that's a lot to dive into over a single summer though!
"STL" is a perfectly valid way to refer to the C++ Standard Library through metonymy. Source: I am STL, an STL maintainer, with the sovereign right to name what I work on.
This sounds like a lot of fun, but I'm concerned about the limited ROI. How many practical, modern use cases does Cpp have at this point for those of us who don't work in a few very specific verticals like finance or game dev? Even in those aforementioned industries, C++ is reserved for niche roles / use cases.
Of course not all hobby projects need to be "practical" or directly useful - but time is a valuable resource and I at least would like to have an actual non-toy project goal in mind when choosing to better grok a language. What is C++ uniquely good for in 2017?
edit :
Useful answers to this question -
* extending libraries for higher level languages
* embedded dev
TBH it sounds like you immersed yourself in the "everything is node or go or rust" HN bubble. C++ is one of the most widely used languages for application development.
In terms of application development, cross-platform GUIs are a pain in virtually any other language, ignoring platform specifics like Objective-C or dot net. Ever tried to ship a frozen Python binary? Never again.
It's a little like saying what are some good modern uses for Java? Then you remember that millions of people use Android every day.
I work in computer vision and deal with hardware a lot, both embedded (micros) and 'higher level' (cameras, random optomechanics). You get drivers in C/C++, often dot net, and occasionally other languages. Sometimes you get lucky and someone's written a Python wrapper already, but most of the time it's faster just to use the C++ (otherwise now you have another library to maintain and keep up to date with the vendor - someone else can do that!).
If you work in web development, it's easy to forget that you can't just write a backend in Python and then make it look snazzy with CSS and Javascript. It's one of the few areas where C++ doesn't have much penetration. That said, browsers are written in C++ (Firefox and Chrome, for example) and of course the web servers themselves (plus some C).
The combination of C++ and Python is very powerful. Modern C++ is very easy to read and if you use the STL, you can write surprisingly compact code. I'm also a big fan of Qt for GUI development (plus the other bits you get with it).
> It's a little like saying what are some good modern uses for Java? Then you remember that millions of people use Android every day.
Of relevance here, millions (or whatever) of developers need Java every day to build Android applications and all kinds of line-of-business applications all over the world
You can't say the same thing about C++, even if developers build ontop of C++ tools. That is the very point I'm driving towards : not that Cpp isn't an important language or ubiquitous, but that 99% of developers don't have a realistic need for it in 2017.
Yes, it's an important language - but only like 0.1% of developers actually have a good reason to use it.
> If you work in web development
Or mobile development, or game development, or desktop application development - i.e. the vast majority of apps that consumers actually interact with don't require much if any C++ development even if they rely on tools written with C++.
I think most of what you write is based on your imagination about C++ instead of facts and the facts are different. There are millions of C++ developers on our planet.
You can't reuse your Java code on iOS. C++ can be reused on virtually any platform. The only other language you can do that with is C and interpreted languages with the interpreter written in C/C++ (which is slow if it is cross platform).
Every time I have to deal with Qt I just want to stab myself in the eye. It is the least intuitive and most difficult environment I personally have ever had to deal with.
This is just factually untrue. Mobile, desktop, data analysis, machine learning and even games : neither are primarily developed with C++ these days.
I imagine you're going to respond with snark about how game engines are written with Cpp, or mention some edge case where a CLR / JVM language needs to call out to native libraries - but there's no escaping the fact it's a niche skill set and one of rapidly diminishing importance to the overwhelming majority of developers.
There are plenty of applications written in C++, from legacy code bases like MS Office to almost all content-creation tools ever, most applications whose abbreviations contain "computer aided", many libraries, and boatloads of applications. Like I said, C++ is used practically everywhere.
Most applications developed on Qt are C++ (some Python). Qt itself has already a large user base.
> data analysis
From matlab to gnuplot, oscilloscope and spectrum analyser software, data analysis applications are frequently developed using C++.
Those toolkits are only useful for edge cases. SDK performance is adequate for 95% of real world applications.
> From matlab to gnuplot, oscilloscope and spectrum analyser software, data analysis applications are frequently developed using C++.
I.e tools that don't need to be re-implemented, some of which had they been built today could easily have been written with a bytecode / JVM / CLR language.
Another tool I'm not re-implementing. You conveniently left out that all of their models are developed with Python - which is what 99.99% of developers interested in ML are trying to do.
My problem with your line of argument in this whole subthread is that no matter how many examples people give you of important categories where C++ predominates, you've already decided that the sum total of all that is "niche".
I'm interesting in your background: which languages do you use, and what kind of programs do you write? Perhaps it'll become clearer whether C++ is any use to you or not.
From the discussion I've read in this thread so far, it seems like you're claiming "what's the point of the entire field of mechanical engineering" when you, personally, just want to drive a car (not build one), fly on a plane (not build one) and so on.
> I'm interesting in your background: which languages do you use
Scala, Java, C#, Obj-C / Swift, Python, JS.
> what kind of programs do you write?
At work : line of business, database / search / indexing systems, mobile apps, web apps
At home : mobile apps, indie games
> it seems like you're claiming "what's the point of the entire field of mechanical engineering" when you, personally, just want to drive a car (not build one), fly on a plane (not build one) and so on.
You've misunderstood. What I'm claiming is that there are very few tasks at hobby-project scale that C++ is ideally suited for. C++ is a language that's used at team-scale, and is no longer an approachable language for the individual.
In other words, with Java you can build Android apps, with C# you can build Unity games, with Python / JavaScript / Whatever you can build web apps.
What can the individual do with C++ they couldn't do easier faster or better with some other language? Maybe embedded systems - but C seems just as effective for that domain. Likewise for kernel development for obvious reasons.
I actually want a reason to use C++, but "well you can work on Photoshop or high performance computing or HFT plumbing software" is not a helpful answer - both for me and anyone else hoping to pick up Cpp in their spare time.
Well if you're looking for anecdotal evidence: my last hobby project (OCR for a specific book+script), I used Mathematica to prototype (fast iteration) and C++ with OpenCV to implement it (way faster execution).
I started the project in Python but switched because it wasn't particularly good at anything vs. the combination of Mathematica and C++. Actually I prototyped it in C++ too before doing some extra analysis in Mathematica only because it had some algorithms that OpenCV didn't.
Are you asking about the ROI in terms of professional career opportunities? Probably three orders of magnitude greater than it is for Rust, D, Haskell, Lisp... or any of the other flavor-of-the-month darlings that HN uses in their hobby projects, but for which few jobs exist in the real world.
Are you asking about the ROI in terms of learning and personal growth? Then it's tremendous. The language that you probably are using (Java or C#) was written because most average programmers couldn't handle the power and flexibility of C++, so industry developed those languages as lookalikes with training wheels. If you've ridden a bike with training wheels your whole life, then aren't you at least curious at some point to see what it's like with them taken off?
If nothing else, then you'll learn why decisions were made the way they were in derivative languages, and become a better programmer overall. It gives you certain amount of confidence to have experience in a language that most people are afraid of.
> Are you asking about the ROI in terms of professional career opportunities? Probably three orders of magnitude greater than it is for Rust, D, Haskell, Lisp
If you're asking me to be specific, then I'd like to compare the ROI of developing greater C++ intuition vs. developing better machine learning intuition.
> If you've ridden a bike with training wheels your whole life, then aren't you at least curious at some point to see what it's like with them taken off?
Like just about everyone here, I've spent years of my life writing C in systems and OS classes. Are the OO abstractions that Cpp layers on top of C really that important for my personal growth? I don't see it unless I have something practical I can use it for.
> If nothing else, then you'll learn why decisions were made the way they were in derivative languages, and become a better programmer overall. It gives you certain amount of confidence to have experience in a language that most people are afraid of.
This is the definition of hand-wavy, and sounds a lot like the reasons the people on HN give for learning functional languages like Lisp and Haskell that you deride so much.
Do you think the suggested books in OPs link are accessible to me if I've only a couple of intro to C++ and Java under my belt?
Universities are a much longer and unfortunately financially inaccessible route for me. Going to try the "build-a-portfolio-and-start-freelancing" approach.
It's hard to know without knowing what your intro to C++ looked like, and what your background is. If you can get through Accelerated C++, then some of those books may be useful once you've gotten some practice.
From http://www.ensisoft.com/temp/cplusplus_stack.png (why is this a PNG and not a JPEG?), Modern C++ Design and C++ Template Metaprogramming are likely to be the most challenging. Don't get me wrong, they are fantastic works, but are probably not what you need right now.
C++ Primer, C++ Common Knowledge, and API Design for C++ are books that I think you should consider that are not listed in the post above. If you have never studied computer architecture it is an important subject to understand. There are good books like Computer Systems: A Programmer's Perspective, but others may have different opinions.
Well I think my intro was pretty rudimentary. My knowledge of computer architecture is as well, I can tell you what pieces do what, and what a buffer is, but I couldn't really tell you how memory addressing, logic gates, instruction sets work.
Is the JPEG question a test? If so I don't know!
The last ones you mentioned sound good, and I think I'll add those to my list and start with Accelerated C++ and see how that feels.
>How many practical, modern use cases does Cpp have at this point for those of us who don't work in a few very specific verticals like finance or game dev?
I understand your reservations but keep in mind that the blog post is intended for an audience that has already bought into C++ programming and therefore, may want to improve their baseline C++ skills.
It's not an an evangelism article to convince those not using C++ right now.
That said, to answer your question directly... I think that programmers who require high-performance code with low-to-zero cost abstractions will self-select into C or C++ ecosystems. In other words, a programmer thinking about writing a web app to track food recipes isn't going to be perplexed about choosing "C++? vs Ruby? vs COBOL?". Like you hinted at, the domain of the app constrains what the programming languages will be realistically chosen.
> It's not an an evangelism article to convince those not using C++ right now.
I get that. Maybe I should have added a disclaimer to that end.
> In other words, a programmer thinking about writing a web app to track food recipes
You're maybe the 5th person who's made thinly veiled barbs about me being one of those despised subhuman web developers, so I'll just answer this once and for all :
Though I have written web apps in the past, I'm not really a web developer. What I am is a developer who builds shit that people use - be it desktop apps, mobile apps, games or web-apps. I don't give two shits if I'm using RubyScript or a goddamn magnetized needle : if I need the tool I'll happily learn it. My only problem here is I can't find a good reason to learn C++. That's all.
No one is trying to convince you to use C++. Obviously the data show there are tons of C++ jobs and this is something you can google yourself. And finance is not a "niche", considering it's like 20% of the US economy. I'm in finance and I write high-performance simulations and pricers. These things need to be predictable, fast, and the code needs to be maintainable. And yes, despite what the prevailing Go or Rust bros say, modern C++ is maintainable.
You've clearly made up your mind, considering you are just arguing random points -- your opinion on finance is not relevant to the point that there are lots of C++ jobs in finance. And it's not just for some legacy reason: even much of Blockchain infrastructure is build with C++ and many crypto jobs that are open today are for C++.
So, I specifically cited finance in my original comment, and yet you come with "yeah but finance..." as if that's somehow revelatory.
Moreover I wasn't asking about job opportunities per se - like you so astutely pointed out I can just search for those. I was more interested in what could I personally use C++ for that didn't involve joining a large dev team working on some unspecified codebase.
- Zero-cost abstractions (you only pay for what you use)
- High-level abstractions (OOP, lambdas, code-generation, etc. )
I would jump straight to C++ 17. It looks completely different to early 2000s C++ and makes functional programming easier (type inference, lambdas, constexpr, etc. ).
If you learn to use C++ well, you will be able to write faster code faster.
I'd love to, but there are simply no (accessible?) resources. I'd love a "how to write C++17 with no baggage" book, but it simply doesn't exist. (please, correct me if I'm wrong?)
I really want to get to know C++, it looks like it's become a fantastic language, but in all seriousness, I could write fast, performant robust Go within a weekend, I'm proficient in half a dozen other languages, and C++ programmers still unironically suggest a stack of books the height of a small table to beginners.
The Book is intended for all C++
developers, regardless of their experience. The
beginner and intermediate developers will benefit
the most from the book in their attempt to become
prolific with C++.
Experienced C++
developers, on the other hand, will find a good
reference for many C++11, C++14, and C++17
language and library features that may come in
handy from time to time.
Zero-cost abstractions (you only pay for what you use)
True in theory and essentially because C++ still remains mostly a superset of C, but unfortunately the majority of C++ programmers I've met tend to overabstract and not realise it, making this claim not really true in practice.
High-level abstractions (OOP, lambdas, code-generation, etc. )
On the other hand, this is definitely true in practice.
The way it works out in practice is people can develop at a high level, and then when its needed you can go back and refactor where necessary for perf. The average performance does become slower though.
I think this notion is out-of-date. Have a look at this slide: https://youtu.be/_wzc7a3McOs?t=21m37s It shows how C++ has evolved away from just "C with Classes".
I agree that many C++ programmers over-abstract things.
I feel like C++ interacts with Python very nicely and so if you're a Python programmer, learning C++ can be very useful. I use Python and common libraries (e.g. numpy) for most things and then write extensions in C++ if that portion of the code becomes a bottleneck. You can use pybind11 or boost::python to do this pretty easily (though I personally tend to use the cpython C api directly myself). I think this provides a very nice balance between programmer efficiency and machine efficiency.
I wouldn't say that C++ is _uniquely_ good for this (C could be used as well as any compiled language that can expose a compatible C ABI which includes Go, Haskell, etc.), but I do feel like the addition of RAII and exceptions matches the Python paradigm quite well.
> I feel like C++ interacts with Python very nicely and so if you're a Python programmer, learning C++ can be very useful.
I'm currently taking Udacity's Self-Driving Car Engineer Nanodegree. Currently I'm on the 2 week "break" between term 2 and 3, which starts on July 6th.
Anyhow, term 1 used Python (and various libraries of course) exclusively. When I signed up, I knew that at some point they were going to use C++ - so I was concerned if my system would need an upgrade (I use Ubuntu 14.04 LTS); but I was assured it would work ok. I was also concerned because I hadn't touched C++ since VS4 (ie - ages ago!) - and I was thinking "will I be able to do this - rusty isn't the word for my skillset in C++".
Term 2 came around, and that's when reality hit - C++ was to be used almost exclusively thru the entire term. Fortunately, Udacity (as part of one of the lessons) gave us a free "preview" of a course they are developing to teach C++ (not sure if it will be free or paid) - and so I went thru that, and found that it was fairly easy! I suppose that my skills in other languages since I had last played with C++ (ie, PHP, Python, Java, Go, Javascript, etc) all worked to make it seem that C++ was "just another syntax". Granted, there are some things which I only barely grok (templates, for instance - but there are several others), but overall, I got things, and was able to successfully finish my projects and complete the term.
Oh - and I had to upgrade my gcc compiler, and a host of other things - because the version of gcc wasn't C++ 11 - which of course is what they were using mostly. So I got to do some unspeakable things to my workstation (and basically fubar'd it so bad I can't do an upgrade any longer - not without some serious work, but I'll leave that to the end of term 3)...
I guess what I'm saying here is that the experience on the Udacity course led me to the agreement with your premise; C++ isn't really that difficult to pick up the basics of if you already have Python (and maybe some other languages) under your belt.
That said - I am looking forward to seeing what Jai brings, if it is ever released to the public...
I'm not sure what you mean by this. Haven't you had the ability to specify as C ABI with the standard golang compiler since 1.5? I don't believe you need cgo. Maybe I misunderstood your comment?
Whether or not you find C++ uniquely useful for more general (e.g. desktop application) programming, it's still one of the most popular languages. There are lots and lots of legacy C++ codebases that are being actively maintained and updated. OTOH the places where C++ is especially well suited may be niche but they also tend to be crucial.
Yeah I agree with this. It got lost somewhere in this shitshow, but I really was just looking for something to use C++ for : obviously I won't be contributing to a legacy codebase or applying for a job maintaining [insert critical software] built in C++ people have cited.
C++ may not be uniquely good for this but most desktop apps you are using are written in C++. When you add C all your operating systems are written in C/C+, most web servers and databases are.
> C++ may not be uniquely good for this but most desktop apps you are using are written in C++
I disagree. Most desktop apps are written with some kind of bytecode language (like my code editors and IDEs) with a few being written in C++ for very specific reasons (like my web browsers).
"Most desktop apps are written with some kind of bytecode language (like my code editors and IDEs) with a few being written in C++ for very specific reasons (like my web browsers)."
That's maybe true for your Dev tools but not for general purpose apps. MS Office, Adobe products, video players and other stuff regular people use are written in C++.
C++ still tops performance charts, beaten only by C, while still offering high level abstractions.
C++, along with C, which you should also know if you know C++ is also used in the embedded software industry. Because it C++ is still essentially C, you write code for these tiny, bare metal embedded systems and still take advantage of some advanced features like classes, templates, etc...
Where I live, C++ coders are in high demand in various fields, just to let you know.
* Infrastructure (web servers and browsers, OS's, drivers, etc)
* Any desktop apps that are CPU/memory intensive. think image processing, video editing, even office applications
* Finance
* Games
* AI. GPUs are becoming more popular for training machine learning models, and C and C++ are pretty much dominating this space with OpenCL, CUDA, etc.
You mentioned in previous comments that browsers and stuff don't really count because you're not going to be implementing a browser that competes with the big four. But people have to work on maintaining those browsers. Same with MS office, Photoshop, etc.
The world pretty much runs on C and C++. From the steering column in your car to the computational fluid dynamics models that predict hurricanes and save lives, to the telephone switches that route your cell phone calls. Until pretty much every important piece of digital technology, small or large, switches over to a new language, there will be a need for C and C++ developers.
> people have to work on maintaining those browsers. Same with MS office, Photoshop, etc.
People do, but I won't be learning C++ to apply for a job maintaining some gigantic piece of software. I never asked about the job market for C++ developers, because there obviously is one somewhere and I can just search the job boards for them.
Implied in my question, or so I thought, is what kind of project can I use C++ for - not what kind of future employment opportunities could I enjoy if I developed professional-caliber proficiency with C++. I was looking for a reason to use C++ as an individual, not as part of the Chrome or Safari team in 5 years time.
What you can do? The same things pros do ;) You won't be maintaining Photoshop but you may be dealing with large opensource software written in C++.
And what is good for the pros is good for you too. There is a small caveat about game dev though. While C++ is probably the best language for writing game engines, if your plan is to write an indie game, this is probably a bad place to start. You should probably pick up an existing engine and build your gameplay on top of it using the associated scripting language instead. Writing your own engine can be both fun and instructive but it is not the easy path towards a complete game.
> Writing your own engine can be both fun and instructive but it is not the easy path towards a complete game.
Yeah, definitely not and it's kind of an insane undertaking IMO given how full featured engines & frameworks like Unity have gotten.
Maybe I need to take another look at Unreal, given that C++ is sort of the first class dev language for the framework - for now at least.
This is something I've sort of been poking at this entire thread : there are fewer opportunities for developers to use lower level languages (aside from at work, if the job calls for it - but numerically speaking most jobs don't call for systems-tier languages anymore). Many of our day jobs involve higher level languages (which in my case means Scala), and for the overwhelming majority of solo projects there are languages that are quicker / easier / more effective to ship with than say C++.
Just an example of a job I did 2 years ago.
It was for a company that did stuff related to digital signatures on official documents. The part that deals with smartcards is written in C++. They are mostly a Java shop, not C++, and that's why the called me. This is an example of "off topic" missions you can find.
Personally, I mostly work around embedded/industrial systems and everything that goes with it such as test and simulation tools. I know some people who work in scientific computing and C++ is used in this domain too.
I think the performance crown still belongs to Fortran. The compilers have it much easier to squeeze out all the performance. Then comes C, and C++ (if used sensibly).
That's correct, and if I wanted to write a new web browser designed to be performance competitive against the big 3/4 I wouldn't have asked this question to begin with.
Just replace that Josuttis's C++ standard library with C++11 version and throw in Mayers new effective book for good measure and you're all set