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

281–290 of 470 posts

Re: In Defense of C++

#281

Post by account42 »

TuxSH wrote: post #235
butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

> It really isn't. There's a lot of little nuanced differences that can bite you. These are mostly inconsequential when using code other people write. It is trivial to mix C and C++ object files, and where the differences (in headers) do matter, they can be ifdefed away. > void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit beh…

> you can and should use char[] in both languages

Not for temporaries initialized from a string constant. That would create a new array on the stack which is rarely what you want.

And for globals this would preclude the the data backing your string from being shared with other instances of the same string (suffix) unless you use non-standard compiler options, which is again undesirable.

In modern C++ you probably want to convert to a string_view asap (ideally using the sv literal suffix) but that has problems with C interoperability.

Re: In Defense of C++

#282

Post by mat0 »

Whenever I open one of these sites that asks me to confirm tracking, if it doesn’t have an easy way to cancel or reject, I just leave the page. The banner had hundreds of different companies listing “legitimate” reasons to track, and after turning off around 10, I noticed that I had hundreds to go. Sorry, I hope people enjoy your website. I just cannot see a reason to accept that amount of tracking. I don’t care that much about C++ anyway

Re: In Defense of C++

#283

Post by nurettin »

loeg wrote: post #45

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for m…

This is a failed attempt at muddying the waters. You don't know what move semantics is? You go learn what they are. Best/simplest way is to just disable your copy ctor.

You need to know the operator overload semantics for a particular use case? It is not exactly hidden lore, there are even man pages (libstdc++-doc, man 3 std::ostream) or just use std::println.

You are stuck instantiating std::vector? Then you will be stuck in any language anyway.

Re: In Defense of C++

#284

Post by pclmulqdq »

Defletter wrote: post #238
pclmulqdq wrote: post #148

Earlier quoted context omitted.

"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.

I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit because then they can gleefully point at it and pretend that any first-party package manager for C/C++ would inevitably result in the same, nevermind the other languages that do not have this issue, or have it to a far, far lesser extent. Do these cultists just not use dependencies? Are they just [probably inexpertly] reinventing e…

What makes me a C++ "cultist"? I like the language, but I don't think it's a cult. And yes, they do implement their own wheel all the time (usually expertly) because libraries are reserved for functions that really need it: writing left pad is really easy. They also use third-party libraries all the time, too. They just generally pay attention to the source of that library. Google and Facebook also publish a lot of C++ libraries under one umbrella (abseil and folly respectively), and people often use one of them.

Re: In Defense of C++

#285

Post by account42 »

nxobject wrote: post #222
jcelerier wrote: post #208

Earlier quoted context omitted.

But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.

I'd file that in the category of "what I can't recreate, I can't understand".

With that argument you could discard JavaScript because V8 is hard to understand.

C++ giving you the ability to create your own containers that equal the standard library is a bonus, it doesn't make those containers harder to use.

Re: In Defense of C++

#286

Post by jononor »

jcelerier wrote: post #197
jimbob45 wrote: post #144

Earlier quoted context omitted.

You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.

Coming from c++, pip and python dependency management is the bane of my life. How do you make a python software leveraging pytorch that will ship as a single .exe and be able to target whatever gpu the user has without downloads?

Funnily enough a lot of the challenges in this particular case is related to PyTorch and CUDA being native code (mostly in C++). Of course combined with the fact that pip is not really adequate as a native/C++ code package manager.

Perhaps if C++ had a decent standardized package manager, the Python package system reuse that? ;p

Re: In Defense of C++

#287

Post by JonChesterfield »

mat0 wrote: post #282

Whenever I open one of these sites that asks me to confirm tracking, if it doesn’t have an easy way to cancel or reject, I just leave the page. The banner had hundreds of different companies listing “legitimate” reasons to track, and after turning off around 10, I noticed that I had hundreds to go. Sorry, I hope people enjoy your website. I just cannot see a reason to accept that amount of tracking. I don’t care that…

None of it makes it through a pi-hole filter. Website is clean and coherent, no popups. What that implies for the attempt to track is slightly unclear to me, but I don't have great faith in the pop up box being honoured even if it loads.

Re: In Defense of C++

#288

Post by account42 »

sunshowers wrote: post #4
lordleft wrote: post #3

Great article. Modern C++ has come a really long way. I think lots of people have no idea about the newer features of the standard library and how much they minimize footguns.

Lambdas, a modern C++ feature, can borrow from the stack and escape the stack. (This led to one of the more memorable bugs I've been part of debugging.) It's hard to take any claims about modern C++ seriously when the WG thought this was an acceptable feature to ship. Of course, the article doesn't mention lambdas.

Not an issue if you make use of the tools available:

https://godbolt.org/z/xW14hGeoj

Re: In Defense of C++

#289

Post by cyber1 »

Just look at this: https://pvs-studio.com/en/blog/posts/cpp/1129/ - 11 parts about C++ undefined behavior from people who specialize in finding this stuff. And that’s only the tip of the iceberg.

I use C++ daily, and it’s an overcomplicated language. The really good thing about Rust or Zig is that (mostly) everything is explicit, and that’s a big win in my opinion.

In defense of C++, I can only say that lots of interesting projects in the world are written in it.

Re: In Defense of C++

#290

Post by nxobject »

bayindirh wrote: post #280
pornel wrote: post #264

Earlier quoted context omitted.

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…

These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. Howev…

> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time.

I think you're setting the bar a little too high. Rust's borrow-checking semantics draw on much earlier research (for example, Cyclone had a form of region-checking in 2006); and Turbo Pascal was churning through 127-character identifiers on 8088s in 1983, one year before C++ stream I/O was designed.

EDIT: changed Cyclone's "2002" to "2006".

Post reply on HN