61–70 of 310 posts
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...
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 languag…
It is true that C language has some very limited implicit type conversions. For example you can say:
long n = 3;
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…
Yes, there are surely still a few cases where C++ beats Rust on raw merit. And of course C++ still has the advantage in the number of developers who can competently contribute to your project in short order. But both of these advantages are diminishing rapidly, and—to me at least—the writing is on the wall for C++. Its days are numbered.
Earlier quoted context omitted.
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 languag…
> Implicit type conversions are inherited from C, the language you called "awesome". It is true that C language has some very limited implicit type conversions. For example you can say: long n = 3; And the integer 3 is converted to long. This is extremely limited, and does not make the program hard to understand, which is completely different from the craziness you see in C++.
unsigned n;
n = 2.99; // n = 2
n = -1; // n = 2^M-1;
n = 1.0E33; // undefined but not catched
auto n = a + b;
As someone who writes <5 commits of C++ per year, it is very frustrating. I can’t get through a code review without reviewers referencing at least 2 blog posts about proper style for modern C++. I’m sure if I were an expert who used it every day I could remember all the gotchas and best practices, but it sure is tedious to deal with occasionally. Too many foot guns and conventions, not enough constraints in the langu…
Earlier quoted context omitted.
> Implicit type conversions are inherited from C, the language you called "awesome". It is true that C language has some very limited implicit type conversions. For example you can say: long n = 3; And the integer 3 is converted to long. This is extremely limited, and does not make the program hard to understand, which is completely different from the craziness you see in C++.
C does destructive conversions automatically, if you ask for it. E.g. unsigned n; n = 2.99; // n = 2 n = -1; // n = 2^M-1; n = 1.0E33; // undefined but not catched Both C and C++ follow the same philosopy: "Trust the programmer". The programmer is expected to use his expressive freedom, to solve performance problems and stay away from problematic constructs without being told to so. C is a systems programming languag…
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.
find . -type f -name '*.txt' -print0
| xargs -0 cat | tr ' \t' '\n\n' | grep '\S'
| sort | uniq -c | sort -nr | sed 10q
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...
What I do have a problem with is trying to interface with more complex apis and functions. For example a while back I had to implement a https get and post request and it was a total nightmare. Something that takes only a few lines in python took a few days to figure out. Maybe it's lack fo experience but I tried wrestling with libraries like pocco which I couldn't figure out for the life of me but in the end ended up writing a monster of a program implementing the winhttp api directly.
I made a similar comment earlier and someone suggested I should have just used libcurl. How to people normally wrestle with these things without going crazy?
Right at the beginning, > This calls for regular expressions Why? A regular expression is a whole new program, written in a whole new programming language (one used to program finite state machines, instead of Turing ones, but still). Why not just write a simple function to compare string suffix? Is you programming language (C++, in this case) so anaemic that you need a whole different language to do such basic opera…