I studied C++ during university days and after that I never got a chance to learn it seriously due to my job commitments as a web developer. I did work on C# but not C++ professionally. I always admired my friends who could write good C or C++ code. So many times I wish to learn it seriously but these new editors for web development and Python made me lazy enough that I wish to have some environment and way to write…
I learnt C++ in 2018 and have no regrets
221–230 of 259 posts
Re: I learnt C++ in 2018 and have no regrets
#222I tried rust, but they keep changing it and breaking modules i need to use!
Re: I learnt C++ in 2018 and have no regrets
#223Earlier quoted context omitted.
> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each…
For building my (rather small) projects for Windows I use MSYS2 [0]; it uses pacman for package management and has quite a big library of ready binaries. [0] http://www.msys2.org/
Re: I learnt C++ in 2018 and have no regrets
#224Earlier quoted context omitted.
> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each…
Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore. I do agree that there is a lot of room for standardizing tool chain and…
Re: I learnt C++ in 2018 and have no regrets
#225Earlier quoted context omitted.
Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain. Fundamentally: the codebase has worked perfectly well this way for the…
> Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory…
I happen to work in a shop with problems that look somewhat like this. We have a non-trivial amount of legacy code, that we just don't have the resources or motivation to fix. In those cases, we've found that the cohesion of doing it the same (wrong) way everywhere is easier to work with than doing it the new way in some places.
Re: I learnt C++ in 2018 and have no regrets
#226Earlier quoted context omitted.
Some of these codebases have 10s of millions of lines if not more. Such a refactoring could take years.
The benefit of using widely supported tooling is even greater for large codebases. Automated reformatting is easy, and moving code around isn't that hard if it's going hand in hand with a build system that supports it. Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.
Your assertion really depends on your definition of "widely supported". Jumping from fad to fad, however, is only effective as a way to waste time.
>Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.
Using established build systems for C++, whether autotools or even plain makefiles, ensures that the project doesn't suffer from bit rot and developers can focus om developing code instead of wasting their time trying out every flavor of the month. And do note that the main reason C++ hasn't adopted any official build system is that each and every flavour of the month ends up being very horrible and very hard to maintain.
Yes, including CMake. If a build system is known for telling essentially all users that they are doing it wrong, that means the build system is the problem.
Re: I learnt C++ in 2018 and have no regrets
#227Earlier quoted context omitted.
Oops. Sorry. I had completely forgotten HN markdown. I usually use the underscores around book titles with cleartext in mind. I'll remember asterisk in the future.
> I'll remember asterisk in the future. Aaand you've just learned all the formatting HN has :). That, and URLs automatically turn into clickable everywhere except the body of a self-submission (i.e. submitting a text instead of a link). Any other formatting here is just convention.
Re: I learnt C++ in 2018 and have no regrets
#228I learned it this year, with cmake. Then i moved onto go. I tried rust, but they keep changing it and breaking modules i need to use!
If you find your dependencies are breaking:
• Keep a lockfile (Cargo.lock) committed in your project, so that your deps won't suddenly get updated to some newer, potentially buggy/incompatible version.
• If you're updating dependencies, also update the compiler. It's possible that new versions of dependencies require latest version of compiler.
Re: I learnt C++ in 2018 and have no regrets
#229I've learned 15+ years ago, and I stopped paying attention around ~2010, which is just before significant changes were made. Even though I read up on some features and concepts from C++11 and C++14, I feel so disconnected from what's going on as if what I learned was a completely different language. Can anyone recommend any source for someone with lots of pre-C++11 experience to get up to speed with current capabilit…
The combination of "auto" (plus template type inference), ranged for-loops, initializer lists, structured bindings, lambdas and certain new standard library mechanisms (std::unique_ptr, std::variant, std::optional, std::move, etc.) together change the high-level expressiveness of the language, encoding a lot of common patterns and eliminating common, redundant code. For example:
std::vector values = {1, 2, 3};
for (auto v : values) { ... }
New for loops support structured bindings: for (auto &&[key, value] : mapOfStuff) { ... }
There's a lot of little conveniences, such as the ability to define a default constructor, or accept a initializer list in the constructor: struct Foo {
Foo(std::initializer_list values) { ... }
}
Foo f = {1, 2, 3};
or indeed named initializers: struct Person {
string name
}
Person p = {.name = "bob"};
The forthcoming range library in C++20 also finally make lazy sequence iteration functional and composable, e.g. something like (off the top of my head): getNumbers()
| view::filter([](int a, int b) { return a > b; }
| view::reverse()
| view::take(10);
Another big change that's coming is concepts, which are somewhat similar to Rust traits or Haskell typeclasses: The ability to put compile-time constraints on template arguments. For example, in classical C++, invalid template invocations generate notoriously bad error messages, since templates are only compiled once they have been expanded with their arguments: template
T add100(T v) {
// Compiler will fail on this line:
return v + 100;
}
auto n = add100("hello world");
Concepts will let you constrain T to something that actually supports the operations you need: template
T add100(T v) {
return v + 100;
}
// Compiler fails on this line:
auto n = add100("hello world");
Then there's the contract spec, which adds support for Eiffel-type contracts.Lastly, C++ designers seem to have thought a lot about safe memory semantics, and so there's a renewed focus on smart pointers (that actually work) together with move semantics and tightening of cop constructor semantics. The end result is that it's generally easier to work with RAII and avoid explicit heap allocation with the "new" keyword.
Re: I learnt C++ in 2018 and have no regrets
#230I've learned 15+ years ago, and I stopped paying attention around ~2010, which is just before significant changes were made. Even though I read up on some features and concepts from C++11 and C++14, I feel so disconnected from what's going on as if what I learned was a completely different language. Can anyone recommend any source for someone with lots of pre-C++11 experience to get up to speed with current capabilit…
There's nothing really fundamental to the changes in C++11 and beyond: There are lots of little tweaks, as well as some deprecations and outright removals. However, there's the prevailing sense in the community that the many tweaks together genuinely change the flavour of the language, at least from the perspective of traditional C++ development. The combination of "auto" (plus template type inference), ranged for-lo…