Category: C++

raspberry pi 4 status report for 10 april 2020 – running pretty good these days

whbeebe

If there’s one thing I’ve been critical of with regards to the Raspberry Pi 4, it’s been the fact it runs hotter than any prior Raspberry Pi. I run my Pi 4s in a Flirc case (https://flirc.tv/more/raspberry-pi-4-case) in order to keep them as cool as possible during operation. Yet as good as the Flirc case is, the Pi 4 with the Raspbian initial release still easily hit the mid-50°Cs (or hotter) with just regular usage. Recently I’ve noticed that the Pi 4, with the latest version of Buster (including all patches) and the firmware, is running a good 10°C cooler, around the mid-40°C or cooler. When I now put my hand on the case it’s barely warm, not the hot little brick when I first put the Raspberry Pi 4 in the case.

In addition to running cooler, Raspbian Buster appears to be using a lot less memory resources than before, such as when having many open tabs in Chromium. More often than not I could see on htop where swap was being hit with a regular load of Chromium, multiple open tabs on the Terminal with multiple editing sessions, and regular builds with any of Go, C++, Rust, Python 3 or Julia running. I’ve now had the Pi 4 up for five days with continuous use and I haven’t hit swap yet.

And speaking of Julia, I installed version 1.4.0 and then installed all the supporting packages I normally need. One of those packages is Winston, and it has problems. Winston under Julia 1.4.0 is dependent on more packages than ever these days, so much so that any Julia script I’ve written won’t run because not all the current Winston dependencies are met. As a consequence I’ve dropped back to running the prior release, Julia 1.3.1. My scripts still run, and for the time being I’m not updating any of its packages.

configuring xcode’s clang to compile using a given c++ standard

whbeebe


I’ve been working with C++ lately, particularly the compilers that support the latest C++ standards such as C++11, C++14, C++17, and C++2a (the upcoming C++20 which should be finally published sometime in February). Rather than install gcc/g++ via Brew on my Mac, I’ve been endeavoring to learn how to compile against those standards using Apple’s clang/clang++ compilers.

The unfortunate part for me (at first) was what command line switches needed to be passed to clang to enable the ability to compile a given standard’s code. I was able to determine what those switches were by deliberately mangling a switch in a makefile and then running make. For my troubles I got the following helpful list:

note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standardnote: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standardnote: use 'c++11' for 'ISO C++ 2011 with amendments' standardnote: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standardnote: use 'c++14' for 'ISO C++ 2014 with amendments' standardnote: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standardnote: use 'c++17' for 'ISO C++ 2017 with amendments' standardnote: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standardnote: use 'c++2a' for 'Working draft for ISO C++ 2020' standardnote: use 'gnu++2a' for 'Working draft for ISO C++ 2020 with GNU extensions' standard

For example, to compile against C++17, you would use

clang++ --std=c++17 ...

to enable compilation of source code that uses features from C++17 on back. This keeps the tool clutter down on my Mac, which was getting a bit out of hand with the various GCC compilers via Brew. The GCC tools are all very good, but I would rather use clang since it’s delivered by Apple and is a part of the Xcode tool suite available to every Apple user. As of this point in time the Xcode version is 12.1.2 and clang’s version is 11.0.0. One final note, gcc is linked to clang and g++ is linked to clang++.