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 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.
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.
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.
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, ...).
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).
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?
https://www.theregister.co.uk/2016/03/31/microsoft_visual_st...
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?
> 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 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.
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.
> 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.
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.
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.
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'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.
)
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.
https://giantfublog.wordpress.com/2016/10/15/portability-in-...
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1 USE_OPENGL=1 CXXFLAGS=-fno-keep-inline-dllexport
works on multiple machines for me, I write openGL GUI apps.
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.
[1] - http://www.bloodshed.net/devcpp.html [2] - http://www.codeblocks.org/ [3] - https://codelite.org/
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.