Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 4322 views
  • Likes 6 likes
  • Comments 20 comments
Related
Recommended

Sorting in the C++20 release

Jan Cumps

I don't get over-excited about programming languages and their evolution easily.

But it happened this time. C++ is introducing a new dialect. The 2020 standard.

 

There are a number of things that are useful but I wouldn't consider them groundbreaking (watch cppcon videos for people that get excited but do not sound like they are excited).

 

Then there is the new sorting functionality.

In C++, you can overload the sort algorithm.

This is very handy. Developers can create sorting algorithms that can teach their objects to sort themselves.

In the past you had to generate equal, not equal, greater than, smaller than, greater or equal, smaller or equal.

Many times, you implemented two of those, and derived the other ones based on that.

 

There's a new comparator now: "<=>".

This one covers all situations. If it fits your scenario (I think it does in many cases), you get all the comparators implemented in one class member.

That means that it 'll be easer to write objects that plug in to the sorting algorithms of C++.

We all dream to write code that says if (thisObject < thatObject). Or use standard algorithms that can sort or compare our home-written objects.

I think that the <=> operator helps with this, by reducing the work for the class designer.

 

For the record: this does not cause any run-time or code-size cost. It's resolved at compilation.

I take the critique of developers that do not like abstraction: things are happening under the hood.

But no cost for memory, code size or performance. And a gain in understanding what you want to achieve in the code.

I'll post examples later.

 

If you want to start playing with the new options: Try out C++20 Preview: set up a development environment

  • in reply to Andrew J

      wrote:

     

    Arduino have done a good job of masking the complexity with the language and compiler but still, use of pointers/references and memory consumption leakage is still a complexity. When I was working on the R65N MCU roadtest last year, I had to trawl setting-by-setting through the compiler and linker settings comparing against a 'working' example to find the setting that fixed my problem.  In memory management configuration - WT*$% is that all about in this day-and-age!  OK, memory management on a constrained microcontroller is important and necessary but really, I feel C and C++ are constrained by their past and programming for the technology available at the time.  They may be getting simpler, I wouldn't know as they start from a point of being way too complex in the first place image

     

     

    I agree, Arduino has done a good job at hiding the compiler complexity. I find they have a great way of handling libraries and board configuration. But it has taken a good while for the core to mature. Now if you look at the newer Arduino boards this is not always true. For example, I recently got an Arduino Nano 33 BLE board and here they have not quite got it right, yet. This Nano 33 BLE board is built with an Arduino wrapper on top of Mbed OS. Now that is a complex mess if you have ever seen one.

  • I remember when C++ came out and was supposed to be the next best thing to sliced bread.

     

    In some areas it came close to living up to its hype, in other areas, not so much.

     

    Like any language, you have to take time to learn and understand what it can do and how you need to use it before you become truly proficient.

     

    DAB

  • in reply to BigG

    Interesting.  I've programmed professionally (i.e. a paid job) in RPG III, RPG IV, Smalltalk and Java (including enterprise extensions) but have played around with many languages over the years - Basic, Pascal, Cobol, Swift, C amongst others.  I've always found C and C++ verbose in comparison and, in my view, unnecessarily complex.  Which means I've always found the languages tedious to use.  Having started OO programming in Smalltalk, I quite often back-compare OO in other languages to that and feel like they stopped at about 90% OO complete!  In Smalltalk everything is an object, even a Class is an object and its methods are objects, and there are no such things as base types such as int, byte char etc.  I'm not trying to big up Smalltalk, it's been a non-useful language for many years, but it was consistent and simple and even with my incursions into Arduino and microcontrollers, I still find C (and C++) tedious and complex, and the compiler/linker configuration arcane!  Arduino have done a good job of masking the complexity with the language and compiler but still, use of pointers/references and memory consumption leakage is still a complexity. When I was working on the R65N MCU roadtest last year, I had to trawl setting-by-setting through the compiler and linker settings comparing against a 'working' example to find the setting that fixed my problem.  In memory management configuration - WT*$% is that all about in this day-and-age!  OK, memory management on a constrained microcontroller is important and necessary but really, I feel C and C++ are constrained by their past and programming for the technology available at the time.  They may be getting simpler, I wouldn't know as they start from a point of being way too complex in the first place image

     

    I've been playing with LabView recently.  It has some good features - especially parallel execution - but it's a candidate for tediousness to put even C and C++ on a pedestal of enlightenment!

  • Thanks for sharing this update .

     

    Back in the 1990's I was involved in a real-time monte-carlo based simulation software project, which was all done in C++. Back then computers were slow and the sorting algorithms made a huge difference. While I could never quite fathom C++ back then and had whizzy programmers doing the work. I relied on Visual Basic for my analytics software instead. It was slow but it integrated very nicely with Excel. A classic lose-win scenario. Anyhow, sorting algorithms made a huge difference there too - we're talking minutes of a difference with VB. With more speed and power, I can fully appreciate how this (STL option) should now make a difference in reducing code size and complexity. This is a good feature... and thanks to the many applications and good quality examples out there I am finally understanding C++ and I might even find a need for this <=> comparator (beside applying it in a new emoticon  image).

     

    And then I look at Python. I keep reading about the hype and the buzz about Python but it has yet to grab me and I've yet to find a project that requires it (I realise my Linux desktop is all done in Python so I know it's pretty good). Recently, I looked at the end to end programming process rather than just the language and compared it to GO or Golang and thought Golang did things better than Python (although there's not many examples out there). But that's just me.

     

    Then much like   I often wanted to learn C# (and TypeScript) but yet to find a compelling reason to use it. Maybe one day.

     

      /----\

    / <=> \

    |_|_|_|_|

     

    C://

  • in reply to shabaz

    That's the spirit, image. I think that embracing many languages is a big enabler.

    It stops thinking in dogmas, and allows to use good solutions at the appropriate time.