Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I learnt C++ in 2018 and have no regrets

vishnubharathi.codes

Post reply on HN
Print view View original

201–210 of 259 posts

Re: I learnt C++ in 2018 and have no regrets

#201

Post by buovjaga »

RealityVoid wrote: post #196
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Meson is much easier to use and configure for C++, being quite obviously designed specifically with C++ builds in mind. It automagically does the right thing for setting up most C++ build environments by default with virtually no config or quirks you need to learn. It is built on top of Ninja, and generally very fast and efficient. The only real knock against it is that the documentation isn't as good as could be, an…

How would you evaluate Meson as a build system for C projects? I _think_ C and C++ build process is very similar, but I only work professionally with C, so maybe there are some quirks to C++ I am not aware of. Basically, I wonder if you would recommend Meson as a build system for a mostly C project with maybe some C++ parts and some extra external tools ran on top.

Plenty of C projects use Meson: https://mesonbuild.com/Users.html

Re: I learnt C++ in 2018 and have no regrets

#202

Post by mikepurvis »

Jare wrote: post #188
mikepurvis wrote: post #170

Earlier quoted context omitted.

Some subset of those decision are also things which just don't matter, like which side of the road to drive on— the value is in a critical mass of people all doing the same thing more than it is in the merits of either approach. A lot of stylistic stuff like filesystem layout falls into this bucket.

Bless standard formatters (gofmt, etc) becoming the norm.

Appreciating this lays out the boundaries for the the more borderline stuff. An example of this, IMO, is things like unit testing and mocking frameworks. Most are pretty similar, and offer similar functionality, but perhaps with slight differences in capability or approach to solving common corner cases.

You might have some highly-specific need which demands a particular tool, but it's likely that you're best accepting whatever is most popular in your chosen ecosystem (gtest for C++, nose/tox for Python, etc).

Re: I learnt C++ in 2018 and have no regrets

#203

Post by pjmlp »

lmm wrote: post #71
sl1ck731 wrote: post #56

Earlier quoted context omitted.

I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. 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. I wish I had stayed with it since college b…

Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.

Rust is still miles away from providing any useful COM/UWP tooling.

Re: I learnt C++ in 2018 and have no regrets

#204

Post by pjmlp »

Const-me wrote: post #186
lmm wrote: post #71

Earlier quoted context omitted.

Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.

> work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM…

Delphi, JavaScript, Python and C++ Builder as well.

Re: I learnt C++ in 2018 and have no regrets

#205

Post by pjmlp »

zanny wrote: post #66
mempko wrote: post #52

Earlier quoted context omitted.

Most projects use CMake now so it seems the community is starting to coalesce around CMake as the "not official" build system.

Thats besides the growing number using Meson instead.

Meson is hardly used outside GNU/Linux.

Re: I learnt C++ in 2018 and have no regrets

#206

Post by pjmlp »

goatlover wrote: post #62
blub wrote: post #19

Earlier quoted context omitted.

What language can one say that they fully master? I've been using Python since 2008-ish on and off for various scripting tasks and small tools, I can't say that I've "learned" it. They keep adding new stuff, some things I forgot, others I never needed. I've been using C++ professionally since ~2006 and for similar reasons I won't say that I master it either. Metaprogramming is a clear weak point for me, but OTOH I fi…

But you don't hear people make the same sort of comments about languages like Go and Scheme. There's a continuation from complex to less complex and C++ is one one end of that.

No, I hear people complaining about writing boilerplate by hand (Go), not knowing with libraries to use, incompatibilities between libraries or political discussions about what the standard library should be (Scheme).

Re: I learnt C++ in 2018 and have no regrets

#207

Post by pianoben »

anuragsoni wrote: post #23

"To round up, C++ does not dictate about its tooling, which basically gives lot of choices and flexibility. But at the same time it is making it complex for beginners to come in to projects and start projects with it." This was a big problem for me when I first started using C++. I don't remember it being too bad when I was just working on small projects and things I wanted to do at school. The problems started when…

This is why I'm so happy about Bazel lately! It cleanly solves a number of tooling pain points for me: - Cross-platform builds mostly "just work" - Package management, while not painless, is a tractable problem. You can teach your build how to incorporate libraries from tarballs, local filesystem, git repositories, et. - Support for common toolchains (gcc, clang, msvc, android, ios) is built-in!

After the hellscape that is CMakeLists.txt, Bazel is such a breath of fresh air. I'd encourage anyone looking at C++ for new projects to give it serious consideration.

Re: I learnt C++ in 2018 and have no regrets

#208

Post by lmm »

HelloNurse wrote: post #190
lmm wrote: post #86

Earlier quoted context omitted.

Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are un…

All the complications you list derive from the peculiar C++ language design principle of ensuring high performance despite sophisticated abstractions; popular languages are simpler because they stop at basic abstractions (e.g. C and Forth) or because they trade performance for elegance (e.g. C# and to a higher degree Python and Smalltalk). C++ does more at a higher cost, and in recent standard updates the cost has be…

> popular languages are simpler because they stop at basic abstractions (e.g. C and Forth) or because they trade performance for elegance (e.g. C# and to a higher degree Python and Smalltalk).

I'm not convinced. C++ offers some abstractions but is also missing some quite basic ones (no sum types, no true parametric polymorphism, polymorphic code can only be typechecked once fully expanded). ML-family languages offer substantially better abstractions at minimal performance cost or, in the case of Rust, no cost. Even for GCed languages my experience is that at practical levels of developer effort C++'s high performance on benchmarks is outweighed by the language complexity burden (e.g. Haskell code that solved the same problem as C++ code was not only shorter and more maintainable but also substantially faster; no doubt if we'd carefully hand-optimized every line of the C++ it could have achieved higher performance, but even unoptimized C++ took much longer to write than the Haskell solution).

> C++ does more at a higher cost, and in recent standard updates the cost has been steadily decreasing.

The big cost is the complexity of the language, and since the language rarely if ever removes anything standard updates usually add to that rather than reducing it.

Re: I learnt C++ in 2018 and have no regrets

#209

Post by lmm »

AnimalMuppet wrote: post #194
lmm wrote: post #86

Earlier quoted context omitted.

Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are un…

It seems a bit odd to complain that C++ doesn't support garbage collection. I mean yes, it's true, but... part of the point of C++ is to give you control of memory.

Sure, but certain programming techniques become impractical without garbage collection, and a general purpose programmer would be expected to be familiar with those techniques. E.g. C++ programmers tend to just not learn graph-based models/techniques because they're not a practical way of working in C++.

Re: I learnt C++ in 2018 and have no regrets

#210

Post by lmm »

unclewaltr wrote: post #165
lmm wrote: post #70

Earlier quoted context omitted.

Examples? As a maven advocate I've commonly seen this claimed ("we have to have an ant build because we need to do x/y/z custom thing") but I've never seen an example that held up under scrutiny. E.g. there's no reason any project would ever need a custom source directory layout. No project needs to run tests before compile (and if you really need build step x to happen before build step y, you can always separate th…

As one (slightly abnormal) example that I've worked on. We would build the meat of the solution, then run our tests. Upon success, we'd generate language bindings (think swig), compile them and run API tests against those. The languages included C++, C#, Java and Excel 12 bindings (which required their own .cpp files). I can easily see this type of special case worm its way in to larger projects and be valid, yes.

> Upon success, we'd generate language bindings (think swig), compile them and run API tests against those. The languages included C++, C#, Java and Excel 12 bindings (which required their own .cpp files).

Sure, so you need support for a multi-module project. Any serious build tool will have that.

Post reply on HN