Does C++ still deserve a bad rap?
nibblestew.blogspot.com
nibblestew.blogspot.com
This fragility is not at all obvious in the code. It is easy to imagine someone making that kind of change to word_regex and introducing a theoretical security bug that no compiler or static checker is going to pick up (AFAIK). Of course the severity of the bug in practice depends on what std::tolower does in that undefined-behavior situation (which may depend on the run-time locale setting).
I think the author's example actually illustrates the C++ safety problem pretty well. You write a program that looks safe and actually is safe, but slightly different code which looks just as safe is not. You're tiptoeing through a minefield.
(before anyone says that ‘in reality it’s probably fine’)
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 killer feature when directly dealing with large amounts of data:
* 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.
* Try doing anything non-trivial on a microcontroller with 32KB of RAM. You could theoretically use a higher-level language, but you will end up using >10x amount of RAM.
* 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. A C++ implementation will rip anything else to shreds. You just won't get the same speed and memory efficiency.
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. You will get performance where you need it and a peace of mind everywhere else.
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 it hard to leave Python.
You get a pointer to the start of the range, and you know how large it is, so from there it's just pointer arithmetic and assignment. Easy peasy. Now you just have to make sure that you zero data when you're done with it, track how much of that memory is available or used (and which sections), and (optionally) implement your own defragmentation and garbage collection.
Unless you desperately need to specifically manage the memory layout of your data (e.g. for alignment purposes for massive data processing), none of this is worth the time or trouble to do for most projects, not only because it's a huge amount of work for little gain, but because you'll almost definitely screw it up and potentially corrupt your entire data set.
Note that, at least for the on-disk hashmap set, you absolutely can do this in python, so if you're interested in experimenting with this sort of data management, practice it there first.
A good place to start: https://github.com/luispedro/diskhash
No need for that, as C++ provides placement new().
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.
Let me warn you right now. It's not worth it. At all. Don't go down this path. Memory management is easy, but that's not the only crap you have to deal with.
Templating and the whole C++ ecosystem with Cmake compiling to make is a giant headache. It takes about a week to integrate a new C++ library in source code and people are worried about installing or "trying" out new libraries because of memory leaks.... while in python I'll install an entire library in seconds just to try out a function.
I would say if you made an app in python and the same exact app in C++, the C++ app would perform waay better. No question. But the developer experience and effort required to make that same app is much much more painful.
If I want a library in python it takes about a second to install with one command, and these libraries tend to be safe so you're not going to get any resistance if you want to try out 10 libraries in the next hour or so, which is sort of impossible with c++. Also these libraries are easily uninstalled and isolated from other python apps you have. No need to use massively complex package managers like nix to handle isolation.
Fuzzing a library just isn't something that's done in python. The developer just installs it and manually tests it 5 or 6 times in a shell and it's part of the ecosystem in 5 minutes.
If you accidentally leave unused libraries in your code and it gets pushed to prod it's a non-issue.
I switched to c++ because I was ok with the verbosity and also the complexity and also dealing with memory. But literally every single corner of the c++ ecosystem is a pain in the ass to work with. It's getting to the point where I'm just annoyed all the time. If you want high performance apps go with rust or golang. C++ is just not worth it.
For a C++ dev moving to python is like night and day. Imagine a programming environment where you only have to deal with the intention of what your app should do and not all the yak shaving that comes with it on the side. I know some and they tell me they would never go back to c++.
You shouldn't use C++ as the backend for your marketing site, or some simple crud backend where a JIT runtime with GC will do.
Hell, if you're even building a small compiler today a JVM language or Go is a better choice.
But if you need to allocate memory yourself, C/C++ is very hard to beat. Games and systems dealing with huge chunks of memory will always go this route... and just (most likely) copy the dependencies into version control and deal with things that way.
It doesn't matter if the majority of applications are web applications. That doesn't make C++ less relevant because that was never the target audience.
For building cloud services where apps are bottlenecked by the database, the user experience is roughly the same as C++ but the developer experience with python is much much much more easier.
This attitude where consumers have to run the apps or install a runtime to run the app on there personal machines is much more rare nowadays.
but... surely you are aware that the memory leak concern absolutely does not disappear ? you just choose to not care about it in the python case for "reasons" - likely you've never been hit by a system which appends to a dynamic array without ever emptying it, and that can happen in every single language in the world.
But if you want a customer to download an app, which is much more rare nowadays than you can do what Eve online does or iron mail. They deliver actual client side python apps. I don't know what they use internally or how they did it, but pyinstaller is one option you can use to build a python executable.
Represent a data table in memory where the columns are from different types, where the data is backed by a arena allocator and represented contiguously in memory.
Of course you can do a data table representation in almost any language, but once you benchmark the implementations, the languages that gives you full control of memory and are good at moving bytes are the ones that lead in performance.
Lars Bak once said that C++ is a great "byte chunker" (if i recall the term correctly), explaining why its a good language to create a compiler or a VM in it.
The thing is, once you need even more performance, you might need parallel evaluation. And in C++, there are plenty of opportunities to shoot yourself with which even very experienced programmers have sometimes extreme difficulty doing it correctly:
https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedL...
https://preshing.com/20130930/double-checked-locking-is-fixe...
And this is the area which Rust, while being as performant as C++, is heavily improving on.
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.
People using c++ usually care about programs finishing before the heat death of the universe. I had a few Python scripts that spend several seconds parsing larger files, after a rewrite to c++ that changed to almost instant.
Generally languages like C++ are obviously much faster, but a lot of primitive stuff in languages like python is also just C calls and may be optimised to the point of being faster, because doing things in low level compiled languages often comes with its own tricks and problems.
[1]https://stackoverflow.com/questions/9371238/why-is-reading-l...
That assertion makes zero sense if we take into account that parallelization is one of the most basic performance techniques there is, and Python's GIL simply eliminates that option except for multi-process applications which then require serializing stuff back and forth.
Python is pretty much unparalleled as a glue language, and excels at putting together small exploratory scripts for data analysis and number crunching applications, but it makes no sense to present Python as a performant alternative to C++.
In that corner case you still have slow Python glue code calling fast C++ code.
It makes no sense to claim that Python is performant based on the idea that it may be used to glue together calls to performant C++ code, while ignoring the fact that not only Python forces performance restrictions on it's code but also that C++ code is quite capable of calling performant C++ code itself.
To be honest I'm not sure what your new comment is about. If you're saying that Python is not necessarily faster than C then I'm sure no one going to dispute that; in the situation we're discussing, the performance of your code is totally dependant on the efficiency of the libraries that are doing all the work, not your glue code. If you're saying that Python is slower than C when it's doing a non-trivial amount of the execution, then sure, but no one was claiming that either. Or maybe you just want to simplistically categorise languages as "performat" and "non-performant" without thinking about the specific contexts they can be used in, but that wouldn't make any sense. Did I misunderstand?
I would not support that stance. There are areas where parallelization is helpful, like numerical weather models, graphics, and scientific number crunching, but for by far the most cases, parallelization is anything but trivial and requires a pretty deep knowledge about things like the C++ memory models, what read-write barriers, locks, and fences are, and so on. Less than 1% of C++ programmers can really handle that. And apart from that this is an area where other languages like Rust, Clojure, Scala have a strong point, because whether it is done correctly is completely implicit in a C++ program while in Rust, many errors will have the result that your program does not compile. Debugging the same mistakes in C++ will make you pull your hair.
In fact, I'd urge anyone who wants to learn principles of safe concurrent computation in C++, to learn Rust, Clojure and Scala first, they are wonderful languages with strong, highly coherent concepts, and it will make you a much better C++ programmer even if you never use them again.
Of course it is not only possible but common practice to implement parallel computation in games and such in C++, but this is not the standard application of C++.
Parellism in C++ is most often used for scientific applications and other forms of mass number crunching. It's really easy to just throw a "#pragma omp parallel for" on a loop and call it a day but of course that would also apply to C and Fortran and is somewhat limited. Parallelism libraries like Intel TBB which I'm most familiar with are very easy to use and performant. I think there's a large problem in the reluctance of educators to use libraries to teach parallelism and people always dive straight into locks, threads and atomics which are really not the way to approach parallel computing if you're looking to do parallel computing and not looking to implement parallel primitives yourself (i.e DIY tasking-system or lock-free queue)
Focusing on TBB, it facilitates efficient parallelism by providing high-level canned algorithms such as parallel_invoke, parallel_reduce, parallel_for and parallel_do which anybody who claims to know C++ should be able to use easily. It also provides a task-graph which is great for more complex processing pipelines (things like join/split, fan-in/out and queueing). If you need more low level control you operate at the task level and TBB provides customization points for that. There's other libraries out there which provide similar functionality and even the STL in C++17 provides basic parallel algorithms such as transform (equivalent of map in other langs), reduce and many others.
There are two aspects. I agree to the aspect that today, C++ is used often for such tasks.
Now, what are the reasons why C++ is used dominantly in this domain? I think more or less the only reason is performance. The good performance is what makes the authors of such libraries put up with the disadvantages of C++.
However, I think it is also true that Rust allows for a more concise and safe formulation of the computation (also Scala, for example, which serves somewhat different purposes). For scientific applications, correctness matters, and knowing that the code which compiles does not has hidden memory errors and data races is extremely valuable, because it can save a ton of time.
Also, if there are still differences between Rust and C++ performance, they are minor. In many cases, Rust is faster.
Now, if authors of scientific computing libraries were to come to the conclusion that there exist an alternative which produces at least as fast code, provides better and safer support for parallelization, and is with some learning easier to work with, why should these library authors continue to use C++?
Of course, nobody is going to ditch a large C++ project like Eigen over night and rewrite it in Rust. There is too much inertia for that. Also, GCC support is still lacking. However, one can expect that the number of new projects which use Rust is going to increase and the project which are successful there will blaze a new trail. For something like Python extension modules, users of these libraries do not need to know anything about Rust.
Also, some nitpick. C++ is used in important scientific libraries. However, many essential libraries such as Numpy are written either completely in C, or use C interfaces, because C++ does not has a stable ABI and Python uses the C ABI. This would make a switch to Rust pretty easy. In fact, I think the impulses in this domain will come first from researchers and analysts which start to write small Rust extension for Python which use the C ABI and integrate with Numpy, for example.
In that sense, C++ is not batteries included, which can be annoying for small and medium projects.
Essentially C++ and the modern ideas about computer security are at war.
Really? That's the opposite of my impression. It seems to me that they promote it as co-equal to C# as primary focus in their constellation of supported and encouraged application programming languages.
https://docs.microsoft.com/en-us/windows/apps/winui/winui3/x...
I've seen Rust being used for the layer above C++, where it doesn't have to deal with I/O, scheduling, etc that don't play well with Rust but you still want the throughput/latency and memory safety.
Hell, highly optimized numerical simulations are still being written in freaking Fortran.
In some software architectures, there are schedulers with a global view of the entire (potential) conflict graph and they have complete control of what gets executed when. These architectures don’t even require locks because the scheduler has enough visibility and control to guarantee that execution won’t be scheduled such that there would ever be a contended lock or some other concurrency conflict. No amount of mutable references to the same memory will break these models, and the correctness of some implementations have been formally verified. The scheduler can always dynamically reorder execution to guarantee the invariants of the system. These models have the added benefit of having insanely good locality properties such that throughput is excellent.
These software architectures originated in HPC over a decade ago and eventually bled over into high-end database kernels. I learned it from when I worked in HPC many years ago and have used it every since, due to its unambiguous advantages.
For example you might be able to wrap shared-mutable state in a kind of degenerate mutex and pass a "scheduler guarantee" token around that unlocks those "mutexes" without doing any runtime work.
1) Neither iOS, nor "the web" are new platforms.
2) Not only you can program with C++ on iOS, it's heavily used in certain kinds of applications.
3) Why would anyone single out a specific language and claim that it's a problem that you can't use it to build websites with it? This applies to all languages with one exception. Or it did, because now there's WebASM, which makes this argument even more bizarre.
4) C++ had and has first-class support on Windows.
2) Objective-C++ may look like C++ but their different languages. As always beware of edge cases.
3) WebAsm is somewhat “supported“ by 92% of web browsers which sounds great but isn’t enough to be viable for companies like Amazon. But hey it’s a cool toy if you don’t have real work to do.
4) I have run into plenty of missing C++ documentation when C# documentation was available on Windows. It’s supported sure, but very much a second class citizen.
It depends on the task. If the parsing is done once a day then several seconds is nothing, so there is no point in using C++.
If the parser is running very frequently then of course one uses a faster implementation.
Was it worth rewriting those scripts in C++? I'm not trying to be facetious; a few seconds (or minutes) of additional runtime for scripts you hardly ever run or even run only once doesn't really matter, but running such scripts often may then worth the effort to convert them to something faster.
I regularly find myself porting regularly used python/js scripts to C#/dotnet (because it's fast enough, has good collections + LINQ for your somewhat-functional-programming needs and I can skip manual memory management, and async/await programming is not perfect but available and easy enough, + nuget has a lot of stuff and so does the standard lib).
What made you pick C++ over e.g. go or rust or C#?
Mostly for development, I ended up invoking the script quite often and had to wait for the results. In production the input it ran on only changed once a week, so there was no need to run it often.
I most likely tried to run it with Pypy first, thought I am not 100% sure on that. If I ran into a similar issue today I would first try to compile it with Cython as I already try to use type annotations in every new script I write.
> What made you pick C++ over e.g. go or rust or C#?
Most of the project was already C++ and I only had to link in an Xml library for some of the output.
Since you can get within about 2x of C++ speed which still using a high-level language, that makes the argument that the times you really need C++ for performance reasons are quite limited. I'm not saying they don't exist, but they are rare.
And like every tool some tools are crap and other tools are good. Not saying C++ is crap but I'm definitely saying that it is unwise to use this analogy to believe that there are no crap tools out there.
There's this thing that happens among programming languages where everyone likes to think all programming languages are just apples and oranges and everything is equal.
The truth about the world is equality is rare... some things are good and others pure liquid shit. Programming languages are not immune from this property of the universe.
Now about C++... What you say about it is true. I completely agree. However, much of the good of C++ comes with a pile of crap that you have to deal with that's often not worth it for the majority of projects. In my opinion C++ is only good because there's no alternative unless you count Rust or D.
This is only simpler if you don't need to handle read failures. If you want to handle read failures, memory mapping can quickly become way more complicated. You have to install signal handlers and do a complicated dance to correctly handle not having data in some range.
They look simple and approachable on the surface, lead to an elegant code and seem to solve the problem in basic test cases, but in practice they have nasty scalability problems. In particular, trying to work with very large files leads to cache thrashing that affects the entire system, which makes mmaped files particularly unfit for implementing off-memory data structures. Moreover, the code has zero control over this behavior, because we ultimately over-allocate memory and outsource swapping details to the OS.
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/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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
See also https://news.ycombinator.com/item?id=11777662
> * 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).
You can total write a C++ interpreter. And there are Python and JavaScript compilers.
C++'s memory management isn't even necessarily particularly manual. Nowadays people use reference counting in C++ occasionally. (They call them 'smart pointers' I think.)
Is that actually guaranteed by the standard?
> * Try doing anything non-trivial on a microcontroller with 32KB of RAM. You could theoretically use a higher-level language, but you will end up using >10x amount of RAM.
It's a shame Forth never took off. Sometimes I wonder what it would have been like to live in an alternate universe where Forth had been the lingua franca instead of C.
(Ie imagine that universe's equivalent of Unix being implemented in Forth as its killer application and going from there.)
You can go very low level, but it has better higher level abstraction capabilities than C.
It's also really weird, which fascinates me. Eg most Forth code doesn't use variable names.
I've toyed around with Forth a bit. But never used it in anger.
Wikipedia says that Forth is used today in some bootloaders and outer space. I suspect the latter is a historic accident, because the inventor of Forth worked on a big telescope.
See https://en.wikipedia.org/wiki/Forth_(programming_language)
Kinda sorta. Technically, the program runs on an abstract machine, and the compiler is free to do whatever it wants that has the same observable behavior as the code you wrote. But this is not really a problem in practice: You will get what ask for, or occasionally the optimizer will give you something even better.
If you really need to ensure that you have exactly the layout you ask for, you could use "volatile" which tells the compiler that some region of memory is "special". Storing stuff there could have side effects. The memory could change at any time. This will force the compiler to follow your instruction verbatim. But it's not really advised since it will read the data from memory every time even if it's available for quick and easy access in a register - the memory could have changed, better read it again!
One important thing that is not possible to express in C++, is that some value, e.g. a password, should be purged from memory. A copy of the password in some random location of memory, that is not observable, so the compiler is free to create such a copy if it wants to.
import mmap # Unix, Windows
with open('c_structs.bin', 'rb') as file, mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_COPY)) as buf:
result = (YourStruct * 3).from_buffer(buf) # without copying
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.
(I would be really slow writing code in vanilla JavaScript. There's no static checking, and not much dynamic checking. So you need to watch your step very carefully---in some sense, very much like in C++.)
Mine too. I still dislike the lack of Unicode strings by default, and the somewhat confusing tooling (initially) but outside of that I quite love the language. It has a huge potential and I can only hope that the arrival of Multicore to the upstream language will kick it forward and put it in the same league as Rust (although due to GC it can never be that fast I'd think; but who knows).
Well, in theory GC can be made very fast. Though you sort-of have to decide whether you want maximal throughput or real-time latency guarantees.
In practice, we aren't quite there yet, alas.
The way to get really fast code is just to avoid allocation, I'd guess? OCaml allows you to use mutation, and it's relatively easy to peak under the hood to see what your code gets translated into.
The main technical innovation of Rust is the borrow-checker.
But that piece is very related to linear types / uniqueness types. There's some interesting work going on with linear types in Haskell.
And just like Generalized Algebraic Data Types also eventually made their way to OCaml, there's no fundamental reason they couldn't add linear types to OCaml, I guess?
(Linear types can basically be used to encode the FP equivalent of manual memory management.)
I used to think it was typing, then I became more proficient in Haskell and the type system actually saved me time.
My in-the-flow languages right now are Haskell, JavaScript and PHP, but I'm trying to add rust to it.
I have a friend who reaches out to C for quick prototyping. I know many more going for .Net or Java (which are not that far from C++)
But I still find it more pleasant than C++ so I reach for Rust instead. Plus the experience really starts to pay off from one point and on.
---
(Original reply:)
I'll admit it's not a factual and clear-and-cut distinction.
OCaml has warts (no multicore, although that's claimed to be very close to complete now; also no UTF-8 strings by default, and a somewhat surprising tooling, the first time at least) but I found Haskell to ask too much of me to even start -- I almost immediately grokked monads and lazy evaluation but it seemed to be too much effort for something you'd like to quickly play with. And when I saw the list of all compiler variants I almost gave up right there and then.
OCaml, as mentioned in the parentheses above, isn't without problems too but I found that I could get to a working dev stack and the ability to make a quick program and run it, much quicker compared to Haskell. Also, it's very terse.
Not the most compelling or factual of reasons but this is how I arrived at that place where I prefer OCaml for sketching ideas and not Haskell.
Similarly, Erlang (and thus Elixir, I guess) is also comparatively small and simple.
Surprisingly, C would be in the same category, if it wasn't so primitive and likely to make you shoot yourself in the foot.
I've programmed professionally in both OCaml and Haskell (and Erlang and C etc). I find that Haskell is generally more terse than OCaml.
They are both fine languages. Subjectively, Haskell feels a bit more fun to me. But if you want to really get into it, it helps to have some people around who know what they are doing.
> it helps to have some people around who know what they are doing
I think that's the crux of my issue. OCaml wasn't the easiest to start with either but it took me 2-3 casual evening sessions to just be able to sketch code and run it immediately with almost no hassle.
But yeah, can't deny Haskell kind of rubbed me the wrong way so I am likely biased now.
It's been a few years since I last did OCaml. At that point, the ecosystem was a bit more mature for Haskell. More libraries, better editor support, etc.
In some platonic sense I like small languages, but I had come to appreciated all the extra comfort Haskell provides. OCaml was just too much in the uncanny valley of being almost Haskell, but then missing some nice-to-haves. I might grumble, but OCaml is a pure pleasure compared to C++.
Btw, they finally added (optional) stacktraces to Haskell a few years ago.
About all the language extensions in Haskell: I like them, but they can be overwhelming. Luckily, the language extensions your libraries use has almost never any bearing on what language extensions your client code uses.
So you can ignore the extensions, and still use your favourite libraries.
C++ has pretty much unmatched tooling due to the massive ecosystem. I have my own long list of gripes against it's syntax and historical baggage, however it's a language that doesn't really impose a style/idiom like several other modern/newer languages do, making it vastly more applicable from anything from embedded to large-scale programs without restrictions. Modern C++ has smoothed a lot of the rough edges in terms of productivity, but it's still an overly complex language that cannot shed any weight due to backward compatibility, and it's a shame.
Contrarily to many other guys tough, I'd take a dash of C++ compared to "simple" C/C99 any day, especially in embedded. C++ can be vastly simpler and more readable, while retaining 100% control over memory and layout. Most of the memory/threading issues essentially disappear with very little fanfare, but few people talk about that.
I don't want to detract against static checking though! But I feel like newer languages such as Rust are still too young and idealistic, and haven't been beaten by implementation requirements or a system's programming language yet where your silly requirement is somebody else's essential feature. This is how it gets ugly, and this is where C++ has probably something to say.
I still like modern languages though. I like Rust, but won't be able to use it effectively until they get rid of static compilation. I wish I had D's metaprogramming over C++ templates any day, but the GC is a again non-starter. Nim has no static checking, but it should deserve much more consideration than it currently has: it's much more pragmatic than Rust IMHO, and it's also much easier to integrate into existing programs will less hassle.
I can't deny compiler and linker speed in general are better in C++ land but Rust is gradually catching up (too slow for my taste still but sigh). That's a very strong point against Rust to this day.
You might be right that compromises for running in embedded environments might load Rust with the same ugly historical baggage as C++. That's very possible and I can only hope it won't happen, but you do still have an excellent point about the genesis of these problems.
D and Nim I admittedly didn't evaluate very fairly -- gave them half an afternoon each. They were quite nice in fact, but I found the small ecosystem off-putting, especially in a situation when I want to play with an idea that might require libraries for 5+ well-established technologies. So yeah, I wasn't very fair to them but didn't want to dedicate much time for prototyping ideas regardless.
I have now worked with Rust for a year, and I don't see myself ever going back to C++. The statement in the article that "only the final iteration would be unsafe if one would forget to check the length" made me cringe uncomfortably. I might have written similar code as the author, but it now looks clumsy and overly complicated.
But unlike assembly, you don't have control over CPU flag registers and special instructions. Can you explain why and when, exactly, 100% control over memory is needed? Outside of OS kernels, high-frequency trading engines, and real-time control systems? If using assembly is too costly, why is using C++ economical?
And, do you really have control what happens at the machine level? Second and third level caches, hyperthreading, multicore, out-of-order execution, CPU affinity, NUMA, TLB, virtual memory, all that stuff, there is nothing in C++ which controls that.
And I would even argue that this in most cases is a good thing, because unless you are writing an OS kernel, it is none of your programs business - what it should focus on is the logical flow of the computation.
And this is what modern optimizing compilers do: They transform expressions into machine code which has an equivalent observable effect, and executes that what the programs specifies as fast and efficient as possible. Fi you write:
int a = 0;
for (int i=0; i < 100; i++)
a += i;
printf("a = %i\n", a);
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScal...
- the compiler reduces it to a single move and return instruction. This is not specific to C++ compilers - a good Lisp or D or Ocaml compiler will to the same, while managing the memory for you.
Now, control is, as in psychology, a double-edged sword. It allows you to take influence, but too much control is not a good thing, as the example of micro-management shows. In the case of the compiler, if you control too much, it interferes with the compiler's job to transform your expression into efficient equivalent machine code. The fine-tuned code you write today might be optimized for some of the modern hardware, but while it will probably still compile, it might be much less than optimal 15 years from now, and in the case of C++ without the compiler having any leeway to optimize it because you told it way to explicitly what to do.
It also interferes with your job to produce clear, valid, and readable algorithms and code. And the numerous controls which C++ gives make for a very broad and very fuzzy interface, which in turn makes it more difficult to produce good code and hard to do that in a way which is both reliable, strictly valid, and easy to understand. The issue with non-ASCII characters in words in the original article is a good example. Here is another one:
Take
include <vector>;
include <algorithm>;
std::vector<bool> vb(100);
std::fill(vb.begin(), vb.end(), false);
The C++ reference says:
https://en.cppreference.com/w/cpp/container/vector_bool
"Since its representation may be optimized, std::vector<bool> does not necessarily meet all Container or SequenceContainer requirements. For example, because std::vector<bool>::iterator is implementation-defined, it may not satisfy the LegacyForwardIterator requirement. Use of algorithms such as std::search that require LegacyForwardIterators may result in either compile-time or run-time errors. "
Do you think this is funny?
Low-level and high-performance code is not "pretty" by modern standards, as it often requires DMA and tight control over data placement in order to fully leverage instruction-level and hardware-level parallelism. The hardware influences how the data structure layout should be first, and we work on top of it. We abstract structs and containers that capture this layout, so that we can still have a readable program flow at the end.
In this sense, C++ can still be used as a glorified assembler, without the need to drop down to ASM for the simple stuff as your for loop: nobody wants to do that (me included). But contrarily to C, you can avoid a ton of preprocessor macros and get improved type checking, while still using ASM in selected spots if needed.
Your example about vector<bool> is not really surprising. Do you want the iterator to be efficient, or consistent? Tough choice, depending on the scenario. It's annoying that it's not standardized in one form or the other. I remember I was fretting over this detail over 10 years ago, but in actuality I used vector<bool> exactly 0 times in my career so far.
Again, please don't consider this as if I was praising C++. There are _many_ areas, including lack of standardization in the stdlib area (vector<bool> being one of many), that I don't like. I just want to say that it's an incredibly versatile tool which is very hard to replace given the same constraints.
This is true if you look at implementations like these:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
for example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
vs.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I'd say the C++ code in this particular case is not only much longer but also uglier.
However, how much of a fraction of C++ code in use does really require direct control over DMA calls? If you could get an at least equally fast result as when writing "normal C++" in Rust, with more safety and less effort for debugging, would this not be tempting for many people using C++? Because this is what I observed in my case. And this given that I've written no more than a few hundred lines of performance-critical code in Rust, and have worked for > 10 years on performance-critical code in C++ and C.
The thing is, what cppreference says here is that this innocent-looking code might either not compile or cause undefined behavior in whatever part of the program. In my case on GCC 8, it caused memory leak warnings with address sanitizer. For larger programs and especially for programs which have hard requirements on real-time latencies, safety or robustness, this is not acceptable.
And yes, an experienced C++ developer will initially need a little more time to write the same code in Rust, compared to C++. (I do not think this is true for developers new to C++ because C++ is a very large language). However, in any larger program, the time spent for testing and debugging is very likely larger than the time spent for typing in the first code. And in this metric, Rust's strict approach to correctness is far better.
And if you get to debug undefined behavior in large multi-threaded programs, the time you can spend debugging code is basically unbound if you were were not both experienced and careful with writing first.
Side note,I would like to learn OCaml and am interested you drew a distinction between Haskell (former group) and OCaml (latter group).
OCaml is a bit more of a drop-in replacement for something like C++ or D. Mostly because it's strict by default, so it's easier to reason about performance even for a non-expert user.
OCaml's approach to side-effects has now entered the mainstream: it's considered good style to avoid them, but they are still used pervasively. That's very similar to what good modern C++, Java, Python etc style advocates.
Of course, Haskell also allows side-effects. But generally, you track that they are occurring with the type system, you generally stick them in some kind of Monad or Applicative Functor.
As already stated, I'm not a fan, but apparently a lot of people out there manage just fine with C++ and claim that it's actually easy and possible to attain complete control.
I'd imagine that could be somewhat true if you invest decades in that language.
When people write those kinds of things, they're being hyperbolic. It's best not to assent, in light of the chest thumpers. Complete control just isn't possible in C++. More control than many of its contemporaries, yes.
This slightly over 100 page book on move semantics https://leanpub.com/cppmove shows some of the iceberg like complexities dotted all over the place. Some developers probably never use and have never even heard of move semantics.
I've been programming in C++ pretty much my entire career. Personal projects or small projects I'd use Ruby or Python first. I'd only ever use C++ (or a very specific subset of it) if I want to make something extremely performant.
C++ will eventually peak and die off but the timeframe is probably measured in decades and I'm sure there'll places where it holds on even then, like Fortran today. I certainly would't recommend it to a programmer starting out today, instead C or Rust would be better places to get an idea of system level programming.
I think Scott Meyers' "Effective Modern C++" which is in large part a collection of caveats and description of things which don't fit always together also underlines that impression:
https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...
Ended the book in a pessimistic tone. It looked more like a cookbook of pitfalls _everywhere_.
Every new feature looked exciting, but came with a list of cases where the language decides to leave you on your own when it gets too uncomfortable (the "well that's undefined behaviour, I'm sorry, you suck! bye!" escape hatch). So in the end it's like you said: a new list of gotchas to learn by heart.
Also let me use this comment to recommand John Lakos, his talks, his books. He knows how to build large scale applications and if you saw his talk on the 'is_working_day' function (if I remember correctly) you know you were not overthinking.
Also I'd be curious to see that talk you mention, do you remember anything about it that could help in searching for it?
Scott Meyers book was one point.
Then I started to learn Clojure, motivated by the idea that we need better concepts for the upcoming massively parallel hardware (a big influence for me was the article "The free lunch is over" by Herb Sutter: http://www.gotw.ca/publications/concurrency-ddj.htm). I now think that immutability by default is clearly the better way to go, even in close-to-the machine applications like embedded devices and industrial control applications.
Then, I saw this article on the different options and syntax for initializing variables in modern C++: http://mikelui.io/2019/01/03/seriously-bonkers.html
And I was like, no, this can't be serious. I think this was the point where I began to distance from the language (though I still use it at work when I need to).
I got also the impression that the actual language use in C++ is undergoing a serious split. Compare the C++ core guidelines with Google's C++ style guide:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
https://google.github.io/styleguide/cppguide.html
This does already look somewhat like different languages, only that they can be compiled with the same compiler.
And then, the C++17 and C++20 standard iterations, at this point it is just like "this is too much! What is this good for?"
Unlikely. The only candidates for replacement are Rust and D, none of these are anywhere near the adoption of C++.
What C++ can do is get better at being a language and then maybe give tools for developers to phase out outdated constructs or relics from C. It is not going away cause it's the best replacement for C humanity will ever get, at least for the next century.
Neither C nor C++ have replaced Fortran in that sense, either. Yet, as far as I can tell, Fortran has peaked a long time ago.
100x this. If >90% of your serious coding is in one language, you'll become desensitized to its bad parts but you'll be hyper sensitive to anything that seems inconvenient in any alternative. I've seen this over the years with Fortran and C coders. C++ coders do it to C all the time. Lisp coders are notorious for it. It's Selective Perception 101, counting the hits and ignoring the misses. We're all prone to it, and have to correct for it.
If you really want to compare any two languages, you have to give both a more than casual try, and keep an open mind throughout. Otherwise your conclusions are likely to be unhelpful at best.
Consider horrors such as this. In the following statement what are foo and bar?
int x = foo(2) + bar(3);
int x = (foo)2 + (bar)3;
Foo b = c + 3;
Many of these craziness is being addressed by standards committees. C++ as designed by Stroustrup is a horrible language. Just look at his C++ book. It is huge and heavy and in fact Stroustrup takes pride in how big and complex the language is. C is an awesome language. C++ is horrible.
That being said, it can certainly be ugly. A lot of the ugliness comes from trying to maintain itself as a mostly superset of C. Technically it no longer is strictly that, but most C code will compile fine in a C++ source file.
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 will eagerly proclaim that they have macros too -- even if they're not homoiconic and so harder to work with than in Lisp. Few if any are the languages that proudly proclaim that they don't have macros because they thought Lisp macros were a big mistake.
C++ fans themselves often point out that C++ templates can be as powerful as Lisp macros.
So which is it? Is giving users the power to radically transform their language a bug or a feature?
For example:
The casting style can be enforced via linting. There are also C++ cast operators, that in my opinion should be preferred to the C style casts: static_cast, dynamic_cast, reinterpret_cast, const_cast, static_pointer, dynamic_pointer_cast, const_pointer_cast... and you can enforce that those are preferred rather than C style casts.
It is true that C language has some very limited implicit type conversions. For example you can say:
long n = 3;
unsigned n;
n = 2.99; // n = 2
n = -1; // n = 2^M-1;
n = 1.0E33; // undefined but not catched
auto n = a + b;
I disagree. I think ever since it’s inception from C, C++ has tried to increase type safety and continuously move more of the work to the compiler (latest example is concepts). It does empower the programmer to do what they want: OOP, FP, GP...
The philosophy of the language is mostly about abstractions. Abstracting objects, types, resource management etc And using modern C++ features and a recent compiler makes it harder to make mistakes. Using some generally accepted guidelines and static analysis tools helps even further.
Though the syntax is at times ugly due to the age of the language and it has a lot of inertia that makes it hard to get rid of some bad design decisions like some of the defaults, unless someone recreates c++ with the same flexibility and power, and the same powerful compilers/tools but with better syntax and defaults I don’t see the language going anywhere. And I am not holding my breath for another language to quickly be able to reproduce the C++ echo system that have taken decades to develop.
What? C will happily compile this:
void g() {
float f = 3.14;
int* ip = &f;
}
complex c = 3i;
... = c + 4;
The issue with C++ is that implicit is the default, not that it exists.
complex c = 4;
The issue with C++ is that implicit is the default, not that it exists.
If your data type implements the Num typeclass, you can use literals like 4. (A typeclass in Haskell is similar to what they call an interface in Java.)
There's no automatic conversion happening at all. It's done via overloading literals at compile time. (You can do the same for strings.)
What it doesn't solve that by default the compiler tries to find an appropriate implicit conversion. Sometimes it's convenient, sometimes it's harder to see what the code actually does.
Yes, the implicit conversion for all values is part of the problem. The Haskell approach only gives you magic for literals.
Also, I agree that implicit conversions in general should be avoided, but this complex number example feels like the perfect use case.
With that said, C programmers also seem to love their implicit behavior so it's pretty clear where this kind of thinking comes from.
Only if you ignore your compiler output: Even TinyCC will warn about that one on default settings. With the flags I use, the code would in fact fail to compile.
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);
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);
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.
BTW, in C++ every call is resolved at compile time, and the compiler could tell you what you are exactly doing at each line, including whether your examples are function calls or casts. 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. Cppexplorer helps a little bit, but I always find it difficult to understand. It's a problem of tooling, though, the language is well defined.
CLion, ctrl+B.
I don't understand your point. What's exactly the problem of knowing what are foo and bar? Even if you struggle with C++, any half decent IDE allows you to check the symbol and see what's being called with a single mouse click.
So what's exactly the problem?
> As another example consider implicit type conversions:
Again, what's exactly the problem? If you write down "c+3" it's your responsibility to know what you are doing and that "c+3" does make sense. And your example can only start to become a possibility if you explicitly and quite intentionally define your constructors to allow implicit type conversions, which is a direct violation of basic C++ best practices.
Adding to that, your convoluted example is no where near the mess that's javascript or Python and somehow people manage to not screw that up even without any type checking.
So why single out C++ although it does provide all sorts of guardrails and sanity checks?
> Many of these craziness
You failed to show any semblance of "craziness" in any of the convoluted examples you presented. In fact, you only showed you struggle with a language you barely have any experience with, let alone a grasp on rudimentary best practices such as requiring explicit constructors. Thus, why pin the blame on the language instead of where it really belongs: your lack of knowledge and experience using the language?
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 them in the wrong way, you get into a world of hurt. And in the real world, C++ programmers do not agree on which subset to use.
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 intellect to write in, is frankly refreshing.
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.
So if you like a challenge, if you like learning, or maybe if you simply enjoy flexing your brain cells a bit more then most, C++ delivers that on all fronts.
As for whether it deserves a bad rap, that's a little too generalized of a statement, and it reeks of dogma. Ignore dogma, dive in, learn for yourself what you think sucks or doesn't.
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.
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.
I am sure any such developer will get equal treatment from another who is an expert, right?
Whenever I'm forced to using C++ only a tiny amount of the time is spent actually implementing my ideas.
Most of the time is spent figuring out how to fix incredibly cryptic compiler error messages that usually have nothing to do with what I actually did wrong.
Then I have to figure out how to get all the dependencies in a way that will still work in a year or two, without directly committing them to my git repo, and setting up various complex build tools that were created decades before anyone even imagined package management.
Finally I hope that nobody will ever look at my code because I definitely didn't follow "best practices". The best thing I can do is sprinkle "const" wherever I can because of my religious belief that immutability should be the default. If I wanted to stay up to date with the latest developments in C++ and the accompanying proper ways of doing things I feel like I'd have to forget what little I know about the language every time I used it and learn it all over again, just to avoid doing stuff that some blog post now says is "considered harmful". I might as well try staying up to date with JavaCoffeeTypeScript using the latest AngularReactVue and whatnot.
Unfortunately, once a project grows to many developers, many of whom have varying levels of experience, it's just too easy to write bad C++ that becomes impossible to debug. I've been using it for a decade and I swear I barely scratch the surface of its features.
Lastly, and this one is the most annoying, C++ also has cryptic error messages that almost always never mean what they suggest. You'll learn to understand them over time and decode their meanings, but at first glance you'll spend long days hunting for the wrong issue.
"Best" is such an undefined term it's word-noise here. "Best" in terms of end-user extensibility? "Best" in terms of debuggability? "Best" in terms of having a single binary which can be copied and run without regard for machine architecture and OS?
Does it?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The issue with C++ is that it's unsafe by default. Foot-guns abound. The right way is to make everything safe by default and provide an escape hatch when needed, e.g. Rust's unsafe or C#'s unmanaged.
Unfortunately, there's no way to "fix" C++ to be safe-by-default. Too much legacy code out in the world and no appetite in the standards committee for backwards-incompatible changes in future versions of the standard.
It seems obvious to me that e.g. C++2X should entirely drop some older, broken, unsafe concepts, e.g. auto_ptr is the first thing that comes to mind, but there's all kinds of gnarly bits that need to go, and just allow older code to continue compiling under previous versions of the standard.
That does leave libraries in a tough place - if your project wants to move to the (never going to exist) backwards-incompatible C++2X, they would need to update or remove all libraries not compatible with the new version.
But this seems like a way to eventually move the entire ecosystem to a better place. Possibly the only way.
It’s not a perfect solution , and obviously not built in, but it is a big help for avoiding footguns.
It's like the old saw that gets trotted out about C and C++; you can write safe code in any language if you're disciplined about it. The point of safe languages is to make it easy and accessible to write safe code; to design into the language a "pit of success" rather than requiring a big slog to make a flawed language usable.
If that foundation were to be redesigned one'd have to get rid of the current near-100% compatibility with C, making the interop no longer an argument for using C++. Add the fact that most real-world C++ code will also be incompatible, and the strongest argument for using C++ is gone (namely, the impressive ecosystem size and maturity).
At that point there'd be no more justification for the existence of C++ over Rust (or another language that takes Rust's good ideas and supersedes it).
I think that's plenty of reason all by itself.
But..
There is something about the use of destructors, RAII, and even smart-pointers that just feels so...elegant? I'm not sure what the word is I'm looking for. I feel like there's a kernel of a beautiful language hiding in c++ and those features are the integral parts of that.
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?
As others have pointed out, CMake is the de facto standard in C++. However, a combination of CMake with Conan seems to take care of most of anyone's needs. The downside is that the availability of C++ packages in Conan tends to be very limited.
[1]: https://github.com/microsoft/vcpkg [2]: https://conan.io [3]: https://github.com/cpp-pm/hunter
Bjarne Stroustrup
I understand C++ is messy because, back in the day, Stroustrup never say no to a request or suggestion from a potential user. He wanted his language to be widely used. Guess he succeeded.
(Not quite _every_ way: lack of per-container allocators, and less advanced generic/metaprogramming facilities are two particular pain points)
I guess my point is, this is a weird (and IMO, flat-out wrong) dig at the Rust community.
How would you know C++ isn't optimal if you've never tried or thought about anything else.
That and the sunk-cost of learning C++ is large.
I.e. my current lecturer in C programming seemed to imply we were going to be learning about object oriented programming in plain C (specifically inheritance), which does not bode well if he didn't misspeek
#include <iostream>
#include <regex>
#include <string>
int main()
{
std::string s = "Python*C++*Java";
std::regex regex("\\*");
std::vector<std::string> out(std::sregex_token_iterator(s.begin(), s.end(), regex, -1), std::sregex_token_iterator());
for (auto &s: out) {
std::cout << s << '\n';
}
return 0;
}Plus, using std:: is generally a good reminder that you’re using the standard library types and not some homegrown facsimile of that type, as is common in many C++ projects.
`using namespace X;` is somewhat fine if you limit it to a scope by using it in a source file and ideally only the function body where you use it, in header files it is a really bad idea because then the namespace gets exposed to everything including that header. That can lead to the compiler calling the wrong function and you might not even notice it.
Verbose and clunky and needs a web search to do, yes.
I'm guessing it's analogous to Java's Regex. Like, yes, they're there and do as much as any other language, but lord it's a PITA.
There is, however, boost::split from the famous boost library.
auto splitText = text | view::split(' ') | ranges::to<std::vector<std::<wbr />string>>();If one needs random access they can always do the bidirectional range -> vector of string_views conversion.
Ranges are relatively new in the standard and not many algorithms landed in the library. I'm pretty sure there will be many new range algorithms in the upcoming standards. This particular algorithm is probably worth suggesting. I recommend floating the idea on the cpplang slack (there are #ranges and #future_standard channels) and/or the std-proposals mailing list. I never wrote a proposal, but you can chat with people who did.
You can get an invitation here: https://cpplang-inviter.cppalliance.org/
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 management is one of the things that sucks the most in any language, and the ones that dont its because the complexity is hidden in another fundamental layer.
scala> "Mary had a little lamb. The lamb was in federal witness protection.".split("lamb")
res0: Array[String] = Array("Mary had a little ", ". The ", " was in federal witness protection.")I meant for languages where the hard parts are delegated to another like Python and Javascript (C and C++ respectively).
"a, b".Split(", ") // C#
"a, b".split(", ") # Python "a, b".split(", ") split "foo.bar" .
=> foo barThis misses the point. I don't care how the language implements the functionality if it meets my performance requirements and it is convenient to use.
I dont think it does, because it meant you are working on a simple language that can only afford to be simple delegating the harder parts to other languages that took the effort to be designed to deal with everything.
The convenience is payed by someone else, and the language that pay for the hard stuff are the ones that are complex, because they need to work well with any sort of algorithms.
Unicode is a slight pain (it's explicitly supported and works fine but it was designed before UTF8 dominated so there's baggage)
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.
Check the Boost C++ string algorithms library.
https://www.boost.org/doc/libs/1_74_0/doc/html/string_algo/u...
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.
I do believe (not as a religion, but based on the progress made with languages like Rust, Idris, Haskell, Typescript etc) that the trend towards provable/robust safeness will continue in the coming 10 years. Progress is slow, but it is there and the libraries + proof assistants (possibly AI assisted) will improve. Somehow that will find it's way in one or more of the languages we are using now (because shiny new things).
Anyway; I don't have that feeling, at all, about languages and codebases I have been using for 1 or more decades; c, c#, php, java, pascal, perl (only exception is JS; it was awful 10+ years ago and I do like to complain about that but I maintain only 1 significant codebase in 'older' js (about 8 years ago?); it is a (callback hell) nightmare, currently being rewritten in c#); I work on significant sized codebases in all of these and they work fine (no money lost, no people died (no avionics either though, but still enough opportunities where people could've died because of something I wrote or was lead on)).
> Its psychology. We need the shiny new thing to give more meaning to our lives.
'We need' => maybe most people do, I don't. I actually never really liked new things. I want stability as my work demands and has demanded that for decades and it creeped into my non-work life. I want things to be reliable and robust 'forever', not new things that I don't know of how good or solid they are (spoiler; they are usually not, in code nor meatspace). I like to pay people, keep my company healthy and sleep at night; shiny new things do the opposite in most cases.
Well, "serious things", that is, larger, robust programs need a lot of experience and discipline. This is true in any language and if people do not watch for it their library landscape turns into a hot mess quickly. Take Python.
But the thing is, I believe that in many applications, C++ does not make it easier to build serious things. It adds complexity and when working on large-scale stuff, you need extra complexity as much as a hole in the head.
> 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 operations?
This is what people who don't like C++ complain about, in addition to the language, the self-indulgent culture around it.
It certainly ensures that I don't take their conclusion to be worth much.
It's unfortunate that the compilers don't automically turn on -werror, -wall and other useful flags that can help alleviate lots of arcane issues. I also think the tool maintainers do a poor job of promoting the use of UBSAN, ASAN, TSAN, etc. If you watch talks, you'll learn about these tools that solve most headaches, but you have to be so in the know to be aware that these tools exist. You have to dedicate time outside of working hours to really absorb all this information and imo that's unacceptable. Other languages put a larger effort towards making their tooling easy to use and provide amazing documentation (c# is the best at this imo). I'm a c++ dev and I love it in a masochistic way, but if these issues aren't addressed rust will eat c++'s lunch.
(There are of course a number of non-AAA games too, but since you asked about that specifically...)
Isn't that provided by at least Golang and Zig currently?
I don't know, my OS vendor provides Bash, Python, Perl, and a great whack of CLI programs and libraries. I know Python programs are pretty useless on systems without Python interpreters, but so's an ARM64 binary on an x86-64 system. I get what the quote is trying to claim, but it doesn't stand up to much scrutiny.
For almost every modern language, you can easily build and run code - pull code from repo, run the included script or standard command to get the dependencies and build it, bam, you're done without needing to know much about that language.
With C++ it seems like half of the time pulling someone else's old project from github and running make (or whatever the author's instructions in README are) results in failure with some error that's tricky to diagnose and fix. For example, you would get some weird code error message that has zero indication with the actual cause which is that your system has a newer version of some core library than the author had.
At least you won't get these packages that will pull 309 dependencies, and that might build or not with the dependencies that are automatically pulled or not (with a considerable chance that it doesn't).
With C/C++, there's a bigger manual upfront investment if you want to integrate a library, but it might just be that you get cleaner libaries.
As for the claim "As this program has only one thread, it can be formally proven to be thread safe": well, it is technically correct, but it just looks like a somewhat desperate attempt to make something out of nothing, when compared to, say, "thread safety is not an issue here."
I having been writing C++ extensively for research/work/etc the past 5 years. Compared with modern languages it completely deserves the bad rap.
C++ has come a long way, can you write cleaner code than you could 10 years ago? yes. Are there safer abstractions than there were? yes.
The amount of issues I have to deal with in C++ on a day to day basis which are just non-issues in Rust or Go, etc.
Without complaining too much dependency management and tooling are stuck in the stone age.
Every time I get to use Cargo going back to C++ is a nightmare, even Python which has pretty poor tooling around this is a million light years ahead.
Even simple things like having to carefully order headers or deal with obscure cross-platform incompatibility are mostly non-issues in newer languages and the baggage of C and C++ leads to a lot of unnecessary pain that doesn't provide low-level control or performance advantages.
Once you have the discipline you need in C++ to make mutable data structures work its a hugely efficient place to be. However I sleep much better in the non-C++ world.
When you're dealing with UTF-8, you can't overwrite your buffer in the general case because changing case can change the encoded length of the characters.
Of course, it still will support headers.
i like how haskell does it: https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-...
https://madnight.github.io/githut/#/pull_requests/2020/3
I think it's mainly due to the introduction of C++11, C++14 and C++17, which _has_ rejuvenated the language, despite the criticism.
Discussions like this one tend to be sort of skewed, because opponents of an old technology, like C++, tend to be more vocal in their opinions. Likewise, proponents of a new technology, like Rust, also tend to be more vocal. It becomes sort of noisy. Behind the noise, though, I think the fact remains that C++ is still very solid, and probably even more so than it was just a few years ago.
- navigating through template compilation error messages is a pain. - standard library is getting better, but still feels lacking. - different commonly used libraries have different code styles and reimplement the same things in different ways. - combine the previous two and you get small-ish projects where you have 4 or more different types of strings (char, const char, std::string, QString, ...) - no standard build/publish/compile/library distribution system makes using less-known external libraries a giant pain in the ass.
What I want is easy build and dependency management system like maven.
I wish few professional C++ dev unite and build an open source tool like maven (assuming it will not take lot of time) which allow me to:
1. Create a project from skeleton project 2. compile 3. test 4. build/run 5. Key=value=version type system to download and auto build dependency.
That's it. :)
I tried building myself, but I think it is too much for a beginner project. I named the project 'goat'.
The best programming language is the one you are most familiar with. Yes you can write faster code in Ruby,Rust,Python etc but often times those languages hide soo much code, leaving you with a sparse understanding of the underlying concepts.
Language wars are not my forte but, I say use the language you are most comfortable with and become very good at using it. What takes you 30min in c++ may take me 5 min and vice versa. Happy coding!
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]
find . -type f -name '*.txt' -print0
| xargs -0 cat | tr ' \t' '\n\n' | grep '\S'
| sort | uniq -c | sort -nr | sed 10q
CMake helps, but the fact that it's been around for 20+ years, and is still the best tool of it's kind, is food for thought.
I think C++ is not inherently completely bad, the usual thing is "do it the right way" which is usually some spec the community has drafted up with arguments why certain styles or code decisions are bad and what their better alternatives are and why. In the face of Python we have PEP-8 for example.
C++ makes it easy to shoot yourself in the foot with a shotgun, and that means you need to think a little more about your approach and ensure you know what you're doing to begin with.
Anyway, here is my bash version of the problem. Now that WSL is distributed with windows, does it also hit the "runs on all major platforms with no dependencies" mark? For the record, this hits the enjoyment mark 100%.
cat $(find . -name "*.txt" | xargs) | tr ' ' '\n' | sort | uniq -c | sort -k1 -n -r | grep -E '^\d+ [[:alpha:]]+$' | head -n 10
A random example: https://bloomberg.github.io/bde-resources/doxygen/bde_api_pr...
I am sorry but there is no reason to choose c++ for new projects especially when there is Rust, Go etc. But legacy app is exception .
I look at C++ and wish it had C#’s compile-time attributes, first-class reflection, mixins, a decent syntax for pure virtual functions, and a more logical pointer syntax (it’s illogical and you know it). However, they can’t give me those things without drastically breaking backwards compatibility. At that point it’s a new language.
I wish we could just develop a C++ 2 for greenfield projects and stop development of C++ where it’s at instead of Frankensteining more features onto it. I guess that’s what Nim and Rust are for.
int* -> pointer to int
and
&abc -> address of abc
and
abc->xyz -> pointer access to xyz field
and
*abc -> dereference
not as easy as it gets? 4 operators for 4 different things - whats the issue?