Live data from Hacker News

Does C++ still deserve a bad rap?

nibblestew.blogspot.com

51–60 of 310 posts

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

#51
post #17

Is this a nerd sniping thing? It has been a while since I've wrestled with Perl, but I suppose the recursive file search would keep it from being a one-liner. 4-5 "reasonable" lines maybe? Definitely less than 80 characters? I see I don't even have Perl installed on this machine, oh well.

It does seem like a weird choice, since anyone faced with this problem fewer than a billion times will surely choose shell tools. In python it's pretty short, and I don't even know python.

         from collections import defaultdict 
    ...: d=defaultdict(int) 
    ...: for fn in glob.iglob("**/*.txt"): 
    ...:     with open(fn, 'r') as f: 
    ...:         for line in f: 
    ...:             for word in line.split(): 
    ...:                 d[word] = d[word] + 1 
    ...: [(k, v) for k, v in sorted(d.items(), key=lambda x: x[1], reverse=True)][:10]

That said, the C++ version in the article could be tightened up a bit. What's happening on line 34, for instance?

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

#52
post #38

Earlier quoted context omitted.

Why would that be more difficult in C++?

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.

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

#53

Earlier quoted context omitted.

In C++ you can implement it in a way that gives you much more control. Do you want to truncate the string? return new strings? return string views? It all depends what you need. In some languages all strings are immutable and all operations result in new strings and you have no control over that.

The trouble is often it doesn't matter and literally any of those would be useful, and yet none of them exists for you to use, so you have to waste time reinventing the wheel.

Perhaps they're not in the standard library, but they're readily available on Boost, POCO and many other well known mature libraries.

Check the Boost C++ string algorithms library.

https://www.boost.org/doc/libs/1_74_0/doc/html/string_algo/u...

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

#54

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…

This story about the committees fixing Stroustrup's "mistakes" is completely made up from you and is not even remotely true. Also Stroustrup does _not_ take pride in how big the language is, the exact opposite is true. E.g. you will never ever hear Stroustrup speaking about template meta programming or similar weird stuff. He always tries to teach the practical side of C++. His C++ book is not big because the language is complex, but because it is a genral introduction into programming with C++. In fact, if you want to learn the esoteric features of C++, you have to buy other books. Implicit type conversions are inherited from C, the language you called "awesome". Many arcane features of C are nowadays considered as anachronisms and no modern designed language would repeat them.

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

#55

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…

I mean, it's even more weird than you said. It's not impossible that Foo(int) and (int)Foo or int g = foo do completely different things. Foo could define an `operator int` that terminates the program, or does any damn thing.

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

#56
post #2

I say this with a lot of love for C++, and I think it has gotten much better, but just try splitting a string via another string as the delimiter...

Is there any language where string handling doesn't suck? (No script languages please, because they cheat by implementing the hard things on C or C++) From memory the less horrible experience i had was with Go, but there's help for the slices on the runtime which let the difficult parts hidden and also the batteries-included std library, which is one of the most well designed standard libraries out there. Buffer mana…

I would risk to mention Tcl as a good candidate, which might be unfair because the language is designed for strings.

  split "foo.bar" .
    => foo bar

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

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

Since they now have ranges, the discussion can start all over... But I'm maybe no completely up to date, where the discussions is.

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

#58

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…

>In other words type casting can be written as (foo)2 or as foo(2). Just to make it harder to understand what is going on.

Or to make it easy to describe high-level behavior where you don't care about the details. In your example, foo and bar could be some complex vector or matrix types with custom allocation/deallocation logic.

So this line:

  int x = foo(2) + bar(3);
Is an equivalent of 7 lines in Plain C:

  foo tmp_foo;
  bar tmp_bar;
  construct_foo_from_int(&tmp_foo, 2);
  construct_bar_from_int(&tmp_bar, 3);
  int x = add_foo_and_bar(&tmp_foo, &tmp_bar);
  free_foo(&tmp_foo);
  free_bar(&tmp_bar);
Sure, if you don't know what foo and bar are, it's confusing. But if you want to decompose what you are doing from how you are doing it, this syntax rocks.

BTW, (foo)2 syntax is preserved for backward compatibility with C and is deprecated in favor of static/dynamic/reinterpret_cast() (that many people don't use due to clunkiness) and foo(2) is unavoidable if foo's constructor has more than 1 argument.

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

#59
Any software where you will need to develop serious things for will suck.

Almost nobody feels miserable in languages like python because they rarely have to deal with the ugly stuff or having people depending their lives on it. Thats the 50% of the fun writing in it, because you will deal mostly with the cool things, and who would not like the language that gives you that kind of pleasure?

And the languages that are used for this kind of stuff will suck somehow, because its hard to make things right on them, it requires a lot of discipline and you will have to deal with big codebases, in big teams.. so the things gets much harder to do right.

The guy that is chearing Rust today, is the guy that will complain 10 years from now, how Rust sucks, because he have to deal with it everyday in its big avionics codebase and any mistake can cost million of dollars or peoples lives.

Its psychology. We need the shiny new thing to give more meaning to our lives. It will never stop, but with time you learn to navigate over it a little better.

There is very little change in languages now, and once someone does a real paradigm shift, it will be impossible to ignore.

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

#60

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. 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. Any books or resources for digging deeper in these kinds of topics? I’m a Python developer and would like to learn C++ but the just the reasons you mentioned make i…

To get a quick start, try declaring some class variables and then open the Memory window and go to "&variable_name". You can also evaluate "sizeof(variable_name)" to get its exact size.

You'll see a bunch of bytes reflecting how exactly your variable is seen by the CPU. That's exactly how many RAM bytes it occupies. It can quickly copied to a new location, limited only by your RAM bandwidth. It can be dumped to a disk and loaded later, limited only by your disk bandwidth.

Post reply on HN