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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

261–270 of 470 posts

Re: In Defense of C++

#261

Post by CyberDildonics »

LexiMax wrote: post #98
wvenable wrote: post #77

Earlier quoted context omitted.

Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.

I will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake. Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.

But why, where does it become a problem?

Re: In Defense of C++

#262

Post by scrubs »

jlarocco wrote: post #136
duped wrote: post #57

Earlier quoted context omitted.

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

I agree -- I've been at it long enough -- cmake etc makes stuff pretty darn easy.

But in industrial settings where multi groups share and change libs something like debpkg may be used. You add caching and you can go quite deep quickly esp after bolting on cdci.

One must cop to the fact that a go build or zig build is just fundamentally better.

Re: In Defense of C++

#263

Post by palata »

jchw wrote: post #114
duped wrote: post #93

Earlier quoted context omitted.

I'm just pointing out that one reason devex sucks in C++ is because the fact you need a wide array of tools, that are non portable, and require learning and teaching magic incantations at the command line or in build scripts to work, doesn't foster what one could call a "good" experience. Frankly the idea that your compiler driver should not be a basic build system, package manager, and linker is an idea best left in…

I'm not going to defend the fact that the C++ devex sucks. There are really a lot of reasons for it, some of which can't sensibly be blamed on the language and some of which absolutely can be. (Most of it probably just comes down to the language and tooling being really old and not having changed in some specific fundamental ways.) However, it's definitely wrong to say that the typical tools are "non-portable". The U…

> Using vcpkg [...] When you configure your CMake build, your dependencies will be fetched and built appropriately for your targets, and then CMake's find package mechanism can be used just as it is used for external dependencies.

Yes! I believe this is powerful: if CMake is used properly, it does not have to know where the dependencies come from, it will just "find" them. So they could be installed on the system, or fetched by a package manager like vcpkg or conan, or just built and installed manually somewhere.

> Cross-compiling with C++ is hard.

Just wanted to mention the dockcross project here. I find it very useful (you just build in a docker container that has the toolchain setup for cross-compilation) and it "just works".

Re: In Defense of C++

#264

Post by pornel »

jillesvangurp wrote: post #220

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport.

To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no longer provide any value.

Removal of busywork and pointless obstacles won't make smart programmers dumb and lazy. It allows smart programmers to use their brainpower on bigger more ambitious problems.

Re: In Defense of C++

#265

Post by exDM69 »

zahlman wrote: post #82
Night_Thastus wrote: post #81

Earlier quoted context omitted.

>This is the problem. Also, a proper editor can "fold" blocks for you. I can't fix that. I just work here. I've got to deal with the code I've got to deal with. And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope. >Sure, but then you have to understand the assembly that you've stepped into. Assembly? I haven't touched raw assembly since college.

> And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope. How exactly are they more helpful than following the line of the indentation that you're supposed to have as a matter of good style anyway? Do you not have formatting tools? How do you not have a tool that can find the top of a level of indentation, but do have one that can find a paired brace? >Assembly? I haven't touch…

> How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source?

Executables with debug symbols contain the names of the source files it was built from. Your debugger understands the debug symbols, or you can use tools like `addr2line` to find the source file and line number of an instruction in an executable.

Debugger does not need to understand the source language. It's possible to cross language boundaries in just vanilla GDB for example.

Re: In Defense of C++

#266

Post by afdbcreid »

fluoridation wrote: post #162
BeetleB wrote: post #52

> Here’s a rule of thumb I like to follow for C++: make it look as much like C as you possibly can, and avoid using too many advanced features of the language unless you really need to. Also, avoid using C++ classes while you're at it. I recently had to go back to writing C++ professionally after a many-year hiatus. We code in C++23, and I got a book to refresh me on the basics as well as all the new features. And ma…

std::optional does have dereference checking, but it's a run-time check: std::optional ::value(). Of course, you'll get an exception if the optional is empty, because there's nothing else for the callee to do.

But the dereference operator invokes UB if there is no value.

Which is a recurring theme in C++: the default behavior is unsafe (in order to be faster), and there is a method to do the safe thing. Which is exactly the opposite of what it should be.

Re: In Defense of C++

#267

Post by IshKebab »

jandrewrogers wrote: post #217
IshKebab wrote: post #211

Earlier quoted context omitted.

> It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t. Can't agree there. Why wouldn't they be usable if they weren't memory safe? Can you give me an example of this mythical "memory safe in practice" database? Not Postgresql at least: https://www.postgresql.org/support/security/

Database kernels have some of the strictest resource behavior constraints of all software. Every one I have worked on in vaguely recent memory has managed memory. There is no dynamic allocation from the OS. Many invariants important to databases rely on strict control of resource behavior. An enormous amount of optimization is dependent on this, so performance-engineered systems generally don’t have issues with memor…

Ok but can you give one example?

You can micro-manage memory in Rust if you really want so I'm not sure why this would be a factor.

Re: In Defense of C++

#268

Post by IshKebab »

jandrewrogers wrote: post #229
oytis wrote: post #209

Earlier quoted context omitted.

Rust is a systems programming language, it was absolutely designed with the second use case in mind.

This is true. But it has some weird gaps that make it difficult to express fundamental things in the low-level systems world without using a lot of “unsafe”. Or you can do it safely and sacrifice a lot of performance. I am a fan of formal verification and use it quite a lot but Rust is far more restrictive than formal verification requires. Rust is a systems language but it is uncomfortable with core systems-y things…

> without using a lot of “unsafe”

You are allowed to use a lot of `unsafe` if you really need to. How much `unsafe` do you use in C++?

> it is uncomfortable with core systems-y things like DMA because it breaks lifetime and ownership models,

Sure, it means it can't prove memory safety. But that just takes you back to parity with C++. It feels bad in Rust because normally you can do way better than that, but this isn't an argument for C++.

Re: In Defense of C++

#269

Post by gpderetta »

imtringued wrote: post #230
jlarocco wrote: post #136

Earlier quoted context omitted.

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

> It's bespoke Makefile nonsense with zero hope of standardization

technically Makefile is standardized (by POSIX), contrary to most alternatives.

/extremely pedantic

Re: In Defense of C++

#270

Post by gpderetta »

juliangmp wrote: post #252
account42 wrote: post #237

Earlier quoted context omitted.

> Use a build system like make, you can't just `c++ build` This is a strength not a weakness because it allows you to choose your build system independently of the language. It also means that you get build systems that can support compiling complex projects using multiple programming languages. > Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to searc…

> This is a strength not a weakness Massive cope, there's no excuse for the lack of decent infrastructure. I mean, the C++ committee for years said explicitly that they don't care about infrastructure and build systems, so it's not really surprising.

The reality is that for any moderately complex C++ application, actually compiling C++ code is only a small part of what the build system does.
Post reply on HN