Does C++ still deserve a bad rap? • Hacker News Board

Re: Does C++ still deserve a bad rap?

#141

Post by leni536 » Sat, Oct 17, 2020, 10:21 AM UTC

mehrdadn wrote: post #52

seppel wrote: post #38

Earlier quoted context omitted.

It is not difficult to do it, but it is difficult to do right and in a C++ way. That means with least overhead, i.e. not copying stuff if not necessary and not doing any memory allocations. This is why C++ still has no string split is its standard libary: People cannot agree how it should look like. There is, however, boost::split from the famous boost library.

Do you know if they're revisited this ever since string_view was implemented? I feel like a vector should be quite uncontroversial, and you could even propagate the allocator from the string to the vector.

It should return a range of string views, no allocation is necessary.

Re: Does C++ still deserve a bad rap?

#142

Post by secondcoming » Sat, Oct 17, 2020, 10:22 AM UTC

kenniskrag wrote: post #11

mehrdadn wrote: post #4

Earlier quoted context omitted.

Because it doesn't even exist as provided functionality; you have to code basic stuff like this yourself. See for example https://stackoverflow.com/a/14267455

It is possible with a regex iterator #include #include #include int main() { std::string s = "Python*C++*Java"; std::regex regex("\\*"); std::vector out(std::sregex_token_iterator(s.begin(), s.end(), regex, -1), std::sregex_token_iterator()); for (auto &s: out) { std::cout

Stop

Re: Does C++ still deserve a bad rap?

#143

Post by jnxx » Sat, Oct 17, 2020, 10:25 AM UTC

john_moscow wrote: post #20

Like every programming language out there, C++ is a tool. And like every tool out there it has its uses. There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. However, there's one thing you can do in C++ and not in Python or JavaScript or PHP: fully control the memory layout of your data. While you don't need it in most of the cases, it becomes a ki…

> There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it.

Well, I think that Python will probably do that in the shortest code but it is also more or less the slowest language which is today widely in use, at frequently about 1/50 the speed of C.

You of course could write the example in the link in Rust but for a quick script with decent performance, at around 1/6th of the speed of C, I'd probably use Racket. Racket is really a pretty sweet spot between performance and expressiveness.

> C++ is a tool. And like every tool out there it has its uses. [ ... ] While you don't need it in most of the cases ...

The thing is that the space in which C++ is really useful and the best solution is more and more shrinking. If one wants to control the hardware registers and write a kernel, I think C is still best. If one aims for safety and an performance equal to C, Rust is by now a good choice. For example in the task given in the original article, it would correctly process Unicode without any extra effort. It is of course complex, but much less so than modern C++. If one wants to get things done quickly, Python has its place, but I think Racket and similar languages (babashka) have many advantages. If things get more abstract, Ocaml might be an interesting choice. And I think for parallelism on the server, Clojure and Scala are pretty good.

What happened is that, once upon a time, programs in C++ or C were far far faster than anything else, and Java programs were as slow as a slug. But, compilers got better, and this has changed. And also, modern software development is source-code centric, not based on compiled Windows DLLs, much of the used code is in libraries on Github and elsewhere on the net, and it turns out that for this kind of code reuse, functional languages are often a better fit. Now, C++ is still competing with this and adopting functional features, but the result is getting more and more complex. At the same time, languages like the mentioned ones are getting better and better compilers, and they are conceptually far far simpler. And the speed advantage of C++ is shrinking steadily. In fact, by some comparisons it already does not exist any more:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> fully control the memory layout of your data.

This is, looked at closely, not more than a means toward an objective, and that objective is performance. Control over the memory layout is normally not a value in itself.

> * Try implementing an on-disk hash table in Python and you're stuck manually packing ints and longs in an out of arrays. In C++ it could a simple template used with a memory-mapped file.

This can easily be done if you use LMDB. In fact, using it might be faster and LMDB allows for safely accessing the data from multiple processes. LMDB is written in C and of course there exists a Python library for that.

> * Try doing anything non-trivial on a microcontroller with 32KB of RAM.

You can use uLisp on the Arduino:

http://www.ulisp.com/show?1LG8

> * Try designing an application-specific data structure in any other language. Let's say you have an ~8GB in-memory database that slowly adds records one-by-one and then invalidates them in chunks.

Sounds perhaps like a use case for InfluxDB, which is implemented on top of LMDB, by the way.

> What it means in practice, is that unless you have an existing project that uses C++ anyway, you want to partition it: do the memory-critical part in C++, and communicate to it from a higher-level language via a high-level interface.

That's of course possible and is arguable often done that way. But there is no necessity to use C++. You can do the low-level, performance-critical part which needs some control over the memory layout in Rust, and do the rest in Racket, for example. The functional nature of Racket will make parallelism in the Rust part easier. I've tried that and it is really really neat.

Just to say, I've been using C and C++ professionally since, well, now 25 years. And this along with, for example, Python and IEC 61131-3 Structured Text, which is used to program PLCs. Of course, C++ is entrenched and will continue to be used for a long time. There is also heavy investment and interest in industry. But, it is not as essential as C for the hardware access part and there are today a number of interesting other options. I think C will be used for a loooong time from now, but I would not bet my house that C++ is being used as widely 20 years from now.

(The issue with Python is that it is easy to get started with it, and write small personal projects in it, but for the case of programming reliably in-the-large, and using a lot of dependencies, it is showing its deficiencies).

Re: Does C++ still deserve a bad rap?

#144

Post by mehrdadn » Sat, Oct 17, 2020, 10:28 AM UTC

leni536 wrote: post #141

mehrdadn wrote: post #52

Earlier quoted context omitted.

Do you know if they're revisited this ever since string_view was implemented? I feel like a vector should be quite uncontroversial, and you could even propagate the allocator from the string to the vector.

It should return a range of string views, no allocation is necessary.

That sounds like a great idea. Not sure if it might present a bit of a hurdle if the caller prefers it to be random-access, but I'm kind of tempted to try this out and see if it might present issues in practice. It might be worth suggesting it to the standards committee?

Re: Does C++ still deserve a bad rap?

#145

Post by formerly_proven » Sat, Oct 17, 2020, 10:31 AM UTC

giomasce wrote: post #75

flowerlad wrote: post #8

C++ is a very poorly designed language. A lot of the work being done by the committees is fixing Stroustrup's mistakes. Consider horrors such as this. In the following statement what are foo and bar? int x = foo(2) + bar(3); Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things. For exam…

Well, constructors are not very different from functions, from the caller point of view. Also, Python is much worse in this: any call can be monkey patched at basically any point during the execution, but people do not (usually) use this as an example of poor language designing. You expect the programmer to use the language features considerately. BTW, in C++ every call is resolved at compile time, and the compiler c…

> If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it.

CLion, ctrl+B.

Re: Does C++ still deserve a bad rap?

#146

Post by gypsyharlot » Sat, Oct 17, 2020, 10:32 AM UTC

psyclobe wrote: post #138

If you dedicate a large amount of your career on C++, you can be quite productive writing very robust performant code, and these days its getting easier and easier. I've been coding C++ since 1996, and to this day it is still a joy. I do a lot of back end node/typescript, and after dealing with the loosy goosy types and stuff in that language, coming back to a concrete hard core language that requires a much higher i…

"I've always felt writing in C++ requires much more skill, and that alone is a very rewarding experience. I can tune things like arena allocators and make string operations insanely fast, things I agree most problems simply don't require, but still, its a craft that I feel very proud of conquering, and every day you learn something new."

I worked with C++ for years, and I while I agree with the "every day you learn something new part", I also think that most employers and projects don't benefit all that much from time spent playing with your toy of choice, so to speak. That time that you spend learning about C++ each day, could go into learning about security, machine learning, graphics pipelines and a lot of other things.

I switched to a job where I mostly had to use C or Python, and I no longer obsess over my hammer. Unlike my C++-job, we don't go to C++ conferences and spend meeting after meeting talking about the language we're using. We attend conferences on crypto, machine learning, intrusion detection, and other things that could be useful to us.

I agree that there is a time and place for C++, but I feel so much more productive pulling that tool out of my toolbox AFTER I've identified a hot region of my code, and then using it where absolutely necessary.

Re: Does C++ still deserve a bad rap?

#147

Post by jnxx » Sat, Oct 17, 2020, 10:40 AM UTC

btilly wrote: post #33

If this is the best that can be said for it, then yes. 60 lines of "portable code" turns out not to be portable. Practically every line requires some piece of C++ ceremony. The nightmares around the potential for "undefined behavior" and miscompilations of code by C++ are ignored. It has always been the case that there are several subsets of C++ which make reasonable languages. The problem is that when you combine th…

What I am often wondering is why these subsets are not named, while it would increase clearness of communication and what is wanted and needed.

Re: Does C++ still deserve a bad rap?

#148

Post by pdimitar » Sat, Oct 17, 2020, 10:41 AM UTC

I have nothing against C++ per se. Used it on and off for 10 years (but most actively 3). It's a fine language.

To me using C++ means you are ready to give up a lot of time and energy in order to gain a complete control over certain aspects of your program. I was very much into that at the start of my career and gradually started drifting away to more immediate productivity while reserving the right to poke under the hood when necessary. This has led me to Rust and I find it to be the better natively compiled strongly & statically typed language, but YMMV of course.

These days I reach for dynamic languages for personal projects and experiments. I want to sketch an idea and see if it works in the interval of 15 minutes to a day. Languages like C, C++, Rust, D, Nim, Zig, Fortran, Pascal, Haskell, I found to be generally terrible for when I am in a flow state. Using Elixir / JS / OCaml I found that I could iterate much faster.

I never will participate in a language war (although all of us have slipped on that ice more times than we'd like to admit, let's be honest). But to me C++ is simply not productive. It feels like having to learn a 10x5 meters of control panel with dials, blinky lights, keys and levers. I know there are many who enjoy that -- more power to them. But I am not in that group.

Re: Does C++ still deserve a bad rap?

#149

Post by pizza234 » Sat, Oct 17, 2020, 10:41 AM UTC

psyclobe wrote: post #138

If you dedicate a large amount of your career on C++, you can be quite productive writing very robust performant code, and these days its getting easier and easier. I've been coding C++ since 1996, and to this day it is still a joy. I do a lot of back end node/typescript, and after dealing with the loosy goosy types and stuff in that language, coming back to a concrete hard core language that requires a much higher i…

> I've always felt writing in C++ requires much more skill, and that alone is a very rewarding experience. I can tune things like arena allocators and make string operations insanely fast, things I agree most problems simply don't require, but still, its a craft that I feel very proud of conquering, and every day you learn something new.

It's important to distinguish professional from hobby programming.

Challenge for the sake of challenge is certainly interesting/fun, but, no employer would pay employees to write programs in Brainfuck just because it's challenging, while it's ok in hobby programming, because the resources (=time) are virtually infinite. Of course, there's a value in an employer allowing a certain amount of extra resources for the employees' "growth for the sake of growth".

I think the article grossly misses the point of what makes C++ problematic, as it considers a programming language in the context of a single programmer solving a simple problem, while the real-world issues of C++ are in the context of a team and memory management of large programs.

Re: Does C++ still deserve a bad rap?

#150

Post by jnxx » Sat, Oct 17, 2020, 10:46 AM UTC

pmoriarty wrote: post #25

flowerlad wrote: post #8

C++ is a very poorly designed language. A lot of the work being done by the committees is fixing Stroustrup's mistakes. Consider horrors such as this. In the following statement what are foo and bar? int x = foo(2) + bar(3); Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things. For exam…

"Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things." Same as in Lisp, one of the most beloved of languages on HN. Were Lisp's macros a mistake? Some will say yes, but overall the language is more praised for them than damned. So highly regarded are Lisp macros that many languages wil…

This is perhaps a misunderstanding. Lisp macros are a part of the language. Of course you can use them to make your code unreadable. But what they are used for is to evolve and add definitions for things such as iteration, which in other languages, like Python or C++ is not possible without a language change.

For example:

https://lispcookbook.github.io/cl-cookbook/iteration.html

https://docs.racket-lang.org/reference/for.html