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

91–100 of 470 posts

Re: In Defense of C++

#91

Post by jandrewrogers »

beej71 wrote: post #79

It doesn't mention the horrific template error messages. I'd heard that this was an area targeted for improvement a while ago... Is it better these days?

Qualitatively better. C++20 'concepts' obviated the need for the arcane metaprogramming tricks responsible for generating the vast majority of that template vomit.

Now you mostly get an error to the effect of "constraint foo not satisfied by type bar" at the point of use that tells you specifically what needs to change about the type or value to satisfy the compiler.

Re: In Defense of C++

#92

Post by sunshowers »

TuxSH wrote: post #32
sunshowers wrote: post #4

Earlier quoted context omitted.

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.

Capturing lambdas are no different from handwritten structures with operator() ("functors"), therefore it makes no sense castrating them. Borrowing from stack is super useful when your lambda also lives in the stack; stack escaping is a problem, but it can be made harder by having templates take Fn& instead of const Fn& or Fn&&; that or just a plain function pointer.

Borrowing from the stack is definitely useful. I do it all the time, safely (truly safely), in Rust.

Re: In Defense of C++

#93

Post by duped »

palata wrote: post #83
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…

I can use pkg-config just fine. Not sure how relevant the "in order to use a tool, you need to learn how to use the tool". Or from the other side: not sure what I should think about the quality of the work produced by people who don't want to learn relatively basic skills... it does not take two PhDs to understand how to use pkg-config.

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 the 80s where it belongs.

Re: In Defense of C++

#94

Post by loeg »

AaronAPU wrote: post #72
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…

I’ve been programming C++ on a daily basis for more than 20 years and literally never use the >> operator. Never. Not rarely, never.

I didn't mention >>.

Re: In Defense of C++

#95

Post by ecshafer »

wvenable wrote: post #77
butterisgood wrote: post #55

Earlier quoted context omitted.

Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!) I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?). What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck! I have hope for C++front/Cpp2. http…

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.

The first programming language that used overloaded operators I really got into was Scala, and I still love it. I love that instead of Java's x.add(y); I can overload + so that it calls .add when between two objects of type a. It of course has to be used responsibly, but it makes a lot of code really more readable.

Re: In Defense of C++

#96

Post by summerlight »

> 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.

Only if you have full control on what others are writing. In reality, you're going to read a lot, lots of "clever" codes. And I'm saying as a person who have written a good amount of template meta programming codes. Even for me, some codes take hours to understand and I was usually able to cut 90% of its code after that.

Re: In Defense of C++

#98

Post by LexiMax »

wvenable wrote: post #77
butterisgood wrote: post #55

Earlier quoted context omitted.

Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!) I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?). What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck! I have hope for C++front/Cpp2. http…

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.

Re: In Defense of C++

#99

Post by okanat »

nzeid wrote: post #11

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. You know, not sure I even agree with the memory leaks part. If you define a memory leak very narrowly as forgetting to free a pointer, this is correct. But in my experience working with many languages including C/C++, forgotten pointers are almost never the problem. You're gonna be…

Nice thing about Rust is not that you cannot write such code, it is you know exactly where you used peaky memory or re-interpreted something as a unsigned integer or replaced your program stack with something else. All of such cases require unsafe blocks in Rust. It is a screaming indicator "here be dragons". It is the do not press this red button unless you intend to.

In C and C++ no such thing exists. It is walking in a minefield. It is worse with C++ because they piled so much stuff, nobody knows on the top of their head how a variable is initialized. The initialization rules are insane: https://accu.org/journals/overload/25/139/brand_2379/

So if you are doing peaky memory stuff with complex partially self-initializing code in C++, there are so many ways of blowing yourself and your entire team up without knowing which bit of code you committed years ago caused it.

Re: In Defense of C++

#100

Post by bluGill »

duped wrote: post #93
palata wrote: post #83

Earlier quoted context omitted.

I can use pkg-config just fine. Not sure how relevant the "in order to use a tool, you need to learn how to use the tool". Or from the other side: not sure what I should think about the quality of the work produced by people who don't want to learn relatively basic skills... it does not take two PhDs to understand how to use pkg-config.

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…

that idea that packages and builds belongs to simple problem, large projects need things like more than one laguage and so end up fighting the language
Post reply on HN