Late important updates (unified)
I found, that on my Pi's Debian 12 Bookworm (arm64
), there is just an older g++-12
available. Therefore, I am limited to it. Also, this g++
version utilizes -std=c++17
(and so the c++17
tag change) as the highest working standard (so far unverified, trial & error).
Now, I am compiling directly on my Pi using this:
$ g++-12 -std=c++17 -Wall for_review.cpp && ./a.out
I am sorry, that I could have caused trouble by originally even tagging this question with the c++26
tag, which possibly could have been misleading. I will be more careful in the future.
Original question (shortened)
I did not use C++ for ages, plus I was never much good at it, so please excuse my inexperience. Let me present to you my code running on Linux, reading from a text file, storing value in int
for normal (future) operations, and just for show outputting it also properly rounded in float
with one (optional, really) unicode char
at the end of code.
First, I tested the code on amd64
platform. And then transfered it to Pi. I compiled on Linux Mint 22 without Makefile
using:
$ g++-14 -std=c++26 -Wall for_review.cpp; ./a.out
#include <iostream> #include <iomanip> #include <fstream> int main() { std::string rpi_cpu_temperature_file_name = "/sys/class/thermal/thermal_zone0/temp"; std::ifstream rpi_cpu_temperature_file(rpi_cpu_temperature_file_name); if (!rpi_cpu_temperature_file.is_open()) { std::cerr << "Error while opening file: " << rpi_cpu_temperature_file_name << "\n"; return 1; } // Raspberry CPU temperature value in Celsius degrees, actually an integer in a string; // This would have to be divided by 1000 and rounded to get real value then, e.g. 35.3 std::string rpi_cpu_temperature_raw; if (!getline(rpi_cpu_temperature_file, rpi_cpu_temperature_raw)) { std::cerr << "Error while reading from file: " << rpi_cpu_temperature_file_name << "\n"; rpi_cpu_temperature_file.close(); return 1; } else { rpi_cpu_temperature_file.close(); } // integer representing 2 digits with 3 decimal places, example: 35291 which means 35.3 int rpi_cpu_temperature_int = std::stoi(rpi_cpu_temperature_raw); std::cout << rpi_cpu_temperature_int << "\n"; // Properly rounding output, you may try some direct integer, for example: 35291 = 35.3 std::cout << std::fixed; std::cout << std::setprecision(1); std::cout << rpi_cpu_temperature_int / 1000.0 << " \u00B0" << 'C' << "\n"; return 0; }
-std=gnu++20
, and also-std=gnu++2b
with__cplusplus = 202100L
(so only preliminary support for C++23, with a date that's only 2021). You can play around with newer compilers on Godbolt, including running for x86 or AArch64. But no debugger so it's not useful for more than playing around.\$\endgroup\$arm64
) itself, let me repeat that. The problem is in the accepted answer, where the poster used#include <format>
which, no matter what I tried,g++-12
failed to load. There is very simple work-around, but I merely pointed out, it is available sinceg++-14
sadly. (Maybe even ing++-13
which I do not have installed yet. Have a good day and cheers!\$\endgroup\$-std=gnu++20
(or-std=c++20
), its libstdc++ doesn't have complete C++20 support yet, so indeed#include <format>
isn't available until G++ 13. Normally GCC versions that recognize something likec++20
instead of justc++2a
or1y
or whatever have complete support that that standard, but I was forgetting that might only go for changes to the language itself (like the meaning of keywords, semantics of sequencing, etc.), not necessarily to libraries.\$\endgroup\$