What the title says .
Since autumn 2021, I'm learning the c++ 20 language evolutions. Almost finished. Is anyone else into this?
What the title says .
Since autumn 2021, I'm learning the c++ 20 language evolutions. Almost finished. Is anyone else into this?
I'm not using it, but I still have interest and I enjoy seeing what can be done with it.
Any pointer on the evolutions would be interesting to check out.
I have used old STL, although usually dragged reluctantly into it, because I don't use it often enough any more. It's extremely powerful of course but used to be quite difficult to debug from cryptic error messages, maybe that is improved now? No idea. I got there over time though, through lots of familiarity in recognizing the same error messages a few times.
Also, some users may never experience STL since it may be in the libraries they use, but not in the end application code, and not see what a great problem-solver it can be.
Currently I'm keen to learn CMake a bit more, I started a tutorial, and need to get back to it sometime.
I think that STL has been a gem from the start. With warts. The implementation has been lean from the start; better containers, iterators and reuse, than what most of us would invent.
It was a kicker for the template part of the c++ language. The first time that a lot of people could profit from it - even if they didn't understand the abstractions.
And it had a lot of issues. Some because of naïve assumptions, some because the language itself had restrictions, some because they didn't know how it would be used yet.
I think that the c++20 iteration is well worth reviewing, because it's a mature version, that dealt with many of the things (including funny error messages). They kept everything that was valuable from the initial design. Several of the later additions became part of the standard. But they also kicked out some of the later additions that were weak.
This version c++20, I think, is a sound release. Learning it will also introduce the language improvements that have been happening along the way.
Currently I'm keen to learn CMake a bit more, I started a tutorial, and need to get back to it sometime.
That will be valuable at any time. Regardless if you do c, c++, whatever compiler or version, … Being able to set up or use a good build and dependency environment is an asset. Great skill for a single developer. Essential for a mature team.
I recall finding some bugs on occasion with STL, but they could have been compiler bugs. I think on my next software code in C/C++, I'll aim to do incrementally more and more C++ each time, and start using STL again from time to time too. It's a brilliant problem-solver.
If STL can do the job, I've always preferred it over other libs (like boost, or native OS lib). But I haven't stayed up to date with the latest additions of the language.
C++ gets on every release more and more complex. More rules, more exceptional cases and newer complex concepts. Templates were right from the start a little confusing, and they have continued to add more features to it. I just can't imagine how much more complex it has all become. It looks as if they wanted to make the language so complex that nobody would ever be able to fully understand it.
Some will tell you that you don't have to use or learn every features, and I agree, but only if you are the only one writing code. The moment you are working with other's people code you have to learn all these new features (unless they are not used).
A few weeks ago I began learning Rust after seeing more and more support from companies and people, and so far I've liked it quite a bit. I'll probably prefer it over C++ every time unless its not an alternative. Rust feels like a modern language with many new and interesting features that I've never seen in other languages, that make life much easier.
attention: critique and comment:
I've always preferred it over other libs (like boost, or native OS lib).
Some boost libs made it to standard. I think it's a great cradle for ideas.
C++ gets on every release more and more complex.
It does not. They simplify with each release, as well as growing. People use new options, learn from it, and critique. The committee takes the learnings into account.
Templates were right from the start a little confusing, and they have continued to add more features to it. I just can't imagine how much more complex it has all become. It looks as if they wanted to make the language so complex that nobody would ever be able to fully understand it.
They are new if you come from functional programming. They make your life easier if you're building object oriented reusable objects. Templates aren't complex. They are thing to learn if you want to write generic libraries. They are a non-event if you want to use those libraries.
Some will tell you that you don't have to use or learn every features, and I agree, but only if you are the only one writing code. The moment you are working with other's people code you have to learn all these new features (unless they are not used).
That has been true since assembler introduced macros.
A few weeks ago I began learning Rust after seeing more and more support from companies and people, and so far I've liked it quite a bit. I'll probably prefer it over C++ every time unless its not an alternative.
We all have that, don't we? A preferred language that feels like home. Something that's a free thing when doing a hobby.
In this post, I'm looking for thoughts on c++ and STL. There are going to be a wealth of good (better) contenders out there. They won't add to the discussion. There will be Python post here too. If they talk about a different mechanism in the language related to the topic, that may help. Else it's just the internet being the internet.
A Pico OO program that uses a class to talk to an m25xxx SPI flash eeprom IC, and stl containers to return bytes.
The program uses auto to iterate over the bytes:
class declaration:
class m25 { public: m25(spi_inst_t * spi, uint sclk, uint mosi, uint miso, uint ncs) : spi(spi), sclk(sclk), mosi(mosi), miso(miso), ncs(ncs) {} ~m25() {} void init(); std::vector<uint8_t> rdid(); std::vector<uint8_t> rdsr(); private: enum commands : uint8_t { RDID = 0x9F, RDSR = 0x05 }; spi_inst_t * spi; uint sclk, mosi, miso, ncs; // ...
implementation:
// ... std::vector<uint8_t> m25::rdid() { uint8_t buf[3]; // command uint8_t cmdbuf[] = { RDID, }; setDataBits(8); select(); spi_write_blocking(spi, cmdbuf, 1); spi_read_blocking(spi, 0, buf, 1); // Manufacturer Identification spi_read_blocking(spi, 0, buf + sizeof buf[0], 2); // Device Identification (Memory Type || Memory Capacity) deselect(); return std::vector<uint8_t> (buf, buf + (sizeof buf/sizeof buf[0])); } std::vector<uint8_t> m25::rdsr() { uint8_t retval = 0U; uint8_t buf[1]; // command uint8_t cmdbuf[] = { RDSR, }; this->setDataBits(8); this->select(); spi_write_blocking(spi, cmdbuf, 1); spi_read_blocking(spi, 0, buf, 1); // Read Status Register this->deselect(); return std::vector<uint8_t> (buf, buf + (sizeof buf/sizeof buf[0])); } // ...
Several things look completely different than C, others are exactly the same. The parts that are the same, are usually the places where I talk to the RP2040 C SDK.
side story: a year ago, I had to install specific toolchains to be able to test part of the standard c++20 features. And could run it on a Windows laptop and a decent SBC, like the Pi.
Now, I can just use the default Raspberry Pico C toolchain, and then can compile & debug c++20 OO software for the RP2040 controller. Things move.