Hacker News Reader

Comment by rychco | Hacker News Reader

I’ll offer a perspective unrelated to pay: It’s a pain to start learning C++, and even after you do, older devs will roast the hell out of your code because your book/tutorials of choice forgot to mention a crucial (in their opinion) feature that you absolutely should/shouldn’t use! Not to mention you’ve only programmed on Mac/Linux so far & windows is totally different, has a different compiler, different ways to install libraries, different C++ standard features supported, etc.

I like C++, and tooling has come a long way, but it’s so much easier to download rust/Python/node and you’re basically set on every platform & immediately ready to go. NOW consider pay, and even someone enthusiastic about programming C++ will reconsider.

View on HN

As a C++ enjoyer I would 100% have learned Rust if it was around when I started... just for Cargo alone.

Problem is now I've already done my time in the Makefile trenches there's little incentive in me re-learning another systems lang and having to compete with lots of smarter people, with more Rust exp, for jobs whilst giving up all my arcane knowledge of CMake and friends.

Rust being popular atm is great for C++ if I'm honest as it siphons away a new gen of systems programmers over to another lang allowing me to sell my dark services for more coins.

I did my time in the Makefile trenches, too. I'm happy that I've learned other languages. There will always be smarter people than you, but you will bring your particular knowledge and do new things. Keep on learning!

I wonder how the Cobol market is doing?

The funny part about cobol is that even if you say you know the syntax, there is site specific implementation details/features which are even MORE critical than just the language.

If you have time, I would really love to know examples of this. This is very interesting.

See: New Jersey State Unemployment Insurance.

My favourite example of this is that you have to recompile program when a used table schema changes, otherwise it will crash.

edit: Just realized that it's more platform specific than site specific.

I was a Cobol developer for a year in 2016 in Prague. It's hard to make a proper market research because the Cobol market is small. My limited point of view is, that it's not worth the stress. There is nothing new to build with it and young developers are there just to replace the old ones and maintain what's left. Even that it's hard to find a Cobol developer, i couldn't find a Cobol position that would pay more than a React developer.

The incentive is to do it for the greater good. For a safer, better future.

> it siphons away a new gen of systems programmers over to another lang allowing me to sell my dark services for more coins

I've always been curious about whether it really works this way. First order, one would consider supply and demand leading to increased wages. But whenever I've looked into the reports of "COBOL programmers are getting paid a fortune because there are so few of them alive!", the reality has been that wages are ... unimpressive.

My hypothesis is that as the talent pool shifts elsewhere, the market dries up. For instance, new projects aren't started in COBOL any more (well, at least anywhere I've seen...). You're left doing maintenance on ancient systems, where the calculus is always "this needs to be cheaper than a new solution". Maybe it's the "liquidity" of the job market for a given language?

No doubt, though it's worth considering the tech industry is a bit more diversified now than the days of COBOL number crunchers and Space Invaders. What you're describing seems closer to PHP vs. Javascript than something as entrenched as idio-matic legacy C++.

And heck, if I'm wrong I'm sure somewhere like AWS will entomb me as an SRE, or some such, so even long after I'm RMA'd my spaghetti abominations can continue to haunt the cloud.

you have picked up so much meta knowledge (debugging, testing, build optimizations), domain understanding and soft skills that making the switch might be less tough than you think. Plenty of coins in Rust land, too!

This. Learning the language as a whole is an incredibly daunting task. It's ugly, it's built on a combination of OOP and procedural C and quite frankly, the class syntax in combination with header files has aged pretty bad. I feel like I have a lot of code I need to write twice.

The standard committee keeps tacking on new features and decade old footguns are promised to never be fixed (and somehow, people consider this a feature).

Tooling is even worse.

It's only ugly because it was meant to be a federation of different programming paradigms. You can mix low level C calls with homegrown RAII frameworks, or mix traditional OOP with functional programming. Once you start throwing in preprocessor macros, meta programming, and templates, you can have a codebase that is incredibly complex to understand and maintain.

As for the header/implementation separation, I always thought it was a good idea to have that flexibility. I've worked in codebases where the compilation units were fairly large and complex and would be implemented in separate files. This would be similar to partials in C# I've also worked with some code that would determine the target compilation units at build time. Not saying it was the best approach at the time, but it was one option.

If anything scares off people from C++, it would definitely be the breadth of the language, though. You could work in C++ for over ten years and possibly not even encounter or use half of the functionality it provides. And because of it's breadth, going from one C++ codebase to another could look completely different. Especially when looking at something written for a Unix/Linux/Posix system vs Windows.

Templates and Lambdas. Woof.

templates are one of the best features of c++. they're complicated because they're powerful. they certainly aren't perfect, but you won't find anything like them in other popular languages.

I coded in C++ professionally for about 15 years and don't remember it would be "incredibly daunting". Not easy, but doable. But yes, I also exited the pool, now I work in Golang and just wouldn't go back to C++.

As someone who has been writing C++ at Google, this exactly. Despite all the tooling, guidelines and "internal magic", C++ is still an abomination. And no it has nothing to do with memory management, I actually do like C.

I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason).

>C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason).

And what can be used instead of C++? C? If C was better, then C++ wouldn't have been invented. Rust? It's much more painful to use than C++. Zig? It's immature and has very low usage. Nim? Has very low user base. Julia? It isn't solving the same problems.

Mark Russinovich (of Sysinternals fame), thinks Rust should be the non-GC language of choice moving forward.

https://twitter.com/markrussinovich/status/15719951172335042...

If people think C++ is hard to learn and attracts opinionated people boy are they in for a surprise when they start using Rust.

Rust is way easier to learn than C++.

Until one needs to deal with async/await, write GUI code, the upcoming GAT, or macros.

Except that the C++ substitutes for those features (where applicable; C++ has nothing like GAT, and has to make do with complex template meta-programming) are a lot harder too.

C++ has had GAT like capabilities on templates since forever.

Complex template meta-programming only if one is stuck in pre-C++17 compilers.

Learning rust is like cycling over 2 big hills. It’s exhausting and painful if you’re in any way out of shape.

Learning C++ is like cycling from SF to LA. It starts easy enough and every day you’re making a lot of satisfying progress. But you have so far to go because of all the features and quirks of the language.

It’s probably easier to get started learning C++. But it’s also much faster to finish learning rust and be able to read almost all rust code. (Pin still scares me though)

I like the analogy!

I’m still not comfortable with Pin, UnsafeCell, raw FFI (lifetime and ownership handling across the boundary is tricky), and complex macros. But I also think that you don’t need to understand these at all to be an effective Rust dev.

I like you're analogy, but I do think there are features of c++ that are big hills as well. To me it would be SF to LA with some big ups and downs on that long ride.

I'm also curious what's difficult about pin in rust? It basically just disables moving of the object for the lifetime of the pin.

> I'm also curious what's difficult about pin in rust?

I understand the concept. It’s the syntax which trips me up. You don’t mark structs as Pin. You mark them as !Unpin. And then, when is it safe to pin_project fields? Every time I read the documentation I understand it for about an hour. 2 weeks later I need to re-read the docs again to convince myself I’m not subtly messing anything up.

I’ve also gotten myself in hot water writing custom Futures, trying to wade through the barrage of compiler errors at the intersection of lifetimes, Pin and async. It’s a lot harder than it needs to be. The compiler holes around GAT, async closures and async trait methods doesn’t help.

You forgot to mention that someone mined parts of the roads from SF to LA.

More like NY to SF. The Appalachians would be when you're first learning pointers and the Rockies would be about the time you hit the STL and friends.

You have to learn pointers in Rust too and I don't think the STL is any more complicated than Rust's standard library.

Regular Rust code uses references almost exclusively. (Unless you're working in kernel space or building fancy data structures.)

The big difference between C++ and Rust is what happens when you get something wrong. C++ has lots of undefined behavior and nasty surprises for the unwary. (I led a C++ project for a decade and saw it all.) In Rust, if you get something wrong, the compiler typically refuses to compile it. Which is also very frustrating, but the frustration is all up front.

Having cut my teeth in Z80 Assembly, I could never understand people's aversion to pointers. You cannot do anything of any practical use, on hardware, without them.

rust doesn't have many of the features of c++, so it seems easier until you realize it's not.

It would also be easy to get started learning Rust, if people cared enough about doing it. The best way to learn Rust as a first programming language is to start with pure value-oriented programming at first, liberally using .clone() when necessary. Then introduce borrowing, with shared and mutable references; continuing with features involving interior mutability (Cell, RefCell etc.).

This is admittedly quite different from the way people usually learn C++, but it makes sense on its own terms. It's much closer to how higher-level languages like ML and Haskell are taught, and people have successfully learned those languages in introductory programming courses.

Microsoft has apparently ported DWrite to Rust (the C++/WinRT team is now having all the fun in Rust/WinRT, while ignoring the lack of tooling in C++/WinRT after they killed C++/CX), Azure IoT unit is adopting Rust on Azure Sphere alongside C while not supporting C++, and at Ignite Mark Russinovich did mention they are planning to port some sysinternals tools into Rust as kind of POC.

I do not think so, though.

I do respect Mark and his Sysinternals products. However I could not care less what he thinks is the language I should be using. I choose what works for me and as long as it brings me healthy dosh I am not in need of one's "approval.

> Rust? It's much more painful to use than C++.

Unless you're doing something really highly specific to C++ (like Cuda for instance or deep integration with big C++ codebase), saying that rust is painful compared to C++ is laughable.

Gonna have to unwrap() this take

I'll just ignore this take and let it become a problem later.

.expect("fireworks")

Julia is solving many of the same problems as C++. GPU compute, HPC, high performance algebra kernels are all well within Julia's purview. It's not (at least yet) good for things like writing OS kernels but there is a large amount of overlap with C++.

Isn't Julia a dynamically typed language?

Yes. So what?

Then it is not a replacement for C++. It's going to be slow.

it's not. it uses type inference to infer types and llvm to compile down to native code. differentialequations.jl is often faster than the fastest C and Fortran solvers, and Octavian.jl often beats MKL at matrix multiplication.

Type inference changes things. It's awesome that it can beat handwritten C and Fortran code.

Static types are not required for things like type inference and optimizing compilers. It's just that many dynamic languages are not written with performance in mind, and have semantics that make optimization impossible.

Julia was designed from the ground up to have C level performance, and well written Julia code does that easily in throughput focused scenarios.

Julia's intermediate representation which it compiles dynamic code down to is statically typed, and any dynamism just manifests itself as the compiler waiting until the types are resolved at runtime before running again and generating new specialized code.

If your code is written so that the types are all inferrable, there's no pauses.

Yes, but it's strongly typed, which is more important.

Yes but C++ is strongly and statically typed. Julia is not even running in the same race as C++.

While being written in C++, so it can't make C++ go away in those domains.

llvm is c++ but almost all of Julia is written in Julia. codegen and the subtyping algorithm are the two main things written in C/C++.

Indeed, that doesn't change the matter that Julia depends on C++ until the day someone bootstraps the whole toolchain.

I don't think that's true. I started C++ using the 'cfront' system, the major push wasn't because C was somehow lacking, it was because it was fashionable to do object orient programming which is hard in C. Various horrible patterns were invented using function pointers so C programmers could feel like they were doing object oriented programming and all of them sucked.

When cfront turned up, the first versions basically automated that suckage. C++ did get better, but it was still horrible compared to CLOS or Smalltalk. This was largely due to weirdness in how the constructor/destructor ordering worked, the giant bogosity that is multiple inheritance and a few massive other undefined behaviours that every compiler did differently, but I think at this point it's fair to point out the language is bad and things like C# are so much better it's not even funny any more.

Yes, OOP kind of sucks. But you can use C++ without OOP if you so wish.

C# is much better but still it isn't a systems programming language due to garbage collection. So while you can solve some classes of problems easier and better, it can't replace all of C++ use cases.

That depends on the point of view.

Writing compilers, linkers, running bare metal on embedded hardware are all systems programming tasks.

> And what can be used instead of C++?

For most use cases Java is a better option. Very fast, without any of the pain.

If you truly must not have a VM (rare), there's still C. Perhaps rust.

I think this is probably the most salient point. C/Rust then Java. I don't know why people hate on Java so much. And I think C lives fine along side Rust.

Java forces OOP and it's verbosity is worse than COBOL.

> Java forces OOP and it's verbosity is worse than COBOL.

Java doesn't force OOP in any meaningful way. I mean it does, in that you need to wrap all code in a class, but that's a non-issue (one line of code at the top and a closing bracket). You can write Java code where all functions are static and do nothing is object-oriented, when that's the best match for your needs.

On verbosity, you can latch on to the ConstructorAccessorMapFieldGetterFactorySingleton nonsense if you want but that's on you. Nothing in the Java language forces that on anyone. Having been writing Java code since 1996 I've never written such code.

Java is based on Objective-C without any of the nice flexibility, doesn't have value types, has C-like numeric types except they're less flexible yet not any safer, and its culture thinks you organize code by putting it into 6+ layers of namespaces inside other namespaces.

My rule is that languages are good if they have value types, which explains why PHP is good.

C# also has value types and structs. Also a bonus over the top fanboyism is absent.

Java is not very fast compared to c++, or you'd see it in embedded systems all over.

what's fast really depends on lot on what you are building - without more details about the challenge at hand any statements about performance are unhelpful. A huge backend system? The logic in a toaster? A space ship?

> Java is not very fast compared to c++, or you'd see it in embedded systems all over.

Those are quite different domains, with only minimal overlap.

Embedded systems more often that not are not seeking maximum performance. What matters is smaller code size and running on mimimal hardware. Java doesn't do so well there since you have the overhead of the VM. Java is rarely a sensible choice for embedded code. Just use simple C, or rust if it works for the use case.

(Yes I know project green was originally about embedded set-top boxes! But times changed.)

Performance critical systems are usually large servers for either high througput (web or other server traffic) or low latency (HFT) applications. The opposite end of the spectrum from embedded. That's where Java shines. You might be able to beat Java with carefully hand-tuned C++ but just as likely the JIT might beat you. So for maximum performance server code combined with a more sane developer productivity, Java cannot be beat.

I understand, but the topic of this article is about embedded systems. Java is not a player here.

> Rust? It's much more painful to use than C++

Write a sufficiently complex memory safe program in C++. I dare you. It's been proven again and again that humans can't do it. And calling Rust more painful than C++ is just absurd.

> Write a sufficiently complex memory safe program in C++.

That is totally easy.

What's not so easy, necessarily, is complex numerically safe program in C++ (that performs well).

I write them routinely. Many, many people write them routinely. It is easy, in modern C++.

You appear to have fallen for the Rust hype machine.

We do know many people at Google can't.

> Rust? It's much more painful to use than C++.

As someone who has used C++ professionally for two decades, I disagree. Rust's pain is superficial and all up front. C++ pain is death by a thousand paper cuts, especially if you have people on your team that aren't intimately familiar with its pitfalls and its more modern constructs. I don't plan to write a new C++ project ever again, unless there's some very compelling reason to do so. Rust is an absolute breath of fresh air.

> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason).

It's quite a bit easier than Rust and no other popular language has its most important features (cross platform, interfaces with syscalls and other libraries easily, manual memory management possible, likely to be supported for a long time).

Having used both C++ and Rust extensively, I would say that it is easier to get something to compile in C++ than in Rust, but I find Rust overall much easier. C++ is really very complex, and even after more than a decade of using it there are so many things I don't know. With Rust I feel like I have a pretty solid grasp of most of the language.

I agree.. I've been writing in Rust for about 2 months and I find it to be a much easier surface than C++.. getting over the borrow checker isn't as bad as some make it out to be.. in fact, if it compiles it largely works.. you might be cloning one too many strings as a newbie, but you get the hang of it quickly.. when I wrote a lot of C++, I used a really small feature set.. but that was like 20 years ago.. now (apparently) it's a lot better.. with Rust, you need to think about memory, stack, and heap, but it's not ridiculous. The type system is really great. Granted, I'm not writing a database, but so far, I see a lot of really good libraries that integrate really easily, and it's just fun to use. The functional features and futures feel a lot like scala... and it's fast.

oh and the last time I wrote in C++, I was using gmake.. all those compiler and linker switches.. header and linker search paths.. ugh.. I felt like I was launching a rocket to the moon just getting some of that to build. don't miss that.. chasing down memory corruption in threads with gdb.. also painful. I get that C++ is much better now, but I haven't really used it in a long time so can't comment.

Yes, but when you want to do linked structures, really generic code without repetition or decent compile-time programming, then C++ is very powerful at that.

These things are useful in many situations.

Sure, but I wouldn't say that's easy.

I have found table-generation and processing at compile-time to be of big help.

For example, pre-computing values or parsing at compile-time.

This is useful for example in the following situations:

- You want to embed things at compile-time but keep things apart in a file. This file can be used at run-time when developing but is embedded and literally vanishes (you put your config directly in a struct) when deploying. - You do not want to spend extra time at compile-time. - No need to protect data at run-time with mutexes, etc.

The simplification it can yield is not immediately obvious. It can take a bit more work but the result is worth it. D is more powerful than C++ at this, btw.

It _looks_ easier because it lets you do anything you want. C++ makes you feel like you're going faster, but then you spend two weeks debugging a weird memory issue.

I come from functional programming background, so I'm all for taking a little bit longer to make my code compile if that means it'll work. I'd rather deal with compilation errors than waking up at 2am to debug a stupid segfault.

> but then you spend two weeks debugging a weird memory issue

this is not true anymore 90% of the time if you code with a decent knowledge... if you code C, then yes.

C++ has improved a lot over the past decade or so. Compilers can add runtime checks now that make most memory bugs easy to detect and diagnose. C++ has plenty of warts and legacy stuff that you wouldn't keep if you were designing a language from scratch, but it is way better than it used to be and there still isn't anything that fills the same space C++ targets. Rust tries to but IMO it is too opinionated.

> It _looks_ easier to me because it lets me do anything I want. C++ makes me feel like I'm going faster, but then I spend two weeks debugging a weird memory issue.

FTFY!

> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason)

Too bold statement. There are still lots of reasons to keep using C++. LOTS.

I can see why for legacy projects, but for new projects, what are they?

There are lots of reasons to keep using C++ on existing projects in C++ but there are not many reasons to choose C++ for a new project.

This is exactly equivalent to saying that all existing C++ coders should be demoted or fired.

It is, among worse things, damned rude.

The only thing worse would be if you were a C++ programmer in the coal industry...

how does that look?

That's only true if you're writing code with zero dependencies, which is rarely the case.

Not only that: toolchains, IDEs, static analyzers, mature frameworks for Protobuf, Capnproto, C compatibility, Python wrapping of APIs including little friction: deriving classes and exception conversion in pybind11 for example...

There are lots. It is just that some ppl think real world is just like when they sit down to code a zero-dep, no time-pressure thing.

Over C, Assembly, Rust, etc.?

This is exactly equivalent to saying all existing C++ programmers should be demoted to doing only maintenance work, or fired.

As such, it is in violation of site terms and conditions, and damned rude.

If you take criticism of any activity you partake in as being "damned rude" and a violation of site T&C, then there'd never be any discussion at all.

You are not your job, and prepare yourself for listening to honest criticism of the things you base your identity around or you will find it very difficult to learn and grow.

It was not the criticism that was damned rude. Criticize anything you like, or don't.

What was rude and, frankly, hateful, was the call to demote or lay off all C++ programmers.

Apologies if it came as rude or hateful, that wasn't my intention.

Funny thing is I'm a C++ programmer myself right now as I mentioned :) Even if we decide to "deprecate" C++ today, Google alone would have large enough C++ codebase left to maintain for the next two generation of programmers.

So no, I don't think it means we should demote or fire all C++ programmers -- but at the same time I'd like to note that as a programmer no one should be married to a single language -- languages come and go.

There's also the opposite problem: older devs will use outdated features and have best practices in place that are now considered antipatterns. This exacerbates the existing difficulties to modernize legacy code bases and creates incentives to not do so. New devs are forced to learn C++ from 20 years ago which is much worse than modern C++.

The difference between C++ today, and what we had 20 years ago is not much. C++ has functionality built in today, we didn't have, but the OS provided, and now the language has many features we wished we had years ago.

Example: Variadic templates. When that happened, the problems we would bang our head against the wall with magically vanished. Twenty years ago, every implementation of the std library had serious bugs in it. It was avoided. Not the case today. I remember a std::map iterators not working. Watcom's C++ had serious flaws with it, but many exciting products were still created with it.

We didn't complain. We were happy, and worked around our problems.

I think the root of peoples issue with C++ is with template meta programming portions of it, which you can completely ignore, and grow into.

Template metaprogramming is hardly ever needed anymore. C++20 has better built-in features that for most of what was done with it, that compile much faster.

Almost all C++ programmers completely ignore it. You can too.

New way? You mean, expanded.

template metaprogramming is used extensively in libraries. c++20 didn't really change that; it makes metaprogramming nicer to read, but it does not obviate the need for it.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers.

I'm still wondering why `(int)` is spelled `reinterpret_cast<int>` in C++. Do they just like hitting keys on the keyboard?

> I'm still wondering why `(int)` is spelled `reinterpret_cast<int>` in C++

1. because it is greppable and unsafe

2. because there is also static_cast and dynamic_cast

3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast.

All in all, it is nice to ask, but if you do not know what you are talking about except for the surface, then, you should not say:

> Do they just like hitting keys on the keyboard?

No, we do not, but we hate even more to get an ungreppable, undecipherable (semantically) casting lost somewhere in several tens of thousands of lines of code :) This eases finding the suspicious code more easily.

It doesn't matter since (int) is in the C++ language regardless of how we feel about it, so it seems their point still stands.

Seems to be found by grep fine:

  % echo 'int x = (int)1.2f;' > foo 
  % grep '(int)' foo
  int x = (int)1.2f;

Does greppable mean something else in this context?

I'm assuming they didn't mean "grep" in a literal sense, rather that it is easier to find keywords like "reinterpret_cast" when scanning your eyes through code, whereas with C-style casts you'd have a much harder time.

Yes I meant this. But grepping can also be a real problem.It is not just plain int what you cast.

Now find casts that are known to be as unsafe as reinterpret cast for the whole set of types your codebase deals with to audit a violation of the type system. What would you grep?

I would grep 'reinterpret_cast' and I would set warning as error for the c-style casts. So you can assume my codebase does not have any.

I will find any cast to reference, pointer, etc. for any type. How would you do tjat if you do:

(int)a ((int)(MyType*))

and many, many more...

That makes sense, thanks. Grepping for C syntax casts with arbitrary stuff between the parens is clearly not going to work.

> 1. because it is greppable and unsafe

But it is not unsafe, or rather, the C++ casts aren't more safe. They have the same semantics.

There are differences casting between class types, but with numeric types the issues are how to handle the value not fitting in (or being imprecise) in the destination type. Casting a value to int in C++ that overflows is still UB.

It doesn't fix C's other strange numeric issues either, like how `unsigned short` * `unsigned short` produces `int`.

they are unsafe because if you try to cast something that's not valid the compiler won't let you. you can then choose to ignore it and be unsafe, or figure out the problem and fix it.

You can still cast INT_MAX to short no matter how you spell the cast, and the result won't be correct.

There are more casts than those. Anda reinterpet cast is a superset of a static cast.

If you want to narrow, you would use static cast, not reinterpret cast.

If you want to reinterpret a set of bytes as another object then you reinterpret cast (actuall use std::bit_cast, will catch more errors,). So yes, you can still do that but consciously.

In C you could even turn a cast that is essentially a static cast into a reinterpret cast by accident and the compiler would say nothing.

> If you want to narrow, you would use static cast, not reinterpret cast.

But if you do that, it's not safe! It's the same as C, which is not safe - it's "implementation defined".

Swift would trap on overflow here.

> But if you do that, it's not safe!

static_cast does narrowing foor the case mentioned. reinterpret_cast would just reinterpret the same bit pattern as another type.

Whether it is equivalent or not is another story. For example, casting a float to an int will narrow but also will convert the internal format.

You can catch some overflow by {} initialization.

You shouldn't be using INT_MAX for the last decade or so. That's why std::numeric_limits exist.

You want me to type `std::numeric_limits<int>::max()` in a forum comment? Bit long.

C++ casts are safer. I think you are confusing concepts here.

There are C++-style casts that are compile-time errors that C would allow you to do in C style. For C everything is potentially a reinterpret cast basically.

C++ casts are safer than C's.

A reinterpret_cast is something that shows up very rarely, so it’s fine that it’s not concise. And when it is used, it usually can do with a function naming it. I try to have a “no raw reinterpret_cast” view unless it’s chars to unsigned chars for string stuff. And as others have said, it’s grepable and can’t cast away constness. If I’m handing a const unsigned char* to a function taking a char* that I know wind modify the data, I don’t want that to be (char*)ptr. I want it to be const_cast<char*>(reinterpret_cast<const char*>(ptr)) because yikes, it should stand out because it’s awful.

And then I’d wrap that godawful cast in a function overloading the legacy C interface, so the overload has one job: to encapsulate the logic that the legacy function isn’t const correct. So then I’d have like void wrappedFoo(std::string_view s) { foo(const_cast<char*>(reinterpret_cast<const char*>(s.data())), s.size()); } with lots of comments about the cast.

> I'm still wondering why `(int)` is spelled `reinterpret_cast<int>` in C++. Do they just like hitting keys on the keyboard?

They are doing different things. For example, `reinterpret_cast<int>` cannot cast away constness but `(int)` can. There are other differences and you should never use C-style casts. In most C++ code bases I worked on, there were static code analysis checks pre merge that would prevent anybody from merging code with C-style casts to master for that reason.

This is a very good example of C++ being difficult to master. There are heaps of ways of doing one thing and usually there are just one or a few of those a good practice, but to explain the best practice's rationale, you need to know and tell a whole story. A simple cast even needs a story. Let alone smart pointers combined with normal pointers; ampersands and const qualifiers that have different meanings depending on where you put them and so on. You can fill a small book with explaining initializers, a big book with explaining templating. In the same amount of pages you can explain the complete ANSI C.

Absolutely. The reason for this is that C++ has been around for a long time while maintaining backwards compatibility (to C too mostly). I know no language where it's as important to have excellent automated tooling that restricts usage of the language for your project. Thankfully tooling is pretty good nowadays but there is very little documentation on how to start if you don't have an expert on your team to help with that.

I'm sure there's a quote about their logic - something to do with making it long and annoying to really make you think twice about it.

Most people in 2022 have plenty of free bytes on their disks so they don't really care about how long their code is. If you want short code, I can recommend Fortran 77, no identifiers longer than 6 characters allowed.

> have best practices in place that are now considered antipatterns

Like using C++ you mean?

C++ is a tool and it still has its use. If you have ever tried to slowly sprinkle Rust into a large C++ code base you will know that it's hard, laborious and error-prone. For completely new projects that don't need existing C++ libraries: sure, I wouldn't use C++ nowadays. There's tons of good reasons that lots of actively developed code is still C++ though.

IME the nature of C++ attracts smug trivia experts more than typical softeng. Skilled, yes, but unhelpful.

As an older dev, screw those older devs that 'roast your code'.

The really good ones won't do that. The ones that do suffer from some weak superiority complex. I had three awesome mentors when I started writing C, and a couple great mentors when I did what little C++ work that I had to do.

The only scold I ever dealt with wrote overly wrought, overly complex crap. Kitchen sink patterns to handle any possible future variation, instead of solving the problem at hand.

Stay away from people like that, they'll just turn you into the same old grouch.

%90 of what people do today is import some open source library or package to do the heavy lifting and weave them into an app using a scripting language. It is sort of the MS Basic approach of the web app world. Nothing wrong with that. C++ is used for a different class of problems that are not the main focus of the industry anymore. I would likely choose something like Rust today but at the time C++'s star was rising there really weren't a lot of other better options.

I find python such a pleasure in comparison. I can express myself so easily.

True. I also like Python.

The problem is when you need 30 servers instead of one to manage your load, though, lol.

I also love Python the language, but it’s hard to keep using it when it’s so slow. Parallel processing helps, but it’s still slow. Definitely dumping pandas the first chance I get. It’s one of two major bottlenecks with the other being anaconda for Windows. Maybe the culprit is running Python on Windows since it relies on so many parts of nix?

I thought parallelism was pretty limited in python due to the GIL (global interpreter lock, iirc)?

C extensions can help. Some libraries use native wrapped code and that acceleratws things.

Thread based concurrency is limited and near pointless. Parallelism, ie using multiple cores in separate processes, is not

I can recommend pola.rs instead of pandas. For my use case it was insanely faster, I did not try it on Windows however.

Try to update your Python environment and also install ALL recommend dependencies for Pandas (and for Geopandas if you use it). I had one old env in Anaconda (Python 3.9.12, Pandas 1.4.2) and then created a new one in Mambaforge (Python 3.10.6 with Pandas 1.5.0). It gives me speed up one of experiment project from ≈30 min to ≈5 min. Use Python code only for glue and leave extensive calculations for C/C++ code. Pandas and Geopandas have the recommended C/C++ dependencies which dramatically speed up calculations and in new versions as I guess they improve integrations with these dependencies.

PS I also recommend to every one to use Mambaforge instead of Anaconda, because it uses Mamba dependency solver written in C++ and it is in orders of magnitude faster.

> Use Python code only for glue and leave extensive calculations for C/C++ code.

That would completely defeat the point of Python for me. I’d rather switch to typescript or C# / Java before I code in C again, but you’re right. Fast Python is an oxymoron. However, in my case my bottleneck is the pandas library. I have to see whether workarounds like Dask work

As long as you force everyone to run their code through pylint.

Nothing like hitting a really rare corner case at runtime that just fails syntax and the process exits.

> It’s a pain to start learning C++, and even after you do, older devs will roast the hell out of your code because your book/tutorials of choice forgot to mention a crucial

Preach it!

This comment doesn't really align with the HN guidelines.

Neither does yours (or mine).

Reply on news.ycombinator.com